Container-Based Applications on Azure — Simple and Kubernetes-less

Martin Gjoshevski
Microsoft Azure
Published in
5 min readJun 10, 2022

--

The justified popularity of containers due to their compactness and portability has opened many opportunities for stacking them into flexible solutions but not seldom with quite complex arrangements.

The search for the best tools to run code placed into a container and then arrange and orchestrate these containers is certainly an interesting one to follow, and the exploration is far from done.

Containers on Azure

Architects and builders are exposed to the dilemma of where and how to deploy their containerized applications on Azure. Azure is very flexible and offers many container options to run your workloads.

A quick search will return you the following options:

· Azure Kubernetes Service

· Azure App Service

· Azure Container Instances

· Azure Spring Cloud

· Azure Red Hat OpenShift

As the ancient manuscripts say:

“There’s no silver bullet. There is no single solution for every use case and every team.”

A short visit to the Azure Architecture Centre will give you a great flowchart, which can greatly simplify your decision-making process.

Choose an Azure compute service — Azure Architecture Center | Microsoft Docs

I must admit that Kubernetes, in most cases, is my default choice for orchestrating containers, but if you are starting or migrating a project a lot of times, you might have an application that does not require all of the features Kubernetes offers. Therefore, in this blog, we will go slightly deeper into services that, as of now, allow you to run simple container-based applications, which do not require full-fledged orchestration:

a) Azure Container Instances

b) Azure App Service

c) Azure Container Apps

a) Azure Container Instances

Azure Container Instances (ACI) is a serverless container offer which provides a single pod of Hyper-V isolated containers on demand. ACI offer highly versatile sizing, allowing you to select the exact amount of memory and vCPUs your application requires. Concepts like scale, load balancing, and certificates are not provided with ACI containers.

For example, to scale to five container instances, you create five distinct container instances.

When to use it?

The good things:

  • A super-Fast and effortless way to run a container in the cloud, from any container registry.
  • No need to manage Infra/VMs/OS
  • Per-second billing based on resource requirements (CPU + Memory)​

Considerations:

  • No orchestration capabilities (Auto-scaling, Integrated load balancing, Rolling upgrades, Service discovery, Affinity/anti-affinity …)
  • Azure Container Instances do not expose direct access to the underlying infrastructure that hosts container groups. This includes access to the Docker API running on the container’s host and running privileged containers. If you require Docker interaction, check the REST reference documentation to see what the ACI API supports. If there is something missing, submit a request on the ACI feedback forums.

b) Azure App Service

Azure App Service provides fully managed hosting for web applications including websites and web APIs. These web applications may be deployed using code or containers. Azure App Service is optimized for web applications.

When to use it?

  • Running Web Applications
  • Deploying long-running containers/services

The good things:

For more please check: Overview — Azure App Service

Considerations:

  • If you run multiple containers into a shared App Service plan, and some of the containers have unpredictable resource-intensive usage, you might experience the Noisy Neighbor antipattern. Isolating these containers into a new Service Plan is recommended in this case.
  • To avoid underutilization, understand your CPU, Memory, disk size and disk IOPS requirements of your application to determine the most optimal size of your App Service Plan.

c) Azure Container Apps

Azure Container Apps (ACA)allows you to build Kubernetes-style applications and is greatly simplifying the deployment and management aspects. ACA has an opinion on how things should be done, which is not necessarily bad, since this opinion is based on Azure and Cloud Native best practices, which makes this offer quite appealing to people that want to move fast, have powerful orchestration options, but are not necessarily familiar or big fans of kubectl.

When to use it?

  • Deploying API endpoints
  • Hosting background processing applications
  • Handling event-driven processing
  • Running microservices

Considerations:

Azure Container Apps doesn’t provide direct access to the underlying Kubernetes APIs, which means that you can’t just take your existing Kubernetes YAML or Helm charts and use them.

  • Despite being very flexible ACA is opinionated, it is integrated with services like Envoy for ingress, KEDA for scaling, Log Analytics for monitoring etc.
  • Currently supports only Linux containers, no support for Windows.

Summa Summarum

You have already greatly improved the portability and ease of deploying your applications just by dockerizing them.

The decision on where and how to deploy your docker images does not have to be a binary decision. Start with your, your team's experience and the application`s resource and operational requirements. Luckily today most cloud providers offer a variety of services that make “Choosing the right tool for the right job” possible and simple.

Further Reading

--

--

Martin Gjoshevski
Microsoft Azure

Architect and Builder. (Eng @ Microsoft Azure, ex-AWS) - Opinions and observations expressed in this blog posts are my own.