Microservices have been on the rise in recent years. It is possible to cut a large application (monolith) into smaller pieces to make it easier to design and manage. That sounds appealing, but microservices are not just roses and moonshine. In the start-up phase of a new application it creates a certain overhead, which in turn results in more work. When is it useful to switch to microservices? And when exactly not?
Advantages of microservices
The word “monolith” may remind you of a giant stone tablet, but is essentially nothing more than a term used to describe a whole unit within an IT environment. -or an application built from one code bundle. With microservices, it is possible to cut this code bundle up into small pieces and build functions independently in containers or lambda functions. By then linking them together through APIs, they work as a whole. This has several advantages:
- Programmers can work faster by picking up a small part of the application per team
- With large apps that many people work on at the same time, it is easier to manage and expand them.
Big and small
The latter immediately indicates where the hitch is. For large apps like Google Maps, Uber or Home Delivery, splitting into Microservices is indispensable. Such apps are constantly evolving and large groups of developers are working on them simultaneously. By splitting one can work in parallel on functionalities.
For many apps that are still in the initial phase, such an approach is overkill and can be counterproductive. By aggressively cutting your app into microservices from scratch, you waste a lot of time perfecting the development process, while there is not yet a complete picture of how users use the application, and which features lend themselves as a separate component (“Microservice”) by developing.
When to switch?
There is nothing such as a “monolithic” start-up phase per se. You want to start by testing functionality on end-users as quickly as possible via a so-called “minimal-viable product” (MVP). This is almost guaranteed to yield new insights, so you have to return to the drawing board. It is then ideal to gradually work towards a modular structure by changing pieces of code each time. However, do not hesitate to reassemble components if a component itself has no value. Prevent microservices from becoming the goal themselves, and let the road to microservices be primarily an organic process. Microservices often arise out of necessity. For example, because there is a bottleneck in the performance of certain functionality, or if an extra development team hires that focuses on a selective part of the code.
Do you want to know more about the advantages and disadvantages of microservices? We are happy to help you! Contact one of our experts for more information
