Azure Service Fabric vs Azure Cloud Services for cloud native applications

Introduction

When you want to create a native Microsoft Azure application, there are three major architecture models that you can leverage:

• Azure App Services
• Azure Cloud Services
• Azure Service Fabric

In this post I want to do a comparison between the two major azure architecture models: Azure cloud services vs Azure service fabric.

Since there are so many Azure cloud offerings in the plate from Microsoft and it seems every month they come up with new services and add them to their stack of offerings, it is important to have a clear understanding of these services and when you want to use each of which.

In this post, I would try to define these cloud architectural models in simple terms for you and to do a comparison between them so you will have a clear understanding of these models and what to select from Azure for your next enterprise project!

First we will have a definition of these architectural models, and then we will do a comparison of these two architectural models.

Azure Cloud services

Azure Cloud Services is part of the Platform-as-a-Service (PaaS) offering from Microsoft.  It is reliable and scalable. You have more control over the VM which is hosting your application rather than the Azure App service model. You do not need to take care of the maintenance of you host like updating the OS and configuring the infrastructure like the one you have in Infrastructure-as-a-service. The environment (VM and related items) are available for you and you just install your application and you are good to go.

Currently, there are two different flavors of the Azure Cloud Services available for production use, Web Role and Worker Role. The key difference is:

• Web Role is a Windows Server Virtual Machine with IIS
• Worker Role is a Windows Server Virtual Machine without IIS

You can scale out and scale in your cloud service instances. The number of VMs in each Cloud Service type is controlled by the configuration file.

The supported architecture in the Cloud Service platform is the stateless architecture; it means the state of the application cannot be stored on the VM hard disks. It should be on some external providers like the Azure SQL Server, blobs, tables, … By doing this you can leverage the true nature of the cloud application architecture, scale out and scale in, restart the instances when an error occurs without being worry about the state and upgrade instances separately.

Azure Service Fabric

Azure Service Fabric is a distributed systems architecture model that offers a platform to implement Micro Services architecture in Microsoft Azure. This hyperscale Platform-as-a-Service simplifies some of the infrastructure challenges in Microsoft Azure Cloud Services offering and it represents the next generation middleware platform for building enterprise cloud-scale applications. Your application codes will be run on a pool of Virtual Machines, that is called “Cluster”.  You can scale different part of your cloud applications separately, and the developers have more agility to deliver the solution.

There are different programming model available for Azure Service Fabric including both Stateless and Statefull application development. Azure Service Fabric also supports WebAPI with Open Web Interface for .NET (OWIN) and ASP.NET Core. When it comes to the management of Virtual Machines, it gives you the same control over VMs as in the Azure Cloud Services. But at the time of this writing, automatic OS update is not supported in the Azure Service Fabric.

Although Service Fabric in Microsoft Azure is relatively a new offering from Microsoft, but it is been used internally in Microsoft cloud for application development and cloud offerings like Microsoft Azure SQL Server, Skype and other services. It is a reliable and fast service to deliver enterprise scale applications to customers.

Moreover, Service Fabric provides you a platform to host containers as well. Currently it supports

• Docker containers on Linux
• Windows Server containers

So it gives you the flexibility to deploy your codes as a container in Azure Service Fabric and run them along native Azure Service Fabric processes in one cluster!

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

“A move from virtual machines to containers makes possible an order-of-magnitude increase in density. Similarly, another order of magnitude in density becomes possible when you move from containers to microservices.”

Azure Cloud Services vs Azure Service Fabric

There are so many factors that we can talk about when comparing Azure Cloud Services and Azure Service Fabric and which one to use for your enterprise project. Here I have listed some of them:

Is it a greenfield development
The first question here is whether the project is started from scratch or you have inherited something that needs to be improved. Since the Azure Service Fabric is the successor of Azure Cloud Services with a so many new offerings and architectural improvements, it makes sense that for the greenfield development, you use the Azure Service Fabric model. Moreover, if you have an MVC application which runs on premise, you can package it as a windows server container and place it on Azure Service Fabric to run. But if you have some modules which are already in the Azure Cloud Services model and you don’t want to start from scratch or migrate those codes to Azure Service Fabric, it makes sense to continue using that model for the rest of your application

Current skillsets of your team
Developing scalable applications is not a one man show. You have different people in your team with various skillsets and it is not always possible to have training for all team members to use a new technology. So if your current skillset is weight in an older technology (Azure Cloud Service), it makes sense to use that technology for your new project.

High-throughput, low latency
Since the Azure Cloud Services does not support the stateful architecture, you have to use some form of external storage (like a queue or a blob) to store the state of the application. Writing and reading from an external storage system will add some latency to your application. For high-throughput applications it can be a significant amount of time when it adds up. So for applications like interactive storefronts, IoT, search, … it makes sense to develop in Azure Service Fabric stateful model.

Design simplicity
Since the Azure Cloud services does not support stateful architectural model, it is possible that for your application you end up with a more complicated design. Because you have to take care of the state of your application yourself. You will end up adding more external storage to your system to store the state of your applications.

Hybrid environment with containers
If you have a plan to have a hybrid environment in the cloud between your application and containers, Azure Service Fabric is the perfect choice for you. You can run your processes and other available containers side by side in an Azure Service Fabric reliably and scale it upon your needs.

Communication between instances
Since Azure Service Fabric platform provides a Naming service for you, you can use that to communicate between instances of your application. There is no need to know the machine name, or IP address of the instance. You create a socket with the instance name and you can communicate with that instance. This leads us to a simpler communication model rather than what we have in Azure Cloud Services.

Development  / Production environments
Because you can create your App Service Fabric on premise, in your private cloud or in Microsoft Azure, the same environment is running on the development machines and in your production environment. There is no emulator and codes can be easily transferred to the cloud without any changes.

Conclusion

As you see in this blog post, using Azure Service Fabric has many advantages over the Azure Cloud services. So for new projects I recommend using this scalable, reliable service from Microsoft. But due to current skillsets in your organization or inheriting an existing application, you may want to use Azure Cloud Services for your project.