AZ-303 Microsoft Azure Architect Technologies – Implement Solutions for Apps (10-15%)

1. Azure Apps Introduction

Welcome to the section on web apps within Azure App Service web apps, often referred to as just Web apps, is a service for hosting web applications, Rest APIs and mobile backbends. You can usually develop in your own favorite language be. Net, Core, Java, Rubin, Node, GS, PHP or even Python, and the applications run its and scale with ease on Windows or even Linux based environments. You can also take advantage of DevOps capabilities such as continuous deployment from VSTs, GitHub, Docker, hub and other sources, package management, staging environments and so on.

What’s important is that with app services, you pay for the Azure compute resources you use, and they are fully managed services. This means that unlike using a virtual machine, you don’t need to worry about applying patches and antivirus and so on in an app service. A web app is the actual compute resources that Azure provides for hosting the website’s web applications. The compute resources may be shared or actually on dedicated virtual machines, depending on the price tier that you choose. Your application code runs on a managed VM that is isolated from other customers. However, some of the key features and capabilities for app services are multiple languages and frameworks. As we just said, you can use net, Node, JS, Java and so on.

DevOps optimization. So again, you can set up continuous integration pipelines from Visual Studio team services, GitHub bit buckets and so on. You can scale up or out, manually or automatically. And this means you can host your apps anywhere in Microsoft’s Global Data Centers anywhere in the world. You can choose from more than 50 connectors for enterprise systems such as SAP, Siebel and Oracle SAS, services such as Salesforce and Office 365, and other Internet services such as Facebook and Twitter. You can even access on premise data using hybrid connections and Azure virtual networks. App services are secure and compliant. They are ISO, Sock and PCI compliant.

You can choose from an extensive list of templates in the Azure Marketplace that lets you use wizards to install popular open source software such as WordPress, Tumor and Drupal. There’s great dedicated tools within Visual Studio to help you streamline the work of creating deploying Gandhi bugging gaps. There is turn key options for call support and Restful API scenarios with authentication for mobile apps, offline data, sync and push notifications, and finally, you can even run server less code, run code Snippets on demand without having to explicitly provision and manage infrastructure. Through the next section, we’re going to be examining just some of these features.

2. Web Apps Introduction

In this lecture, we’re going to have an overview of web apps. In this last lecture, we talked about the various different abilities and services that can be run as app services, and web apps are essentially a subsection of the overall app services that you can run. Web apps are perhaps the more traditional type of app services. A web app is essentially a website running under an IIS website or similar. When running a web app in Azure, it’s actually running on top of a virtual machine. However, you don’t need to actually worry about that virtual machine, as the whole concept of it is actually abstracted away. However, that web app itself can still be used to connect to storage services, databases, and so on within the Azure platform. With this in mind, an app runs in an app service plan. An app service plan defines a set of compute resources for the web app to run on, ie. The virtual machine. One or more apps can actually be configured to run on the same computing resources. When you create an app service plan in a certain region, for example UK, south or West Europe, a set of compute resources is created for that plan in that region. Whatever apps you put into this app service plan will run on those compute resources as defined within your app service plan.

Therefore, each app service plan defines the region that it’s running in, the number of VM instances that you want to run to support it, the size of those VM instances, and the pricing tier. When choosing the app service plans, you can choose different pricing tiers, and they are in turn grouped into the following shared, compute free and shared. The two base tiers runs an app on the same as your VM as other app service apps, including apps of other customers. These tiers allocate CPU quarters to each app that runs on shared resources, and the resources cannot be scaled out. These are essentially the cheapest or sometimes free tiers that you can use and should only really be used for development.

Next, we get the main dedicated tiers, which are Basic, Standard, Premium and Premium V. Two these run apps on dedicated Azure VMs and only apps in the same app service plan share the same compute resources. On the higher tier, the more VM instances are available for you to scale out. The isolated tier runs on dedicated Azure VMs, which in turn run on dedicated Azure virtual networks. And this provides network isolation on top of compute isolation for your apps, and it also provides the maximum ScaleOut capabilities. Finally, the consumption tier is really used for function apps. It allows to scale functions dynamically without having to define compute and CPU. We will therefore cover consumption plans later on when we look at functions.

The Azure App service environment. Ie. The isolated option of a service plan is an Azure app service that provides fully isolated and dedicated environments and it’s used mainly for securely running app services and again, at high scale this capability, you can actually host your apps as Windows Web apps, Linux Web apps, docker containers, mobile apps, and even functions. App service environments are appropriate for application workloads that require very high scale isolation and secure network access and high memory utilization.

Customers can create multiple ASES within a single Azure region or across multiple Azure regions. This flexibility makes ASCs ideal for horizontally scaling stateless application tiers in support of high compute workloads. However, ASES are completely isolated to running on only single customers applications and are always deployed into a virtual network as opposed to normal apps that aren’t connected to an underlying virtual network. Customers have fine grained control over inbound and outbound application traffic. Applications can establish high speed secure connections over VPNs to on premise and corporate network resources.

Because of this, as key ASES come with their own pricing tier, and ASC is dedicated exclusively to a single subscription and can host up to 100 app service plan instances. The range can span 100 instances in a single app service plan to 100 single instance app service plans, and everything in between. An ASE is composed of front ends and workers. Front ends are responsible for Http and Https termination and automatic load balancing of app requests within the ASE. The front ends are automatically added as the app service plans in the ASC are scaled out. The workers are roles that hoards your actual apps, and the workers come in thick sizes either one CPU with three and a half gigabytes of Ram, two CPU with 7GB, or four CPU with 14gb. Customers don’t need to manage frontends and workers. All infrastructure is automatically added as you scale up your app service plan.

As app service plans created or scaled in an ASC, the required infrastructure is just automatically added and removed. However, it’s important to note that there’s a flat monthly rate for ASCs that pays for that dedicated infrastructure and doesn’t change regardless of the size of the ASC. On top of that, you then pay for your individual app service plans based on the CPU.

All apps hosts in an SC are in the isolated pricing zone. Azure app services provide built in authentication authorization support so you can sign and use an access data by writing minimal code or no code at all. Secure authentication authorization do require deep understanding of a security, including federation, encryption, JWT, tokens, grant types, and so on. An app service provides these utilities so you can spend more time and energy on providing the business value without having to worry about all this. The Authentication and Authorization module runs in the same sandbox as your actual application code, and when it’s enabled, every incoming Http request passes through it before being handled by your application.

The module handles several things for the Ore app. It authenticates users with the specified provider such as Microsoft, Twitter, Facebook and so on it validates stores and refreshes tokens, it manages the Authenticated session, and it injects identity information into the Request headers. For all language frameworks. App service makes the users claims available to your cord by injecting them with the Request headers. For example, for ASP. Net 46 apps, the app service populates claims printable current with the authenticated users claims.

The app service also provides a builtin Token Store, which is a repository of tokens that are associated with the users of your web apps, APIs, or mobile apps. When you enable authentication for any of the providers, this token is stored immediately available and made available to your app. If your application code needs to access data from these provided on the user’s behalf, such as to post to the authenticate user’s Facebook timeline or read the corporate data from the Reactive Directory graph, you typically would have to write code to do all this.

App servers uses Federated Identity, in which third party identity provider manages the user identities and authentication flow for you. The five main identity providers available by default are Azure, Active Directory, Microsoft Accounts, Facebook, Google, and Twitter. We’ll look in more detail at how we use this when we go through the examples. Azure App Services is a multitenant services except for the app’s service environments, apps that are not on the ASE Share network infrastructure with other apps, and as a result, the inbound and outbound IP addresses of an app can be different. Regardless of the number of instances, each app only has a single inbound IP address. The inbound IP address may change when you perform any of the following actions deleting an app or recreating it deleting the last app in a resource group and region combination and recreating it or deleting an SSL binding. Sometimes you might want to dedicate static IP for your app.

To get static IP inbound IP address, you need to configure an IP based SSL binding. If you don’t actually need SSL functionality to secure your app, you can even upload a cell science certificate for this binding. Regardless of the number of scaled out instances, each app has a set number of outbound IP addresses at any given time. Any outbound connections from the app itself to another service, such as a back end database, uses one of those outbound IP addresses as the origin IP address. You can’t know beforehand which IP address is given an app instance, so your back end service must open its firewall to all outbound IP addresses of your app. Hybrid Connections is a service that runs in both Azure and a feature of the Azure app service. As a service, it uses capabilities beyond those that are using the app service.

Within app services, hybrid connections can be used to access application resources on other networks, such as an on premise network. It provides access from your app to an application endpoint. It does not enable an alternate capability to access your application in other words. You can use a hybrid connection for your web app to connect to a SQL database on an on premise database, but it will not allow users on that on premise database to connect to the web app over that secure connection. You can also use something called Azure Traffic Manager. Traffic Manager can be used to control how requests from web clients are distributed to apps in the app service. When app service endpoints are added to an Azure Traffic Manager. Azure Traffic Manager keeps track of the status of the web apps so it can decide which of these endpoints should receive traffic.

It uses four different routing methods priority, weighted performance, geographic Multivalued, and subnet. By setting up these different profiles, you can configure Azure Traffic Manager to balance between services within the same region or direct traffic to the user’s closest region. When you deploy web apps mobile, Backbends and APIs, you can deploy two separate deployment slots. Deployment slots are live apps with their own horse names. App content configuration elements can be swapped between two deployment slots, including the production slot. This is very useful because it means you can validate app changes into a staging deployment slot before swapping it with a production slot. All web apps can be set to auto scale. In other words, you can set thresholds either timed or based on CPU usage to automatically add additional instances as required to support workloads. Finally, web apps support a feature known as Web Jobs.

Web Jobs is a feature of the app service that enables you to run a program or script in the same context as the web app. Because of this, there is no additional costs to using Web Jobs. They simply run on the same underlying virtual machine as your web app. The Web Jobs SDK can be used with Web Jobs to simplify many programming tasks. It’s kind of like an alternate alternative to Azure functions. They’re essentially two types of Web Jobs continuous and triggered. Continuous jobs start immediately when Web Jobs are created.

They run on all instances that the web app runs on, and they support remote debugging. Triggered, on the other hand, start only when triggered manually or on a schedule. They run on a single instance that Azure selects for you, and it doesn’t support remote debugging. Using Azure Web Jobs, you can upload exe PowerShell files, bash scripts, PHP scripts, Python scripts, Node, JS, or JavaScripts to run the automated process that you want to execute. In the next lecture, we’ll go ahead and create a web app and run through some of the options.