What Is DevOps?

I’m currently finishing up some of my “part written” blog posts, and after releasing my post around CPD planning I thought I would get my DevOps post out as well.

Over the last few years, I have been learning to be more agile and carry out tasks with a DevOps mindset (or at least try to). DevOps has many different meanings to many different people, and I thought I would try to blog about what I think DevOps is.

First up, DevOps it is not a product or tool that can be purchased, although it makes use of tools to assist with processes. DevOps is more of a discipline or mindset that can take time to achieve especially in large organisations or organisations with legacy ways of working.

Second, DevOps is not tied to a particular operating system, cloud platform or programming language. No matter if you are using Microsoft Windows, a flavour of Linux or Apple MacOS. Whether you prefer to code in Python, Java, C# or JavaScript. If your cloud preference is AWS, Azure or GCP. You can still utilise a DevOps mindset.

CALMS

CALMS stands for Culture, Automation, Lean, Measurement and Sharing.

Culture

People are important. Probably even more so than the technologies involved. For a DevOps culture to work the people involved should be open minded and work together. This culture should not be limited to just the “technical” parts of the team, it should expand to management as the culture should embrace openness, transparency and honesty. If a “no-blame” environment can be created then that helps people to be honest about mistakes, which leads to people embracing failure and then to using failures to improve themselves, others and any technology they are working with. This all leads to faster feedback loops, leading to faster fixes.

Automation

When it comes to tasks, I enjoy automating them. Why? Because in the long run it not only saves me time but also helps with idempotent results (getting the same result each time). It may take a little longer to automate a task, but if it saves time later it is worth it. Automation can be brought in when using Continuous Integration or pipelines and is fantastic for testing (my recent blog posts on unit tests, hopefully soon I will share my functional testing posts using automation and selenium). If a release can be tested automatically then it reduces the risk of a human missing a bug. If infrastructure can be defined as Infrastructure as Code (IaC) to build the reliable infrastructure each time (where a human may miss a step or misconfigure a device, or not be available to scale the web servers) then it should be automated.

Lean

The modern world is a fast-moving place. The tech world moves even faster. To keep up with release / feature demands or customer requirements, teams need to be lean, fast moving and focused during a sprint. This is where sprints and squads (small teams) come in. Squads allow for a small team to focus on a particular release feature, problem or business requirement. The aim of the focus should be broken down into the smallest parts and then each part worked on during the sprint. Lean may mean small deployments, but they occur more frequently.

Measurement

The DevOps mindset is great, but if results cannot be measured then organisations may question why use it. Measurement is important, and a DevOps culture should bring reduced failure rate (particularly in production), reduced recovery time (from failure to being back available), reduced time to release (idea to testing to production) and an increased frequency of deployment. These measurements rely on the culture and automation being in place.

Sharing

Something that sometimes gets missed in the tech world is the sharing aspect of work. Having one person being the go-to / keeper of information introduces a bottle neck and also a single point of failure (SPOF). DevOps is about collaboration, discussing work tasks (especially during sprint planning), discussing issues that have come up (especially during any retrospectives) and documenting work. With great sharing comes better releases, technology that is better understood by the team (and organisation) and it increases skills throughout the team.

My mindset on DevOps grew after reading The Phoenix Project (Gene Kim, Kevin Behr, and George Spafford) and The Unicorn Project (Gene Kim). Also check out this page – https://itrevolution.com/the-three-ways-principles-underpinning-devops/ – to read Gene Kim discussing the 3 ways.