As we’ve discussed before, Azure App Service is the primary PaaS offering from Microsoft. You simply deploy your application code and voila — your website/API is live.
That means no more setting up your own VM or installing your own OS or even web server.
Well, that’s the general idea, but remember:
There is no Cloud, it’s just someone else’s computer
The goal of PaaS is to alleviate the need for you to worry about lower-level details by moving you one abstraction level higher. At the end of the day, though, your application code must be running on a VM somewhere.
That’s where an App Service Plan comes in.
Every App Service you create must have an associated App Service Plan.
Think of the App Service Plan like a hosting plan that you purchase. You still want to specify that your web app runs on a certain amount of CPU and RAM and disk space, and you may even need to indicate what OS (Windows/Linux) you want to be setup for you.
Basically, an App Service Plan is a facade over a VM that will house one or more of your apps. Microsoft just wants to streamline the process of getting your app out there by offering a few standard hosting options to choose from, priced in terms of the underlying specs and operating system.
Yes, there is a VM. No, you don’t have to manage it.
So, it’s up to you whether you choose to think of your web app as being deployed to a hosting plan or if you want to think of your App Service Plan as a pre-configured VM that you don’t directly access; either way, we’re talking about the same thing.
You’ll still be able to examine a few aspects of the underlying VM like browsing the file system or the OS/application processes currently running on the machine. However, this information is mostly exposed to you through the Azure Portal itself, making the distinction clear: you can peek in, but it’s not your responsibility after all.
You can, with a few clicks, upgrade the specs of the App Service Plan to double the number of CPUs used, for example, and still expect that your app will work without any additional steps. You can even configure auto-scale-out rules that will seamlessly add additional boxes to your App Service Plan based on certain CPU or memory thresholds that you specify.
You pay by the size of the App Service Plan selected as well as the number of underlying VMs that will simultaneously run your code.
The App Service Plans come in a few different tiers (free/shared/basic/standard/premium) and VM sizes. Tiers unlock additional features like auto-backup and staging capabilities (e.g. deployment slots), while VM sizes determine how much horsepower your apps will have access to.
I should also call out that you can host several apps on the same App Service Plan to optimize your resource consumption (and associated costs). You can also configure auto-scaling rules for those occasional spikes in traffic. These parameters give you both the flexibility and scalability while you hone in on your application’s actual usage patterns and needs.
Note: it’s also possible to setup a “consumption”-based App Service Plan, but we’ll discuss that in a future blog post!
Back in the early days of cloud, people used to debate the choice of hosting their servers on-premise versus in the cloud. The debate eventually progressed to whether you want to host your own VMs in the cloud, or simply host the actual web app in the cloud (leaving the infrastructure, VM, and even the platform concerns up to someone else).
Well, I think that software companies should focus on making great software.
The less time you have to spend on maintaining your servers and worrying about OS-patching cycles the more time you’ll have to differentiate yourself from your competitors using the software you create.
Stay curious,
MJ
