Container apps are buzzing for quite some time now and like the virtualization transition that started about 15 years ago, it will take some time before apps are container based. My job has never been on the developer side of IT, but more on the IT-Pro side. While job types have been growing more towards each other in the past years, I will never be a true developer that spends most of its time writing code for applications. Simply because that’s not what I like to do. Obviously, there are other people that do like to code and do not like the Ops side of it.
This blog is generally more about the platform side and the abilities we currently have and can leverage to provider better platforms for developers. For many IT organizations in the past 10+ years it was always about providing a platform that supports VMs to run applications on. Where today these requests are slowly shifting more and more to be able to provide a platform that can run both VMs and Containers. If your organization has requirements to run the apps or containers on the Edge or close to users, you were out of luck because only public clouds offer managed container platforms.
Well, that time has changed since Azure Arc and tons of development in enabling the ability to run container platforms on any environment. While fully manageable from a single management pane the Azure Resource Manager. For IT organizations the time is here to be ready if these requests start coming from your organization. There are many different platforms and options available when you wish to create and execute your containerized application. I am not going to drill down to all the options, since we are focused on the Microsoft products with a hybrid approach I’ll scope it down to Microsoft offers that you can use. Microsoft has several container platforms that can be used to run in both the public cloud and in our own datacenter or edge location.
There are lots of reasons to run a container platform on the edge with Azure Stack HCI or Windows Server. It can be more cost efficient, faster and/or with lower latency to your end users or devices. Remember… AKS on Azure Stack HCI is free when you have an active Software Assurance. It can also be a security, a data locality or any other valid reason. Now, let’s talk about some of your options.
One of the biggest container platforms is Kubernetes which is implemented by Microsoft on Azure as Azure Kubernetes Service (AKS). AKS is available on public Azure and on the Edge through Azure Stack HCI or Windows Server with Azure Arc. This way you can deploy and manage Kubernetes to everywhere you would like. That includes in your branch offices, factories or in stores close to your register, devices or customers as needed. Just deploy your Azure Arc Connected AKS Management Resource Bridge and you are able to deploy clusters in all offices or locations you require.
Before you are able to use this you first need to onboard AKS on your HCI or Windows Server cluster. This is done through the AKS Management Resource bridge. Through this resources bridge Azure is able to communicate with your cluster and is able to add or remove worker clusters or scale up and down. Integrate it with Log Analytics workspaces to gain insights and monitoring, register it with Azure Active Directory (Azure AD) to provide authenticate based on Azure AD instead of a kubeconfig file. Below we have a management pane (with the GUID) and a worker cluster running on our HCI environment:
It’s then a matter of deploying your workloads through the Kubernetes API. And there you have your first containerized app running in your datacenter or edge location.
But if you prefer not to give access to the complete AKS API. Or work with microservices that go all the way to zero instances if they are not in use. There is a solution available on top of AKS which is called Azure Container Apps (ACA). With ACA you can provide your users an ACA Environment which is more like a light version of AKS that runs on top of an AKS cluster. More details about Azure Container Apps are available on Microsoft Learn.
Recently Splitbrain was involved in the private preview program of Azure Container Apps on Azure Stack HCI with Azure Arc. Which has now been released to public preview. With the Connected Environment, you can deploy an ACA environment in your own datacenter and use it as a region in Azure to deploy apps to. Just like in the AKS example. After you deployed your Azure Container Apps Connected Environment you can deploy your container apps at a custom location. Below the custom location “sb-lab-cl11” is our Azure Stack HCI Lab environment in our datacenter.
In this test we have a simple container app image that is published on Azure Container Registry. That we can deploy with a simple command through Azure CLI:
“az containerapp create –resource-group $groupname –name apphelloworld –environment $connectedEnvironmentName –environment-type connected –image sbweacr.azurecr.io/apphelloworld:latest –registry-server sbweacr.azurecr.io –registry-username sbweacr –registry-password $pass –target-port 80 –ingress ‘external'”
So that is it.. No fuss with Yaml files and Kubernetes API’s. Ofcourse you can also deploy it through the portal. Deploy an ARM template and use that in various other tools.
To summarize, the snowball of a new area of application development is already rolling down the hill. With AKS and ACA together with Azure Arc, you can jump on to support container-based applications. In both public and private cloud, or wait for the snowball to run you over 😉