Decomposing Monolithic Applications into distributed Microservices is an art. The process could be anything from just adding few Microservices or transforming every aspect of solution architecture into Microservices.
It was easy to shred a Monolithic Application (talk Microservices) into small logical services, but it felt like 10x10m photograph cut into the jigsaw of 1000s pieces when realign to service boundaries (actual work). For a good introduction about Microservices please read martinfowler.com .
The challenge is how to decide the service boundaries; there are many articles from various thought-leaders that I can refer to you. Thus, it would not be a good use of the blog post to discuss and being a critic of proper methodology. Here are some references,
- Decompose by business capability
- Decompose by domain-driven design subdomain
- A detail guide by Martin Flowler
Let us come back to the topic; the following figure explains the fictional current state architecture and target state architecture (Microservice Architecture).
The above architecture diagram represents monolithic architecture on the left side while a target architecture on the right side. Monolithic Architecture has transformed into three service layer and an UI layer.
Now, let us try to understand what are the characteristics of the individual layer and placing building blocks using Microsoft Azure.
API Layer
With a Microservice Architecture, the API Layer provides decoupling consumers from the services. API layer can also act as control point where it can authenticate and authorise calls, throttle requests, telemetry supports and data validations without having implemented for individual services.
Typically, the API layer can describe with following characteristics,
- Self-contained or Single Granular Function
- Light-weight
- Resilient
It works as a backbone of UI as next layer. Thus API layer faces some unique challenges than other layers, i.e. Security (OWASP Top 10), High Availability and Performance.
In Cloud Architecture Pattern: Azure Service Fabric and Microservices – Part 1 (Physical Architecture), we have already discussed significance of Application Gateway, Internal Load Balancer, Service Fabric and VM Scale Set.
API Management
Azure API Management is a managed service by Microsoft Azure, it is an optional service in proposed physical design.
Key services provided by API Management,
- Verifies API Keys, JWT Tokens, Certificates as credentials.
- Accept API calls and route them to correct domain.
- Ability to enforce quotas and rate system (ideal for commercial service providers).
- Layer-7 Cache.
- Logging (Metadata and Analytics).
- Transforms and composite API (without code).
- Prevent DOS attacks.
- Provides development portal (very useful for testing API).
Composite layer
The aim of Composite Layer API is to construct the aggregated response or orchestrate some core services to perform a task while allowing each domain core service to construct a fully hydrated response.
The composite layer could also be useful to handle domain ambiguity, concurrency, competing subscriptions, handling payload (custom response by delivering request specific parameters). I come across an excellent article by Vinay Sahni describing various possibilities around composite service layer.
Why Service Fabric is an ideal choice for Composite API?
Let us try to answer the question using Aggregator Microservices Design Pattern, in the simplest form an aggregator would be invoked to aggregate data from various backend services and pass it forward. It is a typical case for Composite API.
Typical Composite API would be high throughput, data and compute-intensive services. The common challenge to deliver efficient composite API is distributed computation and distributed-state hydration. Service Fabric ( Key capabilities ) complement the purpose high-throughput computational API.
Core Layer
Core Services handle persistence of domain data and apply business rules, processes and other logic. While a high level of reuse is desired thus agility, availability, continuity, eventual and distributed consistency are the major factor for any successful core services implementation.
Core Services are components and organised around business capabilities or domain boundaries, it uses decentralised governance and decentralised data management. The services also endorse Single Responsibility Principle.
How Service Fabric fits into Microservices?
For this comparison, I am going to take subject neutral reference as view point. Microservices.io is driven by Chris Richardson, a thought-leader on the subject. We are going to refer solution benefits & drawbacks and iterate them with Microsoft Service Fabric.
| Requirements for Microservices | Mapping element of Service Fabric |
|---|---|
| Microservices are relatively small, IDE faster and making a developer more productive, the application starts faster and speed up development | Service Fabric programming model using VS.NET, or host guest executables and application frameworks i.e. .NET Core or Node.js |
| Deployed independently of other services, easier to deploy new versions frequently. Each team can develop, implement and scale their services regardless of all of the other teams. | Deploy applications in seconds. Deploying hundreds or thousands of applications per machine. Deploy different versions of the same application side by side, and upgrade each application independently. |
| Fault isolation | Watch the self-healing resource balancer orchestrate the redistribution of applications across the cluster. Service Fabric recovers from failures and optimises the distribution of load based on available resources. |
| Should eliminate any long-term commitment to a technology stack. | Application frameworks of your choice, such as ASP.NET Core, Node.js, etc. |
| Dealing with the additional complexity of creating a distributed system. | Your applications automatically scale and are distributed according to the available resources. Resource balancer orchestrate the redistribution of applications across the cluster. |
| Deployment complexity. | Service Fabric enables the deployment of multiple application instances. Each instance is managed and upgraded independently. |
Microsoft Azure and Service Fabric can support many sub-patterns within Microservices patterns. i.e. Client/Server side Discovery, Single/Multiple Service Per Host, Chassis Pattern, Log Aggregation, Application Metric, Audit Logging, Exception Tracking and Health Check API (probes).
Microservices can explore the 3D scale-up model in Azure (X-axis for performance, Y-axis for functional decomposition or service host and Z-axis for data persistence) using PaaS only. That helps organisations to bring down their operational cost (service management) and also benefit from business continuity.
In the next series of post, we would discuss Service Fabric from Security perspective.