The top 4 benefits of deploying services to a Service Fabric platform

The backbone of modern application development consists of a resilient and scalable service-based API tier. The ability to host, monitor, and scale infrastructure to service a potentially large quantity of requests can become cumbersome, complicated and expensive.

Azure Service Fabric is a microservices platform and container host that has been introduced to handle this infrastructure burden. Service Fabric also adds additional features such as provisioning, deployment, scaling and monitoring of the contained APIs.

Although Service Fabric is an Azure platform, it works on any type of cloud infrastructure. You can deploy it on the Azure cloud, another public cloud, or an on-premises infrastructure.

In this article, I walk through several key benefits of using Service Fabric. Then, I offer an overview of how you can use Thriftly in conjunction with Service Fabric.

Availability, deployments, and versioning

One of the primary benefits of utilizing Service Fabric is to ease deployment of a service (or container) across a distributed cluster made up of multiple machines. Service Fabric was designed for small to large deployments and every size in between, and is able to scale seamlessly based on demand. Each deployment is bundled as a structured package which makes it easily replicable across an environment.

When deploying APIs to Service Fabric, all incoming traffic is ingested through a single point of ingress which is then distributed across the underlying physical or virtual infrastructure. It may also become necessary to be able to host multiple versions of a service depending on its clientele — Some may follow an upgrade path quicker than others. Service Fabric allows for the hosting of individual versions of a service side-by-side, which enables each instance to be upgraded individually at convenient times. Additionally, having services hosted in a clustered environment allows for upgrades and maintenance without downtime or outages, as it redistributes requests to serviceable nodes while an upgrade is taking place. This same logic is used when rolling back from failed deployments.

Monitoring applications

Another benefit of utilizing Service Fabric is the ability to rigidly and thoroughly monitor applications and services, as well as their supporting infrastructure.
The first level of application monitoring is through the instrumentation of the application code itself. Because this type of logging is facilitated by the application business logic, it is up to the developer to select the tooling of their choice and to integrate it within the code.

Service Fabric introduces a health model that can also be leveraged from within the application or service code. It does this by providing a real-time view (well, technically, it's only "near real-time") of a cluster's health by monitoring the underlying infrastructure and the services it hosts. The goal of this monitoring is to keep the application delivery team aware of potential problem triggers that may cascade into larger problems causing outages. Introducing this model into custom business logic code instrumentation is helpful in maintaining the overall health of the system. As a Service Fabric environment is hierarchical, differing metrics, thresholds and rules can be defined as health policies to indicate the tolerances of what is considered healthy (OK), a warning, error, or unknown.

The Service Fabric platform reports on a variety of events. These contain node events such as starts/stops, scale in/out, and activation/deactivation. These logs will help identify problems with hardware but will also report on events triggered using the Service Fabric API to modify the status of a node. Cluster events reported by the Service Fabric include upgrade and configuration logs of the Service Fabric itself, allowing the tracking of changes across the domain to completion (or rollback if unsuccessful). Service Fabric will also report on the creation and deletion of applications and services, partitioning events, as well as on the overall health of the nodes.

Deployment options and environment parity

Currently, the most popular way of deploying Service Fabric-based services and applications is by using the Service Fabric infrastructure available through Microsoft Azure. Utilizing Azure infrastructure, however, is not required. As noted above, because Service Fabric is a platform rather than an Azure-specific service, it can be deployed on any infrastructure, including development machines.

This is a key advantage not just because it means Service Fabric supports a flexible deployment strategy, but also because it allows organizations that have already invested heavily in an existing on-premises infrastructure to keep using that infrastructure in conjunction with Service Fabric.

Another benefit worth mentioning on the topic of deployment options is that Service Fabric is consistent across different environments or deployments. That means that a Service Fabric deployment on development machines is identical to that which is available in the production environment, eliminating behavior discrepancies between environments.

API management

Service Fabric also integrates with Azure API management. By utilizing Azure API management, organizations can import service definitions. They can also define complex routing rules, add access control, rate limiting, monitoring, event logging and response caching — all without modifying application code.

Leveraging Thriftly with Service Fabric

Azure API Management

Thriftly provides the ability to leverage existing legacy code assets and expose them as web services, or quickly develop new services altogether. Each service is provided along with service definitions, such as a WSDL. These service definitions can be easily imported into Azure API Management to provide a single point of ingress for the services and to leverage the management features such as rate limiting, security, response caching and monitoring.

Service Fabric hosting

Thriftly provides the ability to deploy services to non-Thriftly servers. This makes it possible to package Thriftly service-based code for deployment directly to Service Fabric, either running in Azure or on-premises.

Integrating Service Fabric SDKs

When developing new services or enhancing existing business logic code targeting the usage of Service Fabric infrastructure, SDKs are available to be integrated into the code to leverage platform features like logging and health monitoring.

Conclusion

Thriftly.io provides the ability to quickly introduce services into both legacy and modern codebase that is easily deployed to Service Fabric. By leveraging Service Fabric, organizations are able to obtain security, scalability, throttling, and monitoring of their services. Service Fabric can be deployed in the cloud or on-premises depending on the requirements of the organization.