How do microservices work (as opposed to monolithic systems)?
Let’s delve even deeper into how microservices work. As you know, in a standard monolithic system, the codebase can be roughly divided into two parts: the frontend and the backend. Each of these has a separate repository of code.
Typically, different teams would handle these and each layer can have its own dominant technology (e.g. React for frontend and Node.js for backend). This is illustrated below.
:quality(75))
How monolith architecture works?
As opposed to monolithic architectures, in a microservice-based architecture, the frontend layer remains the same, but the backend is split into multiple parts dedicated to specific functionalities. Each one of them can have its own repository. And since they are strongly encapsulated, each microservice can be potentially written in a different language, as can be observed in the graphic below.
This is a big advantage for the efficiency of software systems based on microservices, which alone can make up for many potential disadvantages of microservices, which we will also mention later.
:quality(75))
How microservices architecture works with multiple technologies?
For many projects – in which there is no need (or ability) to involve so many different technologies, and the presence of so many repositories creates confusion (complex project structure, difference in code organization between repositories, etc.) that outweighs the benefits of this separation – a simplified version can be used. By using monorepos, one can create repositories that include code for all microservices that use the same technology stack.
:quality(75))
How microservices architecture works with monorepos?
Back to the monolithic vs microservices question. How else does the microservices-based architecture differ from the monolith?
Microservices | Monolith | |
Development | Each service is an independent app. It might (but not necessarily need to) have a separate code repository, so conflicts are much less common. In order to share some code, you need to have a separate library. You can scale teams much easier because each team might be assigned to a specific service. Adding new features is either extending one of the existing services or adding a new one. | Everything is in a single place, so it’s much easier to share code. At the same time, it might lead to an unmaintainable state where everything is coupled. Working in the same area might lead to conflicts in code, which will lead to longer development time. Adding new features is about adding new code to an existing app. It’s harder to scale teams. |
Testing | Each service is a separate app that requires unit tests and component/contract tests. What’s more, we should add an additional layer that will allow us to test integration between multiple services at once. | Easy to test. Everything is in a single place. Most of the time, it can be covered with the unit and E2E tests. |
Deployment | Each service requires a separate CI and deployment process. You need to orchestrate the whole infrastructure and configuration for the whole system. However, if something goes wrong only a single service won’t be able to start up. | You set it up once. Does not require a lot of orchestration. However, if something goes wrong, you cannot deploy your app at all. |
Maintenance | Requires DevOps knowledge of Docker, Kubernetes, and more. | Easy to maintain |
Reliability | Breaking one service does not break others, so only a set of functionalities might be affected. | Breaking a single place in an app breaks everything. |
Scalability | Each service is scaled independently. We use only as many resources as we need. | In order to scale a single part of a system, you have to scale the whole system which might lead to resources not being used fully. |
Releasing | You release a single service, so only tests related to this specific service are necessary. | You release the whole system at once, so the whole regression is necessary every time. |
Authors
Adam Polak
A Certified AWS Solutions Architect helping clients use the cloud. He's a former software developer with experience in PHP, Node.js and frontend technologies. VP of Technology at The Software House. Passionate about East Asia; lover of Japanese food.
Mariusz Richtscheid
Software Architect experienced in backend technologies such as Node.js, cloud infrastructure, software architecture, and DevOps. Keenly interested in data engineering. One of the creators of Kakunin – our open-source framework for E2E testing. In his free time, Mariusz loves biking, machine learning, and 3D graphics.