What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.

What's DevOps?

Wikipedia defines DevOps as:

DevOps (a clipped compound of "development" and "operations") is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.

I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.

DevOps came as a response to shortcomings of the traditional way of separating development and operations activities. If we look at Damon Edwards’ article What is DevOps?, we will find a description of the traditional way, the way it worked, and what shortcomings it has. Also Mike Loukides, in one of his articles, does a great job in describing the history of the relationship between development and operations, and why we need DevOps in its modern form. I strongly recommend you read both of these articles.

Key Components of DevOps

From my experience, there are several key components or principles when implemented then we are set for a successful DevOps experience. Those components and principles are:

• Automated Delivery Pipeline
• Configuration Management
• Regular Integration
• Automated Monitoring & Health Checks
• Firefighter Role
• Infrastructure as Code

  When you first look at this list you may say: “We’re already following those principles without doing DevOps”. That might be true but DevOps adds emphasis to the fact that the development team needs to be responsible for defining, understanding and implementing these components. In other words, DevOps encourages developers to dive into aspects of software delivery that Ops would traditionally own. It’s worth mentioning that from a project management point of view, DevOps tasks and stories should be treated the same way we treat those that solve direct business problems like generating a report, or providing a log-in page. That is, DevOps work needs to be well-defined, prioritized, planned, executed and tested just like other user stories or features because the same team of developers will be working on them. Unfortunately, I won’t be able to go into details about this aspect of DevOps management in this post. In the following sections, I will explain a bit what each component is all about.

1. Automated Delivery Pipeline

First, let’s talk about the “pipeline” part of this terminology. We want to create a process that defines what needs to happen in what order from the moment new code is published to source control to the last step of making that code available to customers in production. That is, the pipeline is an ordered list of well-defined and stable steps that start with pushing new code and ends with that code being in production. The second aspect of an Automated Delivery Pipeline is automation. Once our steps or recipe for delivery is defined, we need to script and automate it.

2. Configuration Management

When we deploy the same artifact like a web application WAR file to different environments, how do we ensure that the application in Development environment is only using the Development database and that in Production it’s only using the Production database? Or more generally, how do we ensure that the application is only talking to resources specific to the environment in which it’s running? Configuration management is the answer to this problem. There are two approaches to determining what resources an application should use; we can either determine those resources at run time or at deploy time. Both approaches rely on externalizing those concerns from source code into a configuration file. Hence, it’s called configuration management.

3. Regular Integration

Integration in this context is simply to deploy our application to an environment where it will interact with other applications and components in the ecosystem. Agile software development puts strong emphasis on having a feedback cycle in order to validate the solution we’re implementing is indeed solving customer problems and to also detect issues early on. Having a regular schedule of integrating our application is essential in creating a feedback cycle. When our integration cycle is tighter, so would our feedback cycle.

4. Automated Monitoring & Health Checks

Since DevOps involves operational duties, we want to know about problems before they are reported or noticed by users so we can solve them before they impact our users. We need to develop the ability to periodically and automatically check the health of our application and react appropriately when it’s in a bad state in a timely manner.

5. The Firefighter Role

When the development team takes on the “ops” duties as part of implementing DevOps, it means that the team will have to deal with issues not only related to the business functionality they implemented but also with infrastructure issues, monitoring alerts going off, impaired servers and services, etc. These issues are interruptions to the team’s development activities which can result in reduced velocity and loss of concentration. An approach that I like to employ is to define a Firefighter role and rotate it among the team. All issues that crop up are directed to the Firefighter and she is tasked with resolving the issues.

Dealing with issues that crop up are opportunities to get first-hand experience at how the application actually works in real life and those insights will certainly help the application to evolve and mature.

6. Infrastructure as Code

This could be the most recognizable part of DevOps but I intentionally list it at the end to emphasize that it’s not the only aspect. Over the years, many good practices came out of developing software for business problems that are widely adopted but many of those practices are not employed to infrastructure as commonly. Treating infrastructure as code does not only mean to write code for infrastructure but it also mean to apply the aforementioned best practices to infrastructure code.

Conclusion

All of the previous DevOps components discussed in this post are not to be treated in a “all or nothing” manner. Instead, it’s better to take them one by one. We can pick one to understand, design and implement. Once we are satisfied with its benefits, we can move on to the next one.

This list of components is not intended to be a definitive list but they are what I personally experienced to be most influential. If you have other components or principles you believe should be included, please let me know in the comments section. I’m very interested in hearing from fellow “Dev Operators” about their experience. As a follow-up to this post, I will be publishing a second blog post that will shed more light into the aforementioned components.