Writing an Azure Custom Resource Provider

 

Introduction: This is an extensibility platform to Azure. It allows us to define custom APIs that can be used to enrich the default Azure experience. Before we review the custom resource providers, let us review the Azure Resource Provider. Partners build and deploy native Azure Applications for customers using the resource providers. For example, with Microsoft.KeyVault/vaults as <resource-provider>/<resource-types>, partners can store keys and secrets using the Microsoft.KeyVault secret provider.  All the resource providers in Azure are listed via the Portal and while may be ready to use, most require the users to register them with the click of a button so that they are ready to use. Resource providers come with their own schema, templates, permissions, and the conventions followed via Azure Resource Manager. Notably, the separated resource template and resource provider pattern lowers the barrier for service model composition when deploying Azure services.

The Azure Custom Resource Provider allows these partners to extend the Azure Control plane to new services for their customers. The 200+ Azure services categorized as Compute, Storage, Network and PaaS services continue to form the base while other internal and external services are added. The Azure Resource Manager maintains tags, RBAC, ARM Templates, Locks, policies and activity logs for the resources and the create, update, delete of the resources are exposed via the CLI, PowerShell, HTTP request, and Azure Portal.  The Azure Custom provider is in public preview mode, so it is not available to run mission critical SLA based workloads.

The Custom resource providers are a list of contracts between the Azure and the endpoints. It describes how the Azure should interact with an endpoint.  The resource provider acts like a proxy and forwards requests and responses to and from the specified endpoint.  A resource provider specifies two types of contracts: resourceTypes and actions. The endpoint definition is comprised of three fields: name, routing type, and endpoint.

The use of Custom resource providers is not restricted to a cluster-based ecosystem or container-based orchestration frameworks. The Azure Service operator serve those scenarios. Azure Service Operator is an open-source project that exposes Azure Services as Kubernetes operators. Exposing Azure Resources on the Kubernetes control plane is desirable for several reasons and if the exponential growth in popularity of the Kubernetes infrastructure is any indication, then those reasons must hold. Azure resources are also managed in the cloud via the Azure resource manager, so the concepts of resource manifest and state reconciliation are similar. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services. It is often a strategic decision for any company because it decouples the application from the hosts so that the same application can work elsewhere with minimal disruption to its use.   

Azure offer Kubernetes and containers via services that have resource providers as Microsoft.ContainerService and Microsoft.ContainerInstance respectively. These resources are sufficient to launch an instance of Kubernetes and containers. If we are looking to bring resources directly to the Kubernetes control plane, we will require the Azure OSBA. The Azure OSBA expands the service catalog and enabled Azure resources to be recognized as Kubernetes custom resources. Azure Service operators take it a step forward and enable the resources to be managed via the Kubernetes control plane.