Deciding between Azure Web Apps and Cloud Service

Anze Vodovnik -

Recently, at a project, we had to decide which technology to use. So far, for most of the projects I've been a part of, that run on Azure, we've gone with Cloud Services. Obviously, each project had their own separate reasons. For example, when we rebuilt MojeDelo.com at Studio Pešec, we used Cloud Service because we needed to run Solr. At that time, Azure was pretty new, so we were early adopters of the PaaS technology, and had to come up with new ways of doing this. Web Apps (or Websites) didn't even exist back then, if I recall correctly. Similar reasons existed for next projects. Lately, at Saop, when we were building the Single Sign On solution - Directory Services (called Saop User Account by Marketing), we again faced the dilemma. However, we needed to support using certificates for signing in, and Websites (they were still called that then) do not give you enough flexibility.

Now, however, any time I start an Azure project discussion, assuming it requires a web front-end, I start with a Web App. Sure, it gives you a little less control over the underlying environment, but that is exactly what I wish for.

MSDN has some articles on this, one you can find here, that are pretty good at extensively covering the differences. The following image is taken from the linked article and clearly shows the benefits of each approach. Note that I've intentionally omitted Virtual Machines because I really don't like them. They make sense for porting legacy apps there, but it's not really PaaS.

What actually are Web Apps and Cloud Services

Put bluntly, the easiest technology to explain is the Virtual Machines. You basically run a Virtual Machine you provisioned yourself (and need to manage yourself) on Microsoft's hardware. They manage replication of the disks so that it's all stable and fairly redundant. So if anything happens, your VM is more or less undamaged and back up.

Cloud Services build on that concept. It's basically a managed virtual machine, where Microsoft manages the operating system (and updates to it), but you still have control over it. Why is that good? Because you can do stuff like install custom software on provisioning (e.g. Solr, as mentioned above), or register custom root certificates (such as in our case), unlock configuration sections, etc.

The Bad Side of Cloud Services

The primary problem, and the one receiving the most criticism is that is takes a seriously long time for a deploy/upgrade to happen. The reason for that is that it does a lot of stuff in the background to make sure your application has 99,95% availability. That means it has to provision a new VM (that actually means spinning a brand new Windows machine, running all configuration tasks, installing your software (pre-reqs)...). When it's done, it reconfigures the load balancer in front of your machine to make sure new sessions go to your new machine. And then it kills the previous machine... Well, that's a very rough description. But it gives a good overview of the amount of work that needs to be done.

So, every time you upload a new version of your code, it takes around 15 minutes for it to be deployed to the machines. That is if everything works. So, as you can figure, that was a big complaint and pain point. In addition, Microsoft figured out that companies have various requirements for their web applications. So they built Azure Websites. Then they figured out that the name isn't doing it justice, and they rebranded to Azure Web Apps.

The Benefits of Web Apps

Well, Microsoft figured out that a lot of projects these days involved serving up a (web) front-end. Then, they figured a lot of projects also need one or more of the following: a back-end for mobile clients, an API access point, and some logic connecting various different APIs together.

 

They figured this is one product, and they call it Azure App Service. A part of that service, is Web Apps. Quoting Scott Gu's blog, this is what the idea behind Web Apps is:

  • Support for .NET, Node.js, Java, PHP, and Python code
  • Built-in AutoScale support (automatically scale up/down based on real-world load)
  • Integrated Visual Studio publishing as well as FTP publishing
  • Continuous Integration/Deployment support with Visual Studio Online, GitHub, and BitBucket
  • Virtual networking support and hybrid connections to on-premises networks and databases
  • Staged deployment and test in production support
  • WebJob support for long running background tasks

In my opinion, the biggest benefit is the continuous integration/deployment support. An update is really fast, and can be done using command line tools (e.g. Azure Powershell SDK). We are using that as part of our build process, and as part of the formal production deployment process.

Why did you choose Web Apps instead of Cloud Services?

Well, for the latest project, it was a fairly easy decision. We needed something that scales easily, allows us to publish quickly and we wanted it to be as transparent as possible - meaning that it has to run almost the same on a local IIS as it will in the Web App. This also means that we can also switch easily to cloud services, if need be.

We did not have any custom configuration requirements, and we offloaded all other requirements (like the certificates) to our other product - the User Account.

All the other benefits, like the much much faster deploy, contributed a lot to the decision. In addition, we can still use multiple slots when deploying (e.g. staging, production). For our background jobs, where we needed to have Workers deployed previously, we now use Web Jobs which are basically still workers, only billed and provisioned differently.

What happens when you outgrow Web Apps?

Well that one is easy. IF we ever outgrow them - note that the major reason that could happen is if we introduced a requirement that is unsupported on that environment, like custom certificates, we'll simply redeploy that as a cloud service. In the end, you have to understand that both deployments are basically web applications running on IIS.

What good does that do me?

Basically, very little. As with all architectural questions, the only correct answer is "it depends". However, it does give you a perspective into my thinking process and the factors that affected the decisions above. But, if you need a second opinion with your decisions, leave a comment underneath, or send me an email (first name at this domain dot com).