Over the years, containerization has grown in popularity among organizations and will continue to grow. For example, containerization is slowly becoming the de facto approach when it comes to building applications following the microservices architecture.
It is undeniable that containerization has a lot of advantages, but these advantages come at a cost. Usually, that cost is due to the effort required for setting up and maintaining the technology and tools (such as the orchestrator and underlying VMs for the nodes) that make containerization work.
To facilitate the adoption of containerization, cloud providers offer multiple containerization services, each of which serves a given purpose. In this article, we’ll focus on Microsoft Azure but pretty much the same goes for every major cloud provider. The purpose here is to reduce the efforts mentioned earlier to maximize the benefits.
Containerization services in Azure
If you’re familiar with Azure, you’ve certainly noticed that there are plenty of services around containerization:
- Azure Container Instances (ACI): This service is useful when you need to execute a single container in an isolated environment. ACI supports both Windows and Linux containers and can start in a matter of seconds. Use cases include running a build server or bursting in the context of an AKS cluster.
- Azure Kubernetes Service (AKS): ACI provides no scaling nor load balancing functionalities. If you need these, then AKS is likely to better suit your needs. With AKS, you get a managed Kubernetes cluster in Azure, and you can access it and control it through the standard Kubernetes CLI commands.
- Azure Container Registry (ACR): this service gives you the ability to create a private registry for your container images and only give access to select users and groups (within your organization, for example). ACR also has a feature called “tasks” which can be leveraged in the context of image scanning and hardening.
- Azure Service Fabric: somewhat similar to AKS but the underlying orchestrator is proprietary.
Yet another containerization service?
Since there are already plenty of containerization services available in Azure, why did Microsoft decide to introduce a new one?
AKS is certainly powerful, but managing the cluster is under your responsibility. In addition, AKS doesn’t allow for scaling based on events (other than CPU/RAM utilization). That’s what Azure Container Apps has been created for.
Azure Container Apps (ACA) provides you with a managed container orchestration service in a serverless manner. You and your team can then focus more on your applications (microservices) and less on the underlying infrastructure.
Benefits of Azure Container Apps
Since ACA is a serverless offering, it will scale your applications automatically to meet the demand. Scaling can go from zero up to the maximum of replicas defined during the creation of the ACA instance. If no events (i.e., HTTP requests, messages in a Service Bus queue, …) are sent to our ACA instance then no pod is running which means that no cost is incurred.
The second benefit of ACA is the ability to execute multiple revisions (i.e., versions) of the same container in parallel. It can be useful for canary testing scenarios, and you can even redirect traffic between revisions.
A third benefit is that the load is automatically balanced across available replicas.
A fourth benefit is an availability, out-of-the-box, of the Dapr runtime, since Dapr is becoming more and more popular when it comes to building microservices applications.
There are also other benefits provided by ACA, such as the ability to manage application secrets from the application, the ability to monitor application logs centrally from Azure Log Analytics (which seems trivial but is very interesting especially in a microservices architecture where all microservices logs are aggregated into the same Log Analytics instance which greatly simplifies monitoring and debugging). There’s also the ability to execute containers from any registry (Docker Hub, ACR, …).
Limitations of Azure Container Apps
One limitation that we noticed, and that is worth mentioning here, is that ACA doesn’t allow you to manage the cluster using Kubernetes CLI commands (or any commands at all). Since ACA is a serverless offering, it makes total sense that you don’t have access to the underlying infrastructure and hence you can’t manage it yourself (that’s what serverless offerings are all about, right?). It makes sense but it is worth mentioning. Thus, if managing the Kubernetes cluster is what you need, then ACA is not the right service for you. You should instead consider AKS.
Scaling options in ACA
Several options can trigger scaling in ACA. These options are:
- HTTP traffic (i.e., number of concurrent HTTP requests to your microservices)
- Events (e.g., messages in Azure Service Bus or Kafka)
- CPU or Memory usage
- Any scaler supported by KEDA
Azure Container Apps use cases
There are plenty of use cases for ACA. Here are a few:
- Public API endpoints
- Background processing (e.g., continuously running background processes for data transformation)
- Event-driven processing (e.g., an application that reads messages from a queue and processes them as they arrive)
How to use Azure Container Apps?
There are a certain number of steps to take to use ACA.
Step 1: Upgrade your Azure CLI
Simply type “az upgrade”:
Step 2: Install the ACA extension
This is required since ACA is still in preview:
You can also check if the ACA extension is already installed by typing this command:
If the command returns no output, then it is likely that the command isn’t installed. Otherwise, you’d have a bunch of JSON data.
You’ll also need to have Microsoft.Web resource provider registered. Likely, it is already registered but if needed you can type “az provider register –name Microsoft.Web”.
Step 3: Create a Log Analytics workspace
We’ve previously mentioned that Log Analytics is used to aggregate logs for applications deployed into the same ACA instance. We thus need to create that workspace before creating the ACA instance:
Step 4: Get the client ID and client secret of the Log Analytics workspace
These values will be needed to create the ACA instance.
This command returns the client ID:
This command returns the client secret:
Step 5: Create the ACA instance
An ACA instance is referred to as “Container Apps environment” and it is created through this command:
It takes under a minute to create the Container Apps environment.
Step 6: Deploy the application
Now that the Container Apps environment is created and ready to use, we can deploy an application into it. For that matter, we’ll use a sample application provided by Microsoft. We can then simply type:
Step 7: Running the application
We can now head to our Container Apps environment in the Azure portal, click on “Apps” to reveal our only application named “my-container-app”:
We can click on its name, copy its URL and browse to it:
Note that the first time we run the application, we’ll experience a delay due to the provisioning of the underlying infrastructure. If we want to avoid such delay, we have to set the minimum replicas to 1 rather than 0.
Once the application is loaded, its UI will be displayed in the browser. For our example, we’re presented with the beautiful ACA logo 😊:
To sum it up…
Containerization can be very effective but can also be challenging (e.g., required efforts to set up, configure and manage). That’s why most cloud providers, such as Microsoft with Azure, offer various tools and services to help us reduce these efforts. Each offering serves a given scenario.
Today, we took an overview of the latest containerization offering in Azure that is called “Azure Container Apps” whose purpose is to allow us to create Kubernetes clusters in a serverless manner.
