Azure Kubernetes Service (AKS) - Blessings and Curses that come with a bulk of configuration options
Use Cases and Deployment Scope
The problem that Azure Kubernetes Service (AKS) adresses is the need for an runtime environment that allows to run our application in an orchestrated platform, that like Kubernetes allows automated deploy/management of containerized images. For this purpose it would be possible to use virtual machines (e.g. with plain docker) but of course even with a reduced complexity in some regard, such a solution would offer way less possibilities e.g. the use of an k8s operator. Besides this, Azure for example offers options (data centers, pricing)
Pros
- Amount of locations (data centers) available
- Option to commit to Azure Kubernetes Service (AKS) for a longer periode to save cost
- Offering a lot of configuration options, to custom-tailor it to your needs
- Fast deployment of the Azure Kubernetes Service (AKS) and Nodes
Cons
- Documentation about all of these different configuration options is scarce, scattered and sometimes even untraceable (undocumented)
- Terraform provider often runs succesfully but elements are missing/not there and no error is thrown
- The tool landscape arround it is not sophisticated, other providers offer a terraform runtime for example
Likelihood to Recommend
In a scenario, where a company respectively a team uses a managed K8s for the first time, the Azure Kubernetes Service (AKS) can be overwhelming. So many different options respectively aspects to consider, in my opinion this makes it very hard to start without outside support. In addition, Azure does not offer a terraform runtime as e.g. Terraform Cloud, you need to take such things in account too.
But if you have the need for a lightweight k8s that starts up relatively fast, the Azure Kubernetes Service (AKS) is suited for you.
