Read Time:7 Minute, 16 Second

Deploy is lava! How Managed Kubernetes helps businesses put out fires

New times have required businesses to look for new solutions to respond to customer requests and anticipate service expectations. The ubiquitous monolithic architecture did not meet the requirements associated with the rapid scaling of projects. In addition, the components of the monolith during the burnout often disrupted the operation of the entire service.

Downtimes are extremely dangerous for any business, therefore, microservice architecture has become increasingly used as an alternative to a monolith in a variety of projects. It is worth noting that this process was also preceded by the popularization of the DevOps methodology, but perhaps this is a topic for a separate article.

We can say that microservice architecture appeared at a time when the client-server architecture evolved towards distribution systems. Distributed systems differ from the traditional client-server model in that they run several different applications on several different but interconnected systems.

The architecture itself did not yet solve the problems associated with the speed of deployment, but was already moving in this direction. At the same time, it was impossible to perceive it as a panacea for all problems. For example, problems with the authorization component could still lead to unavailability of services, but this is already a problem of critical areas, and not the entire application as a pain point.

Many developers consider microservice architecture to be the main driver of the development of the entire industry, but does this mean that a monolith is definitely bad? Not really.

Features of monolithic architecture

The choice of architecture largely depends not only on the tasks of the project, but also on the organization of the team. For small teams of 2 to 5 people, a monolithic approach can be more beneficial for a number of reasons.

Working in one application solves the problem with logging and security, which is often neglected in the microservice approach.
There is no need to pay as much attention to the interconnection of components as in a microservice organization.
Easier monitoring.
The entry threshold for microservices is an order of magnitude higher, since development requires specialists with certain competencies in the team.

A monolithic architecture is really good when you need to quickly roll out a new feature to the production, but there is no way to prepare the infrastructure – more often this is a solution for new products. It is also necessary to understand what difficulties and at what stage the team will be able to transfer with the least loss of resources.

At the same time, some large projects are in no hurry to switch to microservices, since it is more profitable for them from the point of view of costs and resources to scale the infrastructure than to re-architect the entire service.

The graph shows the approximate ratio of the cost of the code as the project develops: the more code you have to add to the monolith, the more expensive the solution will be. At the same time, the less you have to pay for it.

Since the division of a large monolith into microservices is a rather painful process, it can be done gradually, but the choice of architecture itself should be made based on business needs. It's worth asking yourself is the application big enough to split it into microservices?.

To move from a monolith to microservices, two approaches are most often used. Big bang approach and incremental refactoring.

In the big bang all efforts are focused on refactoring the monolith. The introduction of new features for this period is suspended.

The incremental refactoring ensures that new features are implemented as modern microservices that can interact with the monolith via APIs. At the same time, the code is not directly integrated into the monolith.

As the product is upgraded, the functionality of the monolith is gradually delegated to microservices.

When a company chooses its refactoring path, it is important to consider the following aspects:

What business components to separate from the monolith and turn them into distributed microservices.
How to separate databases from application to separate data complexity from application logic.
How to test new microservices and their dependencies.

Features of microservice architecture

The microservice architecture is based on the principle that each microservice realizes its own business opportunity. It can be tested, deployed, or upgraded without affecting neighbors. This separation of powers provides high fault tolerance (if configured properly) and opens up the possibility of application containerization.

Containerizing microservices is the next step in the evolution of application development and maintenance. The approach allows you not to worry about the consistency of languages - any microservice can be written in a language that is most relevant to the tasks of the node.

Each container as a unit of software contains a development environment, code, system tools, various libraries and settings – very convenient, but their main feature is that the microservice is isolated. Thanks to the clear boundaries of the container, it can be easily moved or scaled, for example, as the load on the application increases. In addition, it can be painlessly updated, so that customers do not feel that some part of the application is being worked on.

In conditions of seasonal demand or during advertising campaigns, the number of users can increase dramatically, so downtime in this segment will negate all marketing success. During peak loads, a container may burn out, so a quick replacement from the image will be required. Now it is obvious why monolithic applications are increasingly being cut into microservice architecture.

Orchestration and Kubernetes

Is it possible to automate this process so that new ones come to replace the burnt out ones, and deliveries are carried out uninterruptedly? Container management proved to be a daunting task, which is why orchestration systems emerged.

With their help, it became possible to configure dependencies between containers and deploy them faster and easier. One of the most popular solutions is Kubernetes, also known as K8s.

For 8 years, Kubernetes has gone from a curious solution and a side project of developers from Google to a real brand. We will not investigate why this happened, but K8s turned out to be convenient for developers and for business at the same time *.

* Under such asterisks, the most difficult tasks in textbooks and the most inconvenient terms of contracts are always hidden. In the case of Kubernetes, there were several such things:

There are extremely few experienced Kubernetes specialists on the market.
Maintaining your own full-fledged DevOps department is likely to be uneconomical, especially for startups.

Kubernetes as Managed Service

The service is based on the principle of delegation. Businesses get the opportunity to focus on the product itself and customer care, and not worry about the infrastructure.

First of all, the service allows you to qualitatively improve the processes of deployment and scaling. Due to the fact that the logic when each microservice writes data to its own database is considered the best practice, the provider also provides administration, backup and protection of the infrastructure.

Selectel's Managed Kubernetes can make things easier for many businesses, no matter their size:

For startups, this is a great opportunity not to engage in independent deployment and maintenance of the cluster.
For medium and large businesses, this is an opportunity to build a flexible, fault-tolerant platform of any scale, suitable for working in different clouds, with different code and OS. For many, the key benefit here will be the ability to quickly scale to the expected workload.

The best practice in this sense is to consolidate the client services and the container registry in one place. This provides high speed image downloads and changes the approach to security. Now you can not use public servers to store images, but store all data in your provider's own repository. In Selectel, the service for facilitating the storage, management and deployment of containers is still in beta testing, so it is free to connect.

The provider is also responsible for the availability of the cluster and maintains the latest versions of K8s itself and components.

Together with Managed Kubernetes, you can connect all the necessary services for web or mobile applications. Managed Kubernetes is fully compatible with other company products. Moving an application to the cloud, using S3 object storage, or protecting against DDoS attacks are syncretic with Managed Kubernetes, since we build the entire infrastructure ourselves, and do not work as resellers with solutions based on other people's developments.