A Tryst with Microservices on Microsoft Azure ServiceFabric
Ever wondered about creating a truly SaaS solution that can cater to thousands of use cases and business rules having a huge user base across various tenants and accessed via multiple channels?
Let us jump in.. We would consider building a SaaS solution for a Customer relationship management system that does the Sales & Marketing functions right! All of this for a fictitious Consumer Product & Goods company called “Mico”. We can build it traditionally with bricks & mortar and be done with it…But, we are not here to create monuments. We are smart, the millenial bug has bitten us and we understand Mico’s digital transformation strategy!
The design thinking and solution architecture entails for a microservices based approach — a lego based approach!
We want to create these lego(s). And then, join them together, put some life in it and make our sweet little minion stretch & dance!!
Basic business building blocks for Mico
- Customer
- Products
- Sales Order — Invoice, Taxes & discounts
- Agreements with Customers
- Reward Management
- Pricelist for products per customer type
- Survey
- …..
The technical building blocks
We need a platform, preferably a PaaS (on-prem or on-cloud) to realise the technical building blocks..We have several options — IBM Bluemix, Amazon AWS, Redhat Openshift, Microsoft Azure.. Mico chose Microsoft Azure Platform to realise and host their sales & marketing solution. From the Azure catalog, following runtimes/services would create the symphony:
- Azure ServiceFabric = our microservices garage
- Azure SQL = our microservices best half
- Azure Biztalk Rules service = rules engine to our rescue..microservices best friend — currently in preview, has a much scaled down capability compared to its parent- Biztalk server business rules engine.
- Azure API management = the great face of what “Mico” does
- Azure Mobile App service = our magician..it does some magic w.r.t synchronization, push notifications etc.
- Azure Biztalk services = it does the dirty jobs of plumbing with other backend systems.
- Azure Blob storage = our media store
API for everything is the theme! Each layer in the architecture must expose APIs for consumption and most (if not all) of them are to be managed by the API management layer..This would promote an API-enabled ecosystem within the “Mico” enterprise — not restricted to sales & marketing functions only!
Azure API management component acts as the de-facto entry point from all channels. It provides a much needed facade with great features of rate limiting. “Mico” can leverage API analytics to make key decisions such as infrastructure scaling, channel optimisation etc.
In this post, let us have an understanding of designing & realising microservices on service fabric…
Microservices with Service Fabric
Azure Service Fabric provides a framework and runtime to realise the sales & marketing platform for “Mico”. This implies that several microservices would work in tandem and would form a honey comb. The microservices would follow the single responsibility principle and would manage their own dedicated data store.
Service Fabric is Microsoft’s next gen platform that is purpose built to realise this new paradigm of microservices. It provides a runtime that hosts the applications/services and manages the several nodes (machines as in VMs) on which they are hosted. Nodes are managed by a service fabric cluster. Auto-scaling(spawning new nodes based on load) and resource balancing (ability to move services from node to node based on resource limits) enables to meet the key non-functional requirements of scalability and resiliency respectively. For the developers, service fabric provides a SDK which is armed with couple of programming models:
A) Reliable services and
B) Reliable actors
Each of the above two models have 2 classifications each: Stateless & Stateful.
Let us take a pause before we jump into the intracicies of the programming models and the implementation patterns for microservices.
We’ve stepped in to 2016, and if we look back in 2015, we find that as per Gartner’s web-scale IT hype cycle, “microservices” is at the peak! The below diagram, indicates there are several others. The ones marked in colours are applicable for “Mico”. Although, I did not plot the technologies on the graph, microservices undoubtedly remains at the top of the curve!
The Sales Ordering process
Let us consider the sales ordering process of “Mico”. Primarily 4 major building blocks would be in play.
a) Customer: Each sales order would be associated with a customer
b) Product: Sales order line items
c) PriceList: Product price list can be categorized per customer type and is valid for a time period.
d) Taxes & Discounts: The applicable taxes & discounts per configured rules.
Microservices Identification Method
As of now there is no defined methodology of arriving at microservices but we can very well apply IBM’s SOMA (Service Oriented Modelling & Architecture) methodology to identify the microservices. Considering the sales sub-domain and performing a functional decomposition helped to arrive at the below microservices.
The microservices would follow the single responsibility principle and would manage their own dedicated data store. You can visualise the below microservices as micro-apps — they are literally on their own..
Interaction schematic
A typical interaction flow for the sales ordering process would be like below. Microservices interact in a chain to fulfill the ordering process.
Transactions can be initiated via the mobile app while the device is online. The requests flow via the API gateway (Azure API management layer) to the Azure mobile app service which in turn invokes the SalesOrder APIs(get, post). The SalesOrder microservice interacts synchronously or asynchronously(via event pub-sub mechanism) with other microservices while creating or updating a salesorder. It leverages the TaxDiscount microservice which in turn invokes the policy APIs exposed by Biztalk rules to execute the applicable rules.
Let us see how we classify & label the identified microservices using the Azure Service fabric programming models — stateless service, stateful service, stateless actor, stateful actor.
- SalesOrder.WebAPI: It is a stateless WebAPI service. This is a headless service that interacts with the APIs exposed by the SalesOrder service to retrieve, create, update & delete sales orders.
- SalesOrder.Actor: It is an actor-based service. A stateful actor is activated for each sales order created for a customer. The actor represents the lifetime of the order, from creation to invoice generation to receipt generation.
- Customer.Service: It is a stateful service that manages various customer types pertaining to various tenants (countries where ‘Mico’ operates). It is partitioned by tenantID that allows to hold the customer profiles for each tenant.
- Product.Service: It is a stateful service and holds product catalog information. It interacts with the pricelist microservice to retrieve prices per product per customer type & time period.
- PriceList.Service: Similar to customer service, PriceList microservice is a stateful microservice that is partitioned by tenantID as well.
- TaxDiscount.Service: Is a stateful service that holds the configurations for tax and discount calculation and applies them on a specific sales order.
Okay..we’ll pause again!
Based on the above discussions till now, it is evident that for the “Mico” enterprise, per the microservices architecture pattern, we are applying ALL the 3 dimensions to scaling: XYZ axis of scaling!
How is that ?
a) Y axis: We have already functionally decomposed “Mico’s” sales function and have identified the microservices
b) X axis: Azure service fabric provides out of the box support for cloning (via auto-scaling) and by having stateful service replicas
c) Z axis: Wherever necessary, Azure service fabric’s partitioning (data) capability is applied to route requests to specific nodes having a sub-set of data (in “Mico’s case, the sub-sets equates to tenants).
Realisation
For now, let us have 3 of the above microservices created: #1(the stateless webapi), #2(sales order stateful actor) and #4(product mgmt stateful service).
The microservices are contained within an application (MicoSalesMarketing)— it is a logical grouping that holds the related microservices.
For brevity, I have leveraged the standard WCF remoting for inter microservice communication. Note the uri to the microservices. The format is fabric:/<application-name>/<microservice-name>
Below is a view of the Service Fabric cluster. I have an instance of Service Fabric running on the local machine. The cluster has five(5) nodes(virtual machines). When the MicoSalesMarketing application is deployed to the cluster, the 3 microservices are distributed across the nodes automatically.
On the left panel, you can see how the resources are balanced by service fabric.
Let us have a different visualization of the above cluster.
Service fabric would apply automatic resource balancing, that is, would move the services from one node to the other if a specific node’s resource limit is reached.
If we drill down further, we would find how we applied partitioning on the above microservices and how their replicas are distributed across the nodes.
Partitioning
For the above stateful microservices (Product management & Sales Order), I’ve specified a partitioning scheme in the ApplicationManifest. Partitioning implies data partitioning of the stateful services. Partitions can be performed on a specific key(number range) or on a hash key. For a multi-tenant solution such as for “Mico”, we can include the tenantID as one of the parameters in the hash. Again, for brevity, I’ve considered a number range for partitioning.
Service fabric ensures the balancing of the partitions. For SalesOrder stateful actor microservice, each of the five partitions have a dedicated primary node and the 2 X active secondaries are distributed in other nodes. This allows for very high scalability of sales order process and optimum hardware resource utilisation. If a specific partition grows to node’s resource limit, Service Fabric rebalances partitions across nodes.
Below is a visualisation of the partitions replicas of both sales order stateful actor and product management stateful service. For a specific service, such as, Sales Order, we have one primary replica per node thus reducing the contention of data chunks for sales order. For this 5 node cluster, we can see that some of the nodes (nodes 1, 2 & 5) hold primary replicas of both the services. To scale out further, we can add more nodes to the cluster and end up with one primary replica per node. The overall performance of sales & marketing solution would definitely improve!
Microservices based architecture is not limited to the above facets of scalability and realization. A streamlined devops process with robust logging & monitoring of the microservices would result in a self-healing solution.
I would post more of my findings and experiments with microservices on Service fabric..Before I sign off, let me touch upon the failover perspective. Below is a view of our cluster map. Service fabric places the nodes (VMs) in a two-dimensional grid of fault domains and upgrade domains. This way the microservices would remain available in case of hardware failures and also during application upgrades.
You would find more details on the specifics of service fabric in Microsoft’s Service Fabric documentation. The documentation covers all the aspects of service fabric very well.
If you find this TL;DR helpful, please recommend or comment. If there are specific aspects you would like me to cover, please give me a shout. Oh and by the way, if you’ve found any error in this post, let me know please!!
