Azure Service Fabric is a PaaS offer for distributed systems that simplifies the packing, provisioning, and management of scalable and reliable microservices. Before we start with a deep analysis, we should deal with the microservice architecture in general.

Let's take a look at the first diagram:

Core elements of this architecture are the services (or microservices). The services are defined by the following characteristics:

• A service is small, which means a service offers only one function in contrast to the application with many functions.
• A service is independent. This has several meanings for our work:
  • Each service has a separate code base, and this without the need to share the same technology stack, libraries, or frameworks. You can use, for example, C# for the first, Java for the second, and a JavaScript framework for the third service
  • Each service can be managed or deployed from a separate development team or a business unit, and this without the need to rebuild or redeploy an entire application in the case of updating an existing service.
  • Each service is responsible for persisting their own data or external state. This is a big difference from the traditional model, where a separate data layer handles data persistence.
• Services are loosely coupled. Imagine the microservice architecture as a pool of work units. You can call up at any time a single work unit to work on a specific task or to implement any combination of work units to perform complex tasks:
  • Services communicate with each other by using a well-defined API. Internal implementation details of each service are hidden from other services.

The other elements of the architecture are:

• API gateway. The API gateway is the entry point for the microservice architecture because a typical client never calls a service directly. Instead, the client calls the API gateway, which forwards the call to the corresponding services on the backend.
• Another operational scenario for the use of the API gateway is, you can summarize the answers of multiple services and then return the aggregated response.

In general, the advantages of using an API gateway are the following:

• It decouples clients from services. This allows services to be versioned or redesigned without the need to update all clients.
• Services can use messaging protocols that are not available on the internet, for example AMQP.
• The API Gateway can also perform other tasks. For example, authentication, logging, or load balancing.

Management: The management component is responsible for the placement of services on the node, the identification of errors, the realignment of services across nodes, and so on.

Service Discovery: The service discovery component includes a list of services and a description on which nodes they are located. This enables a service lookup to find the endpoint for a specific service.

Now we have an idea of how a microservice architecture looks in general. Next, we should look at the whole from the view of Microsoft Azure.

In other words, we should now clarify what is behind the Azure Service Fabric offer.

We begin with a general answer: Azure Service Fabric provides you with a simple solution to the complex challenges of developing and managing cloud applications. You can avoid infrastructure issues and focus on implementing business-critical workloads that are scalable, reliable, and easy to manage.

Now let's go a step further into the details. Look at the following diagram, with information about the Azure Service Fabric infrastructure:

The key element of the infrastructure is the Service Fabric Cluster. A cluster contains a network-connected set of virtual or physical computers on which your microservices are deployed and managed. Clusters can be scaled to thousands of computers.

A computer or a virtual computer that is part of a cluster is referred to as a node. Each node receives a node name. Nodes have features such as placement properties.

Some nodes have administrative tasks, for example, for error monitoring. These nodes are then called management nodes.

Not shown in the diagram, but still present:

• Each computer or virtual machine has a Windows startup (FabricHost.exe) service that runs on startup and starts two executable files: Fabric.exe and FabricGateway.exe. These two executable files together form the nodes.
• In a development environment, you can host multiple nodes on a single computer or virtual machine by running multiple instances of Fabric.exe and FabricGateway.exe.

Let's take a closer look at the Azure Service Fabric offer:

• Programming models: Azure Service Fabric offers you various options to develop your services. You can use the offered Service Fabric APIs to access the platform's full set of functions, or you can write your services in any programming language, and then host the service on a service fabric cluster. The Azure Service Fabric provides the following offers and concepts for developers:
  • Guest executables: A so-called guest executable is an arbitrary executable that can be run as a part of your application. This type of executable never calls the Service Fabric APIs directly, but they still use all features the platform offers by calling the REST APIs provided from the Service Fabric.
  • Reliable services: Reliable services is a framework for developing services that provide a full integration in the Service Fabric platform and make use from the full set of platform features. The framework provides you with a set of APIs that allow the Service Fabric runtime to manage the life cycle of your services and that allow your services to interact with the runtime. The framework also gives you full control over design and implementation choices, and you can use it to host any other application framework, such as ASP.NET Core. Reliable services can be stateless, similar to most service platforms, in which each instance of the service is created equal and state is persisted in an external solution, such as Azure Cosmos DB or Azure Table Storage. Reliable services can also be stateful, where the state is persisted directly in the service itself using so-called reliable collections. The state is made highly-available through replication and is distributed through partitioning.
  • Reliable actors: The reliable actor framework (built on top of the reliable services framework) is a framework that implements the virtual actor pattern, based on the actor design pattern. The reliable actor framework uses independent units of compute and state with single-threaded execution called actors. The reliable actor framework provides a built-in communication for actors and pre-set state persistence and scale-out configurations. Like the reliable services framework, the reliable actor framework is fully integrated into the service fabric platform and uses the complete function set offered by the platform.
  • ASP.NET Core: The Service Fabric platform also provides integration with ASP.NET Core for building web and API services that can be included as part of your services.
• Management subsystem: The management subsystem handles the life cycle of applications and services. For this the subsystem provides the following tools:
  • Cluster manager: The cluster manager is the primary service that interacts with the failover manager from the reliability subsystem to place the applications on the nodes according to the restrictions on service placement. The resource manager in the failover subsystem then ensures that these constraints are always respected. The cluster manager also manages the life cycle of the applications from provision to de-provision, and is integrated with the health manager to ensure that application availability is not lost from a health perspective during upgrades.
  • Health manager: The health manager allows you to monitor the integrity of applications, services, and cluster entities (for example, nodes, service partitions, or replicas). Cluster entities can report status information that is then aggregated to the central health store. This integrity information provides a snapshot of the integrity of each service and each node that are distributed across the cluster. You can use this information to make necessary corrective action. Integrity query APIs are used to query integrity events reported to the integrity subsystem. The integrity query APIs return the raw integrity data stored in the integrity store or the aggregated, interpreted integrity data for a particular cluster entity.
  • Image store: The image store provides storage and distribution for the application binaries. The image store is offered in the form of a simple distributed file store, where the applications are uploaded and downloaded.
• Communication subsystem: The communication subsystem provides reliable messaging within the cluster through the so-called naming service. The naming service resolves service names to a location in the cluster and enables users to also manage service names and properties.
• Reliability subsystem: The reliability subsystem provides the mechanism to make the state of a Service Fabric service highly available. For this the subsystem provides the following tools:
  • Replicator: The replicator ensures that state changes in secondary replicas are automatically replicated by state changes in the primary service replica. The replicator saves the consistency between the primary and secondary replicas in a so-called service replica set. Fabric replicator makes the service state highly available and reliable.
  • Failover manager: The failover manager ensures that when nodes are added to or removed from the cluster, the load is automatically redistributed across the available nodes. If a node in the cluster fails, the cluster will automatically reconfigure the service replicas to maintain availability.
  • Resource manager: The resource manager places replicas of your services over the failure domain in the cluster and ensures that all failover units are operational. The resource manager also balances service resources across the underlying shared pool of cluster nodes to achieve optimal load distribution.
• Hosting subsystem: The cluster manager (part of the management subsystem) informs the hosting subsystem (running on each node of the cluster) which services it needs to manage for a particular node. The subsystem then manages the life cycle of this specific service on this node. The subsystem also interacts with the reliability and health components to ensure that the replicas are properly placed and are healthy.
• Federation subsystem: In order to assess the importance of a group of nodes in a distributed system, you must understand the entire system as a whole. The federation subsystem uses the communication functions provided by the transport subsystem and merges the various nodes into a single unified cluster that is viewed as a whole. It provides the master functions of the distributed system required by the other subsystems, for example, error detection, leader election, and consistent forwarding. The subsystem builds on distributed hash tables with a 128-bit token span. The subsystem creates a ring topology. The federation subsystem also guarantees through intricate join and departure protocols that only a single owner of a token exists at any time. For error detection, the subsystem uses a leasing mechanism that is based on monitoring heartbeats and switching. The federated subsystem also ensures that only one user can be owned by the token at a time with complex access and exit protocols. This is, for example, the prerequisite for guaranteeing consistent forwarding.
• Transport subsystem: The transport subsystem implements a point-to-point communication channel, and this channel is then used for communication within service fabric clusters and communication between the service fabric cluster and clients. It supports one-way and request-response communication patterns, which provides the basis for implementing broadcast and multicast in the federation subsystem. The transport subsystem secures the communication by using X509 certificates or with Windows security. This subsystem is only used internally by the Service Fabric and is not directly accessible.
• Testability subsystem: The testability subsystem helps application developers test their services through simulated faults before and after deploying applications and services to production environments.

Is that all? There is a clear answer: no, because Service Fabric services are delivered and activated as a process by default, but they can also be offered as containers. So, you have the option to combine Azure microservices and Azure Container Services in your solution approaches. If you choose this option, the Azure Service Fabric works as an Orchestrator for Azure Container Services.

Microsoft itself uses this approach, for example, for its new Azure IoT Edge product.