Avoid lock-in when using additional cloud services in combination with managed Kubernetes services in public clouds

In this article I will try to make you aware of the consequences when using additional cloud services and add-ons when using managed Kubernetes services in public clouds. I’ll use Azure AKS as an example to make my case clear.

AKS and the use of additional Azure services and add-ons

Azure is a popular cloud platform. For many companies the use of Azure Kubernetes Service (AKS for short) is therefore obvious. But using AKS alone is not enough to host containerized apps in a secure and manageable way. You will have to implement solutions for monitoring, logging, security and making your apps publicly available (configuring ingress). And to who else do you turn to for all of this? Of course, Azure.

That is why AKS is becoming a goldmine for Microsoft. For example, Azure offers many extra services (and more are being added) that can be used in combination with AKS. Think, for example, of the Azure Monitor, Azure Application Gateway, Azure Container Registry (ACR), Azure Key Vault and Azure Defender. All great services, but beware, using these services is not free of change.

In addition to a number of paid services, Azure also comes with AKS add-ons that should make the use of AKS more secure and manageable. Examples include the Application Gateway Ingress Controller (AGIC), HTTP Application Routing and Azure Policy.

The consequences

But what are the consequences of using these extra services and add-ons? The answer to this is of course highly dependent on the chosen cloud strategy. If it’s not a problem for you to be stuck in using Azure forever, the only consequence is that you might just have to pay a lot of money. But if you want to be prepared for a possible exit or just want to be able to switch flexibly between different public cloud providers, then you’ve got a serious challenge.

Azure’s strategy of offering extra services and add-ons when using AKS therefore is only serving one goal, to keep you on the Azure platform for as long as possible (and to pay a lot of money in the meantime).

The alternatives

Now you may be wondering, “but what am I supposed to do then?” The answer to this is: harness the power of Kubernetes! Whether you’re using Kubernetes on AWS, Azure, Google Cloud Platform, Alibaba Cloud, or Digital Ocean, the Kubernetes API is (often almost) identical. So if you run everything natively on Kubernetes, you can transfer your containerized apps to a Kubernetes cluster with another cloud provider at any time. But to make this possible, you will need to invest a significant amount of time (and therefore money) to develop a native Kubernetes platform solution, with all the additional solutions you need to host your apps in a manageable and secure way. Try to run everything completely on Kubernetes itself, without having to rely on cloud specific services and add-ons.

A few examples / suggestions:

• Use a Nginx Ingress Controller in combination with a standard Load Balancer instead of the AGIC. Optionally, the Ingress Controller can be combined with a ModSecurity WAF
• Use Grafana Loki for logging and Prometheus Operator for metrics and alerts instead of Azure Monitor
• Use Harbor (open source) as a container registry as an alternative to ACR. Harbor comes standard with 2 container image vulnerability scanning engines
• Use HashiCorp Vault (open source) for secret management as an alternative to Azure Key Vault
• Use OPA Gatekeeper (own installation / configuration) as an alternative to the Azure Policy add-on
• Use add-ons like External DNS instead of the AKS HTTP Application Routing add-on

But there is also a much easier way. At Red Kubes we have already developed a solution in which all these solutions are integrated. We call it Otomi Container Platform. Otomi can be installed as an added value layer on top Kubernetes in any Cloud (and even on-premises on OpenStack or Vmware ESX) and contains all the tools you need. Otomi is completely cloud agnostic and open source. This makes it possible to migrate containerized applications without impact (the data migration aside) from one cloud to another. Another advantage of Otomi is lifecycle management. Instead of having to deal with the lifecycle management of all the different add-ons and applications yourself, you only get updates from Otomi. This results in enormous time savings.

Wrapping up

The examples I provided here do not only apply to Azure. We see the same development in AWS and GCP. The large cloud providers are developing more and more additional services to make the use of Kubernetes as easy as possible. But without even noticing you will be completely tied to a particular cloud provider.

To be clear, all the services and add-ons that are being offered by the big guys are great to get you started. And if you feel comfortable getting tied up to just one provider, using all of these services and add-ons can really be beneficial.

I hope this provides some food for thought and hopefully makes you aware of the consequences of using all of these additional services, but also of the alternatives that are available.

Like to know more about Otomi? Visit https://redkubes.com