IaC with Bicep and ARM

Infrastructure as Code (IaC) for SAP: Mastering Bicep and ARM Templates

Introduction: Why Infrastructure as Code Matters for SAP

When organizations transition their SAP workloads to the cloud, the complexity of the infrastructure often becomes the primary bottleneck for operational efficiency. Traditionally, managing SAP environments—composed of complex SAP Application Servers, HANA databases, and intricate networking requirements—involved manual configuration in a web portal. This approach is prone to human error, difficult to audit, and nearly impossible to replicate consistently across different environments like Development, Quality Assurance, and Production.

Infrastructure as Code (IaC) changes this paradigm by treating your infrastructure configuration exactly like application software. By defining your Azure resources in text files, you gain the ability to version control your infrastructure, automate deployments, and ensure that your production environment is an identical clone of your testing environment. For SAP professionals, this means moving from "click-ops" to a repeatable, reliable, and scalable deployment model.

In this lesson, we will explore the two primary methods for declarative infrastructure management in Azure: Azure Resource Manager (ARM) templates and Bicep. We will dive deep into how these tools function, how they differ, and how you can implement them specifically for SAP workloads. By the end of this guide, you will understand how to build, maintain, and deploy SAP infrastructure that is stable, secure, and ready for the demands of high-performance enterprise applications.

Understanding ARM Templates: The Foundation

Azure Resource Manager (ARM) templates are JSON-based files that define the resources you need for your SAP landscape. When you submit an ARM template to Azure, the Azure Resource Manager service parses the JSON and orchestrates the creation or update of the resources defined within it.

The Anatomy of an ARM Template

An ARM template consists of several key sections that act as a blueprint for your deployment. Understanding these sections is critical for debugging and writing your own templates:

• Parameters: These are the inputs you provide when you deploy the template. In an SAP context, these would include the VM size for your HANA database, the virtual network name, or the SAP System ID (SID).
• Variables: These are internal values used to simplify the template logic. For instance, you might construct a resource name by concatenating a prefix, the SAP SID, and a suffix.
• Resources: This is the core of the template. It lists the specific Azure resources, such as Virtual Machines, Managed Disks, or Virtual Networks, that you want to deploy.
• Outputs: These allow you to return data after the deployment is finished. You might output the Private IP address of the newly created HANA database server so that other automation tools can use it.

The Challenges with JSON

While ARM templates are functional and powerful, they are notoriously difficult to read and maintain for complex SAP architectures. Because they use JSON, they are verbose, lack comments, and require complex syntax for simple logic like loops or conditional deployments. For example, a simple string manipulation in JSON requires nested function calls that are easy to break and difficult to troubleshoot. This is precisely why Microsoft introduced Bicep.

Introducing Bicep: The Modern Way to Deploy SAP

Bicep is a domain-specific language (DSL) for deploying Azure resources. Think of Bicep as a "transpiler"—it provides a cleaner, more readable syntax that compiles down into standard ARM template JSON. You get all the power of the underlying ARM engine without the headache of writing thousands of lines of verbose JSON.

Why Bicep is Better for SAP

1. Readability: Bicep syntax is concise. A 500-line ARM template can often be reduced to 100 lines of Bicep code.
2. Modularity: Bicep has native support for modules, allowing you to break your massive SAP deployment into smaller, reusable components (e.g., a module for the database tier, a module for the application tier).
3. Type Safety: Bicep provides built-in validation. If you try to assign an invalid VM size to your SAP application server, the Bicep compiler will alert you before you even attempt the deployment.
4. No State File: Unlike other third-party IaC tools, Bicep does not require you to manage a state file. The "state" is always stored in Azure itself, which is a massive advantage for security and simplicity.

Callout: Bicep vs. ARM Templates While Bicep is the recommended choice for new infrastructure, it is not a replacement for the underlying Azure Resource Manager. Bicep is simply a more developer-friendly interface for the same ARM backend. You can think of Bicep as the "source code" and the generated JSON as the "compiled binary." You should always write in Bicep, but you should understand that the Azure portal and CLI interact with the resulting ARM JSON.

Step-by-Step: Deploying a Simple SAP Compute Node

To understand how to implement this, let's look at a practical example. We will create a Bicep file that deploys a single Virtual Machine designed for an SAP Application Server.

Step 1: Define Parameters

First, we define the inputs. We want our template to be flexible, so we use parameters for things that change between environments.

param sapSid string = 'PRD'
param location string = resourceGroup().location
param vmSize string = 'Standard_E4ds_v5'

@secure()
param adminPassword string

Step 2: Define the Resource

Next, we define the Virtual Machine resource. Note how much cleaner this is compared to the equivalent JSON.

resource sapAppServer 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: 'vm-${sapSid}-app-01'
  location: location
  properties: {
    hardwareProfile: {
      vmSize: vmSize
    }
    storageProfile: {
      imageReference: {
        publisher: 'SUSE'
        offer: 'sles-sap-15-sp4'
        sku: 'gen2'
        version: 'latest'
      }
    }
    osProfile: {
      computerName: 'sap-app-01'
      adminUsername: 'azureuser'
      adminPassword: adminPassword
    }
  }
}

Step 3: Deployment

To deploy this, you simply use the Azure CLI: az deployment group create --resource-group mySAPResourceGroup --template-file main.bicep

Note: Always use the @secure() decorator for passwords or keys. This ensures that the values are not logged in plain text in the deployment history or the Azure activity logs.

Designing for SAP: Advanced Concepts

SAP infrastructure is not just about a single VM; it is about the "SAP Landscape." This includes high availability, networking, and storage performance.

Modularity in SAP Deployments

When building SAP infrastructure, avoid putting everything in one file. Instead, create a folder structure that mirrors your SAP landscape:

• /modules/network/vnet.bicep
• /modules/storage/disks.bicep
• /modules/compute/hana-db.bicep
• /modules/compute/app-server.bicep
• main.bicep (The orchestrator)

In your main.bicep, you call these modules like this:

module sapNetwork './modules/network/vnet.bicep' = {
  name: 'networkDeployment'
  params: {
    vnetName: 'sap-vnet'
  }
}

module sapHana './modules/compute/hana-db.bicep' = {
  name: 'hanaDeployment'
  params: {
    subnetId: sapNetwork.outputs.subnetId
  }
}

This modular approach allows you to update the database tier without touching the application tier, significantly reducing the risk of accidental outages during infrastructure updates.

Handling High Availability (HA)

SAP requires high availability for the HANA database. In Azure, this typically involves deploying two VMs in an Availability Set or Availability Zones. Your Bicep template should handle this by using loops:

param nodeCount int = 2

resource hanaNodes 'Microsoft.Compute/virtualMachines@2023-03-01' = [for i in range(0, nodeCount): {
  name: 'vm-hana-${i}'
  location: location
  // ... other properties
}]

This ensures that you can scale your database cluster from a single node to a multi-node setup simply by changing the nodeCount parameter.

Best Practices for SAP Infrastructure as Code

Implementing IaC for SAP is a journey. To ensure your implementations are successful, follow these industry-standard best practices.

1. Version Control is Mandatory

Never deploy infrastructure from a local file on your laptop. All Bicep files should be stored in a Git repository (like Azure DevOps or GitHub). This provides a clear audit trail of who changed what, when, and why. Every change to your SAP infrastructure should be a Pull Request that is reviewed by another team member.

2. Use Parameters for Everything

Hardcoding values is the quickest way to create technical debt. If you find yourself typing a value like eastus or Standard_E4ds_v5 inside a resource block, move it to a parameter file. Create separate parameter files for each environment:

• dev.parameters.json
• prd.parameters.json

3. Leverage Azure Policy

IaC is only as good as the guardrails you put around it. Use Azure Policy to enforce standards. For example, you can create a policy that prevents the deployment of any VM that is not an "SAP-certified" SKU. This ensures that even if someone tries to deploy an undersized VM, the deployment will fail, protecting your SAP performance.

4. Tagging for Cost Management

SAP environments are expensive. Use Bicep to enforce mandatory tags on every resource. Tags such as Environment, CostCenter, and SAP_SID are essential for tracking consumption in the Azure Cost Management portal.

resource sapVm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: 'vm-app-01'
  tags: {
    Environment: 'Production'
    CostCenter: 'Finance'
    SAP_SID: 'PRD'
  }
  // ...
}

Warning: Do not store sensitive information like SAP passwords or database connection strings directly in your Bicep files or parameters. Use Azure Key Vault. In your Bicep template, reference the Key Vault to fetch the secret at runtime.

Common Pitfalls and How to Avoid Them

Even with Bicep, you can run into significant issues if you don't plan your infrastructure correctly.

Pitfall 1: The "Fragile" Deployment

A common mistake is creating templates that are too large. If you define your entire SAP environment (Network, Storage, DB, App, Load Balancer) in one 2,000-line Bicep file, a single syntax error or a failed resource deployment can leave your environment in an inconsistent state.

• The Fix: Break your code into small, functional modules. Use the "Blast Radius" principle: keep the scope of each deployment as small as possible to minimize the impact of failures.

Pitfall 2: Ignoring Dependencies

Azure resources often have dependencies. For example, you cannot create an SAP VM until the Virtual Network and Subnet exist. If you don't explicitly define these dependencies, the deployment might fail because the system tried to create the VM before the network was ready.

• The Fix: Use the dependsOn property or, better yet, use implicit dependencies by referencing the output of one module in the input of another. Bicep is smart enough to understand that if Module B uses an output from Module A, Module A must be deployed first.

Pitfall 3: Not Using "What-If"

Before deploying, always run the what-if operation. This tells you exactly what will happen to your existing infrastructure before changes are applied. It will warn you if a resource is going to be deleted or recreated.

• The Fix: Run az deployment group what-if as part of your CI/CD pipeline. This is your "safety net."

Comparison Table: Manual vs. IaC (Bicep/ARM)

Frequently Asked Questions (FAQ)

Can I mix ARM templates and Bicep?

Yes. Bicep is designed to work alongside existing ARM templates. You can call an ARM template from within a Bicep module, which is helpful if you have legacy templates you aren't ready to convert yet.

Does Bicep support all Azure resources?

Bicep is updated almost instantly when new Azure features are released. It supports the full spectrum of Azure services, including those specific to SAP, such as Azure NetApp Files and Proximity Placement Groups.

How do I handle SAP-specific OS configurations?

Bicep handles the Azure infrastructure (the VM shell). For the OS-level configuration (installing SAP software, configuring HANA), you should combine Bicep with a configuration management tool like Ansible or use Custom Script Extensions. Bicep creates the VM; Ansible installs the SAP bits.

Is Bicep free?

Yes. Bicep is an open-source project from Microsoft and is included in the Azure CLI and PowerShell modules at no additional cost.

Deep Dive: Managing SAP Storage with Bicep

SAP HANA requires high-performance storage. Using Bicep, you can ensure that your disks are configured with the correct IOPS and throughput by defining them as part of the VM deployment.

// Define a managed disk for HANA Data
resource hanaDataDisk 'Microsoft.Compute/disks@2023-01-02' = {
  name: 'disk-${sapSid}-hana-data'
  location: location
  sku: {
    name: 'Premium_LRS'
  }
  properties: {
    diskSizeGB: 1024
    creationData: {
      createOption: 'Empty'
    }
  }
}

By defining storage in Bicep, you ensure that every environment has the exact same disk throughput, preventing the common "why is my Dev HANA server slower than Prod?" issue caused by misconfigured manual disk settings.

Advanced Strategy: The "Golden Image" Approach

In professional SAP environments, you should rarely deploy "naked" VMs and install software from scratch. Instead, use an image factory.

1. Build: Use a Bicep template to deploy a VM.
2. Configure: Use an automation tool (like Ansible) to install the OS patches and SAP prerequisites.
3. Capture: Use the Azure Compute Gallery to create a "Golden Image" from that VM.
4. Deploy: Your production Bicep template then references this pre-configured image.

This strategy reduces the deployment time of an entire SAP application server from hours to minutes. Bicep plays a crucial role here by managing the deployment of these images across your various Azure regions and subscriptions.

Integrating Bicep into CI/CD Pipelines

To truly benefit from IaC, you must automate the deployment process. A typical workflow for an SAP team looks like this:

1. Code Commit: The SAP Basis engineer updates the Bicep template in Git.
2. Pull Request: A peer reviews the changes.
3. Validation: The CI pipeline runs az deployment group validate.
4. Security Scan: A security tool scans the Bicep code for misconfigurations (e.g., open ports).
5. Deployment: The CD pipeline executes the deployment into the target environment.

This workflow removes the dependency on individual "super-users" who have manual access to the Azure portal. It democratizes infrastructure management while simultaneously increasing security.

Key Takeaways for SAP Infrastructure Professionals

• Adopt Bicep Immediately: Move away from manual portal configurations. Bicep is the industry standard for Azure and provides the best balance of power, readability, and maintainability.
• Treat Infrastructure as Software: Your infrastructure code belongs in version control. Every change must be documented, reviewed, and tested in a non-production environment before touching production.
• Modularity is Key: Build a library of reusable modules for your SAP components (HANA, ASCS, App Servers). This allows you to build new landscapes in minutes rather than days.
• Safety First: Always use the what-if operation before deploying. Use Azure Policy to enforce compliance and prevent the creation of non-compliant infrastructure.
• Security by Design: Never store secrets in plain text. Use Azure Key Vault and reference secrets in your Bicep templates.
• Automate Everything: Integrate your Bicep deployments into a CI/CD pipeline to ensure consistency and speed.
• Focus on Performance: Use Bicep to strictly define storage and networking parameters to ensure that your SAP environment meets the required performance benchmarks consistently across all environments.

By mastering these concepts, you transition from being an infrastructure "administrator" to an infrastructure "engineer." This shift is critical for the modern SAP professional, as it allows your organization to move with the speed of the cloud while maintaining the stability and reliability that enterprise SAP systems demand. The tools are ready; the logic is sound—the next step is to begin refactoring your existing SAP footprint into code, one module at a time.