Azure Web Apps

Editor's Notes

• #3: Azure App Service is a PaaS offering that comprises four separate (but related) services: Web Apps is a fully managed compute platform optimized to host Web sites and Web applications Mobile Apps provides infrastructure for hosting back-ends for mobile apps -- for example, it provides infrastructure for sending push notifications not only to Windows clients, but to iOS and Android clients as well API Apps makes it easy to host APIs in the cloud, features integrated support for Swagger (http://swagger.io/), and offers a built-in authentication service for restricting access to APIs Logic Apps allows you to automate business processes and workflow -- for example, automatically finding negative tweets about your company and sending notifications to a Slack channel Together, these services comprise a ready-made solution to many of the challenges involved in publishing Web sites, Web apps, Web services, mobile apps, and more.
• #4: The focus of this presentation is Azure Web Apps (https://azure.microsoft.com/en-us/documentation/articles/app-service-web-overview/). This service supports multiple languages and frameworks, including ASP.NET, Node.js, Java, PHP, and Python, so you can "use what you know" to begin leveraging it quickly. It supports scaling (manually or automatically) so capacity can grow as demand grows. It supports deployment slots for staged deployments -- for example, publish to staging, test your changes there, and then swap it into production only after you're confident it is ready. And it supports continuous integration, enabling you to be agile and aggressive in fixing bugs, adding features, and doing everything else needed to keep your site fresh and up to date.
• #5: When you create an Azure Web App, you are asked to choose an App Service plan (or create a new one). These plans support 7 pricing tiers (Free, Shared, Basic, Standard, Premium, Isolated and Consumption based), with each tier offering a unique combination of capabilities and capacity. Apps in the same subscription and geographic location can share a plan. For more information, see https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/.
• #6: Grouping resources this way helps simplify the implementation, deployment, management, and monitoring of resources in the resource group. From a billing perspective, it gives you a way to view costs for the resource group rather than for individual resources, eliminating the need to figure out which resources are related. You can think of an Azure Resource Group as a unit of management.
• #7: Continuous integration means deploying updates to your Web app as often as needed -- even several times a day. Azure supports many different deployment methods, including FTP, Git deployment (publishing from a local Git repository to Azure), and WebDeploy, which supports diff-deployment, database creation, and more. Visual Studio has integrated support for all three. Teams can also publish via third-party source-control providers such as Kudu (https://github.com/projectkudu/kudu/wiki/Deployment), which supports deployments from OneDrive and Dropbox, as well as repository-based deployments from GitHub, BitBucket, VSTS, and local Git repositories. For more information, see https://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/.
• #9: This process is a tried and tested one that is easily enacted using a combination of Azure features (e.g., deployment slots) and tooling support (e.g., Visual Studio).
• #11: When you deploy an Azure Web App, you can deploy to a separate deployment slot instead of the default production slot when running in the Standard or Premium App Service plan mode. Deployment slots are actually live web apps with their own hostnames. Web app content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a deployment slot has the following benefits: You can validate changes in a staging deployment slot before swapping it with the production slot. Deploying a web app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your web app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. This entire workflow can be automated by configuring Auto Swap when pre-swap validation is not needed. After a swap, the slot with the previously staged web app now has the previous production web app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your "last known good site" back For more information, see https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/.
• #12: A/B testing is useful for determining which of two landing pages, for example, is more effective in engaging customers. With Azure Web Apps, you can easily route traffic to different deployment slots by specifying percentage-based traffic allocations in the portal.
• #13: Manual scaling can be as simple as moving a slider to increase the number of VM instances. Auto-scaling can be enacted by scaling the number of VM instances as CPU utilization increases, or through rules that you specify. An example of the latter is scaling up during certain hours of the day in which you anticipate peak demand.
• #14: With a traditional server farm, there are two ways to scale to meet demand: Scale up by beefing up the servers (more RAM, more cores, etc.) Scale out by adding servers The same holds true for virtual server farms. In App Services, scale up is a choice between B/S/P 1-3, where 1 = 1 Core, 1/75 GB RAM, 2 = 2 Core, 3.5 GB RAM, 3 = 4 Core, 7 GB RAM. You can also scale up/down between tiers (B/S/P), which impacts local HDD storage (10/50/250 GB) as well as the cap on number of instances (3/10/50). * For 3 instances on Basic, only manual scaling is supported ** For Premium Tier, there is a max of 20 if not using ASEs, and 50 if using ASE’s
• #15: Demonstrate scaling out in this and the next two slides by showing the VM count increasing as traffic increases.