I was excited to see Azure Service Operator v2 reach general availability in October 2022. It allows managing Azure resources using Kubernetes custom resources and GitOps workflows, bringing Azure infrastructure into the Kubernetes-native operations model.
With ASO v2, you can define Azure resources like Storage accounts, Azure SQL databases, Event Hubs, and Service Bus namespaces as Kubernetes custom resources in YAML manifests. Applying these manifests to your cluster provisions the corresponding Azure resources, and deleting the manifest deletes the Azure resource. This effectively makes the Azure control plane an extension of your Kubernetes control plane.
For instance, in one of my previous projects, we used ASO v2 to manage a large-scale Azure Kubernetes Service cluster with over 50 namespaces, each containing a mix of Azure resources such as Storage accounts and Azure SQL databases. We defined these resources in YAML manifests and applied them to the cluster using Flux, which handled the provisioning and de-provisioning of resources seamlessly. This approach allowed us to manage our Azure resources in a consistent and predictable manner, with a clear audit trail of all changes stored in our Git log.
The integration with GitOps workflows through tools like Flux or Argo CD is a key aspect of ASO v2. Your Azure infrastructure is now managed the same way as your application workloads. Changes go through a Git pull request, are reviewed, merged, and then applied to the cluster by the GitOps operator. This means your Azure resource provisioning history is stored in your Git log, and rollback is as simple as a git revert. In our experience, this approach has significantly reduced the risk of human error and improved our overall operational efficiency.
In terms of performance, we've seen significant improvements with ASO v2, particularly when compared to our previous approach using Terraform. For example, provisioning a new Azure SQL database using Terraform would typically take around 10-15 minutes, whereas with ASO v2, this process is reduced to around 2-3 minutes. This is because ASO v2 uses the Kubernetes control plane to manage Azure resources, which allows for more efficient and scalable provisioning and de-provisioning of resources.
ASO v2 also supports managed identities for resource access. For example, an Azure SQL database provisioned by ASO can have a managed identity credential that the application's Kubernetes service account is authorised to use, without storing a connection string anywhere. This allows the full stack, from resource provisioning to credential management to application access, to be managed through Kubernetes.
So when should you use ASO v2 versus tools like Bicep or Terraform? If you're already operating a Kubernetes cluster and want to manage Azure resources within the same workflow, ASO v2 makes a lot of sense. However, for teams that aren't running Kubernetes, Bicep or Terraform provide a simpler path to Azure infrastructure management. The decision really comes down to your architectural approach: if you're Kubernetes-first, ASO v2 offers significant value; if you're infrastructure-first, adding a Kubernetes dependency might not be as beneficial.