Share:

Cloud Systems Developer Kishan Gohil recently attended Microsoft’s ‘Ignite The Tour‘ event in London. In this post, he talks about a hot topic from the agenda: containers.

Microsoft brought their long-awaited Ignite The Tour event to London on 16th and 17th January 2020 – and what a two-day event it turned out to be! Attendees were treated to the latest and greatest features in the Microsoft Azure cloud platform. The agenda included a programme of demo sessions (including Microsoft AI & Azure Arc) and presentations on a lot of important topics. One key topic that attracted a lot of attendees was the use of containers and the capabilities of containers in Azure.

There is no doubt about it, containers have arrived and it is one of the hottest trends today and it will only get bigger and better in 2020.

What exactly is a Container?

A container is an isolated resource that has been packaged with all of the code, packages and dependencies so that an application can be quickly deployed and run from one platform to another. A container aims for complete virtualisation for the “stuff” that is required by the application and everything is self-contained. What makes things better is that containers boast a new level of efficiency and portability because the virtualisation is on the operating system and not on the hardware or infrastructure.

What is Azureʼs take on Containers?

Many of the presentations at Ignite The Tour focused on the capabilities on Azure with containers, all of which achieve the same goal: modernise your application and cloud footprint by way of virtualisation. There are several features on Azure that are worth thinking about when it comes to containers but for keeping things quick and easy as a PaaS offering, there are three important services.

● Azure Kubernetes Service (or AKS) is the Azure PaaS offering that gives an easy-to-use service for deploying and managing containerised applications efficiently. Using AKS gives us a fully-managed Kubernetes cluster so there is nothing for us to manage, itʼs “Kubernetes Cluster as a Service”. Kubernetes itself already makes things easy for us as a container orchestrator and now with AKS something that was meant to be easy becomes easier.

● Azure Container Instances (or ACI) is a serverless technology. It provides us with a way to run containers on Azure without the need for servers/ VMs. Running ACI in Azure is a quick way to get a container up and running in isolation. However, it does not provide orchestration in the way that you get on AKS. Personally Iʼd be looking at ACI for testing out containers, but AKS for my Production workloads.

● Web Apps for Containers (part of the Azure App Service) support running containers. This is another great candidate for running a production workload specifically for a web application whether it is a new application or migrated/modernised application. Itʼs a quick and easy way to deploy a web app, and gives the benefits of an App Service such as scaling the number of application instances and the use of a custom DNS to give your web page a fancier URL. Just publish your Docker image into the App Service rather than your code!

What are Docker and Kubernetes?

Far too many people are confusing these two to be the same thing or direct competitors. Actually, Kubernetes is a container orchestration tool while Docker is the container platform. Docker has become a more generalised word for us when we talk about containers. In fact we need to compare Docker Swarm and Kubernetes as two orchestrators, while Docker Engine is the container platform (think of it as the “thing” that runs your containers for you).

So, both Kubernetes and Docker Swarm are similar but Kubernetes is the “favourite”, being widely used by Azure, AWS and GCP! The use of Kubernetes and Docker (Engine) together is most common nowadays.

Are containers completely new?

No, not completely.

In their current form, containers are the next-big-thing (or, current-big-thing) in this era of cloud computing workloads. Before Azure, you might run Java applications “in-container” in Apache Tomcat / WebLogic Server. Here the container was the servlet and it would run one or more applications. However, we needed VMs, we needed a lot of infrastructure, we needed support, we needed patching, it wasnʼt a managed service and it definitely wasnʼt easy to scale.

Why use containers?

One of the most common use cases (mentioned at Ignite The Tour in several sessions) is the idea of using a container to package, modernise and migrate an existing application quickly to get the workload onto Azure. Given the portability of containers, we are able to run the application on our local development environments with the same code, packages and dependencies as we would in production. So it makes things easy and efficient for the developers to modernise an application and get it running on Azure.

Another use case mentioned was to use containers to replace most VMs for some workloads and processing. A common way a lot of people are doing this already is to use containers (not VMs) as agents to run their CI/CD process through Azure DevOps. Microsoft has provided container-based Linux and Windows agents on Azure DevOps to run your Azure CI/CD Pipelines. These containers are configured with a massive amount of common packages and libraries that you need to build, package and deploy other Azure (and non-Azure) based resources, services and applications. This is such a huge benefit because theyʼre fast to use, there is nothing to manage, and there are no infrastructure or storage costs.

What next?

Not so long ago there was the idea of migrating on-premises VMs/physical servers to Azure VMs so you could quickly scale and benefit from cloud-based services. This gave the idea of “lift and shift” which would get your foot into the cloud. However, many were essentially just treating cloud as a VM.  In the cloud, but with a really limited perspective.

I feel there is now a new direction with containers. Replace VMs with containers, or modernise and migrate applications into a cloud-hosted container. Hopefully, this pushes us into a modern space of moving to the cloud – so letʼs move away from “lift and shift” where the “shift” seems like a one-off activity and think more of “migrate and innovate” or “move and improve”.

Letʼs keep thinking of new ways to help turnaround the quick delivery of applications and services.  After all, we are continuously seeing more and more innovative services released on Azure, AWS and GCP – the limits are definitely being pushed as to what is possible on the cloud!

Want to learn more about how you could partner with Cloudreach to migrate and modernise your applications to the cloud using Microsoft Azure? Click here