1. Why microservices?

If you’re in a hurry, you can safely skip this chapter and head straight to the Microservices as seen from the client chapter. This Why microservices chapter is there for those that want to know why microservices should be used.

1.1 What are they?

Microservices are an architectural solution to several challenges faced by modern software. Among other things, they help solve either of the following requirements:

• over time there may be several front-ends for similar business processes (thick clients, SPAs, mobile applications, IoT devices, …), some of which unpredicted;
• applications may be hosted on-premises or in a Cloud infrastructure;
• applications should be resilient: they should remain available when outages occur over parts of its components;
• applications should be able to scale up: when demand is high it should be possible to run them over several machines in order to handle each request faster;
• applications should allow for replications, i.e., having duplicates across different machines or data centers so that computing power outage doesn’t make them unavailable;
• large teams working on the same application should be able to work as independently as possible;
• future applications are likely to interact with a part of the application you are building.

In order to achieve such goals, microservices’ architectures split an application into smaller blocks. If you’ve been architecting applications correctly you probably already separated your application code in projects, but that still makes for one big monolithic application.

A monolithic application bundles its pieces together into a single unit. that cannot easily meet the requirements expressed above. Here’s what a fictitious monolithic application could look like:

On the positive side, a monolithic application is easy to code and deploy.

In order to meet the requirements expressed earlier, a microservice architecture splits the application into several services. The following could be a microservice architecture corresponding to the monolithic application shown above:

How you split the functionality can be debated. It is generally good practice to make sure each service meets a functional need of its own.

1.2 Microservices induce complexity

Services are likely to depend on each other; which doesn’t appear in the schema above. For instance, considering the application above an order would most probably reference a client and several products. Which brings some questions like how do services reference each other? There are answers for that depending on what needs to be achieved. For instance there may be a service-discovery service, or a mediation layer.

This is just an example of the complexity that a microservice architecture brings. We’ll see more later but the scope of this book is not to cover it all, especially since there are potentially many answers to each problem.

What I want you to understand is that a microservice architecture is nothing simple. As the needs grow, the complexity will grow faster than in an equivalent monolithic architecture. My advice: use microservice architecture when you need to meet requirements like the ones listed at the beginning of that chapter. Otherwise keep with monolithic architectures, be it a service-based monolithic architecture.

Anyway, my point is about complexity not impossibility. There’s a lot of awesome tooling out there today that makes a microservice architecture much easier to code, assemble and deploy. We’ll see some of them in this book.