Microservices are a great way to develop modern cloud-native applications. Traditional approach to developing software applications where the entire functionality is encapsulated into a single monolith, has many challenges as the functionality of the application grows. Before you know, what started out as a proof-of-concept or an application that’s designed to meet the needs of a small set of users, quickly evolves into a huge monolith. With growing size comes growing pain.

Monolithic applications are difficult to develop, maintain or enhance. They aren’t as robust as they need to be and significantly increases the development cycle to quickly build and add new features.

Microservices approach to developing software addresses most of the issues with developing monolithic applications. If architected correctly, they can assist in rapidly building newer features and enhance the existing system. They can significantly help in reducing the bottlenecks and can improve the agility of the development teams.

Since the functionality is broken down into small set of services as opposed to one large application, developers can quickly spin up new services as the needs arise. Making changes to one service will have little to no effect on other services. If it’s coupled with other strategies like Event Sourcing, Continuous Integration, Continuous Deployment etc., it’ll be a breeze to continuously develop new services and enhance the existing ones. Development cycles will be much shorter and newer features can be rolled out much more quickly.

Having said that, if you’re not careful, Microservices approach can introduce more problems than they solve. Microsoft Azure Service Fabric is designed to alleviate some of the pain points and provide a platform to manage those microservices effectively.

Tooling around developing Microservices comes in various flavors. You can take the containers approach to developing Microservices (using Docker or Windows Containers) and manage them using Docker Swarm or Kubernetes. Each container can have a set of services bundled with-in it and can work independently.

You can also use a managed platforms like Azure Service Fabric provided by Microsoft. Applications developed using Service Fabric platform can be deployed on an on-premise cluster or through a cluster created on a cloud provider of your choice. Of-course, Microsoft Cloud has the first class support for provisioning Service Fabric Clusters through the portal or via ARM Templates.

I personally prefer managed platforms like Service Fabric because it provides most of the plumbing required to design, develop and maintain microservices. The tooling with Visual Studio is top-notch and it integrates seamlessly with Visual Studio Team Services (VSTS) for Continuous Integration and Deployment to the cluster. If you decide to leverage Microsoft Cloud (Azure), services running on Service Fabric can seamlessly integrated with other services on Azure such as API Management, API Gateway, Application Insights, Service Bus etc.,

Service Fabric clusters can be very secure. You can enable cluster security via certificates. You also have an option to deploy the Service Fabric cluster to a VNET along with other resources.

What exactly is a Service Fabric?

At it’s core, Service Fabric is a distributed systems platform used to build hyper-scale, agile and fault-tolerant microservices on the cloud. It provides set of services for orchestrating the functioning of the applications deployed on the cluster. It abstracts complexities around provisioning, deploying, fault handling, scaling and optimizing the applications that are deployed to the cluster.

It’s responsible for fault handling and recovery of services, should something fail. Service Fabric plays the same role as some of the other microservice orchestration platforms such as Docker Swarm, Kubernetes, Mesosphere, Core OS etc.,

The following figure, provided by Microsoft, shows the features provided by Service Fabric out of the box, to all the applications deployed to the cluster managed by it.

Programming Model

Service Fabric supports quite a few programming models to make it easy to develop variety of microservices. Each service can be either stateful or stateless.

Stateless services are typically used for creating Web APIs or any other service that doesn’t need to maintain their state on the nodes. These services will treat each request as an independent one and will assume all the information required to process the request is contained with-in it. State is maintained in external data-stores like SQL Server, CosmoDB or Redis cache etc.,

Stateful services on the other hand maintain their state on the same cluster. Service Fabric provides data-structures that can replicate state through all the nodes in a cluster. It provides APIs for storing, retrieving and updating data structures. Any time an update is made to a data structure, it’s automatically replicated to all the nodes in the cluster and made available to other instances of the service running on other nodes in the cluster. Since the data and the services are co-located, it can significantly reduce the latency in processing the data.

It also has a first class support for Actor programming model based on the Virtual Actor pattern.

Service Fabric can also help with Service Discovery, Partition Resolution, Replica Selection, Fault Tolerance etc., That way, the team can exclusively focus on the business logic of the services and leave the infrastructure management to service fabric.

Service Fabric Advantage

Microservices developed using Service Fabric can leverage many of the features that come out of the box.

Here are some of the features that come out of the box :

• Hyper Scale — Application developed using Service Fabric can be independently created and deployed without any dependencies. The services can be auto-scaled based on CPU Consumption, Memory Usage etc., Service Fabric can help with maximizing resource utilization with features such as load balancing, partitions, and replications across all nodes in the cluster.
• Partitioning — Stateful services can be partitioned across multiple nodes in a cluster. The partitions are re-balanced regularly to ensure resource availability to each service deployed on the cluster.
• Rolling Upgrades — Services deployed on service fabric platform can be updated in stages with minimum downtime. The update domains are used to divide the nodes in the cluster into logical groups which are updated one at a time. When a service needs to be upgraded (new version deployed), Service Fabric can ensure that newer version can be rolled out one node at at time, thereby ensuring that there is no downtime.
• High Density — Service Fabric offers native support for Microservices. Each service hosted on the Service Fabric will be logically isolated and can be managed without affecting other services. This ensures that a relatively high number of Microservices can be deployed to a node, to maximize resource utilization. This can significantly reduce the costs associated with hosting applications.
• Fault Tolerance — Microservices deployed on Service Fabric can leverage the support of automatic fault tolerance. When Service Fabric detects a fault on an instance of a microservice, it can automatically spin up the new instance of the microservice on a healthy node within the cluster to ensure availability. This process is completely automated and requires no additional effort from the teams managing the clusters or developing microservices.
• Reverse Proxy — When you provision a Service Fabric cluster, you have an option of installing Reverse Proxy on each of the nodes on the cluster. It performs the service resolution on the client’s behalf and forwards the request to the correct node which contains the application. In majority of the cases, services running on the Service Fabric run only on the subset of the nodes. Since the load balancer will not know which nodes contain the requested service, the client libraries will have to wrap the requests in a retry-loop to resolve service endpoints. Using Reverse Proxy will address the issue since it runs on each node and will know exactly on what nodes is the service running on. Clients outside the cluster can reach the services running inside the cluster via Reverse Proxy without any additional configuration.

• API Management — Most of the microservices don’t expose endpoints directly to the external world. Typically, an API Gateway is created that acts as a liaison between the microservices and the client applications. Azure provides a way to deploy an API Management Service within the same VNET the Service Fabric is running on. It can completely eliminate a need to develop a separate service that acts as an API Gateway. It can be hooked up to a Service Fabric cluster (for backend) and can take on requests from the client applications and forward them to the individual microservices. It provides powerful features for managing endpoints, security, request/response transformation, request throttling, user management etc.,

• Service Fabric Explorer — Apart from providing awesome features to help orchestrate the functioning of your Microservices, Service Fabric also provides an awesome explorer to help you visualize the state of your applications and the nodes on which they are running. Service Fabric explorer provides a quick glance of the health of the nodes and shows your what applications are running on which nodes. It’ll also show you any errors/warnings on your applications to give you an insight into what’s happening with your applications running on the Service Fabric Cluster.

It’ll also provide many of the system services out of the box such as Naming Service( Service Resolution ), Image store service (Storing Deployment Packages) , Upgrade Service (Upgrading clusters), Failover manager service (Manage Failed Nodes), Cluster Manager Service (Perform Management Operations )etc., for managing your microservices.

Microsoft provides terrific support for Continuous Integration/Deployment of microservices to the Service Fabric cluster via it’s Visual Studio Team Services platform. The build tool can automatically detect commits to the source control such as Git and trigger a build. Once a build is created successfully, it provides the ability to deploy this build to the service fabric cluster automatically. Having CI/CD pipeline for deployment of Microservices can greatly help in continuously rolling out newer features without worrying about deployment failures.

In the next article, we’ll look at some of the architectural patterns that can be used while developing microservices using Service Fabric.

—
Preetham Reddy, Cloud Solutions Architect at TechFabric
Tech Fabric specializes in building web, mobile and cloud based application using Microsoft Stack (C#, .NET Core, Xamarin, Azure, SQL Service etc.,). If you need help with taking your on-premise application to cloud or convert your monolithic applications to microservices based, we’d be glad to help you out. You can reach out to our sales team at contact@techfabric.com.

‍