Web and Worker Roles: What do I do now? Part 2

image

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. Smile

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” Smile

What do you think?

Bill

About CloudyInNashville

I am a Cloud Architect and Consultant. Over several years I have been working with companies to help them design and build .NET based applications for public and private clouds. My focus is the Cloud, Public Clouds and Microsoft's Windows Azure Cloud platform in particular.
This entry was posted in Application Development, Architecture, Cloud, Cloud Computing, IaaS, Microsoft Azure, Microsoft Azure WebApps, Microsoft Azure WebJobs, PaaS, Windows Azure, Windows Azure Web Sites and tagged , , , , . Bookmark the permalink.

6 Responses to Web and Worker Roles: What do I do now? Part 2

  1. Gerard van der Burg says:

    Great work, this does explain the landscape very clear.

  2. Just a note on WebJobs: It is true that WebJobs normally run in the same Virtual Machines with WebApps. WebApps run in an App Service Plan which puts them on the same pool of VMs competing for the same resources. You can’t control how many resources each tier uses. But you could create a separate App Service Plan for your WebJobs which would also allow independent scaling of the two tiers.

  3. davenoderer says:

    Good job Bill.. I’ve been trying to come up with an approach to present Service Fabric.. still trying to grock it myself!! This lays a good base!

    • Thanks Dave. Just an FYI. They did get around to adding Service Fabric to that document. I will update the blog post as soon as I can get to it. Even their update, however, did not cover it in depth as an option. It still focuses mainly on the other alternatives It also does not distinguish between VMs and VM Scale Sets.

  4. Things in this area are evolving fast. Thanks to my associate Bruce Kyle for bringing to my attention the following guidance on moving Cloud Services to Azure Service Fabric:

    Prescriptive guide to migration of web roles and worker roles (Cloud Services) to Service Fabric:
    https://azure.microsoft.com/en-in/documentation/articles/service-fabric-cloud-services-migration-differences/.

    This article, and the ones it links to are excellent guidelines for migrating from Cloud Services to Azure Service Fabric, which is one of the options I discussed in this blog post series.

    Of course their is still no way to have the underlying VM operating systems patched and updated with rolling updates automatically the way it is done in Cloud Services and App Services. IMHO that is one of the key features of PaaS that is still sorely needed.

    Azure Service Fabric clusters currently run on top of VM Scale Sets which still suffers from this limitation. Hopefully Microsoft will develop a way to provide this feature for VM scale sets soon.

  5. Got an interesting response from one of my sources at Microsoft:
    “It’s important to understand that there is no “one size fits all” story here. If you are looking for an “apples to apples” alternative to web/worker roles, you should be investigating Virtual Machine Scale Sets. This is appropriate when you need to spin up a herd of identically configured VMs that require automatic scaling. There are several gaps we plan to address to make this kind of migration easier.

    If you weren’t using web/worker roles for automatic scaling, but instead were using them to avoid having to manage and patch VMs, you should be looking at the many PaaS layers available for Azure Compute, including the Azure Batch Service, App Service (Web Sites, Web Jobs, Functions, etc.).

    Finally, if you have the flexibility to re-architect your solution, you should be looking at the various container / micro-services offerings evolving in Azure, including Container Service and Service Fabric.”

    That is totally consistent with this blog series. 🙂

    Bill

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s