1. Designing A Microservice Architecture: Microservice vs Monolith

Microservices are a popular architectural style that aims to create modular, scalable, and resilient applications by breaking them into small, independent, and loosely coupled services. Each service focuses on a specific business capability and communicates with other services.

However, designing a microservice architecture is not a trivial task. It involves many challenges and trade-offs that need to be carefully considered and addressed. The process of designing a microservice architecture, starts from identifying the business domains and services, to choosing the database and communication models, to applying the best practices and patterns.

Why not create a monolith?

Before going into details of microservice design, let's look at the traditional monolithic architecture, where the entire application is built as a single unit that runs on a single server.

Monolithic architecture is a very simple architecture that comes with the following advantages:

• Easy deployment: A monolithic application can be deployed as a single executable file or directory, which makes the deployment process easier and faster. There is no need to manage multiple services, dependencies, or configurations as in microservices.

• High performance: A monolithic application can provide high performance, as it can avoid the overhead of network communication and data serialization between different services. The application can also leverage the benefits of shared memory, caching, and transactions within a single process.

• Simplicity: A monolithic application can be simpler to develop, test, and debug, as it has a single code base and a single development environment. The application can also use common frameworks and libraries that support the entire functionality. There is no need to deal with the complexity of distributed systems, such as latency, inconsistency, concurrency, and failure.

• Cost Effective: A monolithic application is cost efficient for multiple reasons like

  • Reduced infrastructure complexity as it can run on a single server
  • Simplified operations and maintenance as it can be deployed and updated as a single unit
  • It saves the operational overhead and costs as it can leverage the benefits of shared memory, caching, and transactions within a single process.

Recently Amazon Prime video migrated from microservice to a monolith architecture which helped in reducing their costs by about 90%. you can read more about it here

Going through these advantages of a monolith, It's obvious to think why we need a microservice architecture in the first place.

It's right, every application doesn't necessarily need to have a microservice architecture. It depends on many small factors like business requirements, how many resources are required and can be afforded, how traffic is distributed among different components of your application, etc. We will identify all such factors that will help us decide what's the right choice.

Let's take a look at some common challenges in a monolithic architecture and how microservices help in solving them:

Complexity

As a monolith application grows in size and functionality, it becomes harder to understand, maintain, and test. The codebase becomes bloated with interdependent components that have multiple responsibilities and dependencies.

The developer experience degrades with such a codebase, mostly for new developers, who cannot completely explore the codebase and get to know every line of code written, the business logic, and hidden behaviors. They don't know if a function already exists for doing something and ends up recreating it or what side effects will occur on doing changes at a component that is used in other modules.

In a big codebase, loading all the code in an IDE, finding a suitable place to make changes, and running tests/builds on CI/CD, all require too much time and resources.

Microservices can reduce the code complexity of an application by breaking it down into smaller and simpler units that focus on specific functionalities. Each microservice can be developed, tested, deployed, and maintained independently, which makes the application easier to manage and understand. Microservices also enable better separation of concerns and modularity, which improves the cohesion and coupling of the code

Scalability

As the application receives more traffic and load, it becomes harder to scale it horizontally (by adding more servers) or vertically (by adding more resources to the existing server). Monoliths grow up in size and can utilize resources in GBs.

Generally in such systems, only 30-40% of the code, resource, or components are responsible for the traffic. while the others are only for some rare tasks that don't happen very often.

Taking the example of an e-commerce application, It receives many orders and product search-related queries. Most of the traffic is around these components only. The other components like customer service, and user profile management, don't receive that much traffic. But when a monolith is scaled, it is scaled as a whole unit. Suppose you are getting 5 times more traffic for orders than for customer services, But you scaled both the database and servers to keep serving the traffic. That usually ends up getting more costly because more than half of the components of your application are never going to use that many resources.

In microservices, each component is built independently as a service. so they can be scaled independently according to their demand and resource consumption. This means that only the services that need more resources can be scaled up or down, without affecting the rest of the application. Microservices also enable horizontal scaling, which means adding more instances of the same service to handle more load.

Reliability

As the application consists of a single point of failure, any bug or error can bring down the entire system. The application becomes vulnerable to security breaches and data loss. The recovery process can become longer and more difficult.

Microservices can enhance the reliability of an application by making it more resilient to failures and errors. Since each microservice is isolated from the others, a failure in one service does not affect the whole application, as long as there are fallback mechanisms in place. Microservices also enable faster recovery and fault tolerance, as each service can be restarted or replaced without disrupting the entire system.

Innovation

As the application is tightly coupled with a specific technology stack. Migrating/switching to a new package or library or updating an existing one, switching to a better design pattern, technology, or framework becomes so hard, that it's better to leave it as it is. The application becomes outdated and less competitive due to these factors.

Each microservice can be developed and deployed independently, which reduces the risk of breaking the whole application or introducing bugs. so they enable experimentation and exploration, as new features, functionalities, libraries, or frameworks can be added or removed easily without affecting the core services.

Challenges in a Microservice

While microservices can address many of the challenges in a monolithic architecture, they also introduce new challenges that must be tackled. Some of the common challenges in a microservice architecture are:

• As the application comprises multiple services that run on different servers and communicate over the network, it becomes harder to coordinate, monitor, and troubleshoot. The system becomes distributed and asynchronous, which introduces issues such as latency, inconsistency, concurrency, and partial failure.

• As the application relies on multiple services that depend on each other, ensuring availability and quality becomes harder. The system becomes vulnerable to network failures, service failures, data corruption, and inconsistency. The system requires robust mechanisms for fault tolerance, error handling, logging, tracing, testing, and security.

In the next article, we will go through the process of Designing a microservice architecture, considering various factors, problems, and tradeoffs.