Azure App Services

Quickly build, deploy, and scale web apps and APIs on your terms.Azure App Service
opensight.ch - roman hüsler

This is the central promise of the Azure App Service on the Microsoft homepage. Will it be fulfilled? Definitely, as you will see in this blog post. The word “quickly” is also important, because complex CI/CD pipelines and web app deployments can indeed be managed quickly and easily.

The Azure App Service offers the following features and functions, some of which we will try out in today’s blog post.

• Applications written in Node.js, Python, PHP, Java, Ruby, .NET Core and ASP.NET
• Run your apps on Linux or Windows
• Using your own code or your own Docker containers
• Host at any scale, from simple websites to cloud-scale applications
• Integrated tool support for Eclipse, Visual Studio Code and Visual Studio
• CI/CD integration with GitHub, Docker Hub, Azure Pipelines, Azure Container Registry, Bitbucket and others
• Comprehensive diagnostics, monitoring and notification features with Application Insights and Azure Monitor

The Azure App Service offers easy scalability. There is the possibility to use more powerful resources (scale up / vertical scaling) or to use more instances (scale out / horizontal scaling).

There is also (depending on the chosen plan) the possibility to define “Deployment Slots” / “Staging Slots”. Accordingly, one can define a “staging environment” in order to first test changes and then carry out a “swap” with the production environment. However, this is not an issue in today’s blog post, as the feature is not available in the “Dev/Test” plan.

Our Example Application – Trendradar

As an example-deployment, in today’s blog post we use one of our test apps: “Trendradar”. The app consists of a backend container (REST API) based on “NodeJS” and a frontend container “ReactJS”. The app is used to measure Internet trends (number of Twitter subscribers, number of mentions of a topic on Reddit). Create “topics” in the app.
Example topic: “Number: Donald Trump Twitter Followers”. The app is an ideal example because it uses a typical cloud-native architecture and is also easy to “containerize”.

But now to the “Azure App Service”.

Create an App Service Plan

The task now is to install the backend (API) for the Trendradar App on the Azure App Service, including the CI/CD pipeline with Github.

We have already created the Azure resource group “AppServiceTest”. Now it goes directly to the deployment of Azure App Service. To do this, an “App Service plan” must be selected. to choose from.

For the test deployment, we choose the Dev/Test B1 plan (100 ACU, 1.75 GB Ram) for around 13$ / Month. price calculation

• dev/test
  Various plans from 1GB-7GB Ram, 100 ACU – 400 ACU. Manual scaling. 10GB shared storage space.
• production
  Various plans from 3.5GB-32GB Ram, 210 ACU – 840 ACU. Automatic scaling. 250GB shared storage space.
• App Services (Isolated)
  Various plans from 8GB-32GB Ram. 195 Mindset ACU. 1TB shared storage space. For very large scaling .

For the deployment, we entered the Git repository of our Trendradar test application directly. Well, when we commit a change to the GIT repository, it directly triggers the Azure Web App CICD deployment pipeline. The progress can be followed on Github Live. Azure Webapps has automatically defined a workflow in the GIT repository, which ensures that the Build and Deploy CI/CD pipeline is executed when we commit new code on the “main” branch.

And voila, the “Trendradar” test application is now available on the Internet and has been equipped with a CI/CD pipeline. From our point of view, this is where the strength of the Azure App Service lies. This actually complex provision of a CI/CD pipeline was relatively easy to implement and took about 15 minutes.

Presistent Storage

The Trendradar App is now accessible on the Internet and works. However, the app is built in such a way that it uses a “/storage/storage.txt” file as storage. So if we record a new “topic” in the app’s API and then commit a new build to the GIT repository, the app will be automatically re-provisioned on Azure App Service. This means that all changes to the “/storage/storage.txt” file are lost. So we need persistent storage.

For this purpose we create a storage release on Azure and enter it in the Azure App Service under “Configuration/Path Mappings”.

Scaling

With the selected app service plan, we can now scale manually. To test the scaling, we now set it to 2 instances (scale out). It was that simple – no load balancer configuration etc.

Azure App Service vs Azure Kubernetes Service (AKS)

Admittedly, we are comparing apples and oranges here – because Azure App Service is not a container orchestration. Nevertheless, we ask the question: what is more suitable for us?

First, the obvious benefit of Azure App Service.

• Easy setup – it just works
  The setup of webapps including CI/CD pipeline is easy compared to a Kubernetes setup. When setting up Kubernetes, you usually need specialists who are well versed in container orchestration, development, CI/CD pipelines, etc. The Azure App Service, on the other hand, hides a lot of complexity in the background and you reach your goal quickly. Out of the box you have a CICD pipeline and simple resource monitoring very quickly.
• Good scaling
  Scaling is also easy to do. It is possible to use more powerful resources (scale-up) or to scale up to more instances (scale out). No configurations of load balancers were to be made, this all happens automatically in the background.
• Good integration into Microsoft ecosystem
  The Azure App Service is well integrated with other Microsoft services such as Github, Web Application Firewall, Azure Autoscale and Azure API Management.

On the disadvantages of the Azure App Service

• No container orchestration
  The Azure App Service is not a container orchestration and therefore does not offer the advantages of a container orchestration. With Kubernetes, you can granularly control how many replicas should run redundantly in your business-critical container deployments, even during the deployment of a new software release. Also with Azure App Service, can you run multiple apps in one service plan to save money? Yes you can – but it is not recommended. You cannot define in the service plan which individual business-critical containers should run at any time or with what redundancy. It is therefore recommended to define a single app service plan per app, which in turn is more expensive than implementing the same scenario on AKS.
• less control
  From our point of view, the advantage of the Azure App Service is also a disadvantage. With a Kubernetes setup, you have control over all system parameters at all times. Meanwhile, with the Azure App Service, it’s difficult to even know the status of the underlying containers at all times. A lot of complexity remains hidden, so things happen automatically that you are not sure about.
• Less interoperability
  As soon as you want to build a service mesh from a wide variety of microservices, there is no way around AKS or Kubernetes from our point of view. Kubernetes has become a standard for cloud native apps in recent years, so many useful tools are also being developed based on this standard for scaling, monitoring and log monitoring, security, etc.