Introduction to DevOps and why it can fail

Many news media reports about Devops cite a failure rate of 70%, or in some cases, a similar level of dissatisfaction that Devops has actually improved the development, deployment and operational management, of software and applications.  These statistics are however, misleading.  Devops is not a product, a brand, or even a certified method.  It is a philosophy of how to create code and build software applications.  It is thus elastic, mutable and prone to misuse and misunderstanding.  Quite often, Devops is simply not understood that well by firms who are supposedly engaged in Devops, and neither is it managed properly.

So what is Devops?

At its core as a philosophy, Devops is trying to achieve the following:

1. Improvement of software quality
2. Deploying metrics to measure quality, functionality and usability
3. Ensuring that Production remains ‘static’, meaning you will not touch production until all code is tested and pass. Everything flows through development.
4. Reducing time to deploy new functionality
5. Eradicating the silos of the development lifecycle namely, development, QA, deployment and operations
6. Stopping the deployment of new versions over a weekend and moving into a continuous delivery cycle measured in days or weeks [or in the case of Netflix and Amazon, hours]
7. Responding more quickly to business requirements and introduce a ‘fast failure’ development culture which feeds into learning and building quality into software development.

These 7 points are the essential aspects of the DevOps philosophy.  The goal of DevOps is to remove the inefficiencies that exist throughout the development, deployment, and operations pipeline, while promoting higher quality of operational code. Some of the traditional ways of developing, deploying, and operating don’t hold up to the constant change that modern software systems undergo.

If we accept these main tenets, then a major aspect of the Devops philosophy is culture in particular, developing a team approach to building software, which breaks down the silos between development, testing, deployment and management.  It is a compression of the lifecycle of software development, with a culture of team based delivery and management, of smaller pieces of functionality, constantly and consistently; as opposed to longer cycles of more complex coding and deployment.

A collaborative culture is empowered through the automation of the key aspects of building software.  Along with this automation, we also employ metrics to measure quality, successful deployments and to learn from failure.  Devops has 3 main areas which form both the collaborative team, and the use of automation.

1 ) A simple example of Continuous Integration or CI:

Imagine I am deploying an application written in Python used by the sales team.

• I can use Jenkins to set up a code pipeline for a specific application I am building in Python
• I install my code, with dependencies in pip, a Python package manager, and then it runs all of the tests.
• If the code is good and ‘passed’ Jenkins will create an ‘artifact’. An artifact is your code compiled into one location.
• Imagine that I now add a simple coding change, which adds a function that returns a string. I make this change and commit it with Git and push it to GitHub.
• Jenkins picks up this change automatically since it is set to pull Git and look for changes every 60 seconds.
• If I change this string again and make an error in the code for whatever reason, Jenkins will flag this as a failure and will notify the developer responsible or the team at large.
• Developers and the team are notified via email, HipChat, Slack, etc.
• I can now fix that error and have Jenkins run through the process again. Once fixed the code is committed to the CI central repository, ready for the CD process.

2 ) Continuous Delivery or CD:

CD means that we can ‘push a button’ and deploy code that has passed through the CI process.  My python code has passed and all bugs are now fixed in a continuous cycle as given above.  Now I want to deliver my code into the central repository for deployment.

• Within Jenkins we have a separate project for our deployment.
• The CD automation tool should pick up the ‘artifact’ that the CI server created and use that in the deployment process.
• When we click on the Build button, we’re presented with some options, including the environment we want to send it to and the version of the build we want to send.
• Once we select the version we want to send and click Build, it’s going to deliver that to that environment.
• The artifact is now placed into the CD repository and delivered.
• By using the same artifact throughout the different stages, you reduce the potential for problems caused by building your app multiple times throughout the pipeline.

Once the software is delivered, it will be operationalized and used within the infrastructure by a tool such as Chef.  Chef is a best of breed code repository which contains all the source code, which entails versioning and close control.  This allows collaboration and rollbacks to be effected easier and more quickly.

Devops is thus the combination of a cultural change with automation.  It is a compressed lifecycle of development which attempts to professionalize and enhance software development quality.  This is what makes Devops hard.  It is as much a philosophy of being a professional, as it is a concrete path to enlightened engineering.  The benefits of Devops are many, but the failure rate with Devops is quite high.

The main reasons why Devops will fail are the following:

• Skill base – you need to understand OOAD software principles and best practices in coding.
• No training on the automation tools such as Jenkins or Chef.
• You will need to know Python and Ruby.
• Devops is good for Cloud native applications, but maybe not necessary for all projects. Make sure you need Devops and that it can help you with your projects.
• Project Management and Change Management skills are lacking or in most cases non-existent.
• Agile or SDLC methods still need to resolve business requirements and this necessitates complete architectural, logical and code documentation.
• Many firms have silos and the people in those silos do not want to lose power, control and relevancy.