Introduction to Micro-Architecture

Microservices Architecture (MSA) is becoming the SOA of the modern era. Like the way SOA improved the enterprise software architecture with new patterns and architectures around it, Microservices Architecture (MSA) has tripped off several new architectural styles and new concepts around how people build enterprise software. Some of them are

• Service Mesh - A technique to communicate amongst microservices.
• Serverless - Running your code as functions on the cloud.
• Micro-Integration - Running your integrations as microservices.
• Micro-Gateway - Running your API gateways in a microservices-compatible manner.

All these architectures can be categorized under the common umbrella of “microservices” and called “micro-architecture.” In this post, I’m going to introduce the micro-architecture and how Micro API Gateway can be utilized in such an architecture.

Figure 1: Micro-Architecture.

As depicted in the above figure, micro-architecture is independent of any type of infrastructure, vendor, or technology. It is an open architecture which can be implemented using the best suitable technology or vendor for the specific enterprise. Let’s understand micro-architecture a bit more with respect to the above figure.

We have three groups of microservices in the figure with three different colors. The microservices started with MS are real backend business logic implementations. MS-X and MS-Y depict two groups of microservices (e.g. lending and deposits microservices groups in a banking system). Each hexagon depicts a load-balanced, highly available microservice (e.g. Kubernetes service). The hexagons marked with MI are integration microservices which are integrating existing microservices (MS type) and providing a complex and advanced functionality.

The arrows connecting microservices with each other depict the service mesh functionality; internally, it uses a sidecar proxy (or not, depending on the selected technology stack). This component provides functionalities like timeout, retry, circuit breaker, service discovery, and load balancing on the transport layer (L3/L4). Then, the configuration of the service mesh is done through the control plane of the service mesh.

We also have the three diamonds, which demonstrate the API micro-gateway functionality where these gateways offer functionalities like security, caching, throttling, rate limiting, and analytics capabilities to the upstream microservices layer. In this diagram, we have used three different micro-gateways for three groups of microservices. This can be extended in such a manner that each MS or MI can have its own micro-gateway.

A Micro API Gateway is a special component in this architecture since it has some cross-cutting features which are already available in other components. If we take the functionality of the service mesh, it has some capabilities like load balancing, service discovery, and a circuit breaker, which are already available in the micro-gateway. It is important to understand that these functionalities are available for internal, inter-microservice communication while the micro-gateway uses these functionalities to expose services externally. This means that we cannot dismiss the necessity of an API gateway within a service mesh-type architecture.

The other cross-cutting component which overlaps with the micro API gateway is the micro-integration layer, where some capabilities like service orchestration, transformation, and composition can be done. We also need to clearly understand that the micro-integration layer offers these capabilities for internal services and at the developer level. However, the types of capabilities available at the micro-gateway are more towards the external user interaction layer, and sometimes users can directly use these features, like API composition to build their own APIs.

On the other hand, using a Micro API Gateway as a replacement for service mesh or micro-integration layer is not recommended, even though it can serve the purpose in some cases. That approach will introduce a lot more complexities when your system grows in the future.

The next advancement of the service which offered in this micro-architecture is the serverless (or Function as a Service - FaaS) capability to developers. Any technology vendor can combine the infrastructure layer with the micro-gateway and micro-integration capabilities hosted on their data centers to offer the serverless service to their customers, so that customers can write their implementations in their preferred programming language and run them as microservices under the hood within their infrastructure. In a serverless world, MS-type implementations will be done by the users and all the other components will be deployed, hosted, and maintained by the cloud provider.

Finally, the applications can consume the relevant APIs by contacting relevant micro-gateways. Based on the application type and the API requirements, the same application can use all the micro-gateways as well.

As the last piece of this article, I’ll share some of the existing technologies we can utilize to realize this micro-architecture.