Quick answer: A monolith is a single application where all the features live in one codebase and are deployed together. Microservices split the application into small, separate services that each do one job and talk to each other over the network. Microservices make it easier for several teams to work and release independently and to scale parts of a system separately, but they add a lot of operational complexity. For most small and medium sized businesses, a well structured monolith is the better starting point, with services split out later only where there is a clear reason.
Microservices have become one of the most talked about ideas in software architecture over the past couple of years. Large companies such as Netflix and Amazon have spoken publicly about running hundreds of small services, and container tools like Docker have made the approach easier to try. It is natural for a business planning a new application, or struggling with an old one, to ask whether it should go the same way. The honest answer is that it depends on your size, your team and your problem, and the right choice for a global streaming service is rarely the right choice for a company with three developers.
What a monolith is
In a monolithic application, everything lives together: the user interface, the business logic and the data access, usually sharing one database. It is built, tested and deployed as one unit.
Most web applications start this way, including most sites built on frameworks like Laravel, Ruby on Rails, Django or ASP.NET MVC, and platforms like WordPress and Magento.
Strengths of a monolith
- Simple to build at first. One codebase, one build, one deployment.
- Easy to test end to end. Everything runs in one place, so a full test does not need a fleet of services.
- Fast internal calls. Features call each other directly in memory, not over the network.
- One database. Transactions that touch several parts of the system are straightforward.
- Simpler operations. One application to monitor, back up and keep secure.
Weaknesses of a monolith
- It can become tangled. Without discipline, features become tightly coupled and changes in one place break another.
- Deployments are all or nothing. A small fix means redeploying the whole application.
- Scaling is coarse. If one feature needs more power, you scale the whole application.
- Technology is shared. Everything uses the same language, framework and versions.
- Large teams get in each other’s way. Many developers working in one codebase can slow each other down.
What microservices are
A microservice architecture breaks the application into small services, each responsible for one business capability: for example customers, orders, payments, stock and notifications. Each service has its own code, often its own database, and is deployed on its own. Services communicate through APIs, usually HTTP with JSON, or through message queues.
Strengths of microservices
- Independent deployment. A team can release the payments service without touching orders.
- Targeted scaling. Run more copies of the busy service, not the whole system.
- Fault isolation. A failure in one service need not bring down the rest, if designed well.
- Freedom of technology. Each service can use the language and database that suits it.
- Clear ownership. Small teams can own a service fully, from code to production.
Weaknesses of microservices
- Operational complexity. Many services means many deployments, logs, monitors and servers. You need good automation, containers or similar tooling, and people who know how to run it.
- Network problems. Calls between services can be slow or fail. Every service must handle timeouts and errors from the others.
- Distributed data. With separate databases, keeping data consistent across services is much harder. Simple reports may need data from several places.
- Harder testing. Testing a full user action can mean running many services together.
- Getting the boundaries wrong is expensive. If you split along the wrong lines, services end up constantly calling each other and changes need coordinating across teams anyway.
The question of team size
Architecture tends to mirror the organisation that builds it. Microservices solve problems that appear when many developers, often in several teams, work on one product and need to move independently. If you have one small team, most of those problems do not exist yet, and you would be taking on the costs of microservices without the main benefit.
A common view among experienced architects is to start with a monolith, learn where the natural boundaries in the business are, and only split out services once those boundaries are clear and there is a real need.
The middle ground: a modular monolith
You do not have to choose between a tangled monolith and a fleet of services. A well structured monolith is organised into clear modules, each with its own area of responsibility and a defined interface. Modules do not reach into each other’s data directly.
This gives you most of the maintainability benefits of microservices while keeping one deployment. It also makes it far easier to pull a module out into a separate service later, because the boundary already exists.
When microservices make sense
Consider splitting into services when several of these are true:
- Several teams work on the product and are blocking each other.
- Parts of the system have very different scaling needs, such as a search or image processing feature that needs far more resources than the rest.
- Parts of the system change at very different rates.
- You need different technologies for different jobs.
- You have, or can build, the automation to deploy and monitor many services: continuous integration, automated deployment, central logging and health checks.
When a monolith is the better choice
A monolith is usually the right call when:
- You are building a new product and still learning what it needs to do.
- Your development team is small.
- You do not have dedicated operations staff or automation.
- The application is moderate in size and traffic.
- Speed of delivery matters more than independent scaling.
Splitting an existing monolith
If you have an old application that has become hard to change, rewriting it as microservices in one go is risky. A safer approach is gradual:
- Identify one area that is clearly separate and causes the most pain, such as reporting or notifications.
- Put an API in front of it inside the monolith, so other code uses that interface.
- Move it into its own service behind the same API.
- Route traffic to the new service and remove the old code.
- Repeat only where the benefit is clear.
This approach, sometimes called the strangler pattern, lets the old and new run side by side while you move. Our guide to legacy system modernisation covers the wider process, and our article on REST API design covers how to design the interfaces between services so they stay easy to work with.
FAQ
Are microservices faster?
Not by default. Calls over the network are slower than calls in memory. They can scale better for particular workloads, but a simple monolith often responds faster.
Do I need Docker for microservices?
Not strictly, but containers make it much easier to package and run many small services consistently. Tools for managing containers at scale, such as Kubernetes, are still young.
Can a monolith scale?
Yes. Many large sites run on monoliths, scaled by running several copies behind a load balancer, with caching and a well tuned database.
Need help choosing an architecture?
We help businesses plan applications that suit their size and goals, and we modernise older systems step by step. See our custom development services.
