From Bare Metal to Cloud: Automating Full Lifecycle Management of Physical Servers at Scale

Manual server provisioning still takes 2-6 weeks on average — from procurement and racking through OS installation, configuration, and approval workflows (Puppet State of DevOps Report, 2024-2025). In an era where cloud instances spin up in seconds, that gap is not just an inconvenience; it is a competitive liability. The bare metal cloud market reached $14.32 billion in 2025 and is projected to hit$36.71 billion by 2030, growing at a compound annual rate of 20.7% (MarketsandMarkets, 2025). Yet the real story is not the market size — it is that 40% of enterprises now run critical workloads on bare metal cloud, and 72% have adopted hybrid cloud strategies that include physical servers (Flexera State of the Cloud 2025, Synergy Research, 2025).

The challenge: how do you manage thousands of physical machines across globally distributed data centers — each with its own availability zone, network topology, and hardware generation — and turn them into a pool of compute resources that development teams can self-service through an API? This guide covers the full stack: from CMDB as the source of truth, through bare metal provisioning engines, to global multi-AZ orchestration and developer self-service portals. Whether you are an infrastructure engineer managing a single colo or an SRE leader designing a planet-scale physical fleet, this is the architecture reference I wish I had when starting.

Key Takeaways

• Manual server provisioning averages 2-6 weeks; automated bare metal engines reduce this to 5-30 minutes — a 90-95% reduction in time-to-production.
• CMDB/Source of Truth is the foundation: without accurate asset data and relationship mapping, automation is fragile and error-prone.
• MAAS, Tinkerbell, Ironic, and Foreman each fit different scale points and ecosystems — there is no single "best" tool.
• Global multi-AZ management requires a hub-and-spoke architecture: a global Source of Truth with local execution planes per region.
• Quant funds and financial firms have unique requirements (low latency, compliance audit trails, exchange co-location) that shape every tool choice.
• The full stack spans five layers: Physical Infrastructure → Source of Truth → Provisioning → Orchestration → Self-Service.

What Is Bare Metal Lifecycle Automation?

Bare metal lifecycle automation is the practice of managing a physical server's entire existence — from the moment it arrives at the data center loading dock until the day it is decommissioned and recycled — through software-driven workflows rather than manual human intervention. The full lifecycle comprises six distinct stages: rack and cable (physical installation and network connection), commission (hardware discovery, firmware validation, burn-in testing), provision (OS installation, security hardening, initial configuration), operate (monitoring, patching, scaling), decommission (data sanitization, resource pool return), and retire (secure disposal, asset record closure).

Each stage traditionally involved multiple handoffs between teams: facilities handled racking, network engineers configured switches, sysadmins installed operating systems, security teams applied hardening standards, and application teams waited — sometimes weeks — for a machine to become usable. Automation collapses these handoffs into a continuous pipeline triggered by API calls or webhook events.

The technical foundation rests on three protocols that have been stable for decades. PXE (Preboot Execution Environment) enables network booting: a server's NIC firmware broadcasts a DHCP request with PXE extensions, receives a TFTP server address and boot file name, downloads a Network Bootstrap Program into RAM, and executes it — all without a local disk or installed OS. IPMI (Intelligent Platform Management Interface) provides out-of-band management through the Baseboard Management Controller (BMC), allowing remote power control, virtual media mounting, and KVM console access independent of the host OS. Redfish, the modern RESTful successor to IPMI, is increasingly supported on newer hardware and offers a standardized API for firmware updates, thermal monitoring, and power capping.

Citation capsule: The bare metal cloud market reached $14.32 billion in 2025 and is projected to grow at 20.7$36.71 billion by 2030 (MarketsandMarkets, 2025). This growth is driven by AI/ML workloads (45% of which run on bare metal), compliance requirements, and the recognition that not everything belongs in a virtualized cloud.

Why Does CMDB Serve as the Foundation?

A Configuration Management Database (CMDB) is an ITIL-defined repository that stores information about hardware and software assets — called Configuration Items (CIs) — and, critically, the relationships between them. In the context of bare metal automation, the CMDB (or its modern variant, the Network Source of Truth) serves as the single authoritative reference that every downstream automation tool queries before taking action. Without it, your provisioning engine does not know which machines exist, your monitoring system cannot discover new assets, and your change management process has no baseline to compare against.

The relationship model is what distinguishes a CMDB from a simple asset spreadsheet. A server CI is connected to: the rack it occupies (location), the switch ports it connects to (network), the VLANs it belongs to (segmentation), the IP addresses it consumes (IPAM), the workloads it hosts (applications), the team that owns it (organizational), and the lifecycle stage it is currently in (status). When you decommission a database server, the CMDB tells you which applications will lose capacity, which IPs can be reclaimed, and which network paths become redundant. Without these relationships, every change is a guessing game.

The DCIM (Data Center Infrastructure Management) market — which overlaps significantly with CMDB for physical infrastructure — is projected to reach $5.01 billion by 2029, growing at 10.6% CAGR (MarketsandMarkets, 2024). This growth reflects a broader industry recognition that you cannot automate what you cannot accurately inventory.

Modern Source of Truth platforms like NetBox and Nautobot have become the de facto standard for infrastructure teams that treat their CMDB as a programmable platform rather than a passive database. NetBox, originally created by DigitalOcean in 2016 and now with over 21,500 GitHub stars, provides IPAM, DCIM, circuit tracking, and VPN modeling out of the box. Nautobot — a fork by Network to Code — extends the model with Git-based data sources, Nornir integration for automated discovery, and a plugin architecture that supports custom data models and automation workflows.

How Do the Leading Provisioning Engines Compare?

Four open-source bare metal provisioning engines dominate the landscape: MAAS, Tinkerbell, Ironic, and Foreman. Each was designed for a different primary use case, and the right choice depends on your existing ecosystem, scale, and operational philosophy.

MAAS (Metal as a Service), developed by Canonical, is the most turnkey option for Ubuntu-centric environments. It provides a web UI for server commissioning, built-in DHCP/DNS/IPAM, and a REST API that treats physical machines like cloud instances. MAAS automatically discovers hardware inventory (every PCI and USB device), runs burn-in tests before commissioning, and supports Ubuntu, CentOS, RHEL, Windows, and SUSE. Its rack controller architecture allows scaling across multiple subnets — critical for multi-AZ deployments. The trade-off: MAAS is opinionated about its ecosystem and works smoothest when you are already in the Ubuntu/Debian world.

Tinkerbell, a CNCF Sandbox project originally open-sourced by Packet (now Equinix Metal), takes a workflow-driven approach. It provisions physical hardware through a declarative workflow engine: you define Hardware, Template, and Workflow objects (using kubectl if desired), and Tinkerbell orchestrates the DHCP, iPXE, and OS installation steps. Its architecture is microservices-based: Smee handles DHCP and iPXE, Tootles provides metadata, Hook is the installation environment, and the Tink server/worker/controller trio executes workflows. Tinkerbell is the natural choice for Kubernetes-centric teams that want to manage physical and container infrastructure through the same declarative patterns. Note: the original tinkerbell/tink repository was archived in December 2025 and moved to the tinkerbell/tinkerbell organization.

Ironic is the OpenStack project for bare metal provisioning and offers the widest hardware driver support of the four — including PXE, iPXE, iLO, IPMI, Redfish, and vendor-specific passthru interfaces. It integrates natively with OpenStack Nova (compute), Neutron (networking), and Glance (images), making it the default choice for organizations already running OpenStack private clouds. Ironic's state machine covers enrollment, preparation, deploy, undeploy, rescue, and servicing — the most complete lifecycle model of any open-source provisioner. The trade-off is operational complexity: Ironic is typically deployed through Bifrost (standalone) or as part of a full OpenStack distribution.

Foreman is the most mature project (active since 2009) and the only one that combines provisioning with full configuration management integration. It serves as an External Node Classifier (ENC) for Puppet and Salt, provides parameterized classes and hierarchical parameter storage, and includes content management (through the Katello plugin) for RHEL/CentOS patch workflows. Foreman supports provisioning on bare metal, Amazon EC2, Google Compute Engine, OpenStack, Libvirt, oVirt, and VMware — making it the strongest choice for hybrid cloud environments. Its 2,900 GitHub stars reflect the largest community of the four.

What Does a Global Multi-AZ Architecture Look Like?

Managing bare metal across a single data center is a solved problem. Managing it across dozens of availability zones spanning multiple continents introduces challenges that are fundamentally about latency, consistency, and failure domain isolation. The architecture that scales globally is a hub-and-spoke model: a global Source of Truth (SoT) serves as the authoritative reference for all asset data, while local execution planes in each region handle the latency-sensitive operations that cannot tolerate cross-continental round trips.

The global SoT — typically Nautobot or NetBox deployed in a highly available configuration — stores the canonical inventory: every server, rack, switch, IP address, VLAN, circuit, and their relationships. It is the system of record that all other tools query. Changes to the global SoT propagate to regional instances through API calls or event-driven webhooks. Critically, the global SoT does not need to be in the data path for provisioning — it only needs to be consistent enough that regional systems can make correct decisions.

Each region (or availability zone, for larger deployments) runs a local execution plane that includes: a provisioning engine instance (MAAS rack controller, Tinkerbell stack, or Ironic conductor), a local image repository (caching OS installation images to avoid WAN transfers), a DHCP/PXE service (network boot must be local — you cannot PXE boot across a WAN), and a configuration management endpoint (Ansible AWX/Tower, Salt master). The local plane operates autonomously: if the WAN link to the global SoT goes down, provisioning within the region continues uninterrupted. The SoT syncs when connectivity restores.

Network architecture for global bare metal management requires careful attention to DHCP relay and PXE proxying. In a multi-AZ deployment, each AZ needs its own DHCP server (or relay agent) that can respond to PXE boot requests within the local broadcast domain. MAAS handles this through rack controllers that proxy DHCP/PXE on behalf of the region controller. Tinkerbell's Smee component serves as the local DHCP/iPXE server. For organizations with many small edge sites, a centralized provisioning engine with DHCP relay agents at each site is the standard pattern.

How Do You Build a Self-Service Developer Portal?

The ultimate goal of bare metal automation is to transform physical servers from a ticket-driven request (submit a form, wait days for a human to rack and install) into a self-service API that developers invoke the same way they request cloud resources. This transformation requires three layers: an abstraction layer that hides physical complexity, a workflow engine that enforces approval and quota policies, and a portal interface that presents resources in a developer-friendly way.

The abstraction layer maps physical resources into logical pools. A developer should not need to know that their workload runs on a Dell R750 in rack U12 of NY5 — they should request "8 cores, 32GB RAM, Ubuntu 24.04, in the US-East region" and let the system find suitable hardware. This requires the provisioning engine to expose a cloud-like API (MAAS and Ironic both do this natively) and a resource scheduler that matches requests against available inventory. The scheduler considers constraints: CPU generation, memory capacity, disk type (SSD vs HDD), network bandwidth, rack power budget, and NUMA topology for latency-sensitive workloads.

The workflow engine handles the human and policy dimensions that pure automation cannot. A typical self-service request flows through: authentication (who is requesting?), authorization (do they have quota?), approval (does this request need manager sign-off?), provisioning (execute the automated workflow), notification (tell the developer their resource is ready), and cost attribution (charge the right cost center). Tools like HashiCorp Sentinel, Open Policy Agent (OPA), or custom workflow engines (Temporal, Camunda) enforce these policies consistently.

The portal interface is where developer experience is won or lost. Backstage, Spotify's open-source developer portal (now a CNCF project), has emerged as the leading framework for building internal developer platforms. It provides a plugin architecture for cataloging infrastructure resources, scaffolding new services, managing documentation, and integrating with CI/CD pipelines. For bare metal specifically, a Backstage plugin can surface the available resource pools, accept provisioning requests, and display the status of active machines — all through a unified interface that developers already use for their other tools.

Citation capsule: 75-80% of organizations have adopted Infrastructure as Code (IaC) practices, with Terraform holding 65-70% market share among IaC users (Pulumi State of IaC Report, HashiCorp, 2024-2025). The self-service portal is the human-facing layer on top of these IaC foundations — it translates developer intent into Terraform plans, Ansible playbooks, and provisioning API calls.

What Are the Quant Fund Special Requirements?

Quantitative trading firms and hedge funds occupy a unique position in the bare metal landscape. Their infrastructure must simultaneously support two very different workload profiles: ultra-low-latency trading (where microseconds matter and kernel bypass is mandatory) and massively parallel research (where strategy backtesting consumes thousands of CPU cores for hours). This duality shapes every layer of the architecture.

For trading workloads, the provisioning engine must support hardware-level customization that most cloud environments cannot offer. This includes: CPU pinning (dedicating specific cores to the trading process to avoid context switches), NUMA affinity (ensuring memory access stays within the local NUMA node), kernel bypass (using DPDK or RDMA to process network packets without traversing the kernel network stack), BIOS tuning (disabling C-states, turbo boost, and hyperthreading for deterministic performance), and FPGA integration (for firms that implement trading logic in hardware). MAAS and Ironic both support custom commissioning scripts that can apply these settings; Tinkerbell's workflow model is well-suited to injecting firmware-level configuration steps.

Compliance and audit requirements in financial services add another dimension. Regulations like MiFID II in Europe and SEC Rule 17a-4 in the United States require detailed records of system changes, access controls, and data retention. Every action in the bare metal lifecycle — who provisioned which server, when, with what configuration — must be logged immutably. This means the CMDB/SoT must have full audit logging, the provisioning engine must generate detailed event records, and the orchestration layer must enforce approval workflows that satisfy segregation-of-duties requirements. ServiceNow CMDB is common in financial firms specifically because it integrates with ITIL change management processes that auditors recognize.

Co-location constraints add a geographic dimension. Trading firms place servers as physically close to exchange matching engines as possible — often in the same data center, sometimes in the same rack. This means the global architecture must support exchange-proximity-aware scheduling: a trading workload must be provisioned in the AZ that minimizes latency to the target exchange (NYSE in NY4/NY5, NASDAQ in NY5, CME in Chicago, LSE in LD4, TSE in TY3, HKEX in HK1). The provisioning engine needs to understand these topology constraints and enforce them automatically.

What Does the Full Reference Architecture Look Like?

Bringing all the pieces together, a mature bare metal automation stack spans five distinct layers, each with its own tooling and responsibilities. This is the architecture I recommend for organizations managing 1,000+ physical servers across multiple availability zones.

Layer 1: Physical Infrastructure. The hardware itself — servers, racks, switches, PDUs, cables — and the out-of-band management network (IPMI/BMC/Redfish). This layer also includes the PXE boot infrastructure: DHCP servers, TFTP servers, and the network connectivity that allows a bare server to find its boot image. The management network is typically isolated from the production network for security.

Layer 2: Source of Truth (SoT). Nautobot (or NetBox) serves as the authoritative inventory of all physical assets and their relationships. It stores server models, serial numbers, rack positions, IP addresses, VLANs, circuits, and power connections. HashiCorp Vault integrates at this layer for secrets management — BMC credentials, SNMP communities, and API tokens are stored in Vault and injected into automation workflows at runtime, never hardcoded in playbooks. ArgoCD or Flux manages the SoT configuration itself through GitOps, ensuring that changes to the infrastructure model are versioned and auditable.

Layer 3: Bare Metal Provisioning. MAAS (or Tinkerbell/Ironic, depending on ecosystem) handles the commissioning and deployment workflow. It discovers hardware, runs burn-in tests, configures RAID and BIOS settings, and installs the operating system through PXE boot. The provisioning engine exposes a REST API that the orchestration layer consumes. For multi-AZ deployments, each region runs a local provisioning instance that syncs asset data from the global SoT.

Layer 4: Orchestration and Configuration. Ansible (through AWX or Ansible Tower) manages post-provisioning configuration: security hardening, monitoring agent installation, application deployment, and ongoing compliance enforcement. Terraform (with custom providers for the provisioning engine) manages the infrastructure-as-code layer, allowing teams to define desired state in version-controlled configuration files. Nornir — a Python automation framework — handles network device configuration (switch VLAN assignment, firewall rule updates) that accompanies each server provisioning event.

Layer 5: Self-Service Portal. Backstage (or a custom portal) provides the developer-facing interface. Developers browse available resource pools, submit provisioning requests, track deployment status, and manage their allocated machines. The portal integrates with the organization's identity provider (LDAP/SAML/OAuth) for authentication and enforces quota policies through OPA or Sentinel. Cost attribution data flows back to the finance team through the SoT's resource ownership model.

The end-to-end workflow for a new server, from rack to production, flows through all five layers:

1. Physical install: Server is racked, cabled, and powered on. The BMC is configured with a known IP on the management network.
2. Auto-discovery: The provisioning engine detects the new machine via BMC, collects hardware inventory (CPU, memory, disks, NICs), and registers it in the SoT.
3. Commissioning: Automated burn-in tests validate hardware health. Firmware versions are checked against the approved baseline. The machine is assigned to a resource pool based on its capabilities.
4. Developer request: A developer requests resources through the self-service portal. The scheduler finds a matching machine in the requested region.
5. Provisioning: The provisioning engine allocates the machine, installs the OS via PXE boot, applies the standard configuration baseline, and runs security hardening.
6. Delivery: The developer receives credentials and connection details. The SoT is updated with the new ownership and workload assignment.
7. Ongoing operations: Monitoring agents report metrics. Configuration drift is detected and remediated. Patching follows the defined maintenance window.
8. Decommission: When the workload ends, the machine is wiped (secure erase), returned to the resource pool, and the SoT status is updated.

What Are the Key Metrics for Bare Metal Automation Success?

Measuring the impact of bare metal automation requires tracking metrics across three dimensions: speed, reliability, and efficiency. The industry benchmarks below are drawn from the Puppet State of DevOps Report, DORA/Google DevOps research, and aggregated case studies from HashiCorp and Gartner.

Speed metrics. The most commonly cited is provisioning lead time: the elapsed time from "resource requested" to "resource usable." Manual processes average 2-6 weeks; automated environments achieve 5-30 minutes for a single server, and can provision hundreds of machines in parallel within hours. Time-to-repair (MTTR) for hardware failures drops from days (waiting for a human to diagnose and replace) to minutes (automated failover to spare capacity). Deployment frequency — how often you push infrastructure changes — increases by 3-5x because changes are tested and applied through code rather than manual procedures.

Reliability metrics. Server-related downtime decreases by up to 70% because automated provisioning eliminates the configuration errors that cause post-deployment failures (Gartner, IDC, 2024-2025). Change failure rate — the percentage of infrastructure changes that cause incidents — drops by 80% because every change is version-controlled, peer-reviewed, and tested in a staging environment before production. Configuration drift — the divergence between intended and actual configuration — is detected and remediated continuously rather than discovered during audits.

Efficiency metrics. Operational cost decreases by 30-50% through reduced manual effort and faster throughput. Server utilization improves by 20-30% because automated resource pooling eliminates the "silo effect" where teams over-provision to buffer against slow provisioning. Zombie servers — idle machines consuming power — account for 10-15% of data center capacity in manual environments; automated decommissioning reclaims this waste (Uptime Institute, Lawrence Berkeley National Lab, 2024-2025). IT staff productivity improves by 50-60% because engineers focus on high-value work instead of repetitive racking and installing.

Frequently Asked Questions

How long does it take to implement bare metal lifecycle automation?

For a single data center with 100-500 servers, a basic MAAS or Tinkerbell deployment can be operational in 2-4 weeks — including hardware commissioning, network configuration, and OS image preparation. A full multi-region deployment with self-service portal, CMDB integration, and compliance workflows typically takes 3-6 months. The longest pole is usually organizational: defining the asset data model, establishing approval workflows, and training teams on the new processes. The technical implementation is well-documented; the change management is what determines timeline.

Can I use these tools with existing VMware or OpenStack environments?

Yes. Foreman natively supports provisioning on VMware vSphere, oVirt, Libvirt, Amazon EC2, Google Compute Engine, and OpenStack — it is the strongest choice for hybrid environments. Ironic is the OpenStack bare metal component and integrates natively with Nova, Neutron, and Glance. MAAS can coexist with VMware by managing the physical layer while VMware manages the virtualization layer — machines are commissioned by MAAS, then handed to vSphere for virtualization. Tinkerbell is more focused on bare metal-only workflows but can integrate with any environment through its REST API.

What is the minimum team size to operate this stack?

A team of 2-3 infrastructure engineers can operate a single-region deployment of 500-1,000 servers. The key roles are: one engineer focused on the provisioning engine and OS image management, one focused on the SoT/CMDB and automation workflows, and one (potentially part-time) focused on the self-service portal and developer experience. For multi-region deployments, add one engineer per region for the first 3-4 regions, then scale more slowly because the automation reduces per-region effort. The break-even point — where automation reduces total operational effort compared to manual processes — is typically reached at 200-300 servers.

How do I handle firmware updates at scale?

Firmware updates are the most operationally sensitive part of bare metal automation because a failed update can brick a server. The standard approach is a canary deployment pipeline: update firmware on a small test pool (5-10 machines), run burn-in validation for 24-48 hours, then progressively roll out to larger batches. MAAS supports firmware updates through its commissioning scripts. Ironic has a dedicated firmware update workflow. For heterogeneous hardware environments, tools like Ansible with vendor-specific modules (Redfish API calls) provide the most control. Always maintain a rollback plan: keep the previous firmware version available and test the downgrade procedure before committing to a fleet-wide update.

What about network booting across WAN to remote sites?

PXE booting across a WAN is not feasible — the DHCP discovery phase relies on broadcast traffic that does not route across subnets, and TFTP's low throughput makes cross-continental OS installation impractical. The standard solution is local PXE proxying: each remote site runs a lightweight DHCP relay agent (or MAAS rack controller) that responds to local PXE requests, while the OS images are cached locally on a site-level image server. For very small edge sites without local infrastructure, virtual media mounting through the BMC (IPMI v2.0+ supports mounting an ISO over the network) is an alternative — the provisioning engine pushes the ISO URL to the BMC, which mounts it as if it were a local DVD.

How do I migrate from manual processes to full automation?

The migration follows a crawl-walk-run pattern. Crawl: deploy the SoT/CMDB and manually populate it with existing asset data. This alone delivers value through better visibility. Walk: deploy the provisioning engine for new server deployments only — existing servers continue to be managed manually. This proves the automation works without risking production. Run: extend automation to existing servers through a "recommissioning" process — as hardware rotates out or workloads shift, machines are decommissioned from manual management and recommissioned through the automated pipeline. A typical migration for a 1,000-server fleet takes 6-12 months, with the majority of value realized in the first 3 months.

What is the ROI of bare metal automation?

The ROI calculation includes: labor savings (30-50% reduction in operational effort for server provisioning and maintenance), downtime reduction (up to 70% fewer server-related outages), utilization improvement (20-30% better server utilization through resource pooling), and speed value (faster time-to-market for development teams). For a 1,000-server deployment, the typical payback period is 12-18 months. The largest single factor is usually the reduction in "server waiting time" — the hours developers spend waiting for infrastructure that could be spent building product.

Conclusion

Bare metal lifecycle automation is no longer optional for organizations managing significant physical infrastructure. The market is growing at 20.7% annually because the alternative — manual server management at scale — is simply untenable. The architecture spans five layers: physical infrastructure, Source of Truth, provisioning, orchestration, and self-service. The tooling landscape offers mature open-source options for each layer: Nautobot/NetBox for SoT, MAAS/Tinkerbell/Ironic/Foreman for provisioning, Ansible/Terraform for orchestration, and Backstage for the developer portal.

The key insight from practitioners is that the technology is the easy part. The hard parts are: building an accurate asset inventory (the SoT is only as good as its data), designing approval workflows that satisfy both agility and compliance requirements, and managing the organizational change from ticket-driven to API-driven operations. Start with the SoT — everything downstream depends on it. Then automate provisioning for new deployments. Then extend to existing infrastructure. Then build the self-service layer.

In the next post in this series, we will dive deep into the PXE boot process — the foundational protocol that makes all bare metal provisioning possible — and walk through configuring a multi-site PXE infrastructure with DHCP relay, iPXE chainloading, and image caching.

Sources

• MarketsandMarkets, Bare Metal Cloud Market Report, 2025, https://www.marketsandmarkets.com
• MarketsandMarkets, Data Center Infrastructure Management Market, 2024, https://www.marketsandmarkets.com/Market-reports/data-center-infrastructure-management-market-264497062.html
• Precedence Research, Server Market Size Report, 2025, https://www.precedenceresearch.com/server-market
• Flexera, 2025 State of the Cloud Report, 2025, https://flexera.com
• Synergy Research Group, Data Center Count and Capacity, 2025, https://srgresearch.com
• Puppet, State of DevOps Report, 2024-2025, https://puppet.com
• Google, DORA State of DevOps Report, 2024-2025, https://cloud.google.com/devops/state-of-devops
• HashiCorp, Terraform Case Studies and IaC Adoption Data, 2024-2025, https://hashicorp.com
• Pulumi, State of Infrastructure as Code Report, 2024-2025, https://pulumi.com
• Gartner, Infrastructure & Platforms Research, 2024-2025, https://www.gartner.com
• IDC, Data Center Automation Research, 2024-2025, https://www.idc.com
• Forrester, Cloud Infrastructure Research, 2025, https://www.forrester.com
• IBM/Red Hat, Hybrid Cloud Survey, 2025, https://ibm.com/cloud
• Uptime Institute, Data Center Industry Survey, 2024-2025, https://uptimeinstitute.com
• Lawrence Berkeley National Lab, Data Center Energy Studies, 2024-2025, https://lbl.gov
• GitHub, canonical/maas, tinkerbell/tink, openstack/ironic, theforeman/foreman, netbox-community/netbox, nautobot/nautobot repositories, 2025, https://github.com