In this post, we will be talking about what are Microservices and how can you deploy your microservice in Azure using ServiceFabric. In the subsequent articles will look at how to create an application using the different programming models available in Service Fabric.
Applications are typically created following the 3 tier architecture, which consists of a front-end tier(UI) a middle tier(business logic) and Data Tier(typically a SQL database). Even though this design allows you to separate the applications in to three different components, as applications grow more often than not the middle tier becomes a one big monolith comprising of multiple services.
This type of design posed particular challenges.
Microservice architecture is the process of breaking down your application into a group of loosely coupled, independently deployable services. Each of this services are responsible for certain functionality. So in our example of an ecommerce service the checkout and product catalog will be individual services. As these services are modular and independent of each other, you can take advantage of different frameworks which are best suited for doing a particular task. This also allows multiple teams to work together each following their own set of release cycle and technology stack. Breaking down applications into small chunks meant that it takes less time to do integration allowing teams to release newer versions of a module without depending on other teams. The individual services communicate with each other using simple API’s.
Service Fabric is a fully managed application platform that allows you to deploy and manage microservices. Service Fabric clusters can be created either in Azure or on-premise or any other public cloud providers running Windows Server or Linux. You can also run Service Fabric in your local dev machine by using the Service Fabric SDK.
Service Fabric provides a number of services out of the box to help you deploy and manage your microservice applications. These system services are available by default run as any other microservices within the cluster.
The primary role of the Cluster Manager is managing the life cycle of the microservice across a pool of resources. It not only takes care of deploying individual microservices into various nodes based on various placement policies that you have configured but also takes care of creating the desired number of instances of individual services, load balancing the resources and also acts as an intelligent scheduler.
The Cluster Manager Service continually monitors how much load is there on each of the machines, the network bandwidth, available memory continuously and whenever a particular node is down it takes care of realigning the services across the available nodes so that the resources in the cluster are efficiently utilized.
In a distributed environment a service can run on any of the nodes. Once deployed, a service can be moved to a different node because of a failover or resource load balancing or scale-out scenarios. In this kind of scenarios its difficult to keep track of the IP address of a particular service. To tackle this scenario, Service Fabric provides a naming service similar to a DNS which tracks the IP address of a particular service to the service name. In service fabric, every service has a unique name which is of the form “fabric:/ApplicationName/ServiceName.” The naming service maintains a registry of the service names and the current endpoint address. The name of service remains the same over the lifetime of a resource.
The cluster manager uses the FailOver Manager service to do resource load balancing whenever a new node is added or removed or failed. The failover manager will automatically redistribute the services and its replicas to maintain the high availability.
Guest Executable: Any existing application written in any language can be hosted in services fabric as a Guest Executable without any code changes.
Reliable Services: These are applications which can leverage the entire range of Service Fabric APIs. Typically you can think of them as console applications. they are typically divided into 3 types
Stateless Application: These are either console applications or ASP.NET core web applications which either do not need persistent storage or uses external storage to store state.
Stateful Application: Stateful applications provides transactional replicated storage option in the form of IReliableCollection where applications can store data.
Reliable Actors: These are based on Actor Programming Models. According to which every entity is an actor just like an Object Oriented Programming where everything is an object. An actor is a computational entity which can process requests, communicate with other actors and create new actors and contains logic to process a request. Each actor is an isolated entity which is responsible for its state. In service fabric, the actor model is based on top of Stateful Reliable service.
In our next article, we will look at creating an Application using the different programming models in Service Fabric. We will create the application using the ServiceFabric SDK in the local dev machine and then we deploy it in Azure.
Comments are closed.