Demystifying the Azure App Service Design
Azure App service is Platform as a service solution for hosting your web app. You can host your WebApps, APIs, Mobile App and Logic App under this umbrella and it gives you all the flexibility of scaling up and down very rapidly. In this post, we are going to understand how azure deploy these apps to the actual server and how they’re able to scale so quickly.
An average user may predict that for each instance one virtual machine will be associated with it for eg if we scale up to 1 instance then there will be one VM associated with it and similarly if there are 5 instances so there will be 5 virtual machines associated with it. This is true but not the whole picture of how they deploy it to servers. These deployments consist of three mains servers:
- Frontend Servers
All the Web requests are passed to this server and its going to pass on the worker role instances based on the availability of the worker instances. It’s also going to check for the HTTPS Certificate validity for the security purpose.
- Worker Instances
This is the server which actually hosts the web application and its job is to execute and serve all the web requests. It is like the brain of the system which is there to take all the request, process it and then going to serve it back to the client.
- Shared Content Location
As the name suggest this is a common share server which is going to host all the content associated with your websites for example the app_data, images or any other files in this location and this is accessible via KUDU. Now if you see the above diagram, all the instances of the worker role are connected to the shared content server and access the data from it.
Scalability
Now when you deploy the application the azure host the application in the worker role instances which has IIS( or any other server) depends on the type of application you’re hosting so basically when we increase the no of instances what azure does behind the scenes is they replicate the worker role node and point it to same shared location server and frontend server. The worker role node is going to be the same what we selected in our app service plan. This process is simple then redploying the same application to the multiple servers and maintain data consistency. Due to replication of the worker role it gives you high availability as if one node fails so the other will take over and serve the requests.
Drawback of this architecture
This architecture stores the files in a separate node which can lead to latency while accessing the files from the worker role. Apart from latency if you’re developing an application that uses the disk and does some sort of disk computation then the performance is going to take a bit of hit as compared to the one VM deployment. Although the performance is going to be good only in the above scenario but you can add caching into your application that can increase your performance by multiple folds.
Summary
Azure deploy your websites, mobile and API app in 3 nodes which are frontend, worker role and shared Content node. Worker role is responsible for the scaling of the application and when we increase the instance the no of worker role increases accordingly. Also, this architecture has some latency issue that results in performance hit but it can be overcome by using caching.