The microservice architecture has been very popular in the industry past few years and we’re learning about the successful adoption of this architecture. The higher rate of architecture style adoption is due to the echo system that’s evolved around this architecture and benefits realized by the organizations. In this blog post, I’ll introduce the microservice, walk through steps to build more of a “Hello World” stateless microservice using the Microsoft Service Fabric, and deploy the microservice to local service fabric environment.

Before we dive in to the building of the stateful microservice let’s look at the basics of the microservice, purpose and types of microservice.

What Is Microservice?

As the name suggests, microservice is an architectural style to decompose the large service in to smaller units of service. There are different ways to decompose the large service and most commonly adopted and best possible way to decompose the service is by the business functionality.

Why Microservice?

We have adopted SOA for a decade and with REST capabilities offered by every language and development platform, the applications developed these days involve building of services and consumption of the services extensively.  Typically, during the design of the application, the architecture established are two tiers (UI tier, backend/service tier) or three tiers (UI, middle/business, data).  Backend or business service tiers are simple during the early stages of development and as the business functionality is added the tiers turn out to be monolithic large and complex services. This is natural with the application development. We’re in the era of digital transformation and there is more expectation than ever before to deliver new features to customer and compete in the global marketplace. The need for agility and deliver faster has forced us to rethink the approach of software development.  Agility is hindered by the monolithic application for the two main reasons:

  • Adding features or maintenance requires significant development and testing effort.
  • Poses deployment and scalability challenges. Entire application stack must be configured to be scalable and results in unnecessary scaling of the resources that’re more than the needs. Rebuilding of the code requires the dependent component to be rebuilt.

The pain points of the monolithic service have led to the adoption of the microservice architecture style to decompose the application components as suites of services. The benefit of the microservices are that the services can be decomposed and built by smaller teams, easily deployable and scalable.

Following are some of the notable points relevant to microservices from Martin Fowler:

  • Build products and NOT projects
  • Design for failure
  • Designing the consumer driven contracts.

For more reading about the microservices, refer to the this article posted by Martin Fowler.

What is Microsoft Service Fabric?

Service Fabric is a mature and reliable platform from Microsoft to build microservices. Microsoft has spent years to develop this platform and internally adopted for their own SaS offerings. Below is the excerpt from the Microsoft documentation about the offerings that use the service fabric:

Service Fabric was born from years of experience at Microsoft delivering mission critical cloud services and is production-proven since 2010. It’s the foundational technology on which we run our Azure core infrastructure—it powers services including Skype for Business, Microsoft Intune, Azure Event Hubs, Azure Data Factory, Azure DocumentDB, Azure SQL Database, and Cortana.

Benefits of Service Fabric have been proven and is a matured platform enabling the usage to rake the benefits of the microservices architecture style.

For quick reference, internal architecture of the Service Fabric platform from Microsoft documentation is depicted here:

Image Source 

Microservice Design

Applications can be designed to comprise of multiple microservice(s) that are either stateless or stateful or combination of stateful and stateless microservice.   Classic Cloud Service Work or web role are examples of Stateless service. Stateless microservice are backed by the cache or NoSQL databases to preserve the state and have slightly higher latency due to external state maintenance. On the other hand, stateful microservice manages the state internally making it best suitable for low latent use case scenarios.  To work with the state when building stateful microservice, reliable service and reliable actor programming model can be leveraged.

Following are the key characteristics of microservices:

Development Pre-requisites

To start with the development of the microservice, you can download the Service Fabric SDK from this link. SDK installs the necessary project templates and run time environment for the development of Service Fabric be it VS 2015 or VS 2017.  This blog will walk you through the steps to create stateless microservice on a Windows Platform with VS 2015 and Service Fabric SDK for VS 2015.

After the installation of the Service Fabric SDK, configure the local cluster to 5 node by right clicking on the orange star icon in the system tray as shown in the below screenshots. By selecting the 5 node setup, we can simulate the node failure scenarios and better understand the inner working of the availability and load distribution feature offered by the Service Fabric.

This would take few minutes for the multi-node cluster to be setup on a single box and when the cluster is ready, following notification is displayed.

Note: Under the hood, the Service Fabric cluster’s core window service “FabricHost.Exe” which runs on every node/VM starts the two executables Fabric.exe and FabricGateway.exe. In case of local environment with 5 node cluster, Fabric.exe spins up 5 instances of the two executables mimicking the multi-node environment. This enables us to locally develop robust microservices without having to wait until the  environment with multi-node infrastructure is setup.

Microservices Use Case

Let’s take the use case to design the system for the Healthcare Flex spending management.  Core needs of the flex spending system would be something like below and would include more core functions when we dive deeper in to the domain:

  • Enrollment and de-enrollment of the participants
  • Processing of the claim request
    • Dependent care
    • Medical expenses
    • Transportation expense
  • Payment transfer and reimbursements
  • Federal compliance reporting

After having identified the business needs, the next step is to design the application architecture.  The key factors to be considered while designing the system are (i) Speed to market (ii) Delivery channels (Mobile, Browser, Bots).

Traditional application design approach since the establishment of the SOA has been to create two tiers, Web Tier and service tier and most of the complex processing are stashed on to the service tier. Nothing wrong with this approach. To remain in business and to be competitive in the market, features need to be rolled out to the customers in a rapid fashion. This objective cannot be met with the traditional design approaches and we need to rethink the approach. So, decomposition is the mantra and microservices architecture helps address the agility.  For the above use case, one way to decompose the services will be something like below.

Microservices architecture helps with:

  • Agility – Enables parallel development of each microservice by smaller team (3-5 members).
  • Quick Scalability for growing business needs.
  • Deployment of granular services.
  • Effective utilization of the resources. With the use of Service Fabric, the servers/nodes will be effectively used through the hosting of the multiple services in a node. In the classic Azure cloud services, each service is deployed per server itself and resource is not better utilized. This is one of the major advantage with the Service Fabric over classic Azure cloud services.

As a next step let’s take one of the microservice MedExpenses API as a Hello World example to build the service using the Service Fabric framework and deploy to the local cluster.

Step By Step Instructions to Build Stateless Microservice Using Service Fabric

  1. Create a new project by choosing “Service Fabric Application” project template.
  2. You will be prompted to select a service template. Select “Stateless Service” in the below wizard and select “OK” for the projects to be created.

Once the wizard completes the project setup, two projects “FabrikamFlexSpending” and “MedExpenseService” will be listed in the solution explorer.

(A) The FabrikamFlexSpending project houses the Service fabric definition (Microservices Global definition) and configuration items such as application definition file, parameters file, publishing profile and PowerShell script to deploy the service to the cluster.

To expand further the contents of the service fabric project “FabrikamFlexSpending” has four folders (ApplicationPackageRoot, ApplicationParameters, PublishProfiles, Powershell scripts).

  • ApplicationPackageRoot – Defines the application manifest listing of the service types, type of service (Stateful or Stateless), configurable parameters. In simple terms this is just defining classes. Instances are configured in the corresponding stateful or stateless projects. It has been structured this way to automate, re-use and sharing.
  • ApplicationParameters –   Parameter values are configured for the various service fabric environments which could be cloud, local one node cluster or local five node cluster.
  • PublishProfiles – Deployment profile for various environments
  • Scripts – Contains the PowerShell script that is to be used for the deployment (new installation or upgrade).

For more details about the ApplicationManifest, ServiceManifest and parameterization please refer to the section Core Concepts.

(B) The project “MedExpenseService” contains the Stateless microservice which is to be instantiated during the execution. Also, the run time configuration/bootstrap code to execute the service through the Service Fabric platform is defined in the file Program.cs and OwinCommunicationListener. The boilerplate code in these files are added during the project initiation after the project template selection.

3. Default controller with the name “ValuesController” is added under the controller’s folder by the template. Let’s leave the controller as-is without any changes.

The WebApi startup configuration are defined in the Startup.cs just how they are bootstrapped in vanilla WebApi project created using the VS WebApi template.

4. Now that we have created a bare bone microservice, lets the deploy the microservice to the local cluster from Visual Studio using CTRL + F5. The WebApi URL  http://localhost:8944/api/values or http://localhost:{{portnumber}/api/values is opened.

Note  – ServiceManifest.Xml  under the WebAPI project > PackageRoot > Config folder contains the endpoint information including the port number.

With the microservice published to local cluster let’s explore the management of the service fabric using Service Fabric Explorer (SFE).

Service Fabric Explorer (SFE) runs at the port 19080 can be used to monitor and manage the cluster.  Default Url of the SFE is http://localhost:19080/Explorer/index.html#/ . SFR can be also be accessed through the system tray icon “Service Fabric Local Cluster Manager” and selecting Manage local cluster.

When we navigate to SFE and expand the application, we would notice that the microservice to be running on only one node even though we have 5 node cluster set up like shown in the screenshot.  Service fabric under the hood manages the distribution of the code and the life cycle of the service.

So, in situations when a node fails, another node in the cluster becomes active and handles the requests.  We could test this locally by selecting the node (in our case it is _Node_0) in the SFE and choosing the action Deactivating (Remove Data) from the top right corner. This action makes the _Node_0 unavailable and Service fabric activates another node in the cluster like in the second screenshot below.

Closing Notes

Microservice is a architecture style that helps build great software to demanding needs. Microsoft’s Service Fabric provides a reliable platform to build services using any language of choice (C#, Node, Java) and exposes management capabilities of the complete life cycle of the Microservices.

Lastly, customers using classic Azure cloud services can effectively use the Azure resources by switching to Azure Service Fabric and rake the benefits of the Service Fabric platform features.

As a next step to dive deep in to the microservices, I recommend watching the Microsoft Virtual Academy (MVA) videos from Jeffrey Richter to gain a deeper understanding and inner workings of Service Fabric. Furthermore, microservices developed using the Service Fabric can be deployed to  both Windows and Linux containers. Links to the service fabric documentation and videos are listed below.

References:

Videos:

Top Image Copyright: lupascoroman / 123RF Stock Photo