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.
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.
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.
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.
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 :
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 Tech Fabric
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 firstname.lastname@example.org.