Comparing Deployment options in Azure for web application

Photo by Christina @ wocintechchat.com on Unsplash

As a follow-up to my previous article, I thought a comparison between various services for build and deployment options in Azure is worth a write and would help people to make better decisions on which approach or service to choose from.

First, let’s see what options are available in azure for this comparison and we will investigate each one with high-level information and comparison in mind. Below are the services available for this:

• Azure App Service
• Azure Spring Apps
• Azure Functions
• Azure Container Apps
• Azure Container Instances
• Azure Kubernetes Service
• Azure OpenShift

Azure App Service

Azure App Service is an HTTP-based service for hosting web applications, REST API and mobile backends. It comes under the category of Platform as a Service. It can handle languages like .NET, Java, Ruby, Node etc.

When an app service or a resource is created, an underlying app service plan is also needed. The App service plan provides the underlying compute infrastructure for hosting the web apps. There are different tiers available to choose from in the app service plan, each tier has different capabilities based on hardware (CPU Cores, Memory etc.) and features(SSL, Auto Scale, Staging Slots, Backups etc.) and has been categorised into dev/test, production (for production workloads), isolated(Advanced networking and scale) and cost factor and time of compute per day for each tier.

We need to choose based on the web app and various features as mentioned above required and opt for the best one.

App Service runs on VMs under the hood with the advantage of not exposing the underlying layer. It acts as a black box that can run code in any language. It provides a single instance of the deployed web app. We can use app service to handle dev, sit, and production environments capable of handling production loads as well through scaling.

Azure Spring Apps

Azure spring apps are the new name for the azure spring cloud service. It makes it easy to deploy Spring Boot applications to Azure without any code changes. The service manages the infrastructure of Spring applications so developers can focus on their code. It provides features like monitoring m configuration management, service discovery, CI/CD integration, blue-green deployments and more.

• Efficiently migrate existing Spring apps and manage cloud scaling and costs.
• Modernize apps with Spring Cloud patterns to improve agility and speed of delivery.
• Run Java at cloud scale and drive higher usage without complicated infrastructure.
• Develop and deploy rapidly without containerization dependencies.
• Monitor production workloads efficiently and effortlessly.

Azure Functions

Azure Functions are serverless functions as a service solution. This allows us to write less code, maintain less infrastructure, and save on costs. Let’s say you have an independent method used by multiple applications, these can be separated and deployed onto azure functions that can be called in the respective applications. Azure functions app can hold multiple functions and supports multiple runtimes, and from a cost perspective, we can use based on consumption or as part of the app service plan. Azure Function App requires a storage account to manage triggers, operations, and logging aspects.

Azure function apps are consumed based on certain triggers; the triggers describe the type of events that invoke your functions.

Some examples of triggers:

• HTTP Trigger
• Timer Trigger
• Queue Storage Trigger
• Service Bus Trigger
• Service Bus Topic Trigger
• Blob Storage Trigger
• Event Hub Trigger

We can bring in new packages, access databases etc under functions giving this wide range of uses. Let’s say we have created a function app with an HTTP trigger. We can make use of the function app capability in the web app by creating an HTTP client and then calling the function app. Simple as that.

Now that we have seen 3 ways of deploying web apps in azure with some brief details, we will look at what is container and the need for it and get into the further deployment options available.

Azure Container Apps

Azure Containers Apps enables you to build serverless microservices based on containers. Azure Container Apps doesn’t provide direct access to the underlying Kubernetes APIs. If you require access to Kubernetes APIs and control plane, you should use Azure Kubernetes Service. Some features include –

• Optimised for running general-purpose containers, especially for applications that span many microservices deployed in containers.
• The capability of supporting Kubernetes and open-source technologies like Dapr, KEDA etc.
• Scale based on traffic and pulling from event sources like queues including a scale to zero.
• Supports long-running processes and can run background tasks.
• Flexibility to write code using any language, framework, or SDK.
• Service to Service communication is possible
• Configuring ingress — Supports 2 types of ingress — HTTP/TCP

Azure Container Instances

Azure Container Instances is a solution for any situation where isolated containers without orchestration, and event-driven applications, quickly deploy from development pipelines, run data processing, and build jobs. It provides a single pod of Hyper-V isolated containers on demand.

Scaling, load balancing and certificates are not provided with ACI containers. Users often interact with ACI through other services like Kubernetes etc.

Azure Kubernetes Service

Azure Kubernetes Service(AKS) is a fully managed Kubernetes option in azure. It supports direct access to the Kubernetes API and any Kubernetes workload. As a hosted Kubernetes service, Azure handles critical tasks like health monitoring and maintenance. When you create an AKS cluster, a control plane is automatically created and configured. This control plane is provided at no cost as a managed Azure resource abstracted from the user. You only pay for and manage the nodes attached to the AKS cluster. Some features are as below:

• Security is managed by Kubernetes Role Based Access(RBAC) and monitors the health of the cluster and resources.
• Clusters and Nodes — AKS nodes run on Azure VMs. We can connect storage to nodes and pods, upgrade cluster components and use GPUs.
• Cluster Node and Pod Scaling — Automatically set the scale up and down based on the demand.
• Cluster Node Upgrades — AKS offers multiple Kubernetes versions.
• GPU-enabled nodes — AKS supports the creation of GPU-enabled node pools. These are designed for compute-intensive, graphics-intensive and visualisation workloads.
• Ingress with Http Application Routing
• Storage Volume Support

Azure Red Hat Open Shift

This service is operated and supported by Red Hat and Microsoft to provide an integrated product and support experience for running Kubernetes-powered OpenShift. With this service we can choose our registry, networking, storage, CI/CD solutions, or built-in solutions for automated source code management, container and application builds, deployments, scaling, health management, and many more. If your team is using Open Shift, then this is an ideal option.

Conclusion

I have tried to cover options of deployment capabilities which are more frequently used and have tried to provide basic information on its capabilities. The choice of which one to go with depends on various factors, including tech stack, application workload, uptime, budget, and performance factors. Depending on the above factors I hope with the information provided you would be in a better position to make a judgement on which service to go with. Follow me for further articles where I expand on parameters to be considered for these above deployments as per certain use cases.

About the author:
Darshan Raviprakash is a Senior .Net Developer here at Version 1.