February 16, 2016 | Written by: Darrell Schrag and Juergen Schneider
Share this post:
It is fair to say that development and operations have different tasks in their list of responsibilities. But there is an intersection of tasks between the two, provisioning and deployment. Both groups have a stake in successful provisioning and deployment of application environments. Unfortunately, they create their own tools and processes to accomplish the “common” functions of provisioning and deployment.
Meet in the middle
We need to eliminate the “translation” required between development and operations. A common language is needed to break this separation.
1. A declarative language removes the need to interpret provisioning and deployment instructions.
2. A declarative language forces a consolidation of options and variants into “good enough” patterns with more predictable operational results. Deviating from accepted patterns would require a good reason.
3. A declarative language promotes automation. After all, DevOps strives to remove much of the human element and human error from its day-to-day processes.
4. A declarative language can be treated just like code. You keep these artifacts in a code management system and you manage changes through a change management system. Developers get these concepts and it would be a natural transition.
Where are we today with a declarative language?
The OpenStack Heat project is on its way to realize this capability. More capabilities are being included in Heat to provide deployment as part of the provisioning process. Now that we have a common language, operation and development can talk to each other and are ready to become one team.
Cloud as a DevOps enabler
Automating provisioning and deployment is key to achieving cost and time savings while increasing quality. In today’s cloud computing environment, the cloud provider supplies this automation and the developer consumes PaaS or IaaS services. A move to cloud brings with it the automation and years of experience cloud providers have in provisioning automation.
Why is this concept not applicable in the traditional or private enterprise cloud world? It should and it will. Cloud is not just an enabler of DevOps, cloud originated it. Cloud providers have gone out of their way to make it easy to use their services. A move to cloud brings with it the automation and years of experience cloud providers have in provisioning automation.
It’s about people
To capitalize on the common language that brings the development and operations teams together, enterprises must create a single team that shares responsibility of enterprise applications. Having a single team includes a common set of objectives and success criteria.
While roles of an operator and a developer still exist, it becomes a team efficiency question of who does what to achieve the goal of having the right application running in a robust, resilient and cost efficient IT infrastructure. Furthermore, being one team structures the line-of-business (LoB) demands for both the IT application and the IT infrastructure. Getting all stakeholders onboard the same team will help avoid conflicting expectations.
Would this all require a potentially significant organization change? Yes, and is that easy? No. Is it valuable to do? Sure. No tool or common language alone is sufficient to gain the true benefit of DevOps and continuous delivery. At the end there are business drivers and expected business results for each enterprise application.
It takes strong IT and business leaders to transform an enterprise. If you haven’t yet, read the book The Phoenix Project to enjoy an example of such a transformation. A transformation which started with many unplanned and unnecessary outages and ended with almost 10 deploys per day.