Migration plan for a cloud service to Service Fabric:

Goal: List some of the considerations towards the migration of a web service hosted on IaaS infrastructure to Service Fabric. A description of the summary and features of Service Fabric are shown here. This article focuses on architectural decisions and recommended practices.

Service Fabric is Microsoft’s distributed platform for building, running, and maintaining microservices applications in the cloud. It is a container orchestrator, and it can provide quality of service to microservice framework models such as stateful, stateless, and actor. It differs from Azure Container Service in that it is an Infrastructure-as-a-Service offering rather than a Platform-as-a-Service offering. There is also a Service Fabric Mesh offering that provides a PaaS service for Service Fabric applications. Service Fabric provides its own specific programming model, allows guest executables, and orchestrate Docker containers. It supports both Windows and Linux, but it is primarily suited for Windows. It can scale to handle Internet-of-Things traffic. It is open to workloads and is technology-agnostic. It relies on Docker and has supported both Windows and Linux containers, but it provides a more integrated feature-rich orchestration that gives more openness and flexibility. 

The table of comparisons includes:

Area	Cloud Services	Service Fabric
Application composition	Roles	Services
Density	One role instance per VM	Multiple services in a single node
Minimum number of nodes	2 per role	5 per cluster, for production deployments
State management	Stateless	Stateless or stateful
Hosting	Azure	Cloud or on-premises
Web hosting	IIS	Self-hosting
Deployment model	Classic deployment model	Resource Manager
Packaging	Cloud service package files (.cspkg)	Application and service packages
Application update	VIP swap or rolling update	Rolling update
Autoscaling	Built-in service	Virtual machine scale sets for auto scale out
Debugging	Local emulator	Local cluster

 

A worker role can be mapped to a Service Fabric stateless service. A web role can also be mapped to a ServiceFabric stateless service. Unlike Web roles, service fabric does not support IIS. A service must move to a web framework that can be self hosted and then the service must be moved to Service Fabric

Worker role and service fabric Service API offer similar entry points. The key differences between the lifecycle of worker roles and Service Fabric services is that the Lifecycle is tied to the VM for a worker role and It is separate from the VM for a service fabric service.

The lifetime of a worker role is determined by when the Run method exits while the RunAsync method for service fabric can run to completion while the instance remains. The Http listeners are described in the service definition files for cloud services while they are specified in the service manifest for service fabric. The configuration for a Service Fabri Service comes from application manifest in the Application package, service manifest in the service package, and settings.xml from the configuration package. The settings can be saved in the setting.xml file, the application manifest can be used to override the setting, and the environment specific settings can be put into the parameter file.