Defining what DevOps really means

Defining what DevOps really means

 

 

Many large firms run into trouble when trying to standardise their development and operational-support processes. They follow ‘DevOps’ guidelines, usually invoking some tepid form of ‘Agile’. When the magic elixir of perfection remains elusive for 2 months, the project management team declares failure and resorts to Waterfall, guaranteeing pain and agony for the company over a protracted period of time, until some brave soul in the future attempts to resurrect the ‘failed’ idea of Agility and DevOps. Thus, the cycle of immaturity creates its own life-force.

 

DevOps is not a product, a brand, or even a certified method. There is no magic involved.

 

DevOps 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. Not understanding something is unlikely to lead to success.

 

So, what is DevOps?

 

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

 

1. Improvement of software quality, reduction of errors and poor deployments
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 by making the environments similar
6. Stopping the deployment of new versions over a weekend and move into a continuous delivery cycle measured in days or weeks
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 and related to culture, an organisation built to provide iterative-Agile premised development. For many firms these 2 issues are problematic, involving ‘organisational-change-management’ or OCM. It is likely that without OCM and a good appreciation of Agile processes (there are 5 core processes within an Agile environment including engineering, organisation, cultural, tooling and operational support), DevOps will fail.

 

On the upside DevOps provides a better way to look at the development, deployment, and operations pipeline, through promoting a culture of collaboration. 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.

Development	Continuous Integration or CI	Jenkins
Delivery of code	Continuous Delivery or CD	Jenkins for eg
Operational Management	Infrastructure as Code or IAC	Chef, Terraform, Ansible

 

A simple example of Continuous Integration or CI:

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

1. I can use Jenkins to set up a code pipeline for a specific application I am building in Python
2. I install my code, with dependencies in pip, a Python package manager, and then it runs all of the tests.
3. If the code is good and ‘passed’ Jenkins will create an ‘artifact’. An artifact is your code compiled into one location.
4. 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.
5. Jenkins picks up this change automatically since it is set to pull Git and look for changes every 60 seconds.
6. 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.
7. Developers and the team are notified via email, HipChat, Slack, etc.
8. 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.

 

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.

1. Within Jenkins we have a separate project for our deployment.
2. The CD automation tool should pick up the ‘artifact’ that the CI server created and use that in the deployment process.
3. When we click on the Build button, we are presented with some options, including the environment we want to send it to and the version of the build we want to send.
4. Once we select the version we want to send and click Build, it is going to deliver that to that environment.
5. The artefact is now placed into the CD repository and delivered.
6. 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.
7. Jenkins usually integrates with Github as a source code repo

 

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 maintained easier and more quickly. Chef is essentially the configuration automation, deploying the application stack to the targeted server estate.

 

Operational Runbooks

A main failure of DevOps is the lack of appreciation of the complexity of Operational Management, who will operate and manage the systems including networking, security, patching, application logic issues, first- and second-line support (developers will only do support for a limited time in reality), and the related costs involved (Ops will be 5x more expensive than Dev).

 

Culture and Tooling

DevOps is 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:

1. Skill base – you need to understand OOAD software principles and best practices in coding.
2. No training on the automation tools such as Jenkins or Chef.
3. You will need to know Python and Ruby (or the code base of choice eg Java).
4. 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.
5. Project Management and Change Management skills are lacking or in most cases non-existent.
6. Agile or SDLC methods still need to resolve business requirements and this necessitates complete architectural, logical and code documentation.
7. Culture. Many firms have silos and the people in those silos do not want to lose power, control and relevancy.

 

==END