sorhanp.github.io
First week of studies as a DevSecOps-developer are behind me. Since I was accepted to my new seat of learning, I really felt that I should use this blog to write about my experiences. In fact it was highly encourage on by the coordinating teacher so start some sort of blog or learning diary. Thus from now on I will be posting these DevSecOps weeklies to summarize what I have gathered to my learning diary during the week. So I will be kind of doing both. My method of writing a learning diary is based on questions stated in this article (Warning: Finnish content). However I have translated them freely so that I can use them here in my blog.
Here is what kind of questions I use for my learning diary and also basis my weeklies on:
- What did you know about the subject already? What was new about you?
- In your opinion, what was the most important thing to understand studying on the subject? Justify the answer.
- How do you think the topic is related to your everyday life?
- How does the topic relate to what you learn in the past?
- Which subject puzzled you?
- Which subject would you like to discuss further?
I will also reflect on these things:
- How have you performed on the subject? What do you think has helped / hindered your studies?
- Have you noticed something about your own learning methods? Would you like to be better at some of your study skills?
Usually I write little more in detail to these blog posts, when the learning diary is more of like a notepad I use to jot down notes on what happened and then scribble down some ideas based on the questions above. The blog is here to flesh out the content even further into presentable sentences. Now that this is out of the way let’s get cracking for this week.
About the studies and orientation week
First week of studies was all about orientation, most of our lecturers introduced themselves and what they are going to teach us. Because of this, not much of the subjects were talked on courses yet, but rather we spent good amount of time getting known each other and crafting our own path on what we would like to learn. That’s right! What is really fascinating on this training, is the fact that each of the students come from very different backgrounds and want to learn different things. Some like to learn to be better programmers while other want to manage programming projects. This coupled with the fact that this training is very short, only eight months, hence it makes sense for each of us to pick and mix what we want to learn, instead of everyone blindly following the same path. Of course there are mandatory parts, such as learning how to use version control, cloud services on modern programming etc. I feel like this is for the best because I can sort of import my self-learning to this school environment to get feedback on what I should learn more.
This “freedom of study” and choosing your own path is even more reinforced with the fact that each of us are given our personal mentor, whom goal is to suggest what kind of things one should learn on the chosen path. My mentor meeting isn’t on this week, but rather next week, so before I can fully plan and implement my path in more detail, I have to wait little longer. Anyway me mentor is the same, who did assessment on my programming skills. So he has understanding of my skills, how I work and what interests me. I’m really looking forward to our first meeting and the cooperation in general.
Part of orientation is also getting known to the campus. We got a grand tour of all the place. I really enjoy visiting the campus since it really feels like a place of learning, there is this “buzz” going on and everyone feels super motivated to learn. Wherever I look I feel that motivation sticking on me, pushing me to learn even more. The location itself is also perfect, because I get my daily walk routines done easily with the distance I cover when walking between my home, day care center (to pick up my son) and campus site. We also got accustomed to how use university’s network and software, how to book a room for a team and such. I have one more thing that I have been getting really close with this whole week and that is the laptop I got to lend for this training. First three days I have been slowly, bit by bit, setting it up and now I feel that is perfect platform to write these blog posts, do programming and document the events unfolding before me, so that I can write good learning diaries each day. Unable to pass this training with flying colors can’t be blamed on the tools, that is for sure.
Known knowns and unknowns unknowns
So other than orientation and setting up good old Ubuntu , well this time Mate version, what else has been happening? Before moving from the orientation I will have to address this one thing I have not heard of before, which I think was rather fun and was good for breaking the ice. Marshmallow Challenge was the name of the exercise and our team won with this “design”, since other teams marshmallows were not properly placed when the time limit was hit:
I will gladly do that everytime I have a meetup with people I do not know and I need to start working as a team, since it really made me partake in a conversation with people I haven’t really interacted with. I learned new thing about myself, which is something what I share with the coordinating teacher. We both like to see if what roles other team members take and then adapt our own role to that, and yeah I definitely feel like that most of the time, because I want everyone around me to feel comfortable in their own, most suitable, roles so that they are more open and passionate, which can then affect my performance for the better.
Anyway, back to the professional unknowns. We had two lessons were we draw a mindmap using collaboration tool known as Mindmeister. First map was the roles of a software team, which made me think about what I really wanted to do when I’m ready to hit up the job market. For now I have been really been focusing on back-end of things, like creating logic for programs rather than designing user interfaces and such. I’m not very visual or visually creative person so I see myself rather in position of back-end developer rather than front-end. However the lecturer also asked what is my dream job in the industry and I have been also thinking about position as a full stack developer since it also has management and business aspect to it, which I’m familiar thanks to my background. This is something I will have to talk about with the mentor next week.
Second mind map was about what all of us student expect from this training. There were many branches about programming languages, databases, UML etc. I think I can handle and learn those by reading about them and of course, simply doing them as much as possible, which I have been doing. Then I stumbled upon this article about what every programmer must know. These parts especially caught my interest:
Divide and conquer: break down your problem into smaller, easy to manage bites. You learned that many different problems have similar or related solutions just like certain algorithms and data structures will have similar properties.
And also this snippet:
The first thing you should do is scope out the requirements of the project. What exactly am I trying to accomplish and what should the end result to be like?
Thus I ended up writing “How to think like a programmer?” and couple of branches to that such as organised and splitting up the tasks in smaller pieces. We discussed this a bit and at that moment there was no definitive answer on how to do this, so I decided to dig up something where I could learn more. This is something that I feel like I would have brush up on and sometimes I feel rather dumbfounded when I’m given a task to solve with programming. Luckily I found out there is a book for this also called Think Like a Programmer: An Introduction to Creative Problem Solving, what is even better, is the fact that it is written using C++ as an example. Well I’m always eager to get into anything related to my favourite language, but what really drove me to get this book was the fact that it was available at this Book bundle. Looks like all the stars were aligned for me to start perform better as a programmer! Again I will my experiences with this book to this blog. I have read the introduction and I’m really looking forward to study more.
Soft skills
On thursday we had a very special guests from Discovery Street Oy, which is a local company that operates near the campus. Their main goal is to help leading and improving software development of companies in Jyväskylä. I really enjoyed the way the these fellows took the situation and instead of talking randomly going from here to there with discussions, they asked us, the audience, what they wanted to hear and build the event to suit our needs. There were alot of talks about soft skills, such as how to perform in the interview situation, what the interviewer wants to hear etc. It felt really nice to hear that these professionals had same kind of views as I do, since I have done interviews on my career. I also even got to share my own experiences and got good feedback on them. This made me again interested more on the management aspect again. Such as how to be good supervisor who really cares about what happens in the workplace. I believe that these soft skills will be more and more important in the future and many people agree.
Discussion was also on networking with the right people either by Meetup, trade show or events such as this where people who know employers, since there is always possibility of that right match happening and a win-win situation is achieved. One party finds a job and another gets perfect candidate to their workplace. Speaking about workplace I also enjoyed the fact that there was a lot of talk about diversity on a workplace, meaning that every team should consist many types of people to get many types of contributions to team. Making me believe in my current set of skills and the fact that there is need for people who have embraced different career paths and are willing to bring new views and ideas to the table in a workplace.
DevOps with security
The last lecture of this week was a introduction to the DevOps and continuous delivery pipeline with continuous integration and continuous delivery and/or continuous deployment. Also known as CI/CD. We talked about concepts and processes of DevOps and environments, such as running Software as a Service(SaaS) on a Infrastructure as a Service(IaaS). The lecture itself was really barebones, but really sparked my interest to start building my own pipeline, so I took look at couple of links provided on the material. One of them was this Finnish article about tools for successful DevOps by Jari Pääkkö, which I took a closer look and decided to write down what I feel about the subject.
First of all, this is really unknown territory to me. I learned bit of software development with waterfall model about ten years ago, but it was neither agile or modern, even by that time. I know that DevOps is not software development model, but it is one important part of models such as Agile. Thus I’m really going to this with open mind and eagerness to learn, since I believe that this will also make me think think like a programmer, thus linking with what I started learning from the book I got. Understanding bigger picture of things has always been more eye opening for me, instead of just simply focusing only on one area. But I digress, what is DevOps and what it used for? It is an ideology, which aims to automate software development, thus making it much faster and of course more agile. The intention is to have clear communication channel between software developers(Dev) and system specialists(Operations, thus Ops) making them work together as a team, rather than singular units, who only focus on their own interests. Learning this makes a lot of sense, since I believe to being successful is all about working together as a team for common goal, capitalizing strengths of all the parties involved. To support cooperation and automation there are bunch of tools, also known as DevOps-tools.
I liked how Jari Pääkkö sums up that DevOps doesn’t automatically happen if the tools are in place and vice versa. Software development can have DevOps without the tools if the cooperation between development and operations is present. The fact is that CI and CD tools have been used long before DevOps, as a terminology, was a thing. This also applies to DevSecOps, meaning that there has been (Sec)urity aspect to DevOps for long time, but lately industry has noticed that cybersecurity plays more and more important role in software development. Anyway back to the tools of the trade, since they are the main focus here. First up is the CI/CD, which was also the topic of the lecture. These tools are used for automatic testing, compiling and deployment of source code. A working program can be deployed several times a day, making the feedback of the output instant, thus fixes for errors and changes to program can be implemented much faster. Comparing this to waterfall model, where the feedback is only got after the whole program is deployed the change is massive. The agile point of view is ever present with these tools and I’m very on board with this mentality, since it is something that I do manually myself when I code, meaning that after couple of lines I test what the program does and doesn’t do and if there is room for improvement. With CI/CD tools, this flexibility is possible in larger scale projects.
Rest of the tools are presented under their headers and on final header I will make a summary of the advantages these tools bring to the cooperation between development and operations.
Virtualization, Cloud services, Containers and their Orchestration
In DevOps the use case is usually hardware virtualization. It enables running multiple instances of same virtual machine on a single physical machine. This same idea can be flipped on it’s head and multiple physical machines can be virtualized to appear as a single virtual machine. Virtualization is very simple concept, and easiest to understand by everyday example of using virtual machine to run another operating system on top of another operating system, kinda like what I have done with my programming setup, described here.
Since Cloud services are based around virtualization, they allow creation of very sophisticated server environments. Cloud service providers grant access to wide selection of tools for setting up desired environments very easily. This coupled with the fact that virtualized environment are very scalable depending on the level of utilization.
But what does Containers have to with Virtualization? Well as described on the everyday example, when virtualizing usually there is another operating system, another software and even the software dependencies that need to me met in order for the virtual machine to work. Containers are here to prevent that excess bloat and removing the operating system out of the equation and leaving only the software and it dependencies to be virtualized. Containers are smaller, easier to move and much more powerful than running full operating system with all the unnecessary software. The lecturer put it the best: “If there is no need for email service on virtual machine, don’t install it. It is one less security hole to worry about”. As can be seen DevOps has elements of DevSecOps, since it takes care of security issues with these tools, even if it is not mentioned in the title itself.
Lastly Orchestration of containers, which is used for automatic placement of containers between multiple virtual servers and handling of communication between them. Orchestration tools provide way to define which servers are used and which containers are able to communicate with each other. It is also possible define how to load is distributed among the containers and what kind of error handling, in cases of container malfunctions, is used. Cloud services may also provide these kind of features.
Software configuration management(SCM), Provisioning and Logging.
SCM is used for controlling and tracking changes in the software and the underlying infrastructure, while provisioning is used for installation, configuration, deployment and management of necessary resources, such as softwares and data, to a server. Both of these concepts go hand in hand and again, like many of the other features of DevOps, these are automated as intensive as possible. Both of these tools aim is to unify the infrastructure amongst all the hardware configurations that enterprise might have. When all the hardware is deployed with equivalent software versions and configurations, possible conflicts between version differences disappear.
While SCM and provisioning are used for homogenize software, logging tools in DevOps means to do that same for all the logs each piece of software provide. Every piece of log history is centralized so that they are available, searchable and especially visualized in easy to understand form. Again all this is done automatically and collected from dispersed group of software without needing to access and manually collect it from multiple places. Again providing valuable feedback instantly. I understand the need for this kind of automation in logging. It would have been very useful in my past working history, since many of the data I needed to present for my subordinates were scattered in multiple places and all the time used for gathering and visualizing this data was away from the real supervisor work, not to mention how it was difficult to provide the most current feedback. Long story short, it is difficult to lead with data, if the data is missing or scattered.
Tools for interaction
To recap DevOps doesn’t automatically happen if the tools are in place, they need to be utilized in order for implementation of DevOps-ideology to be completed. Jari Pääkkö finishes his article by stating that ideology requires humans interacting with fellow humans by cooperation, open mindedness and communication. I have collected in to following chart what each of the tools provide to interaction between (Dev)elopment and (Op)eration(s) = DevOps.
| Tool | Interaction |
|---|---|
| CI/CD | Constant feedback and ability to react faster to errors and modifications |
| Virtualization | Provides common development and operation environments |
| Containers | Same as above |
| Cloud services | Makes working more agile, since server environments can be modified transparently, so that each the parties involved get closer to each other |
| SCM | Since environment are equal, conflict between parties are reduced. Operations can administrate infrastructure using development tools and conventions, while development can use SCM- and provision-tools for creating production environment automatically |
| Provisioning | Same as above |
| Orchestration | Makes installation of information systems and performing changes to production environment much faster. Development has easier time to participate in information system maintenance |
| Logging | Provides layer of transparency, making mutual managerial decisions easier, which is one of the cornerstones of DevOps-ideology |
There are tons of other benefits and most of these provide cross-utilities between each other making DevOps very efficient tool for open communication between the parties. In my opinion this is very pleasant to hear, since I have heard alot of “horror” stories about development of large scale applications with waterfall model that do not provide all the necessary features that the customer needs and even making their business unstable. All of which could be avoided if the parties involved would have interacted with each other better. Waterfall also has high amounts of risk and uncertainty for the developers business, thus using Agile way of developing is much more safer for customer and own business.
Next up I’m going to start following this guide, and find out how I can start building my own DevOps-tools, but that is for the next blog post.
-sorhanp