You've probably heard the term "serverless applications" or "serverless apps" thrown around quite a bit. But let's be real, the term "serverless" is a bit of a misnomer. Misnomer? More like 'myth' or maybe even 'lie'.
It's not that there's no server involved, it's just that you don't have to worry about it...that much. Well, "serverless" is a myth because there's always a server. This article is going to take you through the basics of Azure App Service Plans -- aka. the "server" behind your Azure App Service.
About this Series
This post is part of a series of articles and videos about Azure App Services and ASP.NET Core security. I'll be publishing new content every couple of days along with videos on YouTube.
Here's the video that goes along with this article:
https://youtu.be/O0Z1wyJo3AE
The Myth of Serverless
When someone says their app is "serverless", or they want to use Azure or Google or AWS because it's "serverless", it's not entirely accurate. There's always a server involved. Your app doesn't just magically execute in the cloud. There's something running your application, hosting the files, and the logic. There's a server somewhere.
So, what does "serverless" actually mean? It means you mostly don't worry about the server that your app is running on. You're not worrying about operating system patches, networking stuff, hardware stuff, air conditioning, internet pipes into a building, electricity, and all that jazz. It's someone else's problem. The goal with serverless is to minimize what you have to care about with regard to your hosting environment. The server becomes just an abstraction -- something you don't have to worry too much about.
Azure App Services: The "Serverless" Solution
Azure app service web apps are "serverless". And yes, I'm using quotes because there is definitely a server running your Azure app service web app. This brings us to the crux of our discussion today: app services versus app service plans.
An app service plan is that abstraction that represents your server in a serverless environment. You don't pay for web apps, but you do pay for app service plans. Under the hood, it's basically a virtual machine running somewhere in Azure. This virtual machine hosts your web apps.
The Importance of App Service Plans
Here's something interesting: you can host multiple apps inside the same app service plan. Each of these apps can have different domains and totally different configurations, but they're all running inside the same app service plan.
From the web app's perspective, it runs inside of an app service plan. You pay for the app service plan, which is essentially the virtual machine that hosts your app services. The app service plan is the virtual machine that represents the server that runs your apps, and you can run more than one app inside of the same app service plan.
Why Understanding App Service Plans Matters
Understanding this distinction can save you money and help you scale your application. You have the option in app services to scale up or scale out. Scaling up means throwing a bigger virtual machine with more powerful specs at your app services. Scaling out means having multiple instances of your app service plan running on a VM that maybe is not super powerful.
If someone in your team starts talking about microservices, and they're thinking about hosting them on web apps in Azure, make sure they understand the distinction between the app service plan and the web app. I've seen customers end up paying a lot of money for their microservice architecture because they didn't understand this.
Summary
So, to sum it up, the app service plan hosts your web apps. You pay for the plan, not the web apps. The app service plan is basically a virtual machine that hosts one or more web apps in Azure.
In our next post, we'll do a demo and create an Azure app service. Stay tuned!
