You. Hello and welcome to the let's Talk Azure podcast with your host, Sam Foote and Anne Armstrong. If you're new here, we're a pair of Azure and Microsoft three, six, five focused It security professionals. It's episode 21 of season four. Al and I had a recent discussion around Azure App service, a managed platform from Microsoft within Azure to host your HTP based applications. Here are a few things that we covered modern approaches to application hosting, the features and benefits of Azure App service, how to deploy and manage applications on app service, and how scaling, performance and billing is handled. We've noticed that a large number of you aren't subscribed. If you do enjoy our podcast, please do consider subscribing. It would mean a lot for us for you to show your support to the show. It's a really great episode, so let's dive in. Hey, Alan, how are you doing?
Hey, Sam. Not doing too bad. How are you? Yeah, good, thank you. T minus ten days till Ignite, is that right? Something like that, yeah, around that, yeah. Week on Monday I fly out. It's going to be good. Seems like there's a lot of buzz for Ignite this year. I don't know. Just feels like there's going to be do you think it's going to be bigger than last year? What's your sort of vibe at the moment?
From what I've seen as part of being going there, as part of being part of the staffing for the MVP side of things, yeah, it's definitely some bigger spaces for collaboration, things like that. And well, the fact that it sold out within a couple of weeks of it going as well, I think last year it didn't sell out till late, close to the end, I don't think. Maybe it didn't even sell out, I can't remember. But yeah, it definitely seems bigger from what I'm seeing. And all the schedules are up now as well for all the sessions. Definitely worth checking out.
Yeah, definitely, 100%. Is there a lot of AI related sessions? Is there a big heavy focus on that? Or do you think there's a good distribution of other product bits and bobs anyway? You don't feel like they're missing out on any other product lines, if that makes sense.
Or do you think it's definitely a lot of from what I've skimmed through it all, there's definitely a lot of AI based sessions with all the new copilots coming out and their interactions and things like that, as well as not necessarily the copilots, but actual machine learning within Azure AI and things like that. Definitely on the heavier side of things. But yeah, all the other services and functionalities definitely all got their own spots as well.
Nice. Yeah, it's going to be really exciting and it's great that you get to go out there and meet up with more of the Microsoft community. It's always a good buz at those types of events. Yeah, definitely looking forward to it. I don't think it's going to be a quiet week for me. A lot of things are. Sam, what's this week's episode on?
Yes, so I'm going to be talking around Azure App service. It's something that I've worked with quite extensively, really. Not so much over the past few months, I'd say, but essentially it's a service within Azure to host sort of mainly, actually probably exclusively web applications. It's been around since a day as far as I can remember, and there's some really great features and benefits. So I thought we'd I would say it's a big service in Azure and it definitely warrants its own episode, that's for sure.
Yeah, I think we've definitely talked about it a couple of times. Maybe high level of interactions with it, maybe let's dive in. Okay. So, Sam, what is Azure App service? You kind of started the conversation, but yeah, let's dive in a bit more.
Okay, yeah. So I suppose let's start from the beginning of web application hosting and how you may some organizations still host applications like this, but I'll say the more traditional way of hosting applications, let's keep using the example of a very basic web application that needs a web server and a database server as an example. Your to do list app, right? So traditionally what you may do is you might bring up two servers of some sort. Maybe you'd colocate a server, maybe use some sort of virtual server, and you would install an operating system on that server. Then you install all of the tooling on top of it. So say for your web server, you'd actually have to install a web server. So you might install IIS on Windows, you might install NGINX, Apache, there's various others as well. And you would effectively configure that for your application, you'd somehow package and upload your code to that box. And then you would have to do a similar process for your database server. You would provision your database server and you would install some sort of database management system on that box. You'd network the two together somehow. And then you would point the internet at that web server so that, let's say you've got a public facing app. Your users can get access to that application. So that system, you have ultimate flexibility. It's probably the highest barrier to entry in terms of knowledge and in some respects startup resources, capital expenditure. If you've got to buy those machines, sign into some sort of lease for your colocation, or a minimum contract on a virtual private server, there's a lot of challenges there or drawbacks that you've got to sort of deal with. And then if you own the hardware that it's running on, maybe you even own the environment that it's in. Imagine if you ran it in your own data center inside your own office. A lot of the times you would colocate that out to a separate facility, but you could have the responsibility of the infrastructure, the environment, the operating systems, the software that's inside that stack in order to run that application, and then the application itself, the actual thing that you've just built. You might not also build your own applications. You might be using somebody else's application, maybe an open source application. Let's say you're a university or a college and you're using Moodle as your virtual learning environment. You'd still need to host that somehow. So that's how maybe more traditionally you would host an application and people still do that. And ultimately if you have the knowledge and the resources, there are some drawbacks. But for your use case, that might be completely adequate for what you need. Some other applications need to be highly provisioned, high performance, high throughput really what I would call quotes, public applications. Think of your B to C applications like your social media networks, things like that, where you have high throughput, high amounts of traffic and you've got a lot of discrete users connecting to your system. You can start to have challenges with scalability security resilience in those scenarios. So what are these newer cloud hosting options? So these platform as a service offerings, it's effectively where a hosting provider or a cloud provider run everything from environment boxes, machines, operating systems, even up to that web server and application management layer that is all managed away from you. You can configure, I'd say a good portion of it, but the underlying operating system is the responsibility of Microsoft. The underlying hardware is their responsibility as well. So you're effectively shifting a lot of your maintenance, overhead and management to Microsoft. We'll talk about billing and how know because organizations aren't going to do that out the goodness of their heart, are they? There's a commercial element there. But what really happens in these scenarios now is you provide your code to them and we're kind of really just talking about that web server really. You provide your code to them, usually in a more modern way and we'll talk about that and you provide the files to them and they will bring up an environment that you can host in, right? So you're not having to worry about any of that configuration yourself. It's a completely managed production environment, so it's automatically patched from OS, language frameworks, you name it. They're covering that. They're going to give you a DevOps. In the case of Azure App service, it's going to give you a DevOps integration so you can continuously deploy software into that environment. So GitHub, GitHub and Azure DevOps are supported first party. I believe you can configure other ones. I haven't done it. So I believe you can set up manual hooks for things like GitLab and what's another one? I don't know what Atlassian Source controller is called anyway, but I believe you can configure other Git providers. But don't quote me on that one completely. They're going to take your code, they're going to containerize it and they're effectively going to run it on your behalf. What they're also going to give you the ability to do is to support multiple languages and frameworks without having to do that configuration. So I'll run through the current ones ASP. Net, ASP. Net core. Obviously. Two Microsoft Focus ones java, Ruby, Node, JS, PHP and Python. You can also run PowerShell and other scripts as background services in app service as well. So if you've got, let's say you've got a node JS app as an example, they've got pre installed binaries there, frameworks there, so you can just, in theory, dump your code onto there, pick a version that you want to run it on and away, you know? And management of node JS versions on your own web server is its own challenge in itself, right? So again, instead of having to configure that and manage it, patch it, and all of those things, you can effectively just pick from a drop down list and Microsoft's going to do that for you, which is going to give you it's just one less thing that you've got to worry about once you've dropped your code onto that box. You've got to configure it. So a lot of application use environment variables to configure their applications that are running on it. Things like connection strings or other variables that you want to pass into the application. App service has a way to, I believe they're called configuration settings. You've got an ability to set those in like a web UI. Effectively you can also bind those configuration items to a key vault so that if you have say, sensitive information that you want to pass in, you don't have to just configure it in the portal that any other admin could see. You could basically connect a key vault in and proxy the values into the container and have its own RBAC on top of that. Because the management of configuration is a challenge in itself, setting that up, making sure it's up to date, maybe restricting access to it on the web servers is a challenge. It's something that's been done for ages, it can be done, but again, they're just wrapping it into a really simple service for you. App service has the ability to scale up and also scale out. So what that means is, and we'll talk a bit more in depth about scalability, but you can run multiple instances of your app service and scale it out, like horizontally, maybe even across data centers, availability zones, et cetera, but also scale up and scale down. So when we're talking about vertical scaling, we're talking about essentially adding more resources in to run your system. And it may be that you start off with a lower amount and you grow as your traffic grows, or you might have spiky traffic and that is hard to handle when you manage your own infrastructure. So there's that out of the box. App service is Isosoc and PCI compliant. So from a security and compliance perspective, Microsoft have done a lot of that work for you. You can do things like IP address restrictions and things like that to add extra layers of sort of restriction. On top of that there is a way to also authenticate your users so you can effectively hook in, entraid, ID, Google, Facebook, Twitter, or just a regular Microsoft account. And effectively you can outsource that authentication flow outside of your application's logic. What that's really powerful for is that instead of having to build that routing in and hooking back on those authentication flows, because you could do that even if you had something like B to C. App service is going to handle a lot of that. Taking somebody somewhere else to authenticate and then bring them them back and essentially handing a token back to you is going to make that a lot more simplistic. There's application templates, so there's a marketplace that you can go to and you can install templated applications. So if you're hosting, say a WordPress site, you can go in and do a one click install of WordPress. That's going to be really powerful because again, you don't even have to do that setup. You're just going to click one button, pick your scale size and then you're going to be up and running Visual Studio. Visual Studio code are integrated so you've got sort of dedicated tooling where from an actual IDE on your machine you're going to be able to publish these straight in. There's also API and sort of mobile features. So there's things like cause support, Restful, API scenarios. There's also offline data sync, push notifications, there's sockets, there's any modern application, how should I say it, any modern application design is pretty well supported. If you're using more advanced maybe you're using real time socket connections to push and pull data from your clients that is also supported. So it's very mature. When it comes to running web applications, I've struggled to find an edge case that it doesn't support. Basically from that perspective, I know I've just waffled on for 15 minutes or so. So Alan, any questions? Up to now?
It sounds like the dream. Sounds like the dream, doesn't it, for hosting an application? To be fair, what you've just said in sort of your 15 minutes sprint of it. And like you said, it's just taken a lot of that pain away that you haven't got to pay. Not pay, but you have to have somebody manage the patching of the operating system that makes sure the hardware is okay and in support and all of that sort of stuff. And that's just all done for, you know, the host provider in this know, Microsoft and Azure. You haven't got to worry about it. It just seems like a somewhat no brainer. I can kind of understand that there might be some requirements for applications to only be on premise or in a data center that you fully control due to maybe some more strict regulatory compliances that you have to do, or just strict the type of data you're managing. Maybe I guess we could go down the Azure stack route for that if we really wanted to. But whichever episode we talked about that on exactly.
I think for me, again, because it's platform as a service, you're effectively anything that is platform related, you're handing over responsibility to somebody else, right? And there will be scenarios where it doesn't work high throughput scenarios where you have a huge amount of processing that you have to do. Maybe you'll get a better economies of scale because you may need bare metal access to machines to optimize your application or something like that. Or maybe you need some sort of special CPU instruction that you can't get here. But what I would say is a vast majority of apps are just basic data management apps, right? A lot of CRM systems are just pushing data in and out, transposing it. It's not like you're running huge amounts of processing through it all the time. So my thing is we see this a lot in the applications that we look to support is how much resource are you actually consuming, right? Can you scale back down and go for a lower tier? Because if I said to somebody, oh, I want you to provision a server with 2GB of ram, and you'd be like, no, I'm not going to provision a bare metal box with two gig of ram, because I've got to host the operating system, I've got to host my application. And I've also got to expect that there's going to be an element of scaling there over the years. So I've got to provision for that. But here what you're doing is you're just paying for what you use, not what the platform is consuming, right? It's just what your application is using. So you do have to reframe your thought from a more traditional provisioning perspective.
Well, you can start fast, can't you? You haven't got to worry about, like you said, buying hardware, buying rack space in a data center, et cetera and things like that or anything like that. It's just got a host. I need to put some code up.
To get your app service up and running. I mean, before you push your code to it. It's like a few blades in Azure and it depends how sort of bespoke you want to make that, how long that will take. But then you've effectively got a landing page with an Azure provided domain name and you're sort of ready to go there. You click on the link in the portal and you can see a holding page saying, hey, your app service is ready to go upload some code and get started. So as soon as you've done that, it takes a few minutes and you've got all of that platform ready to go. Like you say, there's no long winded procurement of hardware. I suppose that you can sort of argue that you've got to have a subscription and a billing method set up and all of that sort of stuff. But yes, but if you're an organization that's currently using anything in Azure, you've probably already got some sort of commercial agreement in.
We well, I guess we kind of talked very briefly about this, but how do we deploy app service in Azure?
Yeah, so there's a few different ways you can connect GitHub, sorry, bitbucket is Atlassian's Source Control provider. Completely forgot about that. And Azure DevOps repos as well. You can also deploy so you can effectively, whatever their CI, CD or Pipelines technology is, you can connect a repository in those environments and as you build and push new versions in, they will automatically get deployed dependent on the configuration that you've made. So if you're building software, that's a really good place to be. There's the concept of deployment slots as well. So as you deploy new versions, you can test it on a certain number of users and divert users into there load, balance and scale that way. So there's a lot of flexibility there. I don't want to go into the weeds too much, but I've just got to make you aware that just because you push doesn't mean that all users get it automatically. You can control how that's released. You can also deploy directly from your local machine, so you can produce what's called like a zip deploy and you can effectively upload a zip file of your application. So you can package that usually in something like Visual Studio and then it would go up into app service. Apparently you can also do OneDrive and dropbox folders. I have never seen that in action whatsoever. But as I was researching the edges of my knowledge for this episode, I found that little nugget of information. I thought, that's definitely something that's on my list to give a try now and to work out why that would be needed. But somebody obviously asked for it at some point. So yeah, so there's a couple of different sort of deployment method mechanisms there's. Effectively there's a thing called Kudu, which is like the helper productivity tool that helps you to it handles continuous deployments of your applications, but it also gives you more insights on how they're running. So what you can do is you can click on Kudu in the portal and it takes you to a different place, which is its own separate, self contained sort of application management area. And that's where you can drill in and see what's actually running in the environment. You can look at the files that were deployed and you can delve deeper, basically. So yeah, I've talked about deployment slots, but you can effectively have you can have your sort of production slot. A new version comes online, you can have staging environments where you validate your newest changes and you promote between those deployment slots. And that's basically as you deploy your dev to your staging, to your main to production, that's how you then sort of migrate up those slots and finally promotion to production. So you can use the same infrastructure if you want to, to host all of those different levels, or if you want to, you could obviously separate them out into different areas. You can also run containers themselves. So especially on Linux, it's going to containerize your app, it's going to wrap your app inside of a docker container basically to have the segregation. But you can also deploy containers that you've developed yourself into app service and run them. So if your build pipeline, the output of your build pipeline is an image, like a container image, then it can sort of use those deployment slots to deploy different versions of your image and then promote them through the slots. There's a lot of really good getting started guides for things like Azure DevOps, GitHub actions and also there is also ways to connect them in and there's some good documentation on how to use other automation providers, maybe using Travis CI or something like that as a separate one. It's probably worth noting is there certain areas inside of app service where there is actually persistent data and sort of local cache and temporary data as well. So one of the big things is when you're using platform as a service, people try to work out where they write files to. So there is a persistent storage mechanism inside of app service, but more traditionally we would back a lot of that storage off to either the database layer or integrate something like a storage account for that as well.
Cool, okay, so there's definitely loads of ways to do the deployment side of things. Is there something around app service plans as well?
Yes. Is that what it sits on? Yeah. You effectively have an app service plan which is it kind of represents your web server really? That's where your SKU is based. And on an app service plan you can have multiple apps. It depends what app service plan you have. But what app service plan starts to get us to think about is sort of app service environments as well, where you can effectively build an app service environment that is completely isolated. You can isolate your application from effectively everybody else inside of Azure. It's like another only certain SKUs are supported there. What this is mainly good for is if you do have some sort of compliance need where you do need to officially be inside a completely isolated environment, maybe you want to dedicate your own resources to it as well. So it could be a performance thing with that. But also then you can connect an app service environment to your VNet and have potentially purely isolated and disconnected application from public consumption as well. So it's probably worth calling out now. App service apps do not need to be serviced to the internet. The default out of the box experience is going to be that, but you can privately connect them to a VNet and block all internet traffic as well and isolate them should you wish.
Okay, cool. Okay, so we were going to talk about this. We talked about talking about this earlier. Too many words there. How is scaling handled in app service?
Yeah, I suppose I briefly mentioned it vertical and horizontal scaling. It's going to give you that load balancer that you're going to need in front of it. So if you say that you want six instance of your application, then it's going to give you six instances of your application. There's some limits to how much scaling you can and can't do at different SKU levels. I won't really go into it, but when you're getting into what I call the standard and above more productiony enterprise levels, there's very high limits, so you shouldn't really ever bump into that. There is also auto scaling as well, so you can scale your instances based on a metric within your application. So you might say once my memory or CPU hits, let's call it 90% as a random example, then please add another please add another instance. I'm not sure the actual name they call them. I think they just call them another app service. I think it's just an instance. I don't think it's a node. I think they call it an instance, but you can add one more and then when that demand reduces, you can scale back if you want to. There's a bit of a word of caution there. Your application has to be sort of multi node instance compatible. You need to think about shared caches and memory when you're building applications. So a lot of newer applications are but traditionally a lot of applications were never built designed to be on more than one host at one time. So that's something to think about. And also that scaling can take time to happen. So if you are running what I call like a spiky application, you've got a retail application that an ecommerce platform that is going to get absolutely hammered over Black Friday. It's probably worth pre provisioning. That what I've worked on before in the past, is when a big event is coming up, they'll manually scale it the day before to ten times the capacity, and then the day after the event's done, they'll scale it back down. Right? Yes. They paid ten times the cost for two days or whatever number it was, but they've got none of the drag cost of pre provisioning hardware or anything. So there's ultimate flexibility with these pay as you go plans, because if you do have that up and down traffic, then you've got real benefit there.
That's great, isn't it, really? Because like you said, you're only paying for what you're using or what you've built in effect or sized. So like you said, Black Friday ten times the amount of hosts for a bit for a couple of days or for a week. Don't know how long Black Friday lasts for now, it's like six weeks at this point. But yeah, it's great. So, yeah, it's definitely a load of options there, isn't it? I think the audit scan is quite good and things like that. I guess it's just getting like you said, there's a bit of a delay or a delay of it being spun up as such. So you just need to make sure your metrics sort of right to give you enough time in case it maxes, I guess.
Yeah, to provision a new instance to put the code on there to get it healthy so that the load balancer accepts it, especially if you've got big instances that might take a few minutes to happen. I don't think it's really unreasonable to expect all that magic to happen in that amount of time. So yeah, it's definitely worth thinking about that, but at least you have the ability to do it. That's the most important thing.
Okay, so onto the next bit. So how do we monitor the app service or in effect, manage it on top of it?
Okay, so you effectively got diagnostic settings via Azure monitor, so very similar to any other sort of Azure first service. And then what you do with those logs and metrics is completely up to you. One sort of scenario that I use is I use Application Insights a lot because Application Insights can you can embed it. Well actually if you've got a net application, you can just toggle one, I believe it's like one checkbox and Application Insights will be injected inside of your application so you don't even have to do any configuration of it. And then what you're going to get is you're going to get application metrics and also sort of platform level metrics being fed into the same place at the same time. So you can start to see the correlation of because when you're diagnosing an application level issue you need to see try and correlate the infrastructure and platform issues that are caused by code issues. Like, let's say you have a database query that is fine at the database layer, like you're pulling a huge amount of data back. But then let's say in the web service you're then mutating that data, you're maybe processing it on the fly and maybe it takes a half a second to come back from the database, but then the web server gets absolutely hammered for like three minutes, right, and everything starts timing out. Being able to look through that full chain and see as much sort of enriched information as you can whilst you're debugging, especially in production because you usually get a lot less information, is also really beneficial there. You can have quotas, you can have metrics. Like you can with any other Azure service. You get activity logs, so when you're changing your resources, you get to see them there. Log Stream is really powerful as well. There's an option in the left hand menu, you click Log Stream and it will stream the standard out logs from your application in real time. So what you can do is if you ever want to what I like to do in my development environments is to make that logging to standard out really sort of verbose, so you can see a lot of information. The only thing you have to be careful of that of is that it can log to disk and it can fill up your disk space. So you just got to be a bit careful with that, especially if you set informational to sort of everything so that handled with care. But if you've got your own sort of custom metrics that you want to put out, then you can see it there. So there's loads of different ways to monitor it and it's all sort of fully integrated really, I'd say.
Okay, great. So, networking, we kind of talked about it. I think you said we can hook up to a VNet. Is there anything out of the box? I think you said it's pretty much on the public Internet ready to be used. But is there anything else you need to configure for it?
Virtual Network Integration is there. There is basic inbound and outbound IP like you would with a Virtual Machine. You have the ability to set up very basic IP restrictions and firewall there. You can integrate it with azure firewall. So you can very easily integrate the two and give you a bit more, a lot more power there. Application. Gateway. Nat gateway traffic manager. You say any name of any sort of networking or control related tool inside of Azure, you've potentially got an integration there as well. The big thing with networking for me is that terminating, if you've got a private application, it's giving you that virtual network access, right? And you've got different ways to communicate with that virtual network, right? But what I think is really powerful around these things is because by default your machine is just publicly accessible to the Internet, right? And there are so many things going on there that you just don't have to worry about. You've got a load balancer to scale between your instances. You've got all of the networking stack in front of it that you just don't even have to worry about. You can also put like a CDN in front of it, a cache if you will, in front of it. There's many different tools and many different ways that you could do that. So effectively, if you've got either public or private networking scenarios, there's a lot of feature rich benefit there with app service. So public or private, there's probably a solution there for you from a networking side.
That'S amazing really, isn't it? About the amount of capability there to put in front of it. It kind of feels like there's a lot of Azure services that can just integrate almost is first part integrations, but it's actually designed for all of it kind of thing. Because there are some services that don't really interact with each other because there's no need for it kind of thing. But the app service definitely feels like it's there to grab what it can from other Azure services to help protect it, secure it, make it functional, et cetera. So that probably ties me on to sort of my next question around security. We're always concerned about the application security, its front door, as well as the hosting kind of thing. So how is that handled?
Yes, I suppose there's a few different layers to security, isn't there? Right. It's quite overarching. So let's just talk about some of the key sort of areas really. Okay, so staying up to date is obviously a really important element of know threat, vulnerability, know really making sure you're on the latest supported platforms, programming languages, protocols and frameworks, right. Microsoft is going to continually move you along in terms of doing that. It's probably worth, probably worth some caution there because if you are going to sort of laggard behind and not update, you may bump into issues with them. Retiring app service versions. So for instance, if you're on an older version of PHP, then you have to move your application or rebuild it somehow. They might not still support that version when you come to rebuild at that point. Right. So you do have to have that mentality that you're going to move forward. But that's any sort of general security recommendation that's what we're going to make is that you're staying on current LTS or versions. Identity and access management. So you can disable anonymous access if you wish. You can layer that on. You can force authentication with, with the tooling that we've had that you can also protect sort of back end resources with authenticated access into sort of back end systems. And client certificates are also supported as well if that's an access strategy that you employ. Data protection. So forced redirection from Http to HTPs so you can get it to rewrite all your URLs and enforce it. When you're connecting into other Azure resources, you can force encryption of those connections so that your full end to end, from client to database. You can have full encryption all the way through. We've spoken about this, I spoke about this previously, but taking sensitive information out your code configuration files. So this is where we're talking about proxying secrets into your configuration and into your application from key vault. So key and secret management it's first party, they're ready to go. There's validation of the files that you're uploading to make sure certain deployment artifacts aren't deployed onto the production web server. That can help an attacker to understand more about your application. So they're also thinking about that as well. Networking. So we've got limit of exposure to inbound network traffic. You can decide how you want to connect into those on premise resources, hybrid connections, virtual networks, app service environments. There's a lot of functionality and features there for that isolated, we talked about that. But again, you can have a fully isolated environment and dedicated App service environment if that's what you want to put into there. And yeah, monitoring. So it's integrated with Defender for cloud as well. So not just from a cloud security posture management perspective, but also potential threats that are coming through and actually looking and mapping sort of multistage threats into vendor for cloud. So highly integrated and a lot of these sort of security themes pillars are covered with a lot of the tooling that's there.
Cool. Yeah. I was going to shout out about the Defender cloud integration, but you beat me to it. Yeah. Okay. So device application is secured. How is disaster recovery managed? All set up if a region forbid goes down.
Yes. So we can, if we want to have a multiregion application, what that would normally be set up in the way of is that you'd have something like an active and a standby region and then you do something like Front Door. I think it's called azure. Front door. I think that's its full name. Yeah, it is. Azure front door in front of it. And Azure Front Door is like an access broker with a CDN and caching and it's got a firewall in it. Did we do an episode on Front Door?
Might have done, can't remember. But I think it's kind of a combination, isn't it, of the Azure Traffic Manager and something else, isn't it?
Yeah, it's effectively a broker and access door. It literally is a front door for putting in front of App service well, web applications really. It's not really a true CDN so to speak, but it has got CDN like and routing and firewall capabilities. But what you do is you put Front Door in front of two regions and then you'd effectively look for the health of those two regions and then within those regions you could have multiple app services which are load balanced as well across availability zones. So you could get a lot of really high so that's from a high availability perspective in terms of sort of disaster recovery, there is built in backup and restore capabilities of App service instances as well. I don't believe you get them on the lower tiers, but there are strategies and ways to if you were to rebuild directly from full disaster, there's a few different ways you could approach that because you could do that from your Git provider and your pipelines. There's multiple different ways to approach that, but there is tooling and support built in for high availability and also disaster recovery.
Yeah, okay, I guess in some ways. Well, without using that tooling, if you've got TerraForm, things like that, it'd be quite easy to spin the new service up somewhere if you didn't have that other capability in straight away kind of thing.
Yeah, and multiregion with front door in front of it is going to protect you against portal downtime and things like that. So that's really your high availability strategy for me is really your primary defense mechanism. And then disaster recovery is well, literally as it says, everything goes to but then if everything well, I don't know. Do you see what I mean? So you've got to have both sides of that strategy. But yeah, there is tooling there for you.
Cool. Okay. So it sounds like this does quite a lot of things. I guess the question is how much does it cost? How is it licensed or how is it consumed?
I heard you like free stuff, Alan, so I'm going to give you the good news first. Well, actually no, I think it's pretty good news across the board. So let's talk about the Free plan to start off with. So you can have up to ten web, mobile or API apps. In the Free tier you get one gigabytes worth of storage and I believe you get 1GB of Ram. There's no SLA provided for the free tier, but you get one gig of Ram, one gig of storage, shared CPU cores, but you only get the total of 60 CPU minutes a day. Do not ask me how that is calculated, but effectively you get a quota with that. Applications in the free tier I think are scaled down after 20 minutes, something like that. I think you can force them to stay live on that. So that's really good for validating that your application can be deployed there. Because free is free as we say. You're just not going to get a huge amount of benefits there once we bump up to Basic. So Basic is designed really for sort of lower traffic requirements. You can have an unlimited amount of apps inside Basic. You get 10GB of disk space. You can have up to three maximum instances. Oh, I got the name right. Instances. There we go. I'm reading the table from pricing because I can't remember this off the top of my head. You're allowed a custom domain at that point. We haven't spoken about domains actually. But you can have bind your own custom domains in there as well. No ability to auto scale, but you can do hybrid connectivity and virtual network connectivity. On Basic. You can do private endpoints as well. On Basic, the compute is dedicated. You can either buy one, two or four cores and then either 1.75gb, three and a half gig or 7GB of Ram. The cheapest, the single single core with 1.75 gig of Ram is $13 a month. So for $13 a month you get VNet support. Poor old logic apps. So you get $13 a month. I think it's because you're basically paying for V cores, right? You've got an actual instance there and then it basically just doubles. So two cores is $25 a month, three and a half gig of Ram, four cores, seven gig, $51 a month. So again, pretty, you know, you know, pretty simple there. Basically, if you go Linux, these are all let me just double check. Oh, these are all Linux prices, actually. Okay, it changes a little bit. Okay, I won't go through all the things, right? What I'll do is there's free and Basic that we just talked about. Standard gets you more instances that you can scale up to. You get more disk space, 50GB of disk space and bigger sort of instance sizes. So they're slightly different effectively, they're slightly different CPU, but again, they scale up, but they start at $73 a month. On Linux premium, again, unlimited apps up to maximum of 30 instances, 250 gig of disk space. Everything else is exactly the same. Starts at $82 a month. And then isolated, you get up to 1 disk space up to 100 maximum instances. But the compute type is fully isolated at that point. But you're starting at like $200 a month for a single V core in the isolated environment. It's probably worth noting that on Linux when you go premium, you can start to do reserved instances as well. So I'll give you an example. For a Linux, pay as you go is $82 a month. If you reserve it for three years, it's $37 a month at that point. So you can get some really good savings because everything is a V core based basically. Let me just try and talk to you about okay, so the only real difference with Windows versus Linux is there's an extra SKU, which is called shared. So you've got free to start off with and then you've got shared. Did we have shared before? Let me just double check. No, on Linux it goes free Basic standard, right? And on Windows it goes free shared Basic standard. So there's this extra one called Shared and it's only $9 a month, but you essentially get more CPU minutes. You go from 60 CPU minutes to 240 CPU minutes. So you can basically have your app up for longer. And it's only $9.49 a month basically, at that point. But the rest of the tiers are effectively the same. They just cost more basic. Yeah. So the starting price of Basic on Linux is $13 a month and the starting price of Basic on Windows is $68 a month. So you can have Windows based applications as well. So there's lots of different options there. Sorry, I started to go through them all. I shouldn't have done that. But you can see that there's a lot of flexibility there for you.
Cool. Yeah. So it doesn't sound too expensive to start off with, at least like you said, even with the free to even if you paid for some of the basic ones. I wouldn't say it's breaking the bank, really, to get started at least. And then you move up to your premium tiers when you need to, et cetera, for production.
Yeah, and I'm not 100% sure, but I think the SLAs just start at that basic tier I believe might be Basic or Standard, I'm not sure. And then they're all pretty similar there. So if you are running an actual application, you can get away with Basic, to be honest with you, because it's got a lot of that advanced functionality that you might need, like VNet support and things and bits and bobs like that. So it's pretty flexible, I'd say.
Cool. Okay. So do you think there's anything else we've missed or any previous episodes you want to talk about?
Dev test pricing is available. That is available. You can purchase custom domain through it as well. SSL certificates. It can provision SSL certificates and if you want to buy your own, you can buy them through Azure as well. That's pretty much it really, from my perspective, lot to unpick there because just application hosting in itself is pretty involved. So if you are looking to host an application in Azure, definitely check out App Service because it can save you a lot of time, that's for sure. Nothing else. More from me. Previous episode to call out is probably Function Apps. I would have thought season four. This season episode I can't remember what it is. Is it episode two, three? Episode three. So yeah, function Apps is probably a slightly different type of application, but the way that it's hosted is very similar to App Service, I'd say.
Cool. It's only 18 episodes ago. Seems insane badge for that, if I'm still right. Cool. Yeah, cool. Okay. What's next week, Alan?
Yes, next week we're going to talk about because I don't think we've done it since our very first season when we were new to this. So I think it's worth going through any of the new changes to the Microsoft certifications and the accreditations because there's been some new releases recently about a new type of accreditation there. So I think it's worth just going through that, going through some plans and that especially around I'll probably focus on the security certifications, things like that, because it's my area. But we're generalized as well, generally about all of it. I think that'd be good to just have a top up on that. I don't think we've, like I said, done it since season one, so definitely some time ago.
Cool. All right, that's great. Thanks, Al. Yeah. Okay. So did you enjoy this episode? If so, please do consider leaving us a review on Apple or Spotify. This really helps us reach out to more people like you. If you have any specific feedback or suggestions, we have a link in our show notes to get in contact with us. Yeah, and if you've made it this far, thanks, everyone, for listening, and we'll catch you up on the next one. Yeah, thanks, all.