Chapter 9 Application Architecture

Monolith Architecture

Monolith applications are applications that contain everything in one or two services. Usually a frontend and a backend. Before Microservices, which we will talk about next, monoliths were very common. Figure 9-1 describes what a monolith architecture looks like.

Figure 9-1.  Monolith architecture

In this example, we have a web client and a mobile client; both speak to the same API that in turn is connected to a data store. Depending on the size of the application, this API can potentially be huge. Let’s say there is one part of the API that is seeing intense usage and is slowing the entire API down. To solve this, we would need to scale the entire API or move it to a server with more power. Even worse, the entire system can go down because of a bottleneck in one place.

Another disadvantage of monolith services is maintainability. One big service containing all business logic is hard to maintain or even to keep an overview of what is where in the source code.

However, not everything is bad about monolith architecture. Depending on the size and complexity of your application, this might still be the right choice for you as microservices create extra layers of complexity besides the advantages they bring.

263

Chapter 9 Application Architecture

Microservices

Microservice architecture is a variation on service-oriented architecture. Creating a Microservices-based application means that the backend is split up into different loosely coupled services. Each service has its own responsibility and has no knowledge of the other services. Communication between services usually happens over a message bus. To prevent applications having to implement multiple endpoints, we can implement a gateway per application or type of application should we need to. That gateway knows the endpoints of the Microservices the application needs. Figure 9-2 shows a high-level architecture schema for a Microservices-based application.

Figure 9-2.  Microservices architecture

There is a lot to like about a Microservices-oriented architecture. The split responsibilities mean that we can scale the parts where scaling is needed instead of just pumping more memory into the virtual server. We can create gateways per client so that only the absolute necessary parts of the backend platform are exposed and so on. It also brings with it added complexity and cost; since each service is basically its own application, we need a lot of application servers; all of those servers need to be

maintained. Even if we went with a container orchestration system like Kubernetes, we get extra overhead, and exactly this is the danger of overengineering or over-architecting an application. Microservices are a great architecture pattern, but they are not the silver bullet for all applications; depending on your use case, a monolith application might be just fine.

264