Briefly defined, microservices are chunks of software deployed on computer networks that communicate through network protocols. However, this is not all; they must also obey a set of further constraints.

Before giving a more detailed definition of what a microservices architecture is, we must understand how the idea of microservices evolved and what kind of problems it was called to solve. We will describe the two main steps of this evolution across two separate subsections.

The rise of SOA

The first step in the direction of microservices was taken by the so-called service-oriented architectures, or SOAs, that is, architectures based on networks of communicating processes. Initially, SOAs were implemented as web services similar to the ones you might have already experienced in ASP.NET Core.

In an SOA, different macro-modules that implement different features or roles in software applications are exposed...

In this section, we will give a definition of microservices and detail their immediate consequences on an organization, distinguishing between the microservices definition, which is expected to change gradually over time, and microservices practical organization, which might evolve at a faster rate as new technologies appear.

In the first subsection, we will focus on the definition and its immediate consequences.

A definition of microservices architectures

Let’s first list all the microservices requirements. Then, we will discuss each of them in a separate subsection.

A microservices architecture is an architecture based on SOA that satisfies all the constraints below:

• Module boundaries are defined according to the domain of expertise they require. As we will discuss in the subsections below, this should ensure they are loosely coupled.
• Each module is implemented as a replicable...

An application that requires more than five developers is certainly a good target for a microservices architecture since logical microservices help split the workforce into small, loosely coupled teams.

A high-traffic application with several time-consuming modules is also a good target for microservices architecture since it needs module-level performance optimizations.

Low-traffic applications that require just a small team of less than five people for their implementation are not a good target for a microservices architecture.

Deciding when to adopt microservices in all other situations that fall between the above extreme cases is not easy. In general, it requires a detailed analysis of costs and returns.

Considering costs, using a microservices architecture requires a development effort of about five times that of a usual monolithic application. We got this scale as an average on 7 total rewrites of monolithic...

In this section, we will analyze the fundamental patterns used in all microservices architectures whose description is not tied to a specific programming language or tool. Most of them concern microservice communication. Let’s start with common retry strategies.

Resilient task execution

Microservices can be moved from one machine to another to achieve better load balancing. They can also be restarted to reset some possible memory leaks or to solve other performance issues. During these operations, they may miss some messages sent to them, or they may abort some ongoing computation. Moreover, failure due to software bugs or hardware faults may occur, too.

Since microservices architectures are required to be reliable (almost zero downtime), they are usually redundant, and particular care is needed to detect faults and apply corrective actions. Therefore, all microservices architectures must provide mechanisms to both detect failures,...

In this chapter, we described the basics of microservices, starting from their evolution and continuing on to their definition, organization, and main patterns.

We described the main features and requirements of a microservices-based application, how its organization resembles more of an assembly line than a user-requests-driven application, how to make microservices reliable, and how to handle efficaciously both failures and all problems caused by efficient asynchronous communication.

Finally, we described how to make all microservices more independent from each other with publisher-subscriber-based communication and how to interface a microservices application with the external word.

The next chapter describes two important building blocks for building enterprise-level microservices: Docker and Onion architectures.

1. What is the main difference between a hold-style SOA and a modern microservices architecture?

In Microservices architectures are fine-grained. Moreover, each Microservices must not depend on the design choices of other Microservices. Furthermore, microservices must be redundant, replicable, and resilient.

2. Why are loosely coupled teams so important?

Because it is quite easy to coordinate loosely coupled teams.

3. Why must each logical microservice have dedicated storage?

This is an immediate consequence of the independence of the design choices of a Microservice from the design choices adopted in all other Microservices. In fact, sharing a common database would force common design choices on the database structure.

4. Why is data-driven communication needed?

This is the only way to avoid long chains of recursive request and answers that would cause unacceptable overall response times.

5. Why is...

• Eric Evans, Domain-Driven Design: https://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20
• More resources on DDD can be found here: https://www.domainlanguage.com/ddd/
• A detailed discussion of CQRS design principles can be found here: https://udidahan.com/2009/12/09/clarified-cqrs/
• ASP.NET Core REST API: https://docs.microsoft.com/en-US/aspnet/core/web-api/
• Datadog: https://docs.datadoghq.com/service_catalog/
• Backstage: https://backstage.io/docs/features/software-catalog/
• OpenAPI (REST API specifications): https://swagger.io/docs/specification/v3_0/about/
• Postman: https://www.postman.com/
• gRPC: https://grpc.io/
• RabbitMQ: https://www.rabbitmq.com/
• Azure Service Bus: https://azure.microsoft.com/en-us/products/service-bus/
• Ocelot: https://github.com/ThreeMammals/Ocelot
• YARP: https://microsoft.github.io/reverse-proxy/index.html
• Kong: https://docs.konghq.com/gateway/latest/
...