The Hello World
First, I want to introduce myself to everyone: “Hello” to everyone around the world, or at least to those reading this. My name is Aki Mäkinen, and I am a software developer, devops philosopher, and a professional rubber duck. I am a sailor in the seas of software development, on a journey to unknown shores while surviving the storms and avoiding the shoals, always ready to help a fellow seafarer.
The Journey
My journey with devops started five years ago in my first project. Back then, I was a front-end developer in the project, and we had a dedicated “devops guy” taking care of doing the infrastructure as code and handling the deployments. It was also the first time I heard of devops. Initially I did not wonder what it was all about, or rather, I was happy with the fact that it was about automation and deployment (at least). The project continued and I slowly moved closer to the back-end part of the software. I worked on the API, started doing debugging and scripts to help me with it. Before even realizing it, I was working on the CI/CD pipelines and the infrastructure with Ansible. “So, now I am doing devops, right?” I was thinking.
Charlie Day of It’s Always Sunny In Philadelphia
Time progressed (alas, still no time travel) and so did the project. Then we started talking about features such as doing semantically versioned released of our software components and improving the monitoring and logging of the system. By itself this is not much to mention about, but it was mentioned to be part of the devops work. While this was not the first time I wondered where to draw the line with the concept of devops, it did cause me to further question my, at that time, current understanding of what it contains and where the responsibilities end. This did not help me understand the phenomenon any better and I could not elucidate a better explanation from it than “it is what brings together dev and ops”. I was left puzzled. Often on downtime, and especially in the shower, I was putting the pieces together trying to find the thread connecting all the little nuggets of information.
I moved on to the next project, my role in it being the “devops guy” together with one other team member. Our initial goals were to reduce the build time and the update time after each software change. Later as the team grew, we did other improvements to the software such as UI lazy loading, ahead of time compiling, near zero downtime UI updates, tooling, and so on. All this required that we understood the codebase at least on some level. All of these I added to my “devops philosophizing” and continued thinking.
The Gradual Enlightenment
After thinking long and hard, I saw the first ray of light from the horizon. No, I did not spend all night thinking and wondering devops, rather, it was the light of realization: it is not about tools, or a concrete methodology but a way of thinking, a philosophy. This was the reason I could not draw lines around what it is and what it is not, it was too broad to limit strictly. Based on the observations and some additional thinking, I designed my first version of the definition:
“DevOps is a way of thinking and a way to approach a software project, aiming to optimize the development pipeline and shorten the feedback loops.”
By Douglas O’Brien from Canada – IMGP2543, CC BY-SA 2.0,
https://commons.wikimedia.org/w/index.php?curid=41150509
This definition did not limit what methodologies one should use or whether some technology is or is not devops: if something counts towards the goals set in the definition, it is devops. Finally, I could move forward and start doing work based on that definition. My further work considered the role of developer experience, usability and quality of the tools, failures as a way of learning and so on.
The next step towards further enlightenment came in the form of a request to write material on devops. I happily accepted the challenge, but I needed further support and sources to quote. Once, when I was thinking this out aloud with a great colleague of mine, he told me about Google’s state of devops report: Accelerate: State of DevOps 2019 by DevOps Research and Assessment (DORA) / Google Cloud. I read through the report and was amazed. the report took into account both the technical and non-technical sides of software development, including human factors such as psychological safety and, through several factors, work recovery and risk of burnout. From the report, another source was also found: The Effective Devops. These two sources soon formed the basis of my devops research that continues today.
The Problem
My journey describes the problem perfectly. The model of devops is not often taught, but instead learned and pieced together from observations and pieces of information, with the blanks filled in by common sense. A model born though this kind of process is known as a folk model, and in this case the result is a folk model of devops, an incomplete and at worst a partially wrong picture of the phenomenon. The result is that the model may lead to wrong conclusions and bad decisions, and at best, inefficiency in putting the concept into use from the point of view of the actual model. Based on the observations from different projects, this is a common phenomenon with devops and makes related communication much more difficult. Usually people use it as a term to refer to CI/CD, automation, testing etc., and in this sense, I agree that it has become a buzzword. However, behind the buzzword is an actual and very useful phenomenon that needs to be brought up much more.
The Answer
So, what is devops? This is an incredibly complex question and impossible to answer in a single blog post. Rather than attempting to do that, I will concentrate on the definition, building on top of that in later posts.
While researching the subject, I have seen several attempts to define it. Some people see it as a software development process and visualize it as an infinity symbol with different phases written on it, but the problem is that it leaves the human mostly outside, as well as tooling. One could also argue that it is an extension of agile software development. While agile methodologies are important and are almost always de facto tools in the devops transformation, they are not strictly required to be able to bring the culture and other aspects of devops into an organization. To include communication, information sharing, organizational culture, national culture, technical aspects and the role of the person in the process and the organization, the definition needs to be vague enough to allow variation in the means but still define what it is about and the goals. Building on top of the definition by Google Cloud and using the aforementioned sources to define the goals, my definition is:
“DevOps is an anthropocentric organizational and cultural movement, and a philosophy with a goal of improving organizational and SDO (software delivery and operations) performance, productivity and the quality of the service.”
This definition takes into consideration that devops is a cultural movement and the means to achieve the goals may vary greatly depending on factors such as the national culture, team structures, maturity of the organization and the domain. The details behind the definition will be addressed in later blog posts, as for now the goals are more important to know.
The Summary
In this short blog post I have shared my journey to devops enlightenment, and through my experience as an example, described the problem: the birth of folk models and the spread of these models. To fix the situation, more detailed and deeper information on devops must be spread and taught to everyone working in the field of software development. Now that the goals have been set, we are ready to go deeper and start looking into the specifics.
Now, one could ask how do I know this definition is the best and only correct one? The answer is that it is so far the least incomplete and inaccurate definition encompassing most of the true nature of devops succinctly. While knowledge on devops deepens and time goes on, I believe that it can be improved upon and made more precise to envelop the true nature of devops even better. For now, however, I consider it to be accurate enough to communicate the basic goals and idea.
I hope that this post has given my readers something to think and helped with their own devops journey. In the next posts I shall be taking a closer look into the fundamentals of devops, tooling, and methodologies. Stay tuned for the next post and stay safe!
The Sources
Accelerate: State of DevOps 2019, Google Cloud / DevOps Research And Assessment, available at https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
Effetive DevOps, Jennifer Davis and Ryn Daniels, published by O’Reilly, available at https://azure.microsoft.com/en-us/resources/effective-devops/
Human factors and folk models, Sidney Dekker and Erik Hollnagel, available at https://sidneydekker.com/wp-content/uploads/sites/899/2013/01/Folk-Models.pdf
