Microservices
Learn about microservices and their use in the context of architecture.
We'll cover the following...
I have finally reached one of my favorite topics and the basis for many passionate discussions nowadays: microservices. I believe that this architectural trend will be mainstream for many years to come, so I want to address it in this lesson.
Clarification of terminology
I have often heard from technical people that a microservice means a small service.
This assertion is not necessarily accurate. Here is why:
- While micro means small, in the case of microservices, this indication only refers to a size relative to previously popular SOA services. Historically, the motivation of the microservice architecture was to define finer-grained systems than the previous generation of SOA services.
The corresponding bounded context drives the actual size and boundaries of microservice, and this chopping exercise is not a mechanical “micro” level at all.
- As we all know, a service often means an API with endpoints, which we can invoke from the program’s code. Although a microservice sounds like a service, it does not necessarily need to be an API. In this case, service means capability.
Make sure that you understand the above clarifications to avoid falling into the trap of designing poor microservices.
Implementing microservices
As I briefly explained before, a microservice is an implementation of a bounded context from DDD. It is time that we delve into the technical intricacies behind this statement.
A microservice is a cohesive implementation consisting of all components that solve a specific business need. These components can include APIs with their endpoints, messaging middleware, long-running processes, jobs, console applications, UI applications, a database, etc. Indeed, a single microservice can have one or many instances of all ...