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.
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?
- Small-scale batch processing
- CI/CD agents
- Simple web apps
- Task automation
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:
- Managed production environment - App Service automatically patches and maintains the OS and language frameworks for you. Spend time writing great apps and let Azure worry about the platform.
- DevOps optimization - Set up continuous integration and deployment with Azure DevOps, GitHub, BitBucket, Docker Hub, or Azure Container Registry. Promote updates through test and staging environments. Manage your apps in App Service by using Azure PowerShell or the cross-platform command-line interface (CLI).
- Global-scale with high availability - Scale up or out manually or automatically. Host your apps anywhere in Microsoft's global data center infrastructure, and the App Service SLA promises high availability.
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.
- Powered by Kubernetes and open-source technologies like Dapr, KEDA, and envoy.
- Supports Kubernetes-style apps and microservices with features like service discovery and traffic splitting.
- Enables event-driven application architectures by supporting scale based on traffic and pulling from event sources like queues, including scale to zero.
- Support of long-running processes and can run background tasks.
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
- Choose an Azure compute service - Azure Architecture Center | Microsoft Docs
- Tutorial - Deploy container application to container instance - Azure Container Instances | Microsoft Docs
- Tutorial: Build and run a custom image in Azure App Service - Azure App Service | Microsoft Docs
- Quickstart: Deploy your first container app | Microsoft Docs
Top comments (0)