A Matter of Taste
DevOps is a philosophy for managing software products and services. It is not a checklist for development and deployment. Like food, DevOps is based on a combination of physical and cultural elements. If you compare DevOps to cooking, DevOps is not a recipe to follow, it is a collection of ingredients and cookbooks that make up a cuisine. Every organization that uses DevOps is preparing a meal to satisfy their appetite and fulfill their nutritional needs. If you look at an array of prepared meals, you are likely to see some dishes that appear on multiple tables, and nearly everything will use some of the same staple ingredients. However, each meal will be distinct because the dietary needs of one organization are unlikely to be identical to that of another.
Far too often when I read an article about DevOps, I feel that the author is making rigid assertions about a malleable discipline. Such assertions miss the point because they operate from the point of view that there is only one “right way” to do DevOps. In practice, flexibility in choosing the tools and processes that make up a solution is key to its effectiveness. If DevOps was formulaic, then one book would be sufficient to define the formula; there wouldn’t be worldwide conferences devoted to sharing the successes and failures that resulted from the different ideas that people have tried.
Cultural Aspects of DevOps
Appropriately, many discussions of DevOps address the importance of collaboration as a key theme. Certainly, the cultural aspects of creating high quality software are significant. In a traditional environment, developers produce software and then “throw it over the wall” to be managed by an operations team. It’s not unusual to find each team feeling disdain towards the other. With DevOps, the responsibility for maintaining a running product is shared. Developers get involved managing their own code deployments while operations staff focuses on designing the processes and toolchain that empowers the developers. Each member of the team must be attentive to the needs of the others and they must all share a goal of delivering a stable product. A spirit of collaboration helps team members appreciate each other’s roles which in turn promotes engagement and mutual trust to achieve their goals.
As the cultural aspects start to firm up and a plan starts developing, a DevOps team will be able to identify the requirements that apply to their environment. This is the point at which rigidity starts to make sense. Looking across many organizations, there is an “Infinite Diversity in Infinite Combinations” (IDIC) perspective that applies to the implementation of a DevOps solution, but for a given organization there should be a common solution that everybody uses. The technical components of a DevOps solution need to perform in a reliable and repeatable way so that the output of a DevOps pipeline is predictable. This is where the notion of “Infrastructure as Code” comes into play, to help ensure that predictability.
However, stability doesn’t mean that the environment is immutable. DevOps pipelines and processes change over time. Every effective DevOps environment I’ve ever encountered was a result of using an engineering design process. It starts by recognizing problems in software development, thinking about ways it can be better, establishing the requirements for the changed environment and implementing the changes to make things better. This is an iterative process applied to approach an optimal result. Each increment of the environment provides predictable facets of functionality, but they are only steps along an evolutionary path approaching that optimal result.
When DevOps is treated as a checklist for software development and deployment, key aspects of the discipline are overlooked. Even though building an effective DevOps environment requires sound engineering design process and an understanding of technology, the aspects of flexibility in the design are derived from the presence of strong collaborative culture.
If you an interested in creating or improving your DevOps environment, or if you just have some interesting experiences to share, please feel free to leave a comment below or contact us.