A Brief Guide to DevOps

DevOps. It’s a confusing topic, isn’t it? I’ve been asked a few times about it, and I wanted to take the time to write down how I see it.

Often with culture topics like this, it’s difficult to pin down an accurate description. It also doesn’t help that the term spills out of marketing pieces from tech companies, without any real guidance on what it means. This just adds a lot of confusion, I think. It makes it hard to learn, especially if you just want to understand what it is and why it exists,

So I hope you enjoy this brief introduction to DevOps for busy people.

Let me know if you agree/disagree in the comments!

What is DevOps?

What exactly is DevOps? You might have heard people say things like:

DevOps is a mindset! … It’s a way of working! … It’s culture!

So what actually is it?! Is there a true definition?1

To me, DevOps is a way of thinking about how companies can deliver better software, quicker.

It promotes the idea that development and operations teams need to work more closely together, in order to make reliable software.

A DevOps mindset is about improving developers’ ability to get quality software into production, and increasing developers’ involvement in how their applications are run.

It’s also about using data and metrics to improve the quality of software, and sour ability to recover from faults. And it’s also about how to help operations teams handle applications that need to be released ever more frequently, sometimes several times a day.

DevOps is about thinking how we can deliver software more quickly, by valuing open culture, collaboration and constant improvement.

The Three Ways of DevOps

It’s a bit of a fuzzy concept, and I’ve not found a definition which everyone agrees with.

But, fortunately, there are three guiding principles of DevOps, to help us figure it out. These were initially devised by Gene Kim. They help define what DevOps is all about:

  1. Improve Flow from business to customer

    How can we improve the Flow of our work, so that value is delivered to customers faster and smoother? (In this context, value means useful software features.)

    Can we break down large, risky chunks of work into smaller pieces, so they can be delivered to the customer more often? Or could we automate some tasks that we do repeatedly?

  2. Create and use feedback loops

    DevOps says that we should collect data from the stages of software development, like coding, testing, deploying and monitoring. We then use that data as feedback on how well we’re doing, spot any problems when they happen, give more confidence in the code we’re building and improve the product. Feedback helps us measure our quality and go faster. For example, can we measure the sentiment of the team, or the quality of our code? How can we use that data to improve?

  3. Learn and experiment continuously.

    This means making time and space for learning, and using the things that we learn to make the system better overall. That might mean improvements to how we build software, or how we can make the app better for users.

The DevOps Loop

You might have seen people talk about DevOps and use a diagram like this. It’s sometimes called the “DevOps Loop”:

This picture is a way of showing that building software isn’t a linear process, it’s a constant loop.

When the first version of an application is released by developers, the work doesn’t just stop there! The output from development goes into operations. And then any learnings and output from operations can go back into development. And so we go round the loop again…

So we can see that our job is never done. By going round this loop, we can make our product better and deliver more value.

What problem does DevOps try to solve?

The problem DevOps tries to solve is slowness to change.

Remember the recent spike in online grocery shopping, due to the coronavirus pandemic? Businesses need to adapt fast to change.

But to adapt, companies usually need to change parts of the software that runs their business. For example, they might need to add more servers to cope with demand.

This might seem easy: just tell the development and operations teams to do it!

But, there’s a problem: IT teams in companies are traditionally focused on providing stability (protecting the castle), not quick delivery of new features.

Operations teams want to keep applications stable and up-and-running (maintaining profit).

But development teams want to deliver new features quickly for the business (making more profit).

These can seem like opposing goals.

The result is that delivering new features can often be slow and expensive. By the time that a new feature is ready, the business opportunity might have been missed.

This is a very simple example, but the principle applies across the board. Most software is created or changed for a business need, whether that’s increasing capacity to be able to take more orders, or something like making changes to the payroll system.

DevOps tries to help companies deliver software that users need, faster. In this context, a user could be an employee or a customer - they’re both users.

DevOps recognises the idea that development and operations teams are very important in providing value to the business. So the right culture needs to be in place to allow those teams to deliver that value sooner, and more predictably.

What are some examples of DevOps?

DevOps is about adopting culture and mindset, and not a specific set of rules. But if a company is adopting DevOps practices, you should be able to see some evidence of it, like these:

  • Development and operations teams working closely together

  • New versions of applications are released several times a month, or even several times a day

  • Developers’ code is automatically built and deployed, using scripts or pipelines

  • Servers and infrastructure is built using automation scripts

  • Applications are monitored by tools that collect and report information about application health

  • Automated quality checks are run whenever new code is committed

  • New features can move from idea into production very quickly

  • Developers have more ownership of how their software is deployed and operated

There are many more examples than this! You’ll be able to spot DevOps when you see it.

What’s not good DevOps?

If a company isn’t adopting DevOps fully, you might see that development and operations teams that don’t work well together, and are siloed.

You might also see that features can take a very long time to go from idea into production, because they have to run through many stages, or are bounced from team to team.

If you see an operations team which has simply been renamed to the “DevOps team” - well, that just doesn’t make any sense, and is the opposite of what DevOps is about! It’s about better collaboration between existing teams, not just creating new ones.

Suspicion between teams, or a lack of knowledge-sharing, are also signs that DevOps culture isn’t there yet.

What techy things do you need to know?

You’ve noticed I’ve taken quite a while to talk about technology. This is because DevOps is not primarily about technology. It’s about people. It’s about enabling them to work together, and removing the barriers that stop them from doing so.

But now, the word DevOps is just as much associated with specific tools, as it is with culture. Lots of job ads today use the title “DevOps Engineer” and simply list a set of tools.

So, while it’s good to understand the concept of DevOps, it also makes sense to look at some of the tools that are commonly used by DevOps teams. These tools are often called “DevOps tools” because they help with DevOps principles. They mostly make it easier to share things, collect data or to automate things.

These are tools you might be interested in learning if you’re joining an organisation that uses DevOps, or you want to become a DevOps engineer.

Project management and collaboration

These tools help teams to share and track progress on projects or communicate in real time, even if people aren’t physically near each other. This makes it easier for development and operations teams to know what each other is doing. It also helps the business see when new features are ready.

  • Examples: JIRA, Trello, Slack

Code: writing quality software

Developers need tools that allow them to work on code together, without having to copy it onto memory sticks or send over email! They also need features that allow them to work on the same code at the same time.

  • Examples: GitHub, Bitbucket, GitLab

Build: continuous integration & CI/CD

Good continuous integration is essential for DevOps. These tools are used to automate the process of compile code, run tests, and deploy the application. This means that the same process can be run dozens of times per day without effort.

  • Examples: Jenkins, Travis, GitLab, Circle CI, Azure DevOps

Deploy: configuration management & provisioning

These tools are used to create the environments where applications will be deployed. They might configure servers, install software, or create objects in the cloud. They are controlled using code. This means that environments can be created at the touch of a button.

  • Examples: Ansible, Terraform

Operate: run the application

When an application is built, it is then deployed onto a server or a cloud platform. These platforms run the applications.

  • Examples: Kubernetes, Amazon EC2

Monitor and measure

Applications need to be checked and observed to make sure they are running OK. Monitoring tools allow this information to be collected and reported, perhaps on dashboards or sent to a chatroom. This data is also useful to figure out where the application is performing well, and what could be improved (potential features to go back into the loop).

  • Examples: Prometheus, Splunk, Grafana

How do I get started with DevOps?

DevOps isn’t a tool, a methodology, or a product, or a service that you can buy. It’s not really meant to be a job title, or a team either!

It’s a mindset, or a way of thinking about how teams can collaborate and work together. You might be doing this already without having “DevOps” in your job title or team name.

You can start doing DevOps by doing things like:

  • Collaborating more openly with other teams, sharing your successes and failures so that others can improve

  • Looking at your current software development process, finding the bottleneck (the part of the process that is difficult or takes a long time) and trying to improve it.

  • Automating manual tasks, to give more confidence in your deployments and server builds

  • Writing tests to check the quality of your code, so that it can be measured and continually improved

  • Using a tool to automatically compile and test your code, like Jenkins

  • Gather feedback from end users about the application, so that their ideas can go back into the loop and be developed as new features

Conclusion

DevOps is about thinking how to deliver software better. It’s about encouraging a culture of collaboration between teams, using automation, and feedback loops to help us improve our products and process. It’s not a silver bullet, and it’s certainly not about one team doing all of the work. The benefits of DevOps are a better flow of work from idea stage into production, and delivering software that users value, quicker.

  1. It’s also hard to find a good definition, because the term has been adopted by tech companies to sell their products! ↩