It’s not often that my emails turn into full-blown conversations on DevOps. But when it happens, it’s a great time to take advantage of the insights. John Purrier of Automic and I recently discussed DevOps sustainability. Both of us think that sustaining a modern delivery chain and adopting it are two very different things. However, most only consider the latter. And because of that, in two years (or much sooner), they will find themselves in the exact same place they started—in an environment that is unable to adapt, rooted in habit and suddenly the old guy on the block.
From: Chris Riley
To: John Purrier
Subject: Re: That is not DevOps
Hi John,
After we talked yesterday, I realized that “DevOps” in many if not most organizations is not going to be “DevOps” in two years. And the reason why is that after the container dust settles, or infrastructure as code is second nature, the next thing will come. And when it does, those once-DevOps shops will become the old guard, even legacy, because they did not prepare for the next thing. Pure DevOps principles mean you can take what is thrown at you — not that there is a modern delivery chain in place, because that may not last.
What are your thoughts?
From: John Purrier
To: Chris Riley
Subject: Re: That is not DevOps
Chris,
While I agree with the premise, it points out a huge issue in the DevOps discussion today. People are conflating “DevOps” or “modernization” or “agile” with the deployment of tools. These tools, whether they be CI servers, configuration management, container orchestrators, or what have you, are valuable pieces, but do not constitute a sustainable foundation for moving enterprise IT into the future.
The danger is that we are creating new opportunities for vendor lock-in, under the guise of providing toolchain automation.
From: Chris Riley
To: John Purrier
Subject: Re: That is not DevOps
So really the pipeline is as important as the code that moves along it? I’ve found that many organizations think in terms of releases if they are developers, or in terms of servers if they are IT Ops. But they seldom think about the holistic delivery chain. However, this could be the result of people not knowing how to. For example, it is easy to understand setting up continuous integration environments and processes. But are the processes to set up orchestration, management and iterations for an entire delivery chain not so obvious? Are there principles for that?
From: John Purrier
To: Chris Riley
Subject: Re: That is not DevOps
There are definitely a few things I have learned and a few critical questions to be answered when thinking about modernizing application development and delivery around pipelines and orchestration systems.
Adopting DevOps delivery and deployment pipelines and potentially moving applications and data outside of the corporate firewall is a technical challenge, but the larger challenge is cultural. The move to an architected DevOps delivery requires processes and procedures that need to be made integral to the IT and company culture to be successful. The internal evangelism and adoption of cultural change is probably the biggest challenge.
A realistic inventory of existing systems and processes needs to be done, and decisions made as to whether current applications and data systems a) stay where they are and are maintained, b) be moved to cloud architecture and frameworks, perhaps through PaaS or other application tooling, c) be sunsetted and retired, or d) be re-implemented as cloud-native applications. Orchestration automation is a valuable tool in making the existing systems continue to run seamlessly while investing development and operational resources toward the new or re-architected systems.
In working with enterprises on their application journey to adopting DevOps practices, some common patterns for best practices have emerged. Taking significant, but non-business critical applications such as marketing sites, brochure sites, and short-lived campaigns and running these as pilots gives teams a good feel for new DevOps processes and tools. These pilots also allow for simultaneous deployment of DevOps tooling and processes, along with potentially refactored or new applications. Through an iterative cycle of develop/deploy/retrospective learning, organizations find their own rhythm and cadence for pipeline-based delivery and deployments.
After the pilot period, then the processes can be scaled up to rapidly move more applications, moving from non-business critical to mission critical. At this point, it is critical to have a solid DevOps and Operational automation strategy and implementation to ensure repeatable and reliable deployment pipeline processes.
Tying together cloud system management, pipeline orchestration, and automation tooling will increasingly allow multiple data centers and multiple cloud infrastructures to be part of an overall enterprise IT solution. This will allow truly level playing fields amongst the providers, preventing lock-in and giving the enterprises the governance, insight, and control they need to accelerate their business.
From: Chris Riley
To: John Purrier
Subject: Re: That is not DevOps
Wow! You laid out a great approach. And one of the things that stands out to me is the term “evangelism.” Stewardship is critical to keeping any modernization to the delivery chain moving. I’ve seen this done via “Shared Services” departments, or simply individuals who have the autonomy and the voice to carry the DevOps mantra through the entire team.
As we have both seen, moving from DevOps concept to execution is difficult. We have talked about the importance of the holistic delivery chain, culture through stewardship, and actual tactics. Hopefully, sharing this conversation with the masses will help them move the needle from DevOps talk to DevOps reality.