Are You Afraid of the Word DevOps? – Part 1

We came to realize recently that there is a resistance to the word DevOps and it repels some of you. Sadly, by stopping to this word, it prevents you from entering his world! Do you feel that DevOps is just another buzzword and is hard to relate to something concrete? Bear with me, I’ll show you another door.

To add to the confusion, there are even more scary ones like Site Reliability Engineer (SRE) or Platform Engineer. What are they? How do they relate to DevOps?

Let’s just drop all these words, actually you don’t need them. I prefer to show you how to be successful with the release of your application! In case I need to reference DevOps, I will use instead you-know-which-word to not scare you.

I hope you are reassured enough to jump into it with me, you may well be delighted by this wonderland! I put the extra effort to make this series of blog posts accessible to everyone.

The Starting Point

You are a company and you have this new application or product (I’ll use both words interchangeably) that needs to be released quickly because your main revenue comes from it. However the traditional way of conceiving, developing and then deploying it, takes a lot of time and effort. Moreover, once released, if you have to update your application, it’s again going to take some time by following the same process. This time is called the Time to Market (TTM).

This way of working has generated a lot of frustrations at different levels and an important one was the loss of revenue due to this too long TTM. Also you may have competitors of your application and if they can release their product quicker than you then it will damage your business even more.

For the conception and planning team, it is hard to try a new feature, get a feedback from the end user and adjust accordingly because of the too long time it takes to reach them. So they play it small by choosing common features and discard more creative ones. The innovation is then inhibited and their product will not stand out.

For the developers, they could not see their work or latest update being quickly deployed in production and so they kind of lost interest in it. From their point of view the job was done and they already moved on to other tasks.

For the operation team, they struggled to install the product in production. They followed the instructions given by the developer but it didn’t work. Troubleshooting and fixing these issues also take time and delay the release of your product. If it is an update, they may decide to delay its release even more to avoid a failure in production. That would cycle back to the conception team who gets frustrated because they can’t see the result of their design. The management will be angry as well because at this point the business is not good.

The speed of your TTM at this stage is very low:

Improving your TTM is the goal to make your business more profitable with your excellent product. That should be your main focus. Let me tell you a secret just to give you a shiver, this is what you-know-which-word is all about! And as soon as you step on the gas, you are doing it without naming it!

Your Product

Let’s take an example of a simple product with two components: A web frontend and a backend database. When these two components are installed from the same package on the same server we call this application monolithic. Both components are tightly bound together. To illustrate our previous section, let’s jump into the shoes of each role.

The conception and planning team: The product features and look have been worked out to be functional but nothing disruptive. This is handed out to the development team. A timeline has also been given by the planning team and regular meeting are scheduled to check the progress and discuss any issues.

The development team: The product is coded as per the instructions from the conception team. Each developer put his code into a shared folder that is the current release they are working on. When a new release is being worked on, a new shared folder is created. This way of working can generate some collisions if the tasks are not well distributed. In a worst case scenario, it is possible to lose some code with no possibilities to recover it. For his task, the developer needs to setup a machine to test the results of his code. He uses an old machine in his lab that he is sharing with the other developers. On this lab machine, he sometimes upgrades a package that his code needs or he tweaks the environment to just “make it work”. He doesn’t always take notes of all these changes he did manually. So when the product is ready on his side, he passes it on to the operation team with a guidelines on how to install it. He wrote this guideline from his memory and with the few notes he took. The same process will happen in case of an update of the product.

The operation team: They receive the product package with the guidelines on how to install it. It should be pretty easy, however the machine used for production is different than the one used by the developer. By following the guidelines, the installation failed with some library error that has a too old version. Fixing this one manually may lead to another error in another library so they have to work with the developer to fix the issue. That’s tedious and if that package to deploy was an update, it would have crashed the application that would have then been unavailable to the users during the time to fix it. It generates a lot of stress and irritation. The trust of the operation team in the developers decreases and they are more and more wary or even reluctant to deploy an update. Their goal is to keep the production application up and running.

At this point the deadlines are exceeded and there is a high nervousness at each level of your company. The developers point the finger to the operation team that didn’t install the latest update and the operation team point the finger to the developers because their package is not guaranteed to not crash the production product based on previous bad experiences.

This is speed 0, but the good news is that any improvement from here will be beneficial.

First Acceleration

When a team of developers work on your product, they need a better coding environment than a shared folder. It is more efficient to use a tool that keep track of changes in the source code. This code is stored in what is called a repository and each developer can get its own local copy of it. They can then work on their development part independently and push it back to the repository when done. However this central repository is not the same as a flat shared folder. It is split in different views we call branching. Branching allows each developer to work in a separate environment without impacting the other branches. When everybody is done and we want to aggregate all the code together, a merge operation of all branches is triggered. There may be conflicts to resolve if, for example, the same part of code was modified by several developers. Once everything is cleared up, your product release is ready.

The most popular tool is git and is usually integrated into more advanced products like GitLab that provides other interesting features.

dbi services has a brand new training course on git and GitLab, check it out!

By using a better coding environment, the developers will be more efficient and your product will be ready faster. The speed of your TTM at this stage is still low but has improved:

Second Acceleration

We have seen that the developer using his lab machine during his coding is not ideal. It may have to tweak the machine for the product to work and he doesn’t always take notes of all of his actions. The way to improve this is to script each steps from the beginning to the end. Each required libraries and dependencies are identified and installed first before installing your product. This way the product can be fully installed and re-installed by just running the script. In addition, some scripting language like Ansible are easily readable and thus provide the installation documentation at the same time.

Ansible is very powerful and dbi services has a training course on it that has just been updated. Have a look!

With this script on hand, the developer can now share it with the operation team. By running this script they can deploy the product easily in production too. It then restore confidence in the work provided by the developers and they will be keener to update your product once received. It is a win-win in wonderland!

Now the speed of your TTM at this stage has improved a bit more. It’s not ideal but it is much better:

Summary

We started by explaining what is TTM and why it is important to take care of it to avoid frustration and for your company to flourish. Then by taking the example of a simple product, we dived into a real-life situation of a dysfunctional TTM. Finally we started to improve it by giving your developers an efficient platform for coding and use scripting to be able to easily install the product.

With the advent of containerization in the past ten years, the game has changed and will give us some powerful means to improve our TTM even more. We will dive into it in my next blog. See you there!

If I won my bet, you completely forgot about you-know-which-word at this point!