In a Microservices Architecture, several services constitute the whole application. Each service can run on different machines or in a different process. A service provides some functionality and can expose some information.

If you prefer the video version here is the link 😉:

Solving the Monolith Architecture

In the Monolith architecture, everything in an app is bundled together, usually within the same codebase. This allows easy code sharing and simple internal communication via function calls. And can enable simple tracing and debugging.

However, the monolith architecture has its limitations. All teams must use the same technology stack. Migrating to a new technology can be difficult, risky and costly. Teams must coordinate before releasing changes. Minor changes, even fixing a typo, require redeploying the whole application. On top of that, there is no easy way to give more resources (CPU, memory) to specific parts of the application. The whole application must be scaled, even if only a single part needs more resources.

The Microservices architecture is an alternative to the Monolithic architecture. It tries to overcome these limitations by dividing the application into smaller, independent services that can be developed, deployed and scaled independently. However, this approach introduces new challenges. Tracing requests across multiple services can be challenging, and failure in one service can cascade to other services.

However, there are patterns and best practices that can help build a reliable system.

Implementing Microservices the Right Way

Independent deployability is a simple concept but takes a lot of discipline and deliberate effort to achieve. Services need to be loosely coupled. To achieve loose coupling, the system is split into services based on business capabilities or business domains. For example, a video streaming application can have a user service, a video service, a recommendation service, and so on.

Another critical aspect is ensuring the services hide internal implementation and internal information. As a result, each service will have its own database or at least its own database area. Services will expose their capabilities through an API.

Services can send requests to each other using Inter-Process Communication (IPC) technologies. There are several options, but REST, gRPC, and message brokers are the most popular. REST has a wide adoption and can be easier for interoperability. gRPC is more performant and provides a clear API schema. Message brokers are great for asynchronous communication and can allow even more decoupling. It's also quite common to have a gateway service that acts as an interface between the internal domain services and external applications.

By splitting services by business domain and hiding internal information, changes to one service should not require modifications to another service, and there is a better chance of achieving independent deployability. But why so much emphasis on independent deployability?

The power of Microservices

The idea is that focusing on independent deployability capabilities unlocks other benefits. Because the services have clear boundaries and are loosely coupled, it makes it possible to build teams that can work independently. Each team will be responsible for one or a group of services.

Teams can choose the technology stack that best fits their needs. They can make changes to their services and deploy without coordinating with other teams. Or at least with minimal coordination. Not to mention that each service can scale independently. This is where the Microservices Architecture shines; it gives teams flexibility.

With great power comes great responsibility.

It takes a lot of work to build a reliable distributed system. In an attempt to reduce complexity, It's not uncommon for organisations to impose some restrictions on the technology stack or the approach to use. For example, teams may deploy their services as docker containers managed by Kubernetes in the cloud. This is a fairly common infrastructure setup. And more often than not, organisations rely on cloud providers such as AWS, Azure, or Google Cloud to provide the infrastructure. The same goes for other services such as databases, message brokers, etc.

Using Microservices Architecture has broad implications, and it's not a silver bullet. It's a complex architecture that requires technical expertise and implies organisational changes and consideration of how the teams are structured. But when applied correctly, it can be very powerful and allow teams to build large, scalable and reliable applications. And it provides a high degree of flexibility.