DevOps – The Future of Application Lifecycle Automation / Part 1
Gunnar Menzel, FBCS
Master Architect at Capgemini, BCS Fellow, Architecture, Strategy & Transformation Expert
Build, Release, Run & Repeat – Enterprises are raving about the agile and perfect fusion between IT Development and IT Operations – to 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 – to 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 often seem to be 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: Ensuring that each individual is part of the entire solution lifecycle covering development and operations is one key DevOps concept – 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.
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.
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.
Watch this space for more details in Part 2 ....Thanks for reading.
Principal Architect - Solutions
10 年You've explained the concept and the challenges it faces in adoption very beautifully! DevOps is easier said than done and i think it is also because of how organizations structure themselves and demand service. You've already highlighted how the Dev, Test & Ops teams are measured against different objectives and that definitely is a top reason for the disconnect.
???? Security, Cyber, I/IoT, Open Source; ????
10 年very nice article Gunnar. DevOps isn't a tool but a mindset. As much as as Agile wasn't something you could "buy" as a tool. Same as agile, DevOps needs support from bottom up as well as top down. If only supported by R&D but unknown to mgmt I can't see it's benefits (at least not in bigger companies).
Leadership Advisor at Spencer Stuart; AI Forbes Technology Council; Faculty on Human and Artificial intelligences at Harvard BR, SingularityU, PoliMi GSoM, UniMi; TEDx speaker; ex Microsoft, Capgemini, McKinsey, Ericsson
10 年Hi Gunnar Menzel! quite innovative approach, indeed! Based on my experience, the relationship and interworking between Development, Testing, and Operations is a great challenge in many organizations. Therefore, your proposal may really be of use in many contexts…