Moving from old school Azure Cloud Services to “v2 Azure PaaS”
Depending on how familiar you are with Azure, or rather for how long you have been using Microsoft’s data centers, you may or may not be familiar with how this cloud worked in the beginning.
The feature set offered was fairly limited initially and it was all about Platform-as-a-Service. The old concept of building out a server, and installing a number of components on it before stuffing your own code on top, just wasn’t there. (Virtual machines eventually arrived on Azure, but they tend to fill a different need than as a deployment vehicle for new things you build.)
This PaaS offering has since been referred to as “Cloud Services” in Azure parlance. There are two sides to these services that the developer is exposed to; “Web Roles” & “Worker Roles”.
Web Roles
These are the pieces of the app basically “doing something visible to the user”. You would for instance put your web app here, be it static HTML or dynamic content involving JavaScript. It’s true that it doesn’t have to be visual to qualify — an API receiving calls would also be a Web Role, so it might be more specific to say that it’s the front-ends pieces that go into this role. The tooling in Visual Studio and the Azure SDK has a fairly simple process for creation and deployment of Web Roles. If you know how to build a simple website odds are you will easily be able to put your site into a Web Role and run in the cloud. There is some extra configuration to make it work in Azure, but it’s not painful. (Specifying SSL setup and ports instead of doing it interactively in IIS for instance.)
Worker Roles
Odds are once you start to build on your website you’ll need some background work to happen as well. If you have a site where users upload video files you most likely want to put the files through an encoder on your end so the output will be consistent both with respect to bitrates and codecs. But you don’t want this to occur in the user’s context blocking their workflow. You need it to be submitted and worked on in the background before the result is inserted in the right place. And that is what Worker Roles are for. They could be compared to a service in Windows, and are triggered by schedule, by listening to a queue/file share/something.
The worker roles run mostly “normal” code, but requires some extra wiring to make it act as a worker role. (Similarly a Windows service shares traits with a console app, but also needs some extra setup to install and run in the background.)
The cloud service setup has worked out for a lot of scenarios over the years. There are knobs you can tweak so the service you deploy scale up or out, is highly available, geographically redundant, etc. All those things that can be hard and expensive to solve in your own datacenter.
There was, and is, other issues with cloud services though. Have a simple bug that you need to squash? Sure, just push out a new deployment. It will take 5–10 minutes to provision new servers underneath and then your code will be deployed. That’s a great debugging experience right? Want to split your app into modules of some sort so that each virtual directory of your site is handled separately? (In Visual Studio you can do this by using multiple projects and configuring it to deploy to http://localhost/abc, https://localhost/def, etc. and the different projects will play nice with IIS most of the time.) Sure, just keep in mind each will be a separate instance, and incur costs separately, and needs some additional orchestration to make sure there are no port conflicts and that everything will work seamlessly.
You could basically say that while version 1 was a good version, it might be time for a new version that fixes some of the shortcomings of the original release. I’m not saying Azure hasn’t evolved since launch. Lots of new services have been added, but the foundation of it hasn’t seen that much change.
These challenges are not unknown at Azure HQ, and different teams have been working hard to address them in a number of ways. (Azure isn’t one big team doing everything. While they obviously talk to each other it’s a different task to ensure the platform itself operates optimally, and whether a particular service offers the features the customers require. The organization of Azure could probably make for an interesting read, but is off-topic in this context.)
There are a couple of different routes you can take depending on what kind of application you have. Note that this is the context of Cloud Services, I’m not considering scenarios like whether you should deploy VMs with SQL Server vs hosted SQL databases.
Azure App Services (replacing Web Roles )
If you have a cloud service consisting mostly of Web Roles you can possibly migrate to Azure App Services, or more specifically Web Apps. You deploy in a matter of seconds instead of minutes, and it’s less friction than a web role. You can hook into GitHub and other source control tools, and not even touch the Azure portal to bring up a new version when you commit your code. You don’t get access to the underlying OS instance so there is less flexibility, but in most cases you don’t need this level of access and shouldn’t need caring about the OS.
Azure App Services + WebJobs (replacing Web & Worker Roles)
If your web app fits into App Services, but you have a few background tasks you can possibly adapt the Worker roles to be WebJobs instances instead. WebJobs provides service-like functionality that runs in tandem with your Web Roles. You’ll set up separate project(s) in Visual Studio, but they will be deployed as part of the same web app. (Some “magic” in the background abstracts it away from the UI parts.) WebJobs can be triggered by queues, run on a schedule, or be manually invoked. Really great experience in my book.
Be aware that since it’s running in the same context as the Web App they share the same resources. If you have background WebJobs consuming large amounts of horsepower this will impact the foreground tasks, and you should scale accordingly. Alternatively I have seen some dedicate a Web App to just running WebJobs. (A single url will be exposed in these cases even though there isn’t a website per se.)
Service Fabric (replacing Web & Worker Roles and then some)
While we’re on the topic of modularization, the term “Microservices” often pops up. The idea is that instead of writing large monolithic systems where even minor changes to one part requires redeploying “everything” it would be better, and more maintainable, if the monolith was split into smaller pieces that can be re-worked and re-deployed without affecting other parts of the system.
Rearchitecturing of a system isn’t something we can cover here. (Lot’s of books and articles have been written on the topic.) But Microsoft has catered to this need as well by introducing “Service Fabric”. It lets you build “micro-roles” if you will, and instead of creating a large amount of instances for your roles, you create a cluster that you deploy to. The cluster has logic to ensure the roles are available across server instances, is scaled up as needed, and re-deploy individual services without affecting other parts of the system. It’s neat, and lets you build super-scalable systems. You can upgrade background tasks without touching the up status of the frontend. The drawback is that if you’re building a simple web site with no intent to scale globally it might be overkill, and might be more complexity than you’re looking for. (There are some programming paradigms you need to understand before diving into the Service Fabric so it isn’t necessarily a quick fix for your clunky legacy system.)
Azure Functions (replacing Worker Roles)
But what if you don’t want to go all in on Service Fabric, and just what to run some simple background tasks? WebJobs are nice, but they live in the context of a web app. Which means that even if you don’t care about a web site you will need one just to deploy your “Jobs”. That’s not optimal either. One of the later additions to Azure takes aim at this particular set of problems — enter Azure Functions.
Introduced at Build 2016 it builds on Azure App Service to enable you to write simple “Functions” that focus on solving isolated tasks. That extra wiring needed to deploy a worker role? Gone. You can write small snippets directly in the browser to do those simple background tasks. You can configure it to trigger in different ways, and if you want to customize things you can go into all the settings that App Services expose.
What now?
The bad thing is that there is no “one size fits all”.
The good thing is that there is no “one size fits all”.
Sure, you’ve heard statements like that before. This is however what you are faced with when moving from classic Cloud Services to an “Azure v2". If you want a simple function to do a db cleanup once an hour you will probably appreciate that you can do that in a few lines of code in the browser instead of going through the whole deployment cycle by rolling an Azure Function. If you need to rebuild a largish application to use Service Fabric your initial thought may very well be “why fix it if it ain’t broken”, but once you’ve gone through the process you might appreciate your new cluster. (Don’t take this as an instruction that Service Fabric is the only right way to do those kind of apps.)
What if I happen to like Cloud Services the way they are?
If you’re accustomed to using Cloud Services, and have built your code and tooling around that deployment model there’s nothing wrong with that. You can build great stuff on top of it. Changing it just for the sake of it brings no inherent value. However, you might need to rethink this in the future. I cannot speak for the Azure teams, what they will do further down the line, or when they will do things. But I do not think we will see the current Cloud Services evolve much. It might be a valid option for a long time to come for all I know. (Supply vs demand — as long as enough customers are willing to pay for it...) That will probably mean “Being around” as in “be available in the current form with no new bells and whistles”, and at a point in time it will become a less attractive option when you need to refactor your code to meet new demands from your customers. (Maybe Azure is up to v3 by then, and you can skip the interim version.)
If you have a bunch of instances running in Azure already it’s ok to wait it out a little bit longer. However if you are starting from scratch and intend to deploy something fresh in the public cloud I would highly recommend evaluating the offerings above.
