This is the fourth post in the Automating Private Cloud Director series. The previous posts covered the foundational toolchain: API authentication, Terraform for infrastructure provisioning, and Ansible for infrastructure & post-deployment configuration.
Those capabilities are sufficient for many organizations. But in enterprises with compliance requirements, regulated workloads, or large IT teams, “anyone can deploy from the catalog” isn’t the full story. There are approval gates, budget owners, change advisory boards, and CMDB accuracy requirements that sit on top of the provisioning layer. If you’re coming from VMware, you likely handled this with vRealize Automation Orchestrator (vRO). That’s the gap I’d like to address in this post.
I’m not going to walk through a step-by-step implementation here. Instead, I want to cover the architectural patterns: what the layers are, what sits in each one, and where Private Cloud Director (PCD) fits. Because the honest answer is that PCD doesn’t care what ITSM platform or workflow engine you use. It exposes a clean API, and the enterprise tooling connects to that API.
The Problem with Approval-Driven Provisioning
Self-service catalogs solve the developer-facing bottleneck. But they create a different problem for organizations that need control: any authorized user can deploy anything in the catalog, immediately, with no human review.
For many organizations, that’s fine. For others, it isn’t. Manufacturing environments, regulated industries, and large enterprises typically need:
- A request intake that captures business context (cost center, project code, justification)
- Validation against policy before the request moves forward
- One or more human approvals, routed to the right people
- Automated provisioning only after approval
- A notification back to the requester with resource details
- A CMDB record that reflects what was deployed
VMware addressed this with vRA and vRO. The service catalog was in vRA, the workflow logic lived in vRO, and together they handled the full request-to-deploy lifecycle. When organizations move off VMware, they need to reconstruct this capability with open tooling.
The Three-Layer Architecture
The pattern that works well across most enterprise environments has three distinct layers:
ITSM layer: This is where users make requests and where approvals happen. It’s the system of record for IT work. The leading platform here is ServiceNow, though organizations also run Jira Service Management, BMC Helix, and others. The ITSM layer owns the catalog UI, the request form, the approval routing, and the notifications. It doesn’t do the provisioning.
Orchestration layer: This is the workflow engine that sits between ITSM and infrastructure. It receives the approved request from the ITSM layer, executes the steps in order (validate inputs, call the PCD API, wait for completion, retrieve outputs, send confirmation), and handles branching logic, retries, and failure cases. This is the layer that replaced vRO in most modern architectures.
Infrastructure layer: This is PCD. It receives the provisioning call from the orchestration layer via the API, creates the resources, and returns the results. PCD doesn’t know or care what triggered the request. It sees an authenticated API call and acts on it.
The key design principle is that each layer has a single responsibility, and they communicate through well-defined interfaces. PCD’s Keystone-authenticated REST API is the interface at the infrastructure layer. The orchestration layer’s API or webhook endpoint is the interface at the middle tier. The ITSM platform’s catalog and business rules are the interface at the top.
This separation is what makes the architecture flexible. You can swap the orchestration layer, change the ITSM platform, or replace PCD with a different infrastructure target, and the other layers don’t need to change – only the integration points.
Choosing an Orchestration Layer
This is the question organizations get most stuck on, because there’s no universal answer. A few patterns I see most often:
ServiceNow Flow Designer or Workflow Engine: For organizations that already run ServiceNow at scale, the simplest architecture is to skip a separate orchestration layer entirely. ServiceNow’s built-in Flow Designer can call external REST APIs, handle approval routing, send notifications, and update CMDB records. If your ServiceNow team has the skills to build flows, you may not need Airflow or anything else. The full workflow lives in one platform.
Apache Airflow: Airflow is the most widely adopted open-source workflow orchestration tool in enterprise environments, particularly in organizations with data engineering or platform engineering teams. It models workflows as DAGs (Directed Acyclic Graphs) in Python, which makes them versionable, testable, and auditable. For infrastructure provisioning workflows triggered by ServiceNow approvals, Airflow works well: ServiceNow sends a webhook on approval, Airflow receives it, executes the DAG, and calls back to ServiceNow on completion. Platform9 has published a detailed implementation of this pattern if you want to see how it fits together end-to-end.
Camunda: Camunda is built around BPMN (Business Process Model and Notation), the formal standard for modeling and executing business processes. It’s common in banking, insurance, government, and manufacturing—industries where process compliance, audit trails, and human task routing are first-class requirements. If your organization already has a Camunda deployment or runs in a regulated environment where BPMN compliance matters, it’s a strong fit for the orchestration layer.
Temporal: Temporal is worth calling out for engineering-led organizations building durable, long-running workflows. It evolved from Uber’s Cadence project and provides strong guarantees around workflow state persistence and exactly-once execution. Less common in traditional enterprise IT environments, but increasingly relevant for platform engineering teams building internal developer platforms on top of PCD.
The practical guidance: if your organization already has a mature ServiceNow deployment, start there before adding another tool. If you have a platform engineering or data engineering team that runs Airflow, use it. If you’re in a regulated industry with formal process compliance requirements, look at Camunda. Don’t add orchestration tooling unless the ITSM platform genuinely can’t handle the workflow complexity you need.
ServiceNow and Private Cloud Director: Two Integration Modes
ServiceNow is the ITSM platform most enterprise organizations are already running, so it’s worth looking at how it integrates with PCD specifically. There are two distinct modes, and they serve different purposes.
Mode 1: CMDB Discovery
ServiceNow can natively discover PCD infrastructure via its ITOM Discovery patterns, populating the CMDB with the resources that already exist in your private cloud. This happens through the OpenStack REST APIs with no agents required on the PCD hosts or VMs.
When discovery runs, ServiceNow populates CMDB tables with VM instances (Nova, PCD’s Compute Service), cloud networks and subnets (Neutron, our Networking Service), security groups, Glance images, hardware types (flavors), and the OpenStack datacenter and region hierarchy. The MID Server – a lightweight Java process running on a Linux VM with network access to your PCD Keystone endpoint – handles the API calls from inside the environment.
This is valuable as a standalone capability even before you build any provisioning workflows. It means your CMDB reflects what’s actually running in PCD, which is the foundation for change management, asset reporting, and license tracking.
Mode 2: Provisioning Workflows
The second mode is using ServiceNow as the intake and approval layer for new provisioning requests that ultimately call the PCD API. A user submits a request through the ServiceNow catalog, it routes through approval logic, and on approval a business rule fires that either calls PCD directly or triggers an orchestration layer like Airflow to handle the execution.
The catalog form can be dynamic – using a small intermediary (a Flask app or a serverless function) to query PCD’s API at form load time and populate dropdowns with current images, flavors, and networks from the actual environment. This ensures users are selecting from what’s available, not a static list that may be stale.
These two modes are complementary. Discovery keeps the CMDB accurate for existing resources. The provisioning workflow creates new resources. Together, they give you a complete picture: ServiceNow knows what should exist (from approved requests) and what does exist (from discovery), and the two can be reconciled.
For VMware Admins: How This Maps
| VMware Capability | Enterprise Pattern Equivalent |
|---|---|
| vRealize Automation Orchestrator (vRO) | Airflow, Camunda, Temporal, or ServiceNow Flow Designer |
| vRA Service Broker catalog with approval policy | ServiceNow catalog + approval routing |
| vRA CMDB sync / vRealize Operations inventory | ServiceNow ITOM Discovery for PCD (native OpenStack patterns) |
| vRA project-based cost tracking | ServiceNow request records + PCD tenant RBAC |
| vRO action library (reusable workflow elements) | Airflow operators, Camunda service tasks, or Terraform modules |
| vRA blueprint version control | Terraform modules in Git, referenced by App Catalog templates |
The difference in philosophy is worth noting. VMware’s approach was a tightly integrated proprietary stack: vRA, vRO, vROps, and the CMDB all from the same vendor, deeply coupled to vSphere. The open pattern described here is loosely coupled by design. Each tool does one thing well, they communicate through standard APIs and webhooks, and you’re not locked into any single vendor’s vision of how the workflow should work.
That loose coupling is a feature, not a compromise. When ServiceNow releases a new version of Flow Designer, your PCD integration isn’t affected. When PCD adds new API capabilities, your Airflow DAGs can use them without waiting for Platform9 to expose them through a proprietary connector.
What PCD Brings to This Architecture
PCD’s role in enterprise integration patterns is straightforward: it’s the infrastructure target that everything else calls into. A few things make it a clean fit for this kind of architecture.
The API is standard OpenStack. Terraform providers, Ansible modules, Python SDKs, and ServiceNow’s native ITOM Discovery patterns all work against it without custom connectors. Any tooling that knows how to talk to OpenStack REST APIs works with PCD.
Application credentials (AppCreds) make service account management clean. The orchestration layer authenticates to PCD using an AppCred scoped to the target tenant, not a user account with a password that rotates. This is the right pattern for automated workflows, and PCD supports it natively through Keystone.
Tenant RBAC maps well to enterprise access control requirements. Each team or project gets a tenant, the orchestration layer deploys into the appropriate tenant based on request metadata, and PCD enforces the boundaries. Quota management per tenant gives the platform team cost governance without manual review of every request.
What’s Next?
We’ve covered the full automation stack for Private Cloud Director: direct API usage, Terraform for IaC provisioning, Ansible for configuration management, and now the enterprise patterns for connecting PCD to ITSM and approval workflows. Next, we’ll examine some patterns that can be used to include PCD as part of a CI/CD pipeline.
If you’re evaluating PCD as a VMware alternative, Community Edition is free and gives you a fully functional environment to work through everything in this series on your own hardware.
Thanks for reading along with me!
