For some time now, when developing complex applications such as management software or an operating program, the monolithic model—a single code unit encompassing all functionalities—has no longer been followed. Instead, the system is broken down into small components (services) that are independent from each other and interoperable. This is known as a microservices architecture.

In practice, the system is divided into many independent applications, each performing one single task and, by exchanging data with others, providing the same functionalities that the monolithic system would have had.

The advantages of this choice are many:

• Scalability: Each microservice can be scaled independently from the others, meaning resources can be allocated based on the criticality and demands of a service.
• Ease of development: Each service can be developed, modified, and fixed independently from the others.
• Ease of integration and updating: Services can be updated, modified, and fixed independently. This makes the system more adaptable to user needs.
• Error isolation: If an error occurs in one component, it is easier to isolate and fix it. Also, the impact on the rest of the system is minimal.
• Development speed: Each service can be developed by different teams, in parallel and with different technologies.
• Ease of testing: It is simpler to test the functionality of individual microservices, although it is necessary to create mockups of the components they interact with.

There are also disadvantages:

• Data consistency: Since teams work independently, the data exchange between services must be carefully, thoroughly, and collaboratively designed.
• Team coordination: Synchronizing the work of many teams is more difficult.
• Integration testing: Integration tests are complex because they involve interaction between programs created by different people and with different technologies.
• System management: Managing such a complex system requires software that automates its deployment.
• Communication overhead: Services communicate over the network, which is therefore subjected to significant traffic.
• System cost: A microservices system requires a complex infrastructure and a set of professionals (devops) who are dedicated full-time to its configuration, operation, and monitoring.

The key aspects of developing such a system and the challenges to face are as follows:

1. Correctly identifying the microservices.
2. Managing communication between microservices.
3. Ensuring system security.
4. Monitoring system status.

Correctly identifying the microservices

The division of the service into microservices must be done carefully. The system should be divided based on functionalities so that each subsystem is logically independent before being functionally independent. One should think of the various units as true independent applications. It is important that each of these applications performs one and only one task and does not depend on any of the others.

Managing communication between microservices

The key problem in building a microservices system is certainly the communication between the various components. The most used solutions are:

1. Using an API (synchronous communication): Each application exposes a series of endpoints for writing and reading data. For example, the checkout module can obtain the list of items in the cart by using the getItems endpoint of the cart module. The most commonly used technology to implement an API is definitely REST. But there are others like SOAP (which I personally consider obsolete), RPC, and GraphQL [8].
   

   

2. Using a message broker (asynchronous communication): In this case, there is a component called Message Broker that acts as an intermediary. A publisher/subscriber protocol is used where all messages are sent to the broker, which routes them to the correct recipient based on a subscription channel mechanism. One implementation of this communication form is the MQTT protocol, widely used in IoT.
   

   

3. Using a “service mesh”: This is a service offered by many commercial cloud infrastructures. In this case, each service is associated with a gateway (or sidecar) that handles sending and receiving all messages. There are two other components: the Data Plane, which includes all gateways and handles message routing, and the Control Plane, which manages the Data Plane configuration and thus routing policies, security, and monitoring. One of the most widespread implementations is Istio.
   

   

Ensuring system security

A microservices system works because the various components exchange messages with each other. This information exchange must happen securely and protected. Therefore, communications must at least be protected by some form of authentication and encryption. Each of the protocols mentioned in the previous paragraph, in addition to these two basic security mechanisms, has other more advanced ones. Another measure to increase security could be, for example, to ensure that requests are accepted only from certain IP addresses.

Monitoring system status

A system made up of so many components is not easy to manage, so an adequate infrastructure is needed, as well as tools that allow quickly identifying any errors, inconsistencies, or slowdowns. Various programs can be used for this purpose: Prometheus, Zabbix, Nagios, etc.

Migration from a monolithic system to a microservices one

The challenge many software houses have faced in recent years or are currently facing is the transition from old, massive monolithic applications to microservices applications. Rebuilding complex software from scratch is a huge and risky challenge; the smartest and least risky solution is to identify the logical components that make up the system and isolate, build, test, and integrate them gradually one by one. It is a long path, but it is the only one that increases the chances of success.

Sources and references:

• [1] The twelve factor app.
• [2] Microservices explained on TechWorld with Nana.
• [3] 10 DevOps Tools you need to know on TechWorld with Nana.
• [4] Pattern: Microservice Architecture on Microsercives.io.
• [5] Introducing Assemblage – a microservice architecture definition process on Microsercives.io.
• [6] What are microservices? on Microsercives.io.
• [7] Microservices Architecture: Il Pattern Architetturale Emergente Per Le Grandi Applicazioni Moderne by Giuseppe Capodieci.
• [8] SOAP vs REST vs RPC vs GraphQL on GlueLsbs.com.
• [9] What is a service mesh? on Aws.amazon.com.

*** Note: This article was automatically translated using a workflow created with n8n and OpenAI. The original version of the post is the Italian one.