App Hosting Flashcards
Azure App Service
Is a fully managed platform-as-a-service (PaaS) offering, for building, deploying, and scaling web applications and APIs.
-if we want to access our app, we can easily deploy that and use one of Microsoft’s built in domains or use our own custom domains
-Support for SSL encryption
Web, Mobile, API Apps
-You can build web, mobile or API apps (Windows/Linux)
Container Apps
-You can deploy using only code, but if your solution is containerized, you do get support for Docker containers (Windows/Linux).
Static Web
-You can deploy Static Web to keep costs low
-You can use the products “Static Websites” or “Static Web Apps”
Other Apps:
-App Service Environment (ASE) is a special type of app service that you can deploy very isolated to your own VNet
-You can deploy Function Apps to App Service, using the consumption plan, which makes it serverless
-You can deploy Logic Apps to a App Service Environment
Key Considerations
-Reduced overheads (OS admin, security, runtime configuration, etc)
-Managed web hosting platform with supporting features & capabilities
-Supports CI/CD for packaged or containerized solutions
-Simplified auth capabilities (EasyAuth) supporting Azure AD and others
Architecture
Resource Hierarchy
- App Service Plan: The resources, operating system, and features available to your app
-The underlying infrastructure to host your apps
-If you want features like custom domains, SSL, auto scale, all that can be influenced by the Plan you choose - App(s): Runtime environment for your app (container or language/runtime)
-Not all languages and runtimes are supported across all O.S
-You can run multiple apps on a App Service Plan
Azure App Deployments
We need to be careful with how we perform these deployments or it might bring our application offline.
Deployments
- Source: The source code for your app can be stored in a variety of locations
- Build: Source code must be compiled (ideally also tested, etc)
-In a format that can be used by App Service - Deploy: Deploy with Kudu/FTP/WebDeploy. Uses storage available to instances
Deployment Slots
Is the feature that can help us to overcome the issue of potentially causing outages based on updates that we might be performing to our applications
-You need a supported plan to use this feature
- Production Slot: By default, your app is deployed to a “Production” deployment slow
- Additional Slot(s): You can optionally add extra slots to use for development and testing
-To access other slots (staging), it’s going to use the standard DNS entry for azurewebsites.net (app-staging.azure) - Slot Features
-Traffic: Split traffic by a percentage
-Swap: Swap slots forward/back
App Service Networking
Inbound Connectivity
-We can get Service Endpoints > Public Endpoint
-We can get Private Endpoints > Private IPs
-Resource Firewalls talk about inbound access
Outbound Connectivity
When the app service wants to access some resources from that app that exist inside a VNet. We would need outbound access from our app service
VNet Integration:
Providing access directly through our VNet
-We configure it for a subnet
-Easy to enable, if your app is running on the same region as your VNet
-If it’s not in the same region as your VNet, you can still configure it. You’ll have to use a mode called “VNet integration gateway required”, this means that a VPN gateway will have to be deployed to provide
that access
-The App could access on-premises resources through the VNet, but ExpressRoute is not supported
Hybrid Connections
Getting access to on-premises resources or resources that exist in some other network, such as, AWS, GCP, etc.
-It’s using Azure Relay behind the scene
-You’ll have to deploy the “Relay Agent” on-premises
-The agent will use an outbound 443 connection to the Azure Relay service
-You only require outbound connectivity
Plans and Features (SKUs)
Free/Shared - Shared Compute
-Doesn’t support VNet Integration
-Doesn’t support Hybrid Connections
Basic - Dedicated Compute
-Newer deployments support VNet Integration
-Supports Hybrid Connections
Standard - Dedicated Compute
-Newer deployments support VNet Integration
-Supports Hybrid Connections
Premium - Dedicated Compute
-Supports VNet Integration
-Supports Hybrid Connections
App Service Autoscaling
The ability to scale IN or OUT, based on the demand on our solution
-Uses Azure Monitor behind the scenes
Autoscaling Rules
- Metrics-Based Scaling: “If my VM scale set has really high CPU utilization, i want to add additional machines, so i can meet demand”
-Metrics Rules: The trigger for a scale activity (scale-out and scale-in rules)
-Instance Limits: Min/max and default instance count
–Default: Mean that if the system can’t read the metric, it will ensure that you have at least the amount that you put in
- Scheduled Scaling
-Instance Count: Number of instances to scale to
-Schedule: When the scaling should occur
Considerations
-When combined with Applications Insights, additional useful metrics can be used for autoscaling
-It is possible to develop and report upon your own custom metrics from within your application
-You may wish to use metrics from other resources that your solutions uses/relies upon
App Service Security
Encryption
-We can configure SSL for our custom domain (built in domain has SSL preconfigured)
-If you do use a custom domain, you can upload your own certificates and use those
-You can use certificates for outbound connectivity (Your app needs to access an API that’s on-prem or out on the internet)
-Certificates can be used for encrypting the traffic and for authentication to outbound services
Secure Data Storage
-Use Azure KeyVault to store secret information
Network Security
-Use a Web Application Firewall to protect your publicly web app (You’ll be using something like an App Gateway, Azure Front Door Service or Azure CDN)
-Protect agaisnt attacks, such as, SQL Injection or Cross-site scripting
