Dr. Pranay Jha

A developer clicks Request on a catalog item and a virtual machine appears ten minutes later. Simple from the outside. Underneath, that click crossed three services, a policy engine, a deployment engine, and a cloud account, and any one of them can be where your design succeeds or stalls. Understanding that path is the difference between operating VCF Automation and just hoping it keeps working. So let us follow the click.

Three services and the engine between them

Part 1 named the three services. Here is what each one is responsible for, and crucially, what it hands to the next. The thing that is easy to miss is the deployment engine in the middle: the component that takes a declared template and actually builds it against real infrastructure.

Component	Takes in	Produces
Automation Assembler	Cloud accounts, zones, mappings	VMware Cloud Templates (blueprints)
Automation Service Broker	Released templates and workflows	Catalog items, forms, governed requests
Deployment engine	A request against a template	A deployment of real resources
VCF Operations Orchestrator	Lifecycle events and inputs	Workflow actions, custom logic, day-2

---

How a request becomes a deployment

Follow the click. A user opens Service Broker, picks a catalog item, and fills the form. Service Broker checks governance: is this request inside policy, does it need approval, what lease applies. If it clears, the deployment engine takes the template plus the form inputs and provisions against the project’s cloud zone, which maps to a real vCenter and NSX. The result is a deployment object the user can manage, with day-2 actions attached. Every arrow in that chain is a place a design can go wrong, usually at the governance gate or the placement mapping.

The template is the contract

Everything downstream honours the VMware Cloud Template. It declares the inputs a user sees on the form and the resources the engine builds. Here is a minimal one: a machine whose size is a user-chosen input, attached to an existing network. Small, but it is the whole contract.

formatVersion: 1
inputs:
  size:
    type: string
    title: Machine size
    enum:
      - small
      - large
    default: small
resources:
  app_net:
    type: Cloud.Network
    properties:
      networkType: existing
  app_vm:
    type: Cloud.vSphere.Machine
    properties:
      image: ubuntu-2204
      flavor: '${input.size}'
      networks:
        - network: '${resource.app_net.id}'
# The form shows a small/large picker. The engine builds a VM on an existing
# network. Change the enum and every catalog request inherits it.

Where extensibility hooks in

The default flow rarely survives contact with a real organization. You need an IPAM call here, a CMDB update there, a naming convention enforced before provisioning. That is what the Event Broker is for. Lifecycle events fire subscriptions, and a subscription runs either an Orchestrator workflow or an ABX action. You are not editing the engine; you are subscribing to its events and injecting logic at named stages.

Embedded vs external Orchestrator

One architecture decision falls out of the org type you picked in Part 1. A VM Apps organization can use the embedded Orchestrator that ships inside VCF Automation. An All Apps organization requires an external VCF Operations Orchestrator instance. That is not a preference; it is a requirement that changes your component count and your lifecycle work.

Dimension	Embedded Orchestrator	External Orchestrator
Org type	VM Apps	All Apps (required), VM Apps (optional)
Moving parts	Fewer, ships in the box	A separate instance to deploy and patch
Best when	Simpler VM-centric estates	All Apps, or shared workflows across orgs

Designing each hop: where it breaks and what to check

Tracing the request path on paper is step one. Step two is hardening each hop, because a self-service platform fails quietly: requests succeed in a demo and stall in production. Here is what I check at each stage before I let a tenant near it.

The governance gate

This is where most requests die, usually for boring reasons. An approval policy with no approver assigned blocks every request silently, and the user just sees a request that never completes. A lease policy that is too aggressive reclaims workloads people still need; too loose and you grow a sprawl problem you pay for at renewal. What I validate first: every approval policy has a live approver group, and every project has a default lease that matches how long its workloads actually live. Test it with a request from a real tenant account, not an admin who bypasses half the rules.

Cloud-zone placement

The second-highest-risk hop. A cloud zone maps a project to real compute, and if the mappings are wrong, deployments either fail or land in the wrong cluster. The classic break is a flavor or image mapping that exists in one region but not another, so the same template provisions cleanly for one project and fails for the next. Validate that every project zone has the flavor mappings, image mappings, and network profiles the templates reference. Missing mappings are the single most common cause of a deployment that fails after the form was already accepted, which is the worst place to fail because the user thinks they succeeded.

Template inputs and constraints

The form a user sees is only as safe as the template behind it. An input with no constraint lets someone request a 64-vCPU machine from a catalog meant for small dev boxes. Put enums and ranges on inputs, and use tags and constraints so placement respects boundaries. The mistake teams make is shipping a template with open-ended inputs and trusting users to be reasonable. They will not be, and the bill arrives monthly. Constrain at the template, not in a policy document nobody reads.

Extensibility timing

Subscriptions can be blocking or non-blocking, and the choice matters more than it looks. A blocking subscription at the allocation stage that calls a slow external IPAM adds time to every deployment, and if that system is down, your provisioning is down with it. A non-blocking subscription that updates a CMDB after the fact can fail without stopping the deployment. Match the mode to the dependency: block only when the result is required to continue, and put a timeout and a fallback on anything that reaches outside VCF Automation. The first outage most teams cause themselves is a blocking subscription to a system that was never as reliable as the platform calling it.

Day-2 actions: the part teams forget

Provisioning is the easy half. The deployment object a user gets back carries day-2 actions: resize, snapshot, power operations, delete, and custom actions you wire through Orchestrator. Teams design the create path with care and then leave day-2 as whatever the defaults happen to be, which means users either get actions they should not have, like deleting a production database, or cannot perform the ones they actually need. Decide per project which day-2 actions are exposed, gate the destructive ones behind approval where the workload warrants it, and build any custom day-2 as an Orchestrator workflow triggered from the deployment.

In production, the day-2 surface is where the platform earns or loses trust. A user who can create a workload but cannot resize it without a ticket has been handed half a tool, and they will tell their colleagues so. Map the full lifecycle, not just birth: create, the routine changes in the middle, and a clean retirement that releases the lease and the resources. A platform that can create but not safely manage is half a platform, and it is the half people complain about once the launch glow fades.

The Bottom Line

VCF Automation is four moving pieces, not three: Assembler authors, Service Broker publishes and governs, the deployment engine builds, and Orchestrator extends through the Event Broker. The template is the contract that ties them together. My recommendation when you start designing: trace one real request end to end before you build anything, mark the governance gate and the cloud-zone placement as your two highest-risk hops, and decide embedded versus external Orchestrator from your org type and your need to share workflows, not from a diagram that looks tidy. Get the request path right on paper and the rest of this series is implementation detail.

Next we tackle the decision that shapes everything above it: VM Apps versus All Apps organizations, and how to choose. For more context on where this sits in the platform, see VCF Automation in VCF 9 Explained. Which hop in the request path worries you most in your environment? Tell me in the comments.

References

• What’s New in VCF Automation (Broadcom TechDocs)
• VCF Automation 9: External VCF Operations Orchestrator (vrealize.it)
• Using Automation Assembler (Broadcom TechDocs)

About The Author