If in the cloud, then DevOps. Why?

The term DevOps itself was coined from the words Development and Operation. There are countless possible interpretations of the term on the Internet, but they all agree on a few basic characteristics. DevOps is building on the agile development methodologywhich, 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 exactly 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 on 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 application? 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 bias and allow for the blackest scenario, in the event of an accident, can we return the application to its original state and restore the environment with sufficient speed, ideally instantly?

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 about splitting the development itself into so-called sprints.

Sprint is a predefined period of time divided into several development phases during which activities are planned for the development team. The activities are then worked on to finally test each one and prepare it for release, to be released 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 the management of developers' work according to a predefined plan, and not operational support. This is where DevOps comes in, which effectively extends the agile development methodology with several new solutions.

The main emphasis is on maximum automationwhich allows the new solution to be put into production almost immediately. Therefore, it can be said that in DevOps we don't have these well-defined time periods, sprints.

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

Automation and involvement of Operations bring us the benefit of continuous improvement of the delivered solution (continuous improvements or CI).

However, CI can also mean in the context of DevOps continuous integration, continuous integration. From this point of view, developers are expected to update the solution they are working on several times a day, usually after each small functional part is completed, using a common source code repository, 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 implemented into production, again in an ideal DevOps world, in an automated fashion, thus achieving of continuous deployment (continuous deployment - CD).

And if we combine the two steps CI and CD together, we get a seemingly perfect process, called. CI/CD pipeline (which has already been mentioned in the previous Encyclopedia 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. It requires quite a 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 tailors DevOps to its own. While preparing this article, for example, I came across differences between the Czech and English Wikipedia definitions of the different phases.

For example, why should I use a tool that is built in Ruby when my infrastructure is built on Python? Are there any corporate 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 hardwarewhich is a time-consuming and financially demanding activity. However, we are not yet living on a cloud, and therefore we cannot rule out an on-premise environment in our decision-making.

So what tools should I use in DevOps?

The right solution can make it easier to switch to new technologies in the future. It can help us optimize the operation of our IT department, perhaps even merge IT departments together.

As I mentioned above, so CI/CD pipeline there are 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 used to meet the needs of the operations teams themselves, who nowadays maintain the 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, for example Chef or SaltStack, we get a repeatable solution for infrastructure management.

In addition, if we connect the selected tool directly to the source of requirements 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, although we have been seeing it since 2009, is still often shrouded in mystery, perhaps due to the freedom of its deployment. To cover the topic of DevOps thoroughly would require a whole series of articles (which may come at some point in the future).

However, it is definitely worth getting to know the topic better on specialised websites and Discuss specific tailored solutions with your cloud provider.

And because the cloud is not only DevOps, but many other solutions, we are preparing for you in ORBIT entire Cloud Encyclopedia, where you will find other interesting topics.