Azure Service Fabric - Micro Service Approach

Introduction

In my previous article about micro service approach, we discussed how this approach is different from the earlier style of application development - the monolithic applications. And in continuation to that, I emphasized on breaking every component of your application into smaller independent modules, treating them as exclusive services. 

Now, I would like to tell what's Microsoft's contribution to this approach.

Azure Service Fabric

Have you ever been on Microsoft's Azure Portal? There we have different resources, and management services like Azure API Management. When I was unclear about what micro service is, after reading many articles, found one line just one proper sentence that cleared the picture for me. The statement was:

"Treat every service available over Azure portal as independent module." 

And guess what, it is true to very extent. Microsoft Azure Portal is built over Service Fabric platform. And in March, 2016, they opened this platform for all. Currently this Service Fabric is in Preview state.

If you go by the Microsoft's approach it says:

"Service Fabric enables you to build and manage scalable and reliable applications composed of microservices that run at very high density on a shared pool of machines, which is referred to as a cluster. It provides a sophisticated runtime to build distributed, scalable, stateless and stateful microservices. It also provides comprehensive application management capabilities to provision, deploy, monitor, upgrade/patch, and delete deployed applications. "

@ below url: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

What is Service Fabric ?

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices. Service Fabric also addresses the significant challenges in developing and managing cloud applications. Developers and administrators can avoid complex infrastructure problems and focus on implementing mission-critical, demanding workloads that are scalable, reliable, and manageable. Service Fabric represents the next-generation middleware platform for building and managing these enterprise-class, tier-1, cloud-scale applications.

Some core keywords of Service Fabric:

Cluster:  A network-connected set of virtual or physical machines into which your microservices are deployed and managed. Clusters can scale to thousands of machines.

You can create a local cluster and later push it over Azure. 

Above are different nodes, by default there are 5 nodes given in any cluster, we can always scale up for this.

Node: A machine or VM that is part of a cluster is called a node. Each node is assigned a node name (a string). Nodes have characteristics such as placement properties. Each machine or VM has an auto-start Windows service, FabricHost.exe, which starts running upon boot and then starts two executables: Fabric.exe and FabricGateway.exe. These two executables make up the node. For testing scenarios, you can host multiple nodes on a single machine or VM by running multiple instances of Fabric.exe and FabricGateway.exe.

Application Type: The name/version assigned to a collection of service types. Defined in an ApplicationManifest.xml file, embedded in an application package directory, which is then copied to the Service Fabric cluster's image store. You can then create a named application from this application type within the cluster.

Application Package: A disk directory containing the application type's ApplicationManifest.xml file. References the service packages for each service type that makes up the application type. The files in the application package directory are copied to Service Fabric cluster's image store. For example, an application package for an email application type could contain references to a queue service package, a frontend service package, and a database service package.

Named Application: After an application package is copied to the image store, you create an instance of the application within the cluster by specifying the application package's application type (using its name/version). Each application type instance is assigned a URI name that looks like this: "fabric:/MyNamedApp". Within a cluster, you can create multiple named applications from a single application type. You can also create named applications from different application types. Each named application is managed and versioned independently.

Service Type: The name/version assigned to a service's code packages, data packages, and configuration packages. Defined in a ServiceManifest.xml file, embedded in a service package directory and the service package directory is then referenced by an application package's ApplicationManifest.xml file. Within the cluster, after creating a named application, you can create a named service from one of the application type's service types. The service type's ServiceManifest.xml file describes the service.

Service Package: A disk directory containing the service type's ServiceManifest.xml file. This file references the code, static data, and configuration packages for the service type. The files in the service package directory are referenced by the application type's ApplicationManifest.xml file. For example, a service package could refer to the code, static data, and configuration packages that make up a database service.

Named Service: After creating a named application, you can create an instance of one of its service types within the cluster by specifying the service type (using its name/version). Each service type instance is assigned a URI name scoped under its named application's URI. For example, if you create a "MyDatabase" named service within a "MyNamedApp" named application, the URI looks like: "fabric:/MyNamedApp/MyDatabase". Within a named application, you can create several named services. Each named service can have its own partition scheme and instance/replica counts.

Code Package: A disk directory containing the service type's executable files (typically EXE/DLL files). The files in the code package directory are referenced by the service type's ServiceManifest.xml file. When a named service is created, the code package is copied to the one or more nodes selected to run the named service. Then the code starts running. There are two types of code package executables:

• Guest executables: Executables that run as-is on the host operating system (Windows or Linux). That is, these executables do not link to or reference any Service Fabric runtime files and therefore do not use any Service Fabric programming models. These executables are unable to use some Service Fabric features such as the naming service for endpoint discovery. Guest executables cannot report load metrics specific to each service instance.
• Service Host Executables: Executables that use Service Fabric programming models by linking to Service Fabric runtime files, enabling Service Fabric features. For example, a named service instance can register endpoints with Service Fabric's Naming Service and can also report load metrics.

Data Package: A disk directory containing the service type's static, read-only data files (typically photo, sound, and video files). The files in the data package directory are referenced by the service type's ServiceManifest.xml file. When a named service is created, the data package is copied to the one or more nodes selected to run the named service. The code starts running and can now access the data files.

Configuration Package: A disk directory containing the service type's static, read-only configuration files (typically text files). The files in the configuration package directory are referenced by the service type's ServiceManifest.xml file. When a named service is created, the files in the configuration package are copied to the one or more nodes selected to run the named service. Then the code starts running and can now access the configuration files.

Containers: By default, Service Fabric deploys and activates services as processes. Service Fabric can also deploy services in container images. Containers are a virtualization technology that virtualizes the underlying operating system from applications. An application and its runtime, dependencies, and system libraries run inside a container with full, private access to the container's own isolated view of operating system constructs. Service Fabric supports Docker containers on Linux and Windows Server containers. For more information, read Service Fabric and containers.

Partition Scheme: When creating a named service, you specify a partition scheme. Services with large amounts of state split the data across partitions which spreads it across the cluster's nodes. This allows your named service's state to scale. Within a partition, stateless named services have instances while stateful named services have replicas. Usually, stateless named services only ever have one partition since they have no internal state. The partition instances provide for availability; if one instance fails, other instances continue to operate normally and then Service Fabric will create a new instance. Stateful named services maintain their state within replicas and each partition has its own replica set with all the state being kept in sync. Should a replica fail, Service Fabric builds a new replica from the existing replicas.

Points of Interest

If you go by the above picture, it depicts a normal problem statement, where we have to efficiently work on multiple requests. The simple solution is apply a/ many load balancer in between. 

But with Service Fabric the job is much simpler, with multiple nodes in the cluster and every nodes with mulltiple partition, we can scale up any (much in demand) application over the node and if that is not enough, then we can have the same instance of that application running over another node, that would handle the request. 

In short, if one node is busy handling the request, then the other node is happy to help. 

Service Fabric for Micro Services

Azure Service Fabric emerged from a transition by Microsoft from delivering box products, which were typically monolithic in style, to delivering services. The experience of building and operating large services, such as Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. The platform evolved over time as more and more services adopted it. Importantly, Service Fabric had to run not only in Azure but also in standalone Windows Server deployments.

The aim of Service Fabric is to solve the hard problems of building and running a service and utilize infrastructure resources efficiently, so that teams can solve business problems using a microservices approach.

Service Fabric provides two broad areas to help you build applications that use a microservices approach:

• A platform that provides system services to deploy, upgrade, detect, and restart failed services, discover service location, manage state, and monitor health. These system services in effect enable many of the characteristics of microservices previously described.
• Programming APIs, or frameworks, to help you build applications as microservices: reliable actors and reliable services. Of course, you can choose any code to build your microservice. But these APIs make the job more straightforward, and they integrate with the platform at a deeper level. This way, for example, you can get health and diagnostics information, or you can take advantage of built-in high availability.

Service Fabric is agnostic on how you build your service, and you can use any technology.However, it does provide built-in programming APIs that make it easier to build microservices.

Fun Fact: If you have heard about the game Age of Ascent, it is built over Service Fabric platform, exhausting the concept of micro services, the trivia is, it handles millions of exchange of messages on 1 second and a trillion of messages over a day. 

Hail Service Fabric !!

Below is the url from Microsoft about Service Fabric and Micro Service

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices

History

Base version - 19th May, 2017