Week 119 — What is the difference between a monolith and microservices?
Question of the Week #119
What is the difference between a monolith and microservices?
4 Replies
Monoliths are typically (server-side) applications that run in a single process. These applications are easy to set up and can typically achieve good performance (especially low latency) due to minimal overhead. When one part of the application needs to make use of another, it can directly call that.
If a monolithic application needs to be scaled horizontally (i.e. creating more instances), the whole application can be replicated. With such an application, it is not easily possible to scale individual components.
Microservices aim to solve this issue by splitting the application into multiple microservices with different functionalities. Each service runs in its own process which can be distributed across different servers and scaled individually (i.e. one service can be scaled across more instances than another).
When one microservice needs to interact with another, it needs to do so via a network call. This results in higher overhead (in terms of communication overhead but there can also be higher memory overhead because more applications are necessary) and more implementation complexity (having many communicating components can be hard to implement).
Microservices can communicate either synchronously or asynchronously. For synchronous communication, a microservice sends a request to another microservice and awaits a response. On the other hand, asynchronous communication means that microservices send messages processed which are processed by other microservices without at a later point in time without awaiting any response.
📖 Sample answer from dan1st
Monolith and Microservices are software architecture styles associated with structuring and deployment of code.
All the logic in monolithic systems is grouped into one single codebase. The entire project needs to be redeployed even for a minor change in the codebase. The code is also very tightly coupled that leads to maintaining these applications very difficult as the project grows large. It's not all bad though. Since everything is in the same codebase, debugging and deploying these applications is easy. There are no additional network costs since the entire application runs as a single process and everything happens in memory.
However logic in a microservice based systems is distributed across multiple services, where each service performs a specific task. These services may communicate with each through direct API calls or via messaging queues like kafka. Since the code is distributed, many teams can work parallely on each service and deploy them independently. This leads to faster development and removes tight coupling.
Submission from oneplusiota
Monoliths and microservices are two possible architectures for building web services. The differences between the two lie in how the functionality is organized and composed.
Monoliths package all functionality into a single service. For instance, a "customer" service might expose all of the functionality needed to create and maintain customers, their contact info, billing preferences, shipping preferences, etc. It would typically be accessible through a single interface (such as a web endpoint, message broker, etc.).
On the other hand, microservices would decompose that functionality into multiple services that work together. In the "customer" service above, there might be separate services for customer maintenance, billing preferences, shipping preferences, etc. Each service would have its own artifact and runtime, and expose its own interface (e.g. a customer maintenance web endpoint, shipping preferences message queue, etc.).
The advantage of a monolith is in its simplicity. All of the code to support a particular set of functionality lives together in the same codebase, running in the same process, so there are no issues with compatibility or connectivity between services. The biggest downside is that scaling is more difficult or resource-intensive. To support more requests or batch processes, more copies of the service have to be run behind some kind of load balancer. However, suppose the "customer maintenance" functionality is where most of the load is. In order to support the additional load, the full set of resources required to run the service must still be allocated for every copy, including CPU, memory, disk, database connections, etc.
Microservices are almost the exact opposite. They are inherently more complex, because compatibility needs to be carefully managed at the public interface level in order to support the different lifecycles of each service. Connectivity between the services can be a bottleneck and source of errors. Additional complexity then needs to be built into the service itself to counteract these hurdles. However, each service can be scaled and moved around independently. Since each one is more lightweight than a monolith, the result is an overall savings in resources, along with better characteristics in other areas, such as scalability, throughput, etc.
Submission from dangerously_casual