Microservices Layered Architecture
With Microservices architecture, a single software application/functionality is implemented as a combination of multiple microservices and their interactions. Hence the communications between services and their coordination are vital for a successful realization of microservices architecture.
It is important to understand that, the tasks that an ESB does in an ESB based SOA implementation, don’t simply disappear when you switch to Microservices Architecture. Rather, all ESB/integration functionalities are segregated and dispersed among all the microservices. Therefore some level of logical organization of the microservices based on their granularity and capabilities is quite useful when it comes to the implementation of services.
So, if we have a closer look at the microservices implementation, we can identify different types of services that we can categorize into few different layers. We can come up with a layered architecture as shown in figure 1 ( I originally proposed as a logical set of layers, but this could well be a concrete layered architecture too) with different microservices types.
So, based on service functionalities and granularities, we can identify following service categories.
1. Core/Atomic Micoservices
At the bottom layer, we have fine-grained self-contained services (no external service dependencies) that mostly comprise of the business logic and less or no network communication logic.
2. Composite/Integration Microservices
Atomic microservices are often cannot be directly mapped to a business functionality as they are too fine-grained. Hence a specific business functionality may require a composition of multiple atomic/core services. The middle layer comprises of such composite or integration microservices. These services often have to support a significant portion of ESB functionalities such as routing, transformations, orchestration, resiliency and stability patterns etc.
Composite/integration services are coarse-grained(relative to atomic services), independent from each other and contains business logic(routing, what services to call, how to do data type mapping etc.) and network communication logic(inter-service communication through various protocols, resiliency behaviors such as circuit breakers).
Most of the ESB/integration capabilities(such as EIPs, resiliency and stability patterns) are realized in Microservices architecture at the composite/integration services layer.
These services also could bridge the other legacy and proprietary systems(e.g SAP ERP), external web APIs (e.g. Salesforce), shared databases etc. (often known as the anti-corruption layer).
3. API Services/Edge Services
You will expose a selected set of your composite services or even some atomic service as managed APIs using API services/Edge services.These services are a special type of composite services, that apply basic routing capabilities, versioning of APIs, API security patterns, throttling, apply monetization, create api compositions etc.
Technologies for building Microservices
When it comes to implementation of microservices, most of the current microservices implementation arbitrary use a given framework or a programming language to build microservices without taking the different service types into the account. With the proliferation of the number of services, this will lead to design, implementation and scalability nightmares. Therefore, we need to pick the right technology, based on the nature of the microservices that we are developing.
Core/Atomic Services: Most of the existing technologies are focusing on building these services. There are numerous of frameworks/libraries available for build this type of services (e.g. SpringBoot, Dropwizard, WSO2 MSF4J)
Composite/Integration Services: Most of the current microservice implementations tried to use the same set of technologies to build both core/atomic services and composite/integration services. However, most of the microservices frameworks and platforms are not designed for building composite services.
Therefore building composite services is becoming the most challenging task(just imagine the amount of work related to implementing various integration patterns from scratch, using Java or any other similar programming language) in realizing microservices architecture.
To overcome this problem There are emerging technologies such as Ballerina(which is a programming language designed for service compositions and network interactions), and Service Mesh frameworks (With ‘Service Mesh’ you can offload the network communications to the service mesh and we can only focus on Business logic. E.g. you don’t need to worry about circuit breaking when you call another service).
API/edge Services: Most of the existing (monolithic) API Management and gateway solutions can facilitate these service, as long as API services contain minimal business logic. However, most microservice implementations try to put a massive amount of business logic into this layer, while keeping it as a single monolith. That’s not a sustainable architecture and it violates the key principle of Microservice. So, there are two possible approaches to overcome this problem.
- Offload the compositions to composition layer and can use a monolithic gateway for just exposing them as APIs.
- Segregate API Gateway runtime(micro-gateway concept) so that each API/edge service can be built and manage independently.
The same technologies that we use to build composite service can also be used in API/edge service development. So, most of the existing (monolithic) API Management/Gateway solutions are still evolving to support concepts such as micro-gateways.
