I often hear people telling me they are moving quickly to DevOps and that they are automating their testing and deployment environments. Unfortunately six or nine months later they are disappointed. They have not gotten the benefits they expected. Why is that? Well, DevOps is not just about automation. It involves a fundamental change in the way applications are developed and organizations are running. Let me give you some more insight.
You do not start the DevOps journey by implementing automated testing or deployment to all your applications. Yes that may give you some benefits, but the benefits are related to automating the same old approaches, which only gets you that far. It’s more important to take a hard look at your current application development approaches and transform them, using automation as a vehicle to implement the new.
DevOps is not for everything.
The first realization is that DevOps is not for everything. If you have applications you need to update every other year, does the effort and time it takes to automate the testing and deployment weights out against the increase in speed you will have when you use them. Frankly, I doubt it. So those very stable applications should be left alone.
What you may want to do over time though is to look at the middelware and databases you use for these applications. If you standardize their deployments for other applications, it may make sense to do it here too. That part could then be automated, but don’t automate the full deployment. The benefits will not so much come from the gain in time, but rather from the reduction in operations costs coming from the standardization of the deployment of these components.
The DevOps dream, deploy in minutes.
The DevOps nirvana is all about being able to push new features and corrections in a matter of minutes. In the mind of many CIOs this will be needed to address the requests from the business. No more costly release processes, but “immediate” deployments.
This is a great vision to have. However, getting to a vision takes time. Many elements need to converge to achieve such vision. Let’s list the main ones here:
- Your applications need to consist of independent components so that one component can be re-installed without having to deploy the whole application again. This leads to SOA and micro-services. Without having to go as far as making your applications cloud native, it is important to ensure they are developed in such a way each component can be deployed separately. This implies for example that other components can handle the temporary absence of one of them. They become resilient. But that has to be built into the application architecture. Can your developers transform your existing applications so they are capable of operating in this way?
- Your development team and your operations people need to collaborate as the application needs to be deployed in such a way it can be operated easily. In many companies, having development work closely with operations is not usual. Automation will not add any value in this part of the process, it’s all about teams having to understand how the others work and what is important for them. Standardization is often a benefit here as it facilitates operations. But standardization requires discipline from a development point of view. So all in all, it’s about give and take.
- As already mentioned a couple times, standardization at all levels is required. Standardizing the tools used, the environments to which deployments take place, the deployment of middelware and database components, etc. are required. Beyond that, the standardization of the deployment process itself is critical. Things need to be standardized to be automated.
- Getting teams working together is of the essence. However, many companies struggle with the transformation of their application life cycle to gain the agility they require. Some initiate agile development approaches, and that works well for projects with close involvement of the business. It’s however when end-to-end testing gets in the picture that things become complex. Most of our applications are not stand-alone, they integrate with a set of other applications. And if you have luck, each of these applications is evolving at its own speed. But it is important that, in production, all of them work seamlessly together. This requires not just testing, but also extensive communication between the development and testing teams to ensure the interfaces remain in synch.
Moving away from the lengthy and costly release cycles is a dream for many companies. Being able to just release the functionality you change simplifies the task while increasing the level of agility drastically. That is seen as a great benefit. But implementing automation is not enough unfortunately.
Agile and DevOps industrialize the application life cycle and move away from craftsmanship. It’s sensitizing the organization to that “production line” thinking that takes time. So, deciding one day to put automation in place and hope to get all DevOps benefits will unfortunately not work. DevOps is a great vision, but it requires time and effort to implement.
Take one step at the time
Changing the behavior of a complete IT department in one step is unfortunately not feasible. It also does not make sense. You do not need to become agile and enable DevOps for all your applications. Frankly if you change them less than once or twice a year it is not worth the investment. So, start small, choose one development team. Take one that is looking for change and is interested in trying some new things out. Have them trained properly so they understand what they are getting into. Give them the time to organize their work. Have them work together, ideally in the same room. Give them the opportunity to experiment. Monitor their achievements closely and make them extremely visible. Celebrate their success.
They will be your ambassadors, they will give others the will to change. They will also train others in the new approach. It’s only when the teams grow and the new approach spread that looking at the actual tooling to be used, the processes and procedures become important. Use the learnings from the initial teams, have them participate in the definition of processes and tools. Not only will they give you ideas that are applicable in your enterprise, they will also feel recognized by your request.
This is plain vanilla management of change. I’m not inventing anything here. I’m just applying the concepts to DevOps, where many of us only think about tools and automation.
If you want to get the benefits of DevOps, you will need to work on the people and the organization, or you will not get the benefits you can expect. Keep that in mind when evolving on your DevOps journey.