Misinterpretations of Microservices and what Microservices truly is about

I’ve been in the data integration & application development space for quite some time now and interesting enough I see a lot of misinterpretations of what a Microservices architecture truly is about. Some people think Microservices architecture is new pragmatic approach of building small ‘miniservices’, lightweight services on top of (monolithic) applications, while others directly relate Microservices to Service Orientation and think all SOAP and REST services need to be replaced.

When I need to explain what Microservices is about, it is probably good to start explaining what an ‘application’ is. An application is a computer program designed to perform a group of coordinated functions or tasks. An application typically targets a problem area or tries to satisfy one or multiple users. The way organisations can develop their applications and can use the technical underlying infrastructure has changed over the last couple of years. Instead of seeing the application as a monolith, we have come to an approach of slicing up the application into multiple parts, which allows us to work on individual parts resulting in a higher agility and the ability to more flexible scale the individual parts of the application. This approach is illustrated the best by a picture, so let’s have a look at the image below.

The image on the left slide is a monolith in which the different layers of data, business logic and presentation are combined. The application is typically bundled as a single package. Changes to this application requires the complete application to be tested, packaged and deployed again. On the right side we see an application which uses the Microservices architecture. It consists of a set loosely coupled components. All the components together form the application.

The benefit of having a Microservices architecture is that the components can be developed, tested and deployed individually and independently. Another benefit is that each component runs in its own process, which makes the component much more scalable. Instead of having to scale the entire application we can now scale individual components.

The components in this architecture is something we call ‘microservices’. There are some other characteristics as well worth mentioning:

• Each microservice can have its own runtime, libraries, tools and functions needed in order to execute the microservices’ functions. Containerisation is a popular way of deploying.
• Each microservice can hold its own data.
• The communication to other microservices typically takes place via lightweight mechanisms (HTTP, GRPC, Thrift).

The last line item is probably where the most confusion is coming from. The microservices within a modern application can communicate in the same way as we see communication happing in the context of SOA. So this is where the overlap is, but the communication doesn’t have to be necessarily always the same as we see within SOA.

Developments of the underlying infrastructure

A big trend I see is the developments in the area of the underlying infrastructure. Serverless and platforms like Kubernetes make the management of deployment and scaling the microservices’ application much more easy, but it also brings challenges, which I can best clarify with a picture.

If we have multiple applications, broken down into microservices, running on the same platform, where do we draw the line? When using a monolithic application, it is easy because you are limited to fixed size of the unit. But with microservices it comes to scoping. The scope in which microservices interact determines the scope of the application. The ‘scoping’ is a subject on its own. The book Domain-driven design (DDD) by Eric Evans gives some very interesting insights. Martin Fowler's website also offers also a good starting point: https://martinfowler.com/tags/domain%20driven%20design.html

The principle I use to follow is that within the boundaries (scope) of the application developers have freedom, but when crossing the boundary of the application scope decoupling is required. Within ABN AMRO we do this with our Digital Integration & Access Layer Architecture:

https://www.dhirubhai.net/pulse/abn-amros-data-integration-architecture-piethein-strengholt/