DevOps: The Future of Application Lifecycle Automation / Part 1


Gunnar Menzel

December 15, 2014

Build, Release, Run & Repeat. Enterprises are raving about the agile and perfect fusion between IT Development and IT Operations. The fusion would revolutionize the transition, de-risk IT deployments, eliminate the excuse “but-it-works-on-my-system”, and break the silos between developers, testers, release managers, and system operators.

The Development to Operations (DevOps) promise is Big. It would significantly reduce the outages in live caused by changes introduced; according to estimates, 80% of the outages are due to application changes and/ or new application developments.

But there is a problem. IT vendors have been very quick in providing new products and services under the label “DevOps inside”. However, with the growth in product choices, conflicting definitions and competing services, customers often encounter confusion, while making complex purchase decisions, they are often unsure about how to deploy DevOps and get the most out of the solution.

DevOps is not just a tool set. DevOps includes tools, process and people aspects, with ‘people’ being the critical element of the equation.

DevOps’s main aim is to maximise automation, increased visibility, and tighter control of the pre-production and non-production environments and deployment/promotion of code through diverse environments. It also tries to reduce the “wall of confusion” between development and operations personnel by harmonizing the development and operations tools (allowing feedback from operations to development) as well as re-aligning objectives and incentives.

DevOps People Aspect

To ensure that each individual is part of the entire solution lifecycle, one key DevOps concept is to cover development and operations in order to break the ‘wall of confusion’. Its main aim is to create an appraisal methodology that can jointly measure and reward performance. All key parties that are involved in the “from-development-to-operations-service” supply chain must share same/similar objectives and targets and each person’s performance must be assessed against their impact within the context of the entire solution lifecycle. Individuals should be assessed according to the overall change development and deployment as well as the resulting process stability. Thus both the work groups should be measured using a supply-chain rather than a siloed approach.
Wall of Confusion

DevOps Process

The entire development-to-operations lifecycle must be seen and operated as one coherent end-to-end process, rather than numerous multiple and diverse steps. Individual methodologies can be applied for individual steps – such as agile or waterfall – so long these can be connected together to form one end-to-end process.
End 2 End Process

DevOps Tooling

This is a prime aspect that garners a lot of attention. A single tool or a combination of tools that allows for a simple or fully automatic deployment. It should be able to create, operate, and destroy any type of pre-production or non-production environments and should include infrastructure related as well as middleware and application related components.

The aim should be to accelerate the transition through environments in an efficient and cost-effective manner. The result would be more testing in an early testing phase leading to higher quality. A number of IaaS tools as well as middleware and applications based process tools are available today.

While Docker, Puppet, Chef, and ControlTier are examples of existing tools, VMWare Codestream is a new entrant. Traditional enterprise vendors provide a host of toolsets. For instance, Microsoft offers Team Foundation Server/Visual Studio Online along with Microsoft System Centre and Azure. They sync with tools like Docker and Chef and also integrate with social media through UserVoice, Azuqua, etc.

And finally

DevOps is an old technology understood and discussed by a relatively small number of professionals. With the advent of new technologies and growing demand for faster processes and better quality, DevOps has acquired new dimensions. Organizations across the globe have been implementing a full or partial DevOps solution. However, the road to DevOps is not straight. DevOps is a complex concept with no clear definition or list of products. It lacks a common vocabulary and capabilities required for DevOps implementation differ from one environment to the other.

Follow Part 2 to follow the topic of DevOps more closely.

This blog post is the personal view of the author and do not express the views or opinions of Capgemini.  

Great ! Thanks for your subscription !

You will soon receive the first Content Loop Newsletter