Service Fabric as a platform supports multiple programming models, each of which is best suited for specific scenarios. Each programming model offers different levels of integration with the underlying management framework. Better integration leads to more automation and fewer overheads. Picking the right programming model for your application or service is the key to efficiently utilizing the capabilities of Service Fabric as a hosting platform. Let's take a deeper look into these programming models.
To start with, let's look at the least integrated hosting option – Guest Executables. Native Windows applications or application code using Node.js or Java can be hosted on Service Fabric as a Guest Executable. These executables can be packaged and pushed to a Service Fabric cluster like any other services. As the cluster manager has minimal knowledge about the executable, features such as custom health monitoring, load reporting, state store, and endpoint registration cannot be leveraged by the hosted application. However, from a deployment standpoint, a guest executable is treated like any other service. This means that for a guest executable, Service Fabric cluster manager takes care of high availability, application lifecycle management, rolling updates, automatic failover, high-density deployment, and load balancing.
As an orchestration service, Service Fabric is responsible for deploying and activating an application or application service within a cluster. It is also capable of deploying services within a container image. This programming model is addressed as Guest Containers. The concept of containers is best explained as an implementation of operating system level virtualization. They are encapsulated deployable components running on isolated process boundaries sharing the same kernel. Deployed applications and their runtime dependencies are bundles within the container with an isolated view of all operating system constructs. This makes containers highly portable and secure. The Guest Container programming model is usually chosen when this level of isolation is required for the application. As containers don't have to boot an operating system, they have fast boot up time and are comparatively small in size.
A prime benefit of using Service Fabric as a platform is the fact that it supports heterogeneous operating environments. Service Fabric supports two types of containers to be deployed as Guest Containers:
- Docker Containers on Linux
- Windows Server Containers
Container images for Docker Containers are stored in Docker Hub and Docker APIs are used to create and manage the containers deployed on a Linux kernel.
Service Fabric supports two different types of containers in Windows Server 2016 with different levels of isolation:
- Windows Server Containers
- Windows Hyper-V Containers
Windows Server Containers are similar to Docker Containers in terms of the isolation they provide. Windows Hyper-V Containers offer a higher degree of isolation and security by not sharing the operating system kernel across instances. These are ideally used when a higher level of security isolation is required, such as systems requiring hostile multitenant hosts.
The following figure illustrates the different isolation levels achieved by using these containers:
The Service Fabric application model treats containers as an application host which can in turn host service replicas. There are three ways of utilizing containers within a Service Fabric application mode. Existing applications such as Node.js and JavaScript applications, or other executables can be hosted within a container and deployed on Service Fabric as a Guest Container. A Guest Container is treated similar to a Guest Executable by the Service Fabric runtime. The second scenario supports deploying stateless services inside a container hosted on Service Fabric. Stateless services using Reliable Services and Reliable Actors can be deployed within a container. The third option is to deploy stateful services in containers hosted on Service Fabric. This model also supports Reliable Services and Reliable Actors.
Service Fabric offers several features to manage containerized Microservices. These include container deployment and activation, resource governance, repository authentication, port mapping, container discovery and communication, and the ability to set environment variables. Later in this chapter, we will explore ways of deploying containers on Service Fabric.
While containers offer a good level of isolation, it is still heavy in terms of deployment footprint. Service Fabric offers a simpler, powerful programming model to develop your services, which they call Reliable Services. Reliable Services let you develop stateful and stateless services which can be directly deployed on Service Fabric clusters. For stateful services, the state can be stored close to the compute by using Reliable Collections. High availability of the state store and replication of the state is taken care by the Service Fabric cluster management services. This contributes substantially to the performance of the system by improving the latency of data access. Reliable Services come with a built-in pluggable communication model which supports HTTP with Web API, WebSockets, and custom TCP protocols out-of-the-box.
A Reliable Service is addressed as stateless if it does not maintain any state within it or if the scope of the state stored is limited to a service call and is entirely disposable. This means that a stateless service does not need to persist, synchronize, or replicate state. A good example for this service is a weather service such as MSN weather service. A weather service can be queried to retrieve weather conditions associated with a specific geographical location. The response is totally based on the parameters supplied to the service. This service does not store any state. Although stateless services are simpler to implement, most of the services in real life are not stateless. They either store state in an external state store or an internal one. Web frontend hosting APIs or web applications are good use cases to be hosted as stateless services.
A stateful service typically will utilize various mechanisms to persist its state. The outcome of a service call made to a stateful service is usually influenced by the state persisted by the service. A service exposed by a bank to return the balance on an account is a good example for a stateful service. The state may be stored in an external data store such as Azure SQL Database, Azure Blobs, or Azure Table store. Most services prefer to store the state externally, considering the challenges around reliability, availability, scalability, and consistency of the data store. With Service Fabric, state can be stored close to the compute by using Reliable Collections.
To make things more lightweight, Service Fabric also offers a programming model based on the Virtual Actor pattern. This programming model is called Reliable Actors. The Reliable Actors programming model is built on top of Reliable Services. This guarantees the scalability and reliability of the services. An Actor can be defined as an isolated, independent unit of compute and state with single-threaded execution. Actors can be created, managed, and disposed independent of each other.
A large number of Actors can coexist and execute at a time. Service Fabric Reliable Actors are a good fit for systems which are highly distributed and dynamic by nature. Every Actor is defined as an instance of an Actor type, the same way an object is an instance of a class. Each Actor is uniquely identified by an Actor ID. The lifetime of Service Fabric Actors is not tied to their in-memory state. As a result, Actors are automatically created the first time a request for them is made. Reliable Actor's garbage collector takes care of disposing unused Actors in memory.
Now that we understand the programming models, let's take a look at how the services deployed on Service Fabric are discovered and how the communication between services takes place.