“Microservices” is a trending topic. Big companies are trying to associate their technologies with this concept – but, it is important to know that you don’t need to use any particular technology to follow the microservices way.

In this and some future posts, I will share my understanding about Microservices with definitions and a lot of examples.

Let’s start with the basics.

What are Microservices?

A microservice is a small and autonomous service with one, and only one, very focused capability that a remote API exposes to the rest of the system. (Sam Newman)

A Microservice could be delivered as an isolated service on a platform as a service (PAAS), or it might be its own operating system process. You don’t need to adopt any particular host technology to work with microservices.

A Microservice is individually and quickly deployable. When you change a microservice, you should be able to deploy only that changed microservice to the production environment without touching any other part of the system.  If you need to restart/deploy other services when you deploy a microservice, you are doing it wrong.

To be autonomous, a Microservice owns its data store.

A system with Microservices is a distributed system.

What is a Microservice Architecture?

It is a style of engineering highly automated; evolvable software systems made up of microservices. Microservices architecture is a lightweight form of SOA where each service focuses on doing one thing and doing it well.

How should each microservice be architected?

When creating Microservices, I recommend adopting the Hexagonal Architecture Pattern.

In the figure, we have represented two microservices of an e-commerce system: 1) ShoppingCart and 2) ProductCatalog. Each one owns its own database.

ShoppingCart microservice uses an adapter to communicate with ProductCatalog.

ShoppingCart provides HTTP adapters to communicate with consumers – anyway; it is a design choice. It is pretty frequent to adopt other technologies like message queues, for example, for communication.

How should a system with microservices be architected?

A system built with microservices starts with an API gateway microservice.  The idea is to hide the microservices complexity of the customer application.

Each microservice is a separate process that uses their adapters to communicate with the other.

Why adopt a microservices architecture style?

A system built with microservices is robust by design being more malleable, scalable, and resilient.

It is simpler to practice continuous delivering with a microservices architected system.

Why NOT?

Microservice systems are distributed systems. They are harder to test than monolithic systems. It is also fair to remember that communication across process boundaries is slower than in-process method calls.

Microservices are developed, deployed and managed independently in production. At some point, a lot of monitoring tools will be necessary.

Next steps

Now that we understand the basics of the Microservices architecture style, we are ready to write some code…

Leave a Reply