In my previous blog post in this series I made some recommendations for migrating Cloud Services (Web and Worker Roles) to alternative architectures now that Cloud Services are considered legacy and Microsoft will not be spending any further effort enhancing them. Two solutions that I proposed were Web Apps/Web Jobs and Azure Service Fabric.

After that blog post I did receive some interesting feedback:

“We use Web/Worker Roles with custom software installed and a few other things enabled, so we need a bit more customization than Web Apps provide. Further, we do CPU intensive processing on Worker Roles, and as far as I know Web Jobs run on the same Virtual Machines that serve the Web Role instances; which isn’t suitable for us.”

“Azure Service Fabric is great, but I haven’t been able to confidently decide to move our current apps across to it. There are too many unanswered questions, plus a steep learning curve and necessary tooling improvements are needed.”

These are valid comments; that there is a somewhat steep learning curve; that tooling improvements are needed and that there are still unanswered questions; mostly due to the early state of documentation and the ongoing evolution of Service Fabric.

I empathize with the plight of anyone faced with this decision. It is a decision that many of us who have currently implemented Azure applications are facing. If you need that level of customization you should look at migrating them to Azure Service Fabric Reliable Services or, in the extreme, to Single Instance Virtual Machines and/or Virtual Machine Scale Sets. (Single Instance Virtual Machines are Virtual Machines that are not part of a Virtual Machines Scale Set, as discussed below)

The World before Azure Service Fabric and Virtual Machine Scale Sets

Up until the end of 2015 (when it was last updated) this white paper was an excellent guide to choosing the appropriate Compute option for an Azure application. It covered the tradeoffs between:

1. Web Apps
2. Cloud Services
3. Virtual Machines

It even provided a nice decision table for selecting between them. I used this article to guide many Azure developers in the selection of a compute methodology.

Scott Hanselman has been quoted as summing this up as: “Its Web Apps until it’s not, then it’s Cloud Services until it’s not, then its Virtual Machines.” This does not, however, include Azure Service Fabric and Virtual Machine Scale Sets, which did not exist at the time the article was last updated.

What’s changed?

The above document needs an update to add Azure Service Fabric & Virtual Machine Scale Sets. It could also possibly omit Cloud Services since that is now a legacy technology. If course Cloud Services are not going away. They will be supported for some time. So they may want to keep it in.

The white paper mentioned above was updated recently to include Azure Service Fabric in it’s comparison table.  It still has yet to be updated for Virtual Machine Scale Sets.  Even though it was updated to include Azure Service Fabric in the comparison table the body of the report continues to focus primarily on the other alternatives such as:

1. Web Apps
2. Cloud Services
3. Virtual Machines

It still does not list the reasons for choosing Azure Service Fabric over the other alternatives. Hopefully it will be amended again soon to cover more of the tradeoffs in closing between the options; and also to add Virtual Machine Scale Sets.

Remember, before we proceed though that Azure Service Fabric & Virtual Machine Scale Sets are still in preview, but if you are building new greenfield applications or planning to migrate existing brownfield applications to the newer architectures in the near future it is not too soon to start considering them.

Let’s compare the options:

WebApps

These are often compared to Cloud Services Web Roles. They are based on a pool of Virtual Machines running a pool of IIS instances.

1. Load Balancer automatically created.
2. Auto scaling provided by the platform.
3. Microsoft takes care of all patching of underlying Virtual Machines.
4. Stateless applications.
5. No Startup tasks. (See Cloud Services below.)
6. Cannot Remote Desktop into underlying Virtual Machines.
7. Multiple environments supported.
8. Tooling support in Portal, Visual Studio, SDKs and other tools.
9. Well documented with lots of examples.
10. Management Complexity: easiest if you can fit within its limitations.

WebJobs

Web Jobs are lightweight background workers. They are often compared to Cloud Services Worker Roles.

1. Web Jobs run in the same Virtual Machines with Web Apps. So they share many of the same resources and can degrade Web App performance.
2. Load Balancer automatically created,
3. Auto scaling provided by the platform,
4. Microsoft takes care of all patching of underlying Virtual Machines.
5. Stateless applications that are self-healing.
6. No Startup tasks. (See Cloud Services below.)
7. Cannot Remote Desktop into underlying Virtual Machines.
8. Multiple environments supported.
9. Tooling support in Portal, Visual Studio, SDKs and other tools.
10. Well documented with lots of examples.
11. Complexity: easiest if you can fit within its limitations.

Cloud Services

1. Based on a collection of individual Virtual Machines.
2. Load Balancer automatically created.
3. AutoScaling provided by the platform.
4. Microsoft takes care of all patching of underlying Virtual Machines.
5. Stateless applications that are self-healing.
6. Startup tasks: To install software and do other in-the- Virtual Machine configuration tasks.
7. Can Remote Desktop into underlying Virtual Machines.
8. Multiple environments supported.
9. Tooling support in Portal, Visual Studio, SDKs and other tools.
10. Well documented with lots of examples.
11. Complexity is moderate, but remember that Cloud Services are legacy.

Individual Virtual Machines

1. Virtual Machines created one at a time.
2. Load Balancer: Not automatically provided. Must create one.
3. Auto scaling with need to pre-create all Virtual Machine instances.
4. Microsoft does not update these Virtual Machines. You are responsible.
5. Stateless and Statefull applications, but up to you to manage.
6. Virtual Machine Extensions for Startup customization.
7. Can Remote Desktop into underlying Virtual Machine.
8. Multiple environments are up to you to create and manage.
9. Tooling support in Portal, Visual Studio, SDKs and other tools.
10. Well documented with lots of examples.
11. Complexity is high.

Virtual Machine Scale Sets

1. Based on a Virtual Machine template used to create several Virtual Machines in a Scale Set.
2. Load Balancer: Configured as part of Scale Set creation if you use a Scale Set Template
3. Auto scaling with no need to pre-create Virtual Machines in the set.
4. Microsoft does not update these Virtual Machines. You are responsible.
5. Stateless and Statefull applications, but up to you to manage.
6. Virtual Machine Extensions for Startup Tasks.
7. Can Remote Desktop into underlying Virtual Machines.
8. Multiple environments are up to you to create and manage.
9. Tooling support in Portal, Visual Studio, SDKs and other tools.
10. Well documented with lots of examples.
11. Less Complexity than Individual Virtual Machines.

Azure Service Fabric

Note: Comparison with Service Fabric is still difficult because it is in a state of flux and still evolving. And the documentation is evolving with it. However here are some of its characteristics for comparison:

1. Based on deploying into pre-existing clusters using Virtual Machine Scale Sets and/or Containers. Also will run on premises under Windows Server and Azure Stack as well as on other platforms such as Linux.
2. Load Balancer automatically provided for the cluster.
3. AutoScaling (to millions of Transactions per second)
4. Microsoft does not update these Virtual Machines. You are responsible.
5. Stateless and Statefull applications that are self-healing. Azure Service Fabric has two application models: Reliable Services (closest to what you have now in your Cloud Services) and Reliable Actors (which could require significant refactoring of your application.). It also includes Reliable Collections for state management.
6. Virtual Machine Extensions for Startup Tasks.
7. Can Remote Desktop into underlying Virtual Machines.
8. Multiple environments are up to you to create and manage.
9. Tooling support in Portal, Visual Studio, SDKs and other tools such as the Service Fabric Explorer.
10. Documentation: Still scarce and under change due to the evolving nature of the service. Hopefully this will settle down soon.
11. Complexity: High. Fairly steep learning curve. But very rewarding.

Recommendations

So, when all is said and done, what do we recommend? That depends on whether you are migrating an existing brownfield application or designing a new greenfield one.

Brownfield applications

These are the most challenging. If it “fits” Web Apps/Web Jobs use that approach. If not, then Azure Service Fabric Reliable Services is the next choice to evaluate. And, just like in the case before where Virtual Machines was always a valid last choice you can choose that approach, however even there you have two options, Individual Virtual Machines or Virtual Machines Scale Sets. And consider using Reliable Collections as an alternative to other existing forms of state management and as an alternative of Azure Storage Queues.

So you can start with a lift-and-shift approach to migration and refactor later to take advantage of micro-services and possibly the Actor Model.

Greenfield applications

Here the sky’s the limit. I would first decide how scalable I want my applications to be. If I expect hundreds or thousands of transactions per second, I would look at Azure Service Fabric Reliable Actor model first. After that I would consider Reliable Services.

If nether of this approaches work for you then maybe Virtual Machine Scale Sets is the architecture to choose. Individual Virtual Machines are probably an option now only for fairly simple architectures that don’t need the scalability of Virtual Machine Virtual Machine Scale Sets. Or for the situation where you have to go above and beyond what the other options provide to roll-your-own architecture.

But remember the Architect’s rule: “It all Depends”

What do you think?

Bill