Containers on Azure Platform: Thousand Feet Overview

Introduction

Containers are getting popular day by day. You can develop your application and build a container image that packages your application and all necessary dependencies. Then you push the image to the Container Registry. In your target hosting environment, you pull the image from the Container Registry and run it as a Container. Your application gets live with minimal effort in that environment without having to spend much time in setting up the application and its dependencies.

Containers make our lives easy when it comes to portability. We need to build the container image once and pull the image in various environments, may it be Production or Stage or User Acceptance, and run it in that environment. Building a container image is easy and intuitive.

Usually, all modern applications consist of multiple independent components that communicate with each other. You can host each of these components in a single container. Your application gets spread across multiple containers. This hosting pattern brings in new challenges that you must take into consideration. If one of the containers goes down, your application goes down. To handle this scenario, you need to spin up a new container that replaces the container that died. When the load increases, you should spin up additional containers that can help the application serve additional requests. In short, you need a mechanism to manage and orchestrate your containers. Kubernetes can help you orchestrate your container.

Almost all cloud platforms support the containers ecosystem and help you host your application on containers with ease. The cloud platforms abstract all infrastructure complexities and facilitate you to host your application on the container platform in a simplified manner. Microsoft Azure provides excellent support for Containers.

In this article, we will explore the services offered by Microsoft Azure at a high level that helps you host containerized applications.

Container Ecosystem on Azure Platform

Developers build their applications and use Docker to containerize their applications. They package the application along with its dependencies. Once the container image is ready, developers push the containerized image to a container registry. The container registry can be either private or public. In the case of the public container registry, the images are available for everyone to use. In the case of the private registry, the images are available only to those who have access to the registry. Docker containers get stored in the Docker container registry. Microsoft Azure provides the Azure Container Registry that stores the container images for the developers and is a private Docker Registry.

Once the developers have pushed their images to Azure Container Registry, they need to run their images so that their applications can start serving the user requests. In the Azure Platform, following are the options available to run the container images.

• Azure Container Instance
• Azure Kubernetes Service
• Azure WebApp for Containers

You can use Azure Container Instance to run your container image without needing to build any Virtual Machine. Azure Container Instance is very powerful and lets you run your container images with ease. You can have your images up and running on the Azure Platform in no time.

However, your application may consist of multiple loosely coupled and independent components communicating with each other. In such a scenario, you may have to host each of the application components in separate containers. You may have to make sure that the application is always available to serve the incoming requests and is highly reliable. You need to orchestrate the running containers. Azure provides managed Kubernetes Service that helps you to manage and orchestrate the containers. Azure Kubernetes Service consists of Nodes on which these containers run and the Control Plane that manages and keeps track of these Nodes. The containers run inside pods in the Nodes. The Control Plane schedules identical Pods across the Nodes so that they can load balance the requests. Also, if a Pod goes down, the other identical Pods can serve the requests, thus guaranteeing high availability for the application. Also, if a Pod goes down, the Control Plane makes sure that another identical Pod spins up and starts serving the requests. The Control Plane takes care of all operational and management aspects for the Nodes in the Azure Kubernetes Service Cluster. The underlying Azure Platform takes care of creating and managing the Control Plane, thus encapsulating all complexities in this area.

Azure Kubernetes Service uses Virtual Machines as Nodes. During peak hours, it needs to add more number of Nodes. Spinning up virtual machines may take some time, and the scaling may not be instantaneous. To address this scenario, Azure Kubernetes Service uses Virtual Nodes that can quickly spring into action whenever the incoming traffic increases. Virtual Nodes are based on Azure Container Instances. Instead of running the Containers on Nodes, you run containers on Azure Container Instances. This mechanism helps your applications running on Azure Kubernetes Service to scale rapidly. You can also run your containers on Functions in Azure Kubernetes Service using KEDA.

Azure Web App supports hosting containers. It can interface with Azure Container Registry and pull up and host your Container Images.

Figure 1 demonstrates the Container ecosystem on the Azure Platform. The developer builds the application and packages it as a Docker container image. It then pushes the image to Azure Container Registry. Azure Container Instance or Azure Kubernetes Service or Azure WebApp can run the container image.

Conclusion

In this post, we explored the Container offerings available on the Azure Platform and how they work at a very high level. In the next set of articles, we will dive deep into each of these services in detail.

History

• 6^th July, 2020: Initial version