Infrastructure as Code (IaC) has become a cornerstone for consistent and scalable cloud deployments. Bicep, Microsoft’s domain-specific language (DSL) for ARM templates, brings simplicity and readability to Azure IaC.
In this blog, I’ll walk you through how to design a reusable Bicep module for deploying Azure Databricks, a popular analytics and machine learning platform. We'll focus on creating a parameterized and composable pattern using Bicep and Azure Verified Modules (AVM), enabling your team to replicate this setup across environments with minimal changes.
Why Reusability in Bicep Matters:
As your Azure environment scales, manually copying and modifying Bicep files for every service or environment becomes error-prone and unmanageable.
Reusable Bicep modules help:
- Eliminate redundant code
- Enforce naming, tagging, and networking standards
- Accelerate onboarding of new services or teams
- Enable self-service infrastructure in CI/CD pipelines
Here, we’ll create a reusable module to deploy an Azure Databricks Workspace with:
- Consistent naming conventions
- Virtual network injection (VNet)
- Private endpoint integration (UI, Blob, DFS)
- Optional DNS zone configuration
- Role assignments
- AVM module integration
Module Inputs (Parameters)
Your Bicep pattern uses several key parameters:
Parameterizing the Pattern
These parameters allow the module to be flexible yet consistent across multiple environments.
Naming conventions:
The nameObject structure is used to build consistent names for all resources:
var adbworkspaceName = toLower('${nameObject.client}-${nameObject.workloadIdentifier}-${nameObject.environment}-${nameObject.region}-adb-${nameObject.suffix}')
|
Configuring Private Endpoints and DNS
The module allows defining private endpoint configurations for both Databricks and storage:
This logic ensures:
- Private access to the Databricks UI
- Optional DNS zone integration for custom resolution
You can extend this to include Blob and DFS storage private endpoints, which are essential for secure data lake integrations.
Plugging in the AVM Module:
The actual deployment leverages an Azure Verified Module (AVM) stored in an Azure Container Registry (ACR):
Example usage:
Using the module in your main Bicep deployment:
Conclusion
This Bicep-based or any reusable modules or patterns enable consistent, secure, and scalable deployments across your Azure environments. Whether you're deploying a single workspace or rolling out 50 across environments, this pattern helps ensure governance and simplicity.
Resources
Updated May 19, 2025
Version 2.0Roslin_Nivetha
Microsoft
Joined April 29, 2024
Azure Infrastructure Blog
Follow this blog board to get notified when there's new activity