When comparing microservices vs monolith, it's about one question. Do you split your application into many independent services or keep it together as one unit? Many experienced architects advise starting with a monolith. Microservices are worthwhile when size, teams, and operations support them. This is how you make the decision for your web application.

Microservices vs Monolith: What is the difference?

A monolithic architecture builds and operates an application as one unit. Microservices decompose the same application into small services that run independently of each other. You deploy a monolith as a whole, microservices individually.

What is the short answer?

  • A monolith runs as one process and is built and deployed as a whole.
  • Microservices run as their own processes and can be deployed individually.
  • In between lies the modular monolith. It clearly separates modules but continues to deploy as one unit.

Where do the terms come from?

The term monolith comes from the Unix world and describes systems that become too large. Martin Fowler and James Lewis described the microservice style in 2014. They understand it as an application as a suite of small services, each running in its own process and communicating via lightweight mechanisms. According to the authors, there is no formal definition, only common characteristics.

What characterizes monolithic architecture?

All functions are in one codebase and in one deployment. You operate a monolith more easily than many individual services. This is especially true at the beginning of a project.

What is a monolith?

Fowler and Lewis describe the typical monolith as a server-side application. It processes requests, executes business logic, and reads data from a shared database. Everything runs in one process. Every change requires a new build and a new deployment of the entire application.

What are the strengths of a monolith?

You can start and test a monolith on a developer machine. With a deployment pipeline, you deliver changes to production in a controlled manner. To scale, you start multiple instances behind a load balancer. Calls within a process are also cheaper than calls over the network.

Where does a monolith reach its limits?

As size grows, change cycles become coupled. A small change requires the build and deployment of the entire application. The modular structure can often only be maintained with difficulty. You can only scale the entire application and not the part with the higher demand.

How this manifests in everyday work is described in the article From monolithic to modular. Typical symptoms are long build cycles, unintended dependencies, and limited team autonomy.

What characterizes microservices?

A microservice architecture divides an application into small services that emerge along business capabilities. Each service runs in its own process and can be deployed independently. Microservices can shift complexity into the connections between services.

What characteristics do microservices have?

Fowler and Lewis name nine common characteristics. These include the following.

  • The application consists of services instead of libraries in the same process.
  • The services follow business areas and not technical layers.
  • Each service manages its data itself.
  • Services communicate with each other via simple mechanisms like HTTP APIs or messages.
  • An automated process deploys each service individually.
  • The application tolerates the failure of individual services.

What strengths do microservices bring?

Services can be deployed individually. A change usually only requires the deployment of the affected service. Each service forms a fixed module boundary, and different teams can be responsible for different services. Services may be created in different programming languages. You can scale specifically the service with the higher demand.

How big is a microservice?

There is no fixed size. Fowler and Lewis see a wide range in practice. The largest services follow the idea of the two-pizza team, i.e., a team with at most a dozen people. There are also setups where a team of about six people manages multiple services. What matters is responsibility for a business area and not the line count.

How do both differ in comparison?

The biggest difference is not in the code, but in operations and organization. The biggest difference lies in operations and team organization. The table summarizes the most important criteria.

Criterion Monolith Microservices
Structure One application, modules in the same process Many services, each in its own process
Deployment The entire application Each service individually via automated pipelines
Data storage Usually one shared database Each service manages its data itself
Consistency Transactions via the database Coordination without distributed transactions, often with eventual consistency
Scaling The whole application as a unit Targeted per service
Error handling Calls in process Every call can fail and needs a reaction
Teams Often separated by technical layers By business areas in cross-functional teams
Operations Monitor one application Many services with their own monitoring

How do deployment and operations differ?

You deploy a monolith as a whole. One pipeline is sufficient for this. With microservices, you need many pipelines and strong automation. Fowler and Lewis admit that more services in more complex topologies are harder to deploy. Small steps, feature flags, and a clean pipeline help in both cases, as the article on Continuous Deployment in Practice shows.

How do data and consistency differ?

A monolith usually uses a shared database and transactions. This ensures consistency but tightly couples the parts temporally. Microservices manage their data per service. Distributed transactions are difficult to implement, so teams coordinate without transactions and initially accept eventual consistency. They compensate for errors through compensating operations.

How do scaling and fault tolerance differ?

With a monolith, you scale the entire application. With microservices, you only scale the service with the higher demand. However, every call between services can fail. The application must tolerate the failure of individual services. Fowler and Lewis call this a disadvantage compared to the monolith because it means additional complexity.

What microservices disadvantages are there?

The microservices disadvantages are missing in many comparisons. Fowler calls them the microservice premium. It increases the costs and risk of a project and often brings it into serious difficulties according to Fowler. His Microservices Guide collects the details. The disadvantages particularly affect teams without mature automation and operational experience.

Why does complexity increase?

Calls over the network are more expensive than calls in process. Therefore, interfaces need a coarser granularity. Shifting responsibility between services is harder because you cross process boundaries. Fowler and Lewis also warn of an effect. If the components don't fit together cleanly, complexity only migrates into the connections.

What are the consequences of distributed data storage?

Each service owns its data, so there are no overarching transactions. Teams work with eventual consistency and compensating operations. According to Fowler and Lewis, this is a new challenge for many teams. However, it often corresponds to business practice, as long as corrections cost less than lost orders.

What prerequisites do teams need?

Fowler says you shouldn't rely on microservices without certain basic competencies. As a hurdle, he mentions among other things a mature operations team for many regularly redeployed services. This fits with the observation by Fowler and Lewis that successful teams rely heavily on continuous delivery and automation. The team structure must also fit the architecture, as the article on Architecture Modernization shows.

What does the Prime Video case teach?

The Prime Video team described in 2023 how it merged a sub-service for monitoring video streams into a monolith. The initial setup used distributed serverless components. According to the team, infrastructure costs then decreased by over 90%, and the service scaled better. The report at InfoQ cites as causes among other things costs due to data exchange between the components and limits in orchestration.

The service is just one building block of the platform and not proof against microservices overall. However, the case shows that too fine a decomposition can become expensive.

When does which architecture make sense?

The choice depends on team size, operational maturity, and scaling requirements. Start simple and only split when a concrete problem demands it.

When is a monolith sufficient?

  • A small team is responsible for the application.
  • Scaling requirements remain manageable and concern the application as a whole.
  • You don't yet have experience with the automated operation of many services.
  • The product is new, and domain boundaries are still unclear.

Fowler observes in Monolith First that almost all successful microservice stories started with a monolith that became too large. He admits that this advice is not ideal. A good interface in process is rarely a good service interface.

When are microservices worthwhile?

  • Multiple teams work in parallel and hinder each other on one codebase.
  • Parts of the application have very different scaling requirements.
  • Domain boundaries are clear and stable.
  • Automated deployment and operations are established.

When does a modular monolith fit?

The modular monolith clearly separates modules but continues to deploy as one unit. Fowler and Lewis mention the advice to keep a monolith modular and only split when needed. The article From monolithic to modular calls it a pragmatic entry point that doesn't immediately bring the complexity of microservices.

How does the transition from the monolith succeed?

The transition succeeds gradually and not in a big bang. Detach parts step by step instead of replacing everything at once. This is described by the strangler fig pattern, which Fowler introduced as Strangler Fig Application. A new system slowly grows around the old one until it is replaced.

Which steps are part of the transition?

  1. Analyze the codebase and identify the business domains.
  2. Identify and reduce dependencies.
  3. Define module boundaries and interfaces.
  4. Adapt tests to the modular structure.
  5. Implement step by step and start with a non-critical module.
  6. Check separate deployments as an optional final step.

The steps come from the article From monolithic to modular. How new parts can be safely deployed with feature flags and vertical slices is explained in the article on Continuous Deployment.

What pitfalls threaten during migration?

The biggest risk is described by Architecture Modernization as the "death valley of migration". The old and new systems then run in parallel, are tightly interwoven, and neither functions completely. Typical are duplicate data storage, functions distributed across multiple systems, and increasing complexity for developers.

The way out lies in clear boundaries between old and new systems. Integration runs via defined APIs and events, not via shared databases. How to gradually untangle grown systems is shown in the area Legacy Software Modernization.

Conclusion

Microservices vs monolith is not a question of belief. A monolith is the simpler start and can be sufficient for many applications. Microservices are worthwhile when multiple teams, different scaling, and mature operations come together. The modular monolith combines both worlds and allows a gradual path.

Would you like to assess your architecture or plan the transition? Arrange a free initial consultation with us.

Frequently Asked Questions

The right answer always depends on the context of your project.

Are microservices better than a monolith?

No, not fundamentally. Fowler and Lewis report that many teams experienced microservices as superior and others as a burden that slows productivity. The context decides.

From what team size are microservices worthwhile?

There is no fixed number. As a guide, Fowler and Lewis describe services that a team with at most a dozen people is responsible for. What's important is that multiple teams can work without mutually blocking each other.

Can a monolith scale?

Yes. You start multiple instances behind a load balancer. In doing so, you scale the entire application and not individual parts.

Can a monolith be split later?

Yes. This succeeds step by step via a modular structure and the strangler fig pattern. With Laravel, packages create good prerequisites for modular structures.

Sources & Further Reading