Swarm Of Microservices

The diversity of life forms makes our world interesting and proves that you can go to the same goal in different ways. Leonardo da Vinci experimented a lot with natural forms, transferring their principles to the work of mechanisms.

Research is still ongoing, but in digital form, in the IT world.  An elephant can lift a load heavier than an ant, but an ant can lift more than its own weight. It is the anthill principle that those involved in microservices software development are engaged in.

Strategic planning for application architecture

The monument can be carved from a single piece of stone, or can be assembled from many small pebbles. For the viewer, the result will be the same, but the sculptor will have to build the composition differently and calculate the reaction of the support. Depending on the design, in one case a block is suitable, in the other – a mosaic.

By and large, the choice of architecture consists of two positions:

1. monolith
2. microservices

In the first case, the program acts as a whole, although it consists of parts (arm, leg, head of the monument). Communications between processes go as if inside a single shell, and the failure of one connection leads to damage to the other. In the second case, the application consists of many independent components that communicate on an equal footing. They can perform both their own tasks and general ones.

If we draw an analogy with the location of light bulbs in an electrical circuit, then a monolithic architecture is a serial connection, and microservices are a parallel one. In the first example, there is one flow of electrons, but if one lamp burns out, then all of them go out. In the second, several threads feed the lamps, which are independent of each other’s operation.

3. There is also a service-oriented architecture, in which services are used instead of independent components. For example, several processes require user authentication functionality. No need to rewrite the code for all processes, you can create a single authentication service and use it cyclically for all applications. This is how systems in a healthcare organization work, such as managing electronic health records.

If you imagine a conditional diagram of possible types of architecture, then service orientation occupies an intermediate position between microservices and a monolith, but due to key corporate features, it takes a place outside of direct communication.

Particular solution of a general problem

The work of the microservices system can be compared with the actions of a bee hive.  Each bee performs its own task, as a result of which a global product appears – honeycombs. At the same time, each individual insect may cooperate with colleagues, or may not be aware of their existence.

The main advantages of such a system are:

• Continuous service availability – each “bee” works without regard to the other, so it can be replaced, improved and redirected without harming and stopping the common cause

• Each container (hive) is always ready to work, even if it is not currently used – if necessary, no time is wasted on deploying the service

• For general work, you can attract “bees” of different breeds – it does not matter what language the service is written in and what it does, the main thing is that at the right time it can be updated independently of others, without changing the overall functionality

From the point of view of developing microservices, there are also a number of advantages, namely: teams can work according to their own schedules, functionality can be reused, databases remain independent.

Response time and points of failure

The principle of energy conservation doesn’t allow the process to have only positive properties, there must also be disadvantages. And although the work of microservices is an information structure, not mechanical, errors and failures are also possible in it. They need to be taken into account when designing the application architecture or redirect this task to specialized companies such as Digiteum.

There are also three main disadvantages of microservice architecture:

1. The distributed work of services can do a disservice – if there are many of them and each one simultaneously accesses the other, then the response time will increase and even points of failure may appear

2. integration processes and continuous signal delivery require a lot of interaction with system engineers, testers and service departments – the qualifications of employees must grow along with the complexity of development

3. problem with priorities – the independence of microservices generates inconsistency of actions, if one of them fails, the other may stop responding: the developer must strike a balance between consistency and availability of services.

Advantages and disadvantages of monolithic architecture

A key feature of monolithic systems is that they are managed from a single module, i.e., the application is delivered through a single deployment with a single entry point.

This provides the following benefits:

• easy implementation of business logic, without thinking about the interaction between processes

• simple execution of tests on aggregation of sellers with consumers

• easy deployment and easy scaling with scripts

A large accumulation of components can violate the architectural rules of communication, which leads to the following disadvantages:

• if at least one part of the system needs additional resources, scaling is difficult

• lack of isolation of components leads to slow down or even destruction of the application

• due to the existence of the foundation, the update leads to problems, since all parts of the architecture must be involved in it

A monolith is best suited for startup projects where a small application needs to be deployed quickly.

Convenience depends on the life of the project

Many experts agree that for business, in most cases, a microservice architecture is better than a modular one. But in the end it depends on the type of business and its tasks.

Developers (Digiteum included) pay attention to changes in properties as the project progresses. If at the start there is a difference in the development of functionality in favor of a monolith, then after the release of a minimum viable product, the situation changes in favor of microservices.