DevOps: Peeling the onion
“DevOps means caring about your job enough to want to learn all the parts and not just your little world. Developers need to understand infrastructure. Operations people need to understand code. People need to work with each other and not just occupy space next to each other.”
— John E. Vincent (censored)
DevOps, is an ideology on collaboration between Development and Operations. A collaboration with true interest in each other’s goals, activities and a collaboration on how to most effectively achieve business goals.
DevOps is a continuation of Agile. Within the principles of the Agile manifesto you’ll find the customer experience (CX) ranked number 1. Agile stands for the continuous delivery of a working product on short intervals adding business value for the customer. With DevOps, the collaboration between Business and Development gets extended by adding the collaboration with Operations. Operations gets embedded within the development from the beginning. Working together towards joint goals.
By drawing an analogy with an onion and its different layers let’s look at Agile (DevOps being an extension of Agile). Process and tools being the least powerful but very visible and mindset being extremely powerful and at the core for success. An investment in values and mindset is important to successfully embrace DevOps. The will to put the customer 1st, delivering quality, working together as a team, continuously delivering working products and being flexible regarding changing demands are important characteristics of a person who wishes to work according to the DevOps ideology.
Within the more visible layers of the onion we find the principles. Two important principles of DevOps are continuous integration and continuous delivery. Through continuous integration (CI) and continuous delivery (CD) we meet the business by offering a very short time-to-market for new features and functions. This is done by using fully automated processes to bring new features to the business from the writing of code to putting it into production. Within the framework all changes are tested automatically. By keeping changes small, testing is straightforward and less prone to faults.
Microservices and container technology are instruments Development (Dev) and Operations (Ops) colleagues may use to support their DevOps. Development in microservices brings scalability and availability to your applications by splitting the application in smaller pieces. Containerisation supports this process by keeping every microservice within its own container delivering the possibility to scale each microservice individually providing performance and availability where needed.
Furthermore, splitting applications in microservices and putting them in containers lowers risk. Changes can be applied to a small part of the application (just the microservice) without touching the other components. Because components are smaller, less time is needed to test changes and releasing can be done more often. Of course, this is done through the fully automated CI/CD process described earlier.
Containerisation is a practical way to support you DevOps efforts. Some pros for operations: Containers start very fast, containers have a small footprint and require minimal performance because there’s no overhead. Because of this a container (small system) can be started almost as fast as a regular process or application.
Reorganising to DevOps means, as we saw, a people and process change. It’s at the start of the journey. The right culture and thus way of working gives you the opportunity to effectively use the latest technology.
Embracing the DevOps ideology and instruments like microservices and containers can take place by executing a part of an existing project or a new project through this “new way of working”. The next step is that this way of working is used more often, old applications get redesigned, rebuild or phased out and the new way gets more and more embraced with the goal of implementing a process of continuous improvement with in mind creating the ultimate customer experience.
Still reading? The term DevOps seems to imply that it’s just about Dev and Ops but as mentioned earlier it’s all about people, process and technology which is definitely not specific to these groups of people.
What if we would adapt this mindset, processes and even technology to for example our sales force or other departments? What would happen if account teams would also adapt a more agile way of working and use modern techniques and technologies to accelerate and improve collaboration?
Where would you think your organisation could benefit from implementing a “DevOps” way of working? Please leave your ideas in the comments below or send me a message.
