Blog Post

Azure Infrastructure Blog
2 MIN READ

Designing Reusable Bicep Modules: A Databricks Example

Roslin_Nivetha's avatar
May 19, 2025

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.0
No CommentsBe the first to comment