Azure APP Service

Azure APP Service

Azure APP Service are Microsoft PaaS Service, offers Web Apps, API Apps , Mobile Apps , and Web Apps for Containers ( Linux), App Service Environment and Azure Webjobs.

Azure APP Service comes in variety of pricing tiers and sizes and combination of these two are termed as APP Service Plan. If we talk about pricing, we have six different options, each having a different set of features. Free and Shared are most economical offering and are used mostly in testing and Learning purpose.

Other Four tiers are Basic, Standard , Premium and Isolated. Below are some features available in these tiers.

Any of the tiers discussed above can be executed in dedicated mode. Which means Application is running on its own VM and is Isolated from other customers. This dedicated mode is not available in Free and shared tier.

In addition to different feature limits available per tier, they also comes in in three sizes: Small, Medium , and Large. Basic and Standard VMs currently run on A Series Sizes where:

• Small: 1 CPU, 1.75 GB RAM
• Medium: 2 CPU, 3.5 GB RAM
• Large: 4 CPU, 7 GB RAM

Premium Tier runs on Dv2 Series VM and comes with following allocated compute Resources.

• Small: 1 CPU, 3.5 GB RAM
• Medium: 2 CPU, 7 GB RAM
• Large: 4 CPU, 14 GB RAM

Now in Above table we have discussed Some options like, lets discuss one by one.

• MAX Instance
• Auto scale
• Number of APPS
• Deployment Slots
• Cloning

In you are using Premium plan, you can use more than 20 instances. You can decrease the number of Instance using Auto Scale Option. Scaling out Instances can be done manually also.

In the table, you can see that number of Apps per ASP is unlimited. But in real, there is no such unlimited. It just mean that there is no coded limitation on it, like there is for Free (10) , shared ( 100).

The limitation is not on number of APPS but on the compute resource, that your application requires plus number of instances per pricing tier.

If you can install 500 websites on 1 CPU machine with 1.75 GB RAM and its still responsive, then it’s great. But it’s very unlikely. Then in that case , you need to do careful assessment of your requirement about which app requires how much compute for proper functioning and balance them across different APP service plans and instances. This leads introduction of Deployment Slots, Which are test test instances of an APP on same ASP.

When you create slot on an ASP for given app , you are effectively creating a new process to run a newer version of that same APP.

For Example , your web pages app.dclessons.com and you create a deployment slot “test”. A new webpage will be created named app.test.dclessons.com , you can deploy it and test it. Once you are sure , your test application is working properly, you can do slot swap. This means test site becomes production and production becomes test.

Now requests start flowing through new version once slot swap is performed. Finally closing is done.

Cloning is very useful if you want to move your application to another region. From portal you can move an APP Service plan between resource groups and subscription. However moving to another physical region is not possible via click activity in Azure Portal, Cloning can achieve this objective.

Web Apps:

Azure Web APP Service is PaaS service, where you can built a Web APP and run it over Internet Access. For Web App, you can scale out to 400 CPUs in very few minutes.

API Apps:

API Apps is product offering and is an Interface that exposes one or more method that can be called form other application or customers.

API Apps fully supports Cross-Origin resource Sharing (CORS) and Swagger.

When you create an API APP, you follow same procedure as when creating a regular Web APP.

When we integrate an API, we find very much difficulty to figure out names of all method it exposes, required parameter for them , and kind of Authentication protocol required to communicate with API.

However, Swagger when configured, provides this information, discussed above.

CORS is security feature, that make sure that when code (example JavaScript) is running in your browser, that any outbound calls from within code are allowed. There have been cases where scripts are maliciously injected into client-side Java script that downloads some snippet of malware.  

Azure WebJobs

It is a feature , that supports execution of background task. There are two types of Azure Webjobs

• Triggered ( Remote Debugging not supported )
• Continuous ( Remote Debugging supported )

A Triggered Webjob is program that is scheduled to run using schedular scheme called CRON or can also be run manually. A common format of CRON is discussed in below figure.