DevOps - Introduction

"Looking for DevOps Engineer" is something you see way more often on job platforms. But, what is this about? What does it mean to do "DevOps"? Is it really all about Docker, Kubernetes, Ansible and GitLab? I can ensure you: No, it is about a cultural change.

Why I am writing about DevOps

This has been on my agenda for quite some time. You may not be aware, but I am also writing a book (more or less a collection of topics) about DevOps. It started as a 100% technical beginners guide, but I am facing more and more situations, where cultural and methodical topics are important.

I thought about this and came to the conclusion, that I should involve the community. I did a poll over at LinkedIn, but also asked colleagues, friends, meetup guests and many more, about the same. The result is a shortlist of ~10 topics, that may be interesting to most DevOps enthusiasts, but also beginners. Furthermore, I think it will fit into the existing blog topics very well and add value to you as a reader.

How will this be done

Now... I want to share these topics with you and therefore decided to write about DevOps processes, culture and methods. The articles will provide some links to existing books, lectures, videos and scientific papers.

I will publish a DevOps article approximately once a month. We will start with simple topics and slowly go into more details. Most things will be about best practices, but also about methods and experiences.

The ideas for this year are:

• 2 Core/Context Work framework
• Ways to Work
• Types of Work
• DevOps Ideals
• DevOps Metrics
• DevOps KPIs

Afterwards... let's see. Maybe we will talk about SCRUM, Kanban, Lean, Narratives, Story Telling.

What DevOps means to me

For this article, I will bring one more topic to the table. DevOps (including DevSecOps, GitOps, etc.) is a vast field and sometimes includes more, sometimes less. For me, DevOps is all about a quite simple, but effective idea:

You build it, you run it, you own it.

You can find hundreds of definitions for the terms DevOps. In general, the consensus is somewhat around the two ideas described below.

Dev + Ops = DevOps

The first major concept is, that Dev (development) and Ops (operations) should be way closer together. You may know companies and organizations, where the operator/administrator has nothing to do with the developer of a software. One team takes care of the software development, another one of the deployment and support.

This should be obsolete in DevOps. Instead, the idea is that Development and Operations are part of the same team. Therefore, cross-functional teams, that are made of development, product management, quality assurance, operations, etc. are much more likely in a DevOps culture.

So, let's assume you are in a team, that is responsible for the website of a company. Your team will develop the website, deploy it, do on-call if needed, provide updates, test everything, create documentation and basically own the product.

Depending on the demands of the team, it will be larger or smaller. Often, team members will not have a single role, but work on different topics. Sometimes, you will have a dedicated security expert, sometimes not, sometimes you will have 3 security experts - whatever helps to build, run and own the product.

In larger projects, this can be split up in different ways and there are many concepts, depending on your architecture and business processes.

Full Lifecycle

The second major concept of DevOps is about the lifecycle of the product. As stated in the last section, the team will be responsible for a lot of things. But, what does this mean? Where are these responsibilities, and what should you take care of?

Very often you can find a graphic like the one below on slides about DevOps. Sometimes, it's an infinite symbol, sometime a circle, sometimes a line (depending on the skills of the artist :-p ).

But, what is meant by these? How does this translate to actions and responsibilities? Let's stick with the website team example and go into the different topics:

Plan

Planning the work, actions, milestones and basically everything related to the website development. This can also include other work that is made in the team like writing documentation, going to trainings or talking to customers.

Code

If you want a website, you need to generate code. You can think of HTML, JS and other web languages. But, you should also consider Terraform, Ansible or Kubernetes and everything you need to package and deploy the application. And, for sure, you should think about test code and documentation.

Build

This can be a simple "make a tarball" or the creation of ready-to-be-used container images. If you can create a deliverable, that can be tested afterwards, do it.

Test

After building, testing. Testing and writing tests is part of the team. This can be done manually, automated or even "as a service", but it is owned by the team and not be some obscure QA department in "far, far away".

Release

Shipping or deploying the product is also part of the team. If your job is, to create some installer for your customers, this is the part. If your job is to develop the website, the deployment should be included. In general, a work-item like "new button for XYZ" can be considered "done", if it reached this point.

Operate

Something is going sideways or needs additional configuration? Here you go. You developed the website, you are the one that knows how to tune it and adapt it. Scaling, optimizing, configuring, but also troubleshooting is in your team.

Monitor

Setup up Nagios and forget? No! Monitoring includes gathering feedback, collecting performance data, seeing how the application behaves and which parts are working well or not. Talk to customers and users, create surveys and try to find data, that helps you to make the website even better.

Conclusion

I assume, that is enough as an introduction to the topic. I really hope, that the content will help you to get a better understanding and how you can improve your work.

In the end, the whole DevOps idea was born out of frustration about silos, complicated processes, waiting games and missing feedback. So, let's see how DevOps can help you to bring the fun back in IT. At least for me, it did!