Lasagna or tortellini? Monolithic applications vs microservice architectures
In the IT field, we sometimes come up with juicy metaphors from the culinary field to explain development work better. This is the case of monolithic architectures and microservices. Two very different “dishes”: the first more like lasagne, with more layers, the second more like tortellini, therefore composed of more similar units.
While gastronomic choices lead to heated discussions at the dinner table, the IT world is no different, with its opposing factions. We shall therefore try to explore the pros and cons of each architecture model to understand what this debate is about.
Monolithic architecture
Monolithic architecture is without doubt, the most conventional and historically most used approach. Its structure demands that the application is built as a single unit. A user interface and server-side application made up of various modules that work with the data provided by the user and applies changes to the database that collects it.
The monolithic vision is similar to a soft, fragile lasagne which, despite being made up of several layers and enriched with various sauces, is a single piece.
| Pros | Cons |
|---|---|
| Simple to develop. Requirements, languages and technologies selected during the analysis phase |
Limitations in terms of size and complexity |
| Simple to test | It is often necessary to fully deploy the server for an update |
| Simple to deploy in production | Often a single bug in one part of the application, may have a knock-on effect on the whole application |
| Straightforward when scaling horizontally, as it is possible to make several copies of the server | The impact of a single change can have a domino effect, therefore it is essential to test it thoroughly |
| A change of technology or framework is often hampered as it upsets the whole application | |
| All server development is often delegated to a single responsible company |
Microservice architecture
Microservice architecture, as opposed to monolith architecture, is designed to develop an application as a collection of services.
While the external view from the user interface remains the same, the server logic is divided up into independent services with well-defined tasks. In the business environment, it is often the case that services are exposed by different providers and therefore all services are technologically different in their totality (language, database, etc.).
This distributed structure is very reminiscent of a large plate of tortellini, each one a little different, but overall they will satiate the hunger of those who order them!
A strong example of an application based on this architecture is Netflix. The final architecture includes more than 500 microservices (payments, video viewing, etc.) and the final diagram looks like the following:
Each green node represents the data store of a service, and the blue lines represent the connections between two microservices. While Netflix’s example may be an extreme, the concept of microservice architecture has been adopted in its entirety, even if the merits and shortcomings of this model remain.
| Pros | Cons |
|---|---|
| The problem of complexity is divided by breaking down the application into a set of services | Development is very complex |
| Each service can be developed independently by a team working exclusively on it | Tests take longer as each individual service has to be tested |
| The deployment of the microservice is separate from the rest of the application. | The need to be able to successfully orchestrate services through DevOps such as Docker, Kubernetes, etc. |
| The failure of a service does not compromise the application in its entirety | If a service depends on several microservices, and one of these services malfunctions, that service is no longer accessible |
| The application’s scalability is easier as each service can be scaled independently of the others |
Micro front-end
We have argued above that the front-end is not affected by the opposing choice between the monolith or microservices. However, this is not always the case.
Frequently, different services for an application are developed by different providers who independently develop with different technologies and languages. The same suppliers often also develop the graphical interface that relates directly to the service. The main screen of the UI then becomes a collection of these front-end components (often via <iframe>). In this case, we are referring to the Micro front-end.
The term Micro front-end was first adopted just over two years ago by Technology Radar and brings the concept of microservices to the front-end, with the responsibility for developing individual front-ends being left to the service provider. In this way, each team developing the service is technologically independent of the application as a whole.
Further information
For those who wish to explore the concepts set out below, a number of sources on which the article is based are provided.
Many concepts originated from our notes from the last edition of Pycon, an event dedicated to Python, one of the most widely used languages in the world, which took place in Florence in early May 2019.
Each green node represents the data store of a service, and the blue lines represent the connections between two microservices. While Netflix’s example may be an extreme, the concept of microservice architecture has been adopted in its entirety, even if the merits and shortcomings of this model remain.