If in the cloud, then DevOps. Why?

 

DevOps is a word that is currently being talked about a lot, written about a lot and there is almost no other position in IT HR today than DevOps. What does this term actually mean? What do you mean by that? The answers can be found in the following brief article.

Lukáš K.

 

The term DevOps itself is derived from the words Development and Operation. We can find countless possible interpretations of it on the Internet, but they all agree on a few basic characteristics. DevOps is a superstructure of agile development methodology that, when implemented correctly:

• facilitates work within development teams,
• accelerates the integration of new applications or their functionalities into the cloud,
• improves communication between the development and Operations teams,
• Last but not least, it also improves the quality control of the delivered product.

 

Application development without DevOps and without rose-tinted glasses

It could be argued that this methodology, DevOps, is unnecessary because teams communicate with each other (perhaps even beyond workflows), new applications are in production right on schedule, and everything works perfectly without DevOps.

But what if we take off the rose-tinted glasses and ask the users of the final product about their feelings about using the provided application. Are they happy too? Are their demands and problems being addressed? Is it possible to trace back what happened to the app? How fast was the response to problems and what exactly was moved to the production environment?

And if we really look at our non-devops environment without prejudice and allow for the blackest scenario, in the event of a crash, can we return the application to its original state and restore the environment with sufficient speed, ideally immediately?

 

What is the basis of the agile development methodology?

When discussing the importance of DevOps, its workings, principles and possibilities, we should first take a quick look at agile development itself.

What’s that?

There are several different agile methodologies, but essentially it is a division of the development itself into so-called. sprints.

A sprint is a pre-defined period of time divided into several development phases during which activities are planned for the development team. Work will then begin on the activities to finally test each one and prepare it for release, for release into production.

 

 

In other words, at the end of each sprint, the Operations team is handed a finished working part of the application that the Operations team can implement on the production environment.

 

So what does DevOps solve?

If we take another look at the agile methodology, we can see that it only addresses managing the work of developers according to a predetermined plan, and not operational support. This is where DevOps comes in, effectively extending the agile development methodology with several new solutions.

The main focus is on maximum automation, thanks to which the new solution can be put into production almost immediately. Therefore, we can say that in DevOps we don’t have these well-defined time periods, sprints.

By involving Operations in the entire cycle, developers also receive feedback. Thus, they can flexibly repair the already completed solution or extend it with new functionalities and respond to current needs.

The automation and involvement of Operations brings us the benefit of continuous improvements (CI).

However, CI can also mean continuous integration in the context of DevOps. From this perspective, developers are expected to update the solution they are currently working on using a common source code repository several times a day, usually after each small functional part is completed, instead of sharing a complete complex package of several solutions.

This practice allows you to run automated tests and more easily make corrections if an error occurs. Once the code is tested, it can be immediately, in an ideal DevOps world, automated again, implemented into production, thus achieving continuous deployment (CD).

And if we combine the two steps CI and CD together, we get a seemingly perfect process, the so-called CI/CD pipeline (already discussed in the previous Encylopedia article).

 

 

Is it really that simple?

Simply put: it isn’t.

In the world of DevOps, there are countless tools and solutions that can be used for our needs. This requires a fairly comprehensive analysis of requirements and plans for the future. And although DevOps is a common theme in transforming IT environments to the cloud, the methodology itself is not clearly defined. Each company customizes DevOps in its own way. For example, while preparing this article, I came across differences between the Czech and English Wikipedia definitions of the phases.

 

 

For example, why should I use a tool that is built in Ruby when my infrastructure is built on Python? Are there any company regulations that can affect the whole intended DevOps? Is my environment cloud-based or locally installed on servers?

In general, DevOps methodology is mainly associated with cloud environments. In it, it is possible to dynamically manage the entire infrastructure and respond to current needs without the need to purchase new hardware, an activity that is both time-consuming and costly. However, we are not yet living on a cloud, so we cannot rule out an on-premise environment when making our decision.

 

So what tools should I use in DevOps?

A well-chosen solution can facilitate the transition to new technologies in the future. It can help us optimize the operation of our IT department, maybe even merge IT departments together.

As I mentioned above, the CI/CD pipeline is actually several phases that repeat, and a different tool is appropriate for each phase.

 

 

Is DevOps only suitable for cloud environments?

Absolutely not.

The practices and tools recommended for DevOps can be successfully applied to the needs of the operations teams themselves, who nowadays maintain infrastructure in on-premise environments. Their work includes, among other things, solving requests and problems coming from users or through monitoring tools.

In this case, the requirements and problems can be considered as individual use cases for development. If we program their solution in a tool that offers central infrastructure management, such as Chef or SaltStack, we get a repeatable infrastructure management solution.

In addition, if we connect the chosen tool directly to the source of requests and problems, e.g. ServiceNow, JIRA or various monitoring tools, our environment will be managed with almost zero response time with minimal manual intervention.

 

Conclusion

The DevOps methodology, despite being around since 2009, is still often shrouded in mystery, perhaps due to the freedom of its deployment. It would take a whole series of articles to cover the topic of DevOps thoroughly (which may happen sometime in the future).

However, it’s definitely a good idea to familiarize yourself with the topic on specialized websites and discuss a tailored solution with your cloud provider.

And because the cloud is not just DevOps, but many other solutions, ORBIT has prepared an entire Cloud Encyclopedia where you can find other interesting topics.

 

This is a machine translation. Please excuse any possible errors.