Azure Virtual Machines and App Services are the two basic pillars of Azure cloud services. Both offerings provide a way for you to execute workloads or host your server in the cloud. In both, you pay for some virtual machine in an Azure data center that runs your code. But that’s where the similarities end. One is bare bones infrastructure, whereas the other is a managed platform. One is customizable but hard to manage, whereas the other requires forces you to use the specific tooling and configuration Azure offers. In this blog post, we’re talking about the difference between Infrastructure as a service (IaaS) and Platform as a service (PaaS). We will talk about the differences between the two approaches, the pros and cons of each offering, and the rules of thumb of when to use each.
VMs are easy to understand. You rent a virtual machine from Azure and do whatever you want with it. You can connect remotely to that machine, add or delete files, install programs, expose ports, run servers, etc. It’s somewhat similar to the old on-premise concept, but there are plenty of advantages to using cloud: you don’t need to handle the hardware purchase, the physical storage, and the maintenance of the computer. Azure takes care of broadband connectivity and network uptime. Most importantly, you can scale up and down as you please, though with Azure Virtual Machine you’ll need to manage it yourself with VM scale sets.
Azure takes care of a lot for you, but as opposed to an App Service, you still have to manage and run the server yourself. You’ll have to install a server tech (like IIS), a runtime (like .NET), and a deploy mechanism (like web deploy). You’ll have to take care of OS updates and security patches. And you’ll have to install and manage whatever monitoring and debugging tools you need. If there’s a crash, a hang, or a performance problem, you need to develop a way to investigate it yourself.
An App Service is quite a different beast. Although both Virtual Machines and App Services run on the same VMs under the hood, an App Service doesn’t expose that. Instead, it acts like a black box that can run your code or host your server, whatever language or runtime or operating operating system that might be. That’s why the term Platform as a Service is so well fitted. It doesn’t do anything by itself, but rather it’s a platform to run and scale your code.
An App Service will install the language runtime, server framework, and deploy mechanism on its own. It will update the operating system and will install proprietary monitoring and debugging tools for your convenience. Those would be Application Instance Profiler, Windows Error Reporting for crash dump, etc.
Sounds great, right? But as you might expect, both offerings have their pros and cons.
Pros of App Service
- An App Service saves you the effort of managing the operating system updates and security patches.
- The environment setup is taken care of, whether it’s installing IIS, a runtime setup, or configuring the Windows firewall.
- You get some monitoring and profiling tools out of the box, like performance profiling with Application Insights Profiler or crash monitoring.
- You get deployment slots that allow to deploy to staging environments and then instantly “switch” the staging and production for deploy without downtime. The new production, which was staging a seconds ago, will now get all the production environment settings.
- You get a built-in authentication mechanism known as Easy Auth that allows you to authenticate your users on your own or integrate with 3rd party auth providers like AAD, Facebook, Twitter, or Google (or another OpenID Connect provider).
Pros of Virtual Machines
- You can Remote Desktop connect to a Virtual Machine, something that’s no longer possible with an App Service.
- In a Virtual Machine, you can run whatever processes and services you want, whether those are watchdog services, background workloads, crash monitoring tools, or anything else.
- While an App Service allows to profile and monitor using Microsoft technologies like Application Insights, you can use whatever tools you want in a virtual machine. Those might be Application Performance Monitoring (APM) tools like New Relic, memory profilers like .NET Memory Profiler, or performance profilers like dotTrace. Note that some of those tools can be used in an App Service with Site Extensions.
- If you have a bunch of existing functionality on virtual machines, it will be easier to port to a Virtual Machine on Azure.
Making a choice
I’m going to give you some opinionated advice here, albeit based on experienced. As a rule of thumb, an App Service has an obvious advantage in the amount of work and effort you get to save by not having to manage your machines. So the default choice should be to go with an App Service unless you have good grounds to do otherwise. Even if you have good reasons, they need to be carefully weighted against the ongoing amount of work you’ll have to spend managing your resources.
So what are really good reasons to go with Virtual Machines? One such reason is if you have custom tools that you absolutely rely on. Or any type of customized environment. From my experience in tech companies, this is a very common scenario.
You also might want to run some workload in a language not supported by App Service, which supports only .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python.
We talked about choosing between the two great pillars of Azure: App Services and Virtual Machines, but in truth there are more pillars than that. Specifically, I’m talking about Azure Functions and offerings around containers. To understand those offerings better, check out my article The Best C# .NET Web Application Tech Stack: Deploying to Azure. Cheers.