DevOps Demystified for Non-techies

I’ve recently written 2 blog posts (part-1 and part-2) about DevOps without using its name because it still scares some people. However these posts were meant mainly for a technical audience working in the Information Technology (IT) industry. But what about non-techies (in IT or outside of it) who still need to grasp the gist of DevOps without all the technical jibber-jabber?

Also, if you work as a DevOps consultant like me, have you already tried to explain your job to your love ones and only faced round eyes? I’ve written this blog post for you as well, so read along!

A DevOps Analogy

The easiest way to demystify DevOps is to use an analogy that speaks to everyone: A restaurant! In any type of restaurant you have basically 2 teams: The ones who cook and the ones who serve the customers. First revelation here: DevOps is a way of working so it could apply to everything! DevOps uses a methodology that is represented by an infinite loop as shown below. It follows several steps and we can keep the same name used for IT when it applies to a restaurant.

The Cook Team

The first step for the cook team is to plan the menu and all the dishes they intend to deliver to their customer for each meal. They also have to plan for those dishes to be ready in a timely manner after the customer place an order. There is the general plan to create a menu for the customers and there is also a more dynamic plan to be able to cook each dish ordered by the customer through the serving team.

When this plan is settled, the next step in the DevOps methodology would be to code. Yes in the IT world that is what some people are doing behind their computer! Instead, in a restaurant, the cook team will have to buy the ingredients and prepare them. They will cut the vegetables in small chunks, prepare the sauces, put the meat and the fish into the fridge. During the meal service, they continuously prepare some ingredients in advance to be ready quickly when a new dish order arrives.

The ingredients being ready, they can now put everything together and prepare each dish of the menu with them. That is the build step. Each dish is made of the ingredients prepared previously. During the serving meal, they receive an order and just have to build that dish.

Before the cook team hands over the dishes to the serving team, they test it. You may have seen a cook (often the chef) tasting the sauce before putting it on the plate, or checking the temperature of the meat. They want to make sure the dish is perfect before being served to the customer.

The Serving Team

When the cook team is happy with their work, the serving team takes over these dishes. That is the release step. The waitresses and waiters carefully hold these dishes with sometimes several plates on each arm!

The food is then served to the customers all over the restaurant, that is the deploy step. The dishes are carried to the customer according to what they’ve ordered.

That is also the work of the serving team to put the dish on the table of the customer, set the cutlery and fill the glasses. That is the operate step.

Finally, the serving team checks with the customers everything is all right and if they are happy with their dishes. That is the monitor step where they also take notes if there are some leftovers on the plate or if some customers were unhappy.

The serving team also monitors and takes care of new customers entering the restaurant and writes their order. They pass it on to the cook team and another iteration of the DevOps loop starts. So during a meal, the restaurant goes several times through the DevOps loop.

In a restaurant, this whole process starts again and again for each meal every day. The information gathered during the monitor step are used to plan the next meal and do some changes if required.

The DevOps Consultant Role

You’ve seen that the DevOps methodology can apply to running a restaurant! Would you have thought of that?

In a restaurant, we just don’t call this process DevOps but the way it is organized is quite similar. A well managed restaurant is packed with customers and the dishes are delicious and delivered timely. Overall the restaurant is profitable and has a good reputation. It can even earn Michelin stars and be recognized as a top restaurant by the industry. To reach that level, the DevOps loop needs to flow smoothly. It is the goal of a DevOps consultant to help you with this if you are not there yet.

What could possibly go wrong? Well, you may have watched the show “Hell’s Kitchen”! It is about dysfunctional restaurants that need help to make it all work. In that case there may be issues at any steps from planning to monitoring. Gordon Ramsay would act like a DevOps consultant here. Of course the DevOps consultant doesn’t swear and is always polite with its customers!

If you have been to restaurant, you know that sometimes not everything goes right. The dish can be served cold, you wait for an hour before getting served, nobody seems available to take your order,… There could also be a lack of collaboration between the cook team and the serving team. It could take too long to prepare the dishes or too long to bring that dish to the customer. Each team will point to the other when the customer complains.

All these issues occurs when the DevOps loops doesn’t flow smoothly, so you hire a DevOps consultant for help. He will review and investigate each steps of this loop and make suggestions on how to improve it.

DevOps in IT

Origin of DevOps

You are now ready to learn more about DevOps in IT! But first, did you know that DevOps is not born in the IT industry? It actually comes from the automotive industry. Yes, DevOps is inspired by the Toyota Production System and its continuous improvement of its manufacturing process to build cars.

DevOps is also seen as an evolution of the Agile methodology. Agile is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement.

In IT we don’t deliver dishes or cars in the physical world but we deliver applications. An application could be a website for example where customers can buy goods. To create this website we need 2 teams: The developers (Dev) and the operation (Ops). This is where the word DevOps comes from. It binds the Developer and the Operation teams through the DevOps loop to collaborate and work efficiently together. Traditionally these 2 teams worked in silos but often the delivery of the application (or just a simple update of it) were slow. Applying the DevOps methodology can remediate that by accelerating this delivery time (called Time to Market).

DevOps loop steps

You have seen above we can easily translate the DevOps loop steps from IT to the restaurant business. What changes is what you deliver to your customers at the end. A dish for a restaurant or an application for IT.

Working in the IT industry make use of computers (of course) and their numerical tools. DevOps leverage on that at every steps of its loops. There are a lot of tools (too much actually) you can use. Some are quite popular and you may even have heard about them. Let’s have a look at these steps as they are used in IT.

The Dev Team

Planning is basically still done through the usual IT project tools. You list all the tasks to do and put deadlines for each of them. That’s a very quick summary but I don’t want to confuse you more. The Dev Team is involved in this step along with project managers.

Developers codes (means write a sequence of instructions in a programming language) and often use a tool called git to share their work with the other developers in the team. It is a great tool to put the work of all developers together and track the history of the modifications.

When the development team has gathered the final code from everyone, they are just happy to share it! This step is called build where they produce a single package of your application that contains all the code from everyone.

Before they give this package to the operation team, they prefer to do some tests against it to be sure all the features they have coded work well. It would be bad for a customer to click on a button and it doesn’t work. This is the test step.

The developers may have fixed a few bugs found during this testing but they are now confident to have a package that can be used by the customers. They hand that package over to the operation team.

The Ops Team

The operation team get that release and deploy it on an infrastructure (a bunch of computers with some numerical tools that host all of your applications) and make it available to the customer for using it. Usually they apply a deployment strategy as for example to make this application available only to a subset of users. If everything works well, then it will be made available to all users.

The operation team also operate the infrastructure that hosts the application. This infrastructure could be virtual (yes it is like a computer in another computer!) and even be some little virtual pieces called containers. A container can be created by a tool called Docker and if they are a lot of them we need an orchestrator tool called Kubernetes. If this infrastructure is virtual, we can code it as well! We then use a coding language like Ansible for this purpose.

When this application is used by the customers, it is carefully monitored to detect issues or receive feature requests from the customers. That will start another DevOps loop and if everything flows smoothly then the customers will quickly see the results and benefit from them. The infrastructure that hosts your applications is also continuously monitored to prevent (if possible) or react to any failures in it. It is important to keep this infrastructure up and running otherwise your applications can’t run properly.

What is this DevOps pipeline thing?

Even if you are non technical, you may have heard about the word pipeline. Is it related to plumbing or something? Know that a computer scientist (a more polished name than a geek!) only touch a computer. No real tools from the physical world. So where do you place a pipeline in this DevOps loop?

You have to know also that a good computer scientist is a lazy one. He likes to automate everything (means write code) to not do tasks manually and not do something twice. The coding part, he has to do it manually for now. When his code is done, there are some tools to automate the build and test phases. This is what we call a pipeline. The pipeline is itself some code to automate and string several steps of the DevOps loop together. From the end of the code step to the test step everything happens automatically, like a domino effect.

But that’s not all, when the operation team releases that new application, they can also use a pipeline. They are lazy too! So they use a pipeline that will get a release and deploy it automatically!

By putting the developers and the operations team together, they can be even more laziness! They can build a mega pipeline! This pipeline will then start at the end of the code step until the end of the operate step! That is a strong acceleration inside of the loop but you will need to wear a helmet to not crash out of the DevOps loop! By using this mega pipeline, a developer could push his code directly on production… It is like a cook serving his dish directly to the customer!

Of course in reality building this numerical pipeline takes a lot of time and effort.

Wrap up

This blog post was kind of a DevOps “Origin” to help non-techies understand what it is. From an analogy about managing a restaurant with DevOps we moved to how it is used in the IT industry.

If you want to go further, you can now confidently read my blog post about DevOps in IT for more details. You’ll better understand how an IT company can leverage DevOps.

Finally, to keep you well informed and on top of that topic: The name DevOps is becoming replaced by the term “Platform Engineering”. It focus mainly on improving the developers experience but the methodology is the same.

At dbi services we provide DevOps consulting, trainings (on Ansible, GitLab, and Docker and Kubernetes) as well as give webinars and presentations at events. Check out our website and follow us to stay informed!