In recent years “microservices” has become a buzzword: it can seem that every modern application must be broken into many small services. We use them often in our projects, but not always: they solve real problems of growth and organisation, but bring new ones that come at a cost.
Here we look at what microservices are, the benefits they actually deliver, what they cost and when a well-structured monolith is the better choice. The right question is not “should we use microservices?” but “what problem are we trying to solve?”.
What microservices are
A microservice architecture splits an application into small, independent services, each with one clear job: managing users, payments, documents or notifications. Each service has its own code, is released on its own and talks to the others through lightweight APIs (interfaces that let one program talk to another, usually REST over HTTP) or through messages.
The alternative is the monolith: a single application that contains every feature and is released as one block. A monolith is not the same as old code: it can be modern, cleanly divided into modules and a perfect fit for its purpose.
The real benefits
- Independent releases: you can update the payments service without touching anything else, with smaller and less risky releases.
- Scaling only what needs it: if the catalogue is under load, you add copies of the catalogue, not of the whole application.
- Team autonomy: each group owns its services and works at its own pace, as long as it honours the API contracts.
- Fault isolation: if a secondary service goes down, the rest can keep running, provided it was designed to do so.
In the Atac ERP for Ernst & Young, for example, the application that manages tender procedures is split into Java and Spring Boot microservices, with Spring Cloud Gateway as the single entry point and each microservice in a Docker container on the on-premise system provided by the client.
The costs you don’t see at first
A distributed system is harder to design, test and run than a single application.
- Distributed complexity: a call that used to be a function becomes a network request, which can be slow, fail or arrive twice.
- The network: latency, timeouts, retries and security between services all have to be handled explicitly.
- Data consistency: with one database per service there is no longer a single transaction; you need events or sagas (sequences of steps with compensating actions) and you accept that data catches up after a short delay.
- Observability: to understand what is happening you need centralised logs, metrics and tracing of each request across services.
- DevOps maturity: DevOps is the set of practices that brings development and infrastructure operations together; with many services, automated build and release pipelines and monitoring become essential.
A well-known case: in 2023 the Video Quality Analysis team at Prime Video (Amazon) explained on its tech blog that it had merged a video stream monitoring service, originally built as a set of distributed components, into a single process, cutting infrastructure costs by over 90%. That is not a verdict against microservices, but a reminder: architecture should follow the real workload, not fashion.
When a modular monolith is the better choice
For many projects, especially early on, the soundest option is a modular monolith: one application divided into modules with clear boundaries, each with its own responsibilities and no direct access to the others’ data. It is released as one block, but it is already ready to be split one day.
It is the right path when the team is small, the domain is still changing, the load is predictable or mature pipelines and monitoring are not yet in place. In his 2015 article “MonolithFirst”, Martin Fowler observed that almost all the successful microservice stories started with a monolith that grew too big and was then broken up. And service boundaries are easier to draw once the product exists.
Signs that it’s time to split
- Blocked releases: a small change means rebuilding, testing and releasing everything, and teams keep getting in each other’s way.
- Very different workloads: one part of the application gets far more traffic than the rest or needs different resources.
- Growing teams: several groups work on the same code and coordination costs more than development.
- Different requirements: a critical component needs more reliability or more security and should be isolated from the rest.
- Boundaries already clear: modules have stable interfaces and their own data, so extracting them is an engineering task, not a redesign.
When these signs appear, it usually pays to extract one service at a time, starting with the clearest benefit, rather than rewriting everything.
The patterns we use in our projects
- API gateway: a single entry point that receives requests, checks access and forwards them to the right service.
- One database per service: each service is the only owner of its data, and the others read it only through its APIs.
- Messaging and queues: for long or non-urgent operations, services exchange messages through a queue, so the sender doesn’t have to wait.
- Containers: each service is packaged in a container, a standard bundle with the code and everything it needs to run, identical in development and production.
- Service registry and automated releases: services find each other without hard-coded addresses, and every change goes through a CI/CD pipeline (continuous integration and delivery).
In 2VitaBCognitive for Atlantia the application is made up of 6 Spring Boot microservices with the Eureka service registry, running in Docker containers on Amazon ECS and released through AWS CI/CD services. In the Hera ERP for Atos the REST microservices run on Microsoft Azure, with Spring Cloud Gateway, Eureka, sign-in through Azure Active Directory (now Microsoft Entra ID) and reports in Power BI.
If you are deciding whether to split an existing application or how to set up a new project, we start from your goals and your real workload, not from an architecture chosen in advance. Get in touch and let’s talk it through.
