Differentiating microservices from SoA

Microservices architecture evolves from SoA, but it has key differences that we need to understand. Let's recreate the previous SoA example with a microservices architecture and review the differences and benefits for this type of architecture:

In this architecture, the layers are not bound together, as they are purely divided logically. Each microservice is completely decoupled from the other services, so even our UI components could be completely separate, deployable modules. These microservices own their own data and they could be altered without affecting each other. This is a capability that will stand out when facing continuous integration or delivery, as we could provision data for our tests and pipeline, without affecting other parts of the application.

Because of their independence, they could be very specific. We could use this benefit to build that expertise into our teams. An expert team that controls the domain logic from a business capability could effectively deliver better value to our products.

We could vary the range of development languages, platforms, or technologies to build each microservice. As they are completely independent, we could use a different database for each different business need, or perhaps use certain technologies that will give us the agility required to adapt to certain requirements more easily.

Since they are modular, we could deploy them independently and have different release cycles. When we need to monitor them, we could create different alerts or KPIs based on the nature of what they do and how they are done. It may not be the same for a microservice used in our accounting process as one that just provides content for our marketing banners. For similar reasons, we could scale them separately; we could have more servers for some microservices, or just more CPU or resources for others.

The infrastructure for microservices is usually simpler, as there are not as many complex servers to manage, configure, monitor, and control, no huge database schemas and, since the expertise within the teams is higher, more things can be easily automated. This will make DevOps culture within microservices teams a common practice, and with it we will gain even more flexibility within our products.

As microservice teams are usually small, there is a common understanding within the industry that the optimal size for a microservice team is one that could be fed with two pizzas. Whether or not this is the reality, keeping your team small will help to maximize the value of this type of architecture.

If we look at SoA and then microservices, what we can see is a natural evolution. Microservice architecture takes the advantages of SoA and then defines additional steps in that same direction. So, we can definitely say that: