<-- Back to All News

Broadcom issues guidance for Deployment of VCF Automation Node Architecture and Load Balancing

Publish Date: November 5, 2026

Executive Overview

The strategic management and automated provisioning of software-defined data center infrastructure have converged around the operational reliability of the private cloud control plane. Within modern enterprise environments powered by VMware Cloud Foundation (VCF), technology executives—encompassing Chief Information Officers (CIOs), Chief Technology Officers (CTOs), and enterprise platform engineering architects—rely on VCF Automation (formerly Aria Automation) as the central self-service orchestration engine. VCF Automation serves as the critical bridge connecting developer pipelines, infrastructure blueprints, and multi-tenant resource quotas to the underlying compute, storage, and networking fabric. However, as organizations transition to VMware Cloud Foundation 9.x, the underlying microarchitecture of VCF Automation has undergone a foundational redesign: transitioning from legacy multi-virtual-machine deployment models to an integrated, Kubernetes-based container runtime cluster managed natively within VCF Management Services.

This architectural evolution has introduced acute operational friction during Day-0 deployment planning and Day-2 lifecycle transitions. Infrastructure engineering teams frequently encounter deployment parameter validation stalls, subnet allocation errors, and DNS configuration failures on the initial VCF Installer form. Confusion routinely centers on the structural disparity between node counts and required IP addresses (specifically, why a 3-node cluster demands a contiguous pool of five IP addresses alongside multiple external Virtual IPs), the functional decoupling of dual Fully Qualified Domain Names (FQDNs) operating across a single virtual network interface, and the architectural demarcation between the native, embedded virtual load balancer stack (kube-vip paired with Envoy proxies) and external enterprise Load Balancers or Global Server Load Balancers (GSLB) such as VMware Avi Load Balancer or F5 BIG-IP. Furthermore, when platform teams plan in-place migrations from Aria Automation 8.18.x to VCF Automation 9.x, the expansion to a 9-IP address layout across active nodes, buffer allocations, and per-node VIPs routinely challenges legacy network IP address management (IPAM) baselines.

This technical infrastructure advisory delivers an exhaustive operational, architectural, and systems engineering evaluation of the deployment guidance published by Shree Das, Senior Staff Architect and Technical Product Manager in the VMware Cloud Foundation Division at Broadcom. Deconstructing the 3-node High Availability (HA) cluster topology of VCF Automation, this report analyzes the exact mechanics of the 5-IP node pool, details the decoupling of the Public User FQDN from the Private Services Runtime FQDN, evaluates traffic routing flows across native versus external load-balancing architectures, establishes prescriptive criteria for deploying external GSLB for multi-site disaster recovery, and outlines a comprehensive migration runbook for upgrading legacy Aria Automation 8.18.x estates to VCF 9.x without operational downtime or routing deadlocks.

Features

The technical capabilities detailed in Broadcom’s guidance establish an integrated, highly available cluster architecture for VCF Automation, clarifying the microarchitectural mechanics of Kubernetes-native container runtime clusters, dual-FQDN ingress separation, and multi-tiered load balancing across VMware Cloud Foundation.

  • The 3-Node High Availability Architecture and the 5-IP Allocation Rule: In a standard enterprise High Availability deployment, the VCF Installer deploys three virtual machine appliances that join to form an internal Kubernetes-based container runtime cluster. While three nodes are active, the installer enforces a mandatory pool of five contiguous IP addresses on the management subnet:

    • 3 Active Node IPs: (e.g., 172.16.50.11, 172.16.50.12, 172.16.50.13) Assigned directly to the primary network interfaces of the three virtual appliance nodes. These IPs govern inter-node pod communication, cluster consensus protocols (etcd), internal database synchronization, and node-level operating system management.
    • 2 Reserved Buffer / Expansion IPs: (e.g., 172.16.50.14, 172.16.50.15) Maintained permanently in reserve within the subnet pool. The VCF lifecycle orchestrator utilizes these buffer addresses dynamically during non-disruptive rolling upgrades, automated node replacement workflows, and Day-2 cluster scale-outs. During a rolling upgrade, a temporary replacement node is instantiated and bound to a reserve IP, synchronizing cluster state before an outdated node is cordoned, drained, and decommissioned, guaranteeing zero service interruption.

  • Dedicated Cluster Virtual IPs (VIPs) and FQDN Decoupling: Beyond the 5-IP node pool, VCF Automation mandates two distinct, static Virtual IP (VIP) addresses provisioned on the identical management subnet, mapped to two unique Fully Qualified Domain Names (FQDNs). Both FQDNs resolve to floating VIP addresses hosted by the cluster, but they serve completely decoupled operational planes:

    • VCF Automation FQDN (User / Consumer Plane): Mapped to VIP 1 (e.g., vcfa01.rainpole.io resolving to 172.16.50.2). This endpoint serves as the public ingress for all human end-users, cloud administrators, and external continuous integration/continuous deployment (CI/CD) pipelines. It handles interactive logins to the self-service catalog, Cloud Assembly canvas, Service Broker portals, and external REST API provisioning calls over HTTPS port 443.
    • VCF Automation Services Runtime FQDN (Control / Management Plane): Mapped to VIP 2 (e.g., vcfa01-sr01.rainpole.io resolving to 172.16.50.3). This endpoint functions as a private, machine-to-machine control plane interface reserved exclusively for foundational VCF platform services, specifically SDDC Manager, VMware Cloud Foundation Operations, and core lifecycle orchestrators. It handles automated cluster lifecycle management, certificate renewals, node health heartbeats, and deep infrastructure synchronization. Isolating this endpoint guarantees that high-volume user traffic surges or denial-of-service query floods targeting the public catalog cannot saturate or destabilize core infrastructure management operations.

  • Single-NIC Logical Ingress Architecture: Addressing a common deployment misconception, the architecture clarifies that supporting dual FQDNs does not require appliances to be outfitted with multiple virtual network interfaces (NICs). All three virtual machines and both floating VIPs operate over a single virtual network adapter (NIC 0) connected to the standard VCF Management Network Port Group. The separation between user-facing traffic and platform control-plane traffic is enforced logically at Layer 7 through DNS routing and ingress controller bindings, avoiding multi-homed routing complexities and asymmetric packet drops.


  • Per-Node VIP Architecture for External Health Probing: When an external enterprise load balancer (such as VMware Avi Load Balancer, HAProxy, or F5 BIG-IP) or round-robin DNS is integrated, the external appliance cannot simply target floating VIPs; it must monitor and balance across individual node endpoints. VCF Automation provisions dedicated Per-Node Virtual IPs (Node 1 VIP, Node 2 VIP, and Node 3 VIP). Because VIP 1 covers Node 1, two additional static IPs are allocated for Nodes 2 and 3 on the same management subnet. Siting all per-node VIPs within the local management subnet eliminates cross-subnet routing hair-pinning and ensures accurate Layer 7 health check evaluations.


  • High Availability Without External Load Balancers (Native Ingress Architecture): For standard private cloud deployments, VCF Automation functions out of the box with zero external load balancer dependencies:

    • The Native Embedded Load Balancing Stack: Deployed automatically inside the three appliance VMs during installation, consisting of kube-vip for Layer 2/Layer 3 Virtual IP arbitration paired with an internal Envoy proxy ingress tier.
    • Direct User Ingress Flow: End-users and REST API callers connect directly to the primary VCF Automation FQDN (VIP 1). kube-vip directs the packet to the active node hosting the VIP, where the local Envoy ingress proxy distributes incoming HTTP/API sessions evenly across the internal container pods running across all three nodes.
    • Direct Management Ingress Flow: SDDC Manager and VCF Operations route machine-to-machine calls directly to the Services Runtime FQDN (VIP 2). Envoy validates the request and routes it to the core automation orchestration services.
    • Automatic Failover: kube-vip continuously monitors node health. If the virtual machine holding the floating VIPs experiences an unexpected hardware crash, kernel panic, or network isolation event, a healthy peer node automatically claims VIP 1 and VIP 2 via gratuitous ARP (GARP) in seconds, maintaining continuous platform availability without human intervention.

  • High Availability With External Load Balancers / GSLB (Enterprise Multi-Site Architecture): For multi-site data centers or external tenant-facing environments, the architecture incorporates an upstream external load balancer or Global Server Load Balancer (GSLB):

    • External GSLB Ingress Flow: Inbound traffic from enterprise users routes to the external GSLB virtual IP (e.g., 10.0.0.100). The GSLB layer executes active health probing across regional data centers, handles geographic traffic routing, and provides front-end Web Application Firewall (WAF) inspection. GSLB forwards valid user requests down to the site-local tenant-facing Virtual IP (VIP 1: 172.16.50.50).
    • Preservation of the Native Ingress Tier: Crucially, deploying an external load balancer does not replace or disable the native embedded load balancer. Once packets hit VIP 1, the internal kube-vip and Envoy proxy stack remains 100% active, executing essential container pod-level ingress routing and local microservice distribution across the three virtual machines.
    • Control Plane Bypass: Platform management components (SDDC Manager and VCF Operations) completely bypass the external load balancer and GSLB layer. Internal control plane traffic routes directly to VIP 2 (172.16.50.3) over the local management network. This eliminates external network dependencies, ensuring that lifecycle operations, cluster updates, and emergency maintenance succeed even if external load balancing appliances are offline or misconfigured.

  • Migration and Upgrade Topology: Aria Automation 8.18.x to VCF Automation 9.x: Upgrading an existing Aria Automation environment to VCF Automation 9.x transitions the system from a legacy appliance model to an integrated Kubernetes container runtime cluster tied to VCF Management Services. Broadcom defines the precise 9-IP address layout and 2-FQDN prerequisite matrix required to prevent pre-check failures:

    • 1 x VIP for Automation Runtime Service Platform: Primary Virtual IP for control plane and runtime management traffic.
    • 3 x Active Node IPs: Assigned to the three appliance virtual machines hosting the Kubernetes container runtime.
    • 2 x Reserved / Buffer IPs: Sited within the subnet pool to facilitate non-disruptive rolling upgrades and node redeployments.
    • 3 x Per-Node VIPs: Individual VIPs assigned to each node for local ingress routing and external health probe targeting.
    • 1 x Runtime Service FQDN: Bound to the Automation Runtime Service VIP for machine-to-machine management calls.
    • 1 x External Load Balancer / Round-Robin DNS FQDN: Bound to external balancers or round-robin DNS to distribute client traffic.
Benefits

Adopting Broadcom’s validated node and load-balancing architecture for VCF Automation delivers concrete operational, architectural, and financial advantages over ad-hoc deployments and legacy automation frameworks.

  • Complete Elimination of Deployment Validation Stalls: Sizing and deploying enterprise automation clusters historically represented a high-friction process plagued by parameter validation errors. Misunderstanding the relationship between node counts and required IP pools routinely halted installations midway through execution. Establishing a clear architectural baseline—accounting for the 5-IP node pool, dual dedicated VIPs, and per-node health endpoints upfront—ensures that greenfield deployments and automated SDDC Manager workflows execute deterministically from Day-0.


  • Structural Isolation of Core Platform Lifecycles from User Traffic Spikes: In un-segmented automation environments where user-facing catalog requests and platform management APIs share a single endpoint, a sudden surge in developer provisioning scripts or an external query loop can exhaust connection pools, rendering the management plane unresponsive. Decoupling the user-facing VCF Automation FQDN from the private VCF Automation Services Runtime FQDN guarantees that SDDC Manager and VCF Operations retain dedicated control-plane bandwidth. Lifecycle patching, automated cluster health monitoring, and node orchestration proceed without interference during peak business hours.


  • Radical TCO Optimization via Built-In Zero-Cost High Availability: Conventional enterprise application clusters mandate procuring, licensing, and configuring external third-party load balancing appliances simply to achieve localized high availability. VCF Automation’s embedded kube-vip and Envoy proxy architecture delivers production-grade high availability out of the box. Organizations eliminate the capital expense of purchasing specialized load balancing appliances for internal private clouds, collapse multi-vendor support silos, and avoid managing external load balancer configuration scripts for standard single-site deployments.


  • High-Availability Multi-Site Disaster Recovery Resilience: While the native load balancer manages localized node failures seamlessly, integrating an upstream Global Server Load Balancer (GSLB) equips the enterprise for site-level disasters. External GSLB continuously probes site-local VIP health; if an entire data center facility suffers a catastrophic power loss or network partition, GSLB dynamically updates DNS records to steer user traffic to an active secondary VCF private cloud site. Workload consumers experience transparent disaster recovery failover without modifying local application configurations.


  • Deterministic, Non-Disruptive Day-2 Rolling Upgrades: Upgrading enterprise automation engines historically required taking the entire platform offline for hours to execute database backups and sequential node patching. The allocation of two reserved buffer IPs within the VCF Automation subnet pool enables true rolling upgrades. The platform orchestrator provisions temporary node instances, synchronizes internal state, and decommissions outdated nodes in sequence, maintaining continuous platform availability and allowing infrastructure teams to apply security patches during regular business hours without maintenance downtime.


  • Seamless Architectural Convergence for Brownfield Aria Automation Estates: Organizations operating mature VMware Aria Automation 8.18.x deployments face mandatory migration milestones as they modernize to VMware Cloud Foundation 9.x. The 9-IP address and 2-FQDN planning framework provides network architects with an exact, validated pre-allocation blueprint. Platform engineering teams can reserve required subnet blocks and configure DNS forward/reverse records weeks ahead of scheduled maintenance, de-risking in-place upgrades and eliminating unexpected IP exhaustion during migration windows.


Use Cases

Global enterprise organizations operating across capital-intensive, high-concurrency, and strictly regulated private clouds can implement Broadcom’s VCF Automation architecture to resolve critical availability and deployment bottlenecks.

  • Multinational Financial Services Core Banking Self-Service and Control Plane Isolation: A global commercial banking consortium operates VCF Automation across two mirrored private cloud data centers, serving over 3,000 internal developers provisioning digital banking microservices and transactional database clusters:

    • Facing high developer query concurrency during business hours, the bank enforces strict ingress decoupling: developers interact exclusively with vcfa.corp.bank.com (VIP 1: 172.16.50.2), while SDDC Manager lifecycle orchestration binds strictly to vcfa-sr.corp.bank.com (VIP 2: 172.16.50.3).
    • During a month-end financial closing cycle, a rogue developer script floods the user catalog API with thousands of rapid status requests. While user-facing API queues experience temporary throttling, SDDC Manager executes scheduled cluster compliance audits and automated certificate renewals across VIP 2 with zero latency degradation.
    • The bank achieves total operational separation, protects mission-critical management workflows, and cleanly satisfies European banking operational resilience mandates under DORA.

  • Sovereign Healthcare Integrated Delivery Network Multi-Site GSLB Disaster Recovery: A nationwide healthcare provider manages hospital clinical portals, patient scheduling systems, and electronic health record (EHR) analytics across primary and secondary private cloud facilities running VMware Cloud Foundation:

    • The clinical IT platform team deploys a 3-node VCF Automation HA cluster at each hospital data center, front-ended by an enterprise VMware Avi Load Balancer configured for Global Server Load Balancing (GSLB).
    • Inbound medical staff traffic connects to a global DNS endpoint (portal.healthcare.org at 10.0.0.100), which routes sessions to the active site’s local VIP (172.16.50.50), where embedded Envoy proxies distribute requests across the local 3-node cluster.
    • When an unexpected municipal fiber cut isolates the primary hospital data center, external Avi GSLB health probes detect site failure in under fifteen seconds, dynamically updating DNS routing to redirect clinical personnel to the secondary private cloud facility.
    • The healthcare network ensures continuous, uninterrupted access to patient diagnostic systems for hospital emergency rooms, satisfying strict HIPAA availability baselines.

  • Sovereign Cloud Infrastructure Provider Multi-Tenant KaaS Automation: A European sovereign cloud provider delivers hosted infrastructure-as-a-service (IaaS) and Kubernetes-as-a-Service to municipal government ministries, tax authorities, and law enforcement agencies under strict NIS2 and GDPR data residency mandates:

    • To maximize gross margins, the provider standardizes on VCF Automation utilizing the native embedded load balancer stack, eliminating third-party load balancer licensing costs across twenty regional sovereign enclaves.
    • Embedded kube-vip daemons monitor node health, automatically failing over floating VIPs if an underlying physical server blade experiences a hardware fault.
    • Because all management traffic remains contained within the local VCF Management Network Port Group over a single virtual network adapter, the provider avoids cross-subnet routing complications and eliminates external network sniffing attack vectors.
    • The cloud provider delivers 99.99% self-service portal availability to public sector tenants, maintaining mathematically verified sovereign data isolation without expanding operational infrastructure overhead.

  • Global Digital Retail Platform Black Friday Rolling Upgrade and Capacity Scaling: A global e-commerce retail enterprise operates high-concurrency continuous delivery pipelines that provision ephemeral test environments and production microservices through VCF Automation:

    • Three weeks prior to an international holiday sales peak, the platform engineering group plans an in-place upgrade from Aria Automation 8.18.2 to VCF Automation 9.1 to ingest critical security patches and performance optimizations.
    • Network engineers pre-allocate the required 9-IP address block within the management subnet, reserving the two buffer IPs (172.16.50.14 and 172.16.50.15).
    • During the scheduled upgrade window, the VCF orchestrator executes an automated rolling update: temporary appliance nodes are instantiated using the buffer IPs, synchronized with cluster state, and swapped in sequence while running live developer deployments.
    • The enterprise completes the full platform upgrade in under ninety minutes with zero developer downtime, entering the peak shopping window with a fully patched, highly resilient automation control plane.
Alternatives

A comprehensive infrastructure assessment requires comparing Broadcom’s native VCF Automation node architecture and load-balancing framework against alternative enterprise cloud orchestration and traffic management methodologies.

  • External-Only Load Balancing Models (Legacy vRealize Automation Architectures): In older generations of vRealize Automation (vRA 7.x and early 8.x), the platform possessed zero native load-balancing capabilities. Deploying a high-availability cluster mandated procuring, configuring, and maintaining external third-party load balancers (such as F5 BIG-IP or NSX Edge Load Balancers) to manage even local node failover. While familiar to legacy network administrators, this model imposed severe architectural fragility. If the external load balancer experienced an appliance failure, certificate expiration, or configuration drift, the entire automation platform collapsed, even if all underlying nodes were healthy. Furthermore, external load balancers were required to participate in internal node-to-node communication, introducing latency bottlenecks and complex SSL pass-through configurations. VCF Automation’s embedded kube-vip/Envoy tier eliminates these external failure dependencies for local high availability.


  • Monolithic Single-Node Automation Deployments (The Unmanaged Silo Antipattern): In this cost-cutting operational shortcut, organizations deploy VCF Automation as a single, standalone virtual machine, avoiding the 3-node HA deployment model to save compute and IP address resources. While a single-node deployment minimizes Day-0 planning, it represents an irresponsible operational posture for production enterprise private clouds. A single-node deployment possesses zero redundancy: if the underlying ESXi host crashes, the VM encounters memory corruption, or a software update fails, the entire enterprise self-service provisioning portal and all automated CI/CD pipelines halt immediately. Furthermore, single-node deployments cannot execute non-disruptive rolling upgrades; every subsequent platform patch forces a full service outage, accumulating operational technical debt and frustrating developer teams.


  • Public Cloud Managed Developer Portals and Infrastructure Orchestration (AWS Service Catalog / Azure Automation): Under this cloud-native strategy, enterprises abandon on-premises private cloud automation entirely, utilizing public cloud hyperscaler native portals to provision infrastructure. While hyperscalers provide managed control planes and eliminate physical IP allocation planning, this approach introduces severe long-term financial unpredictability. Hyperscaler consumption models bill aggressively for continuous management run rates, API execution steps, and punitive network data egress fees. More critically, managing on-premises private cloud hypervisors from public cloud management planes creates continuous hybrid networking dependencies, expands external firewall attack surfaces, and introduces severe data sovereignty and compliance liabilities for heavily regulated global organizations.


  • Fragmented DIY Open-Source Automation Orchestration (Custom Terraform / Ansible Pipelines): In this architectural model, internal platform engineering teams bypass commercial automation platforms entirely, constructing an in-house self-service portal using open-source tools (such as Backstage front-ends triggering raw Terraform and Ansible scripts executed on standalone Linux virtual machines). While this strategy avoids commercial software licensing fees, it shifts an extraordinary financial and operational burden onto internal engineering personnel. Custom scripting frameworks lack native integration with VCF Management Services, lack automated Day-2 clustering failover, require ongoing internal developer maintenance, and cannot provide verified Independent Software Vendor (ISV) support during catastrophic provisioning failures.


Alternative Perspective

While the architectural advancements delivered in VCF Automation 9.x provide an exceptional enterprise automation foundation, an objective engineering analysis reveals critical operational prerequisites, IPAM planning dependencies, and architectural trade-offs that enterprise technology leadership must evaluate prior to enterprise deployment.

A primary technical consideration centers on the rigid subnet allocation and IP contiguity prerequisites enforced by the VCF Installer. While allocating five IP addresses for a 3-node cluster and provisioning multiple virtual IPs delivers non-disruptive rolling updates and high availability, it demands strict planning within enterprise IP Address Management (IPAM) systems. In large enterprise organizations characterized by rigid, siloed network governance, requesting contiguous blocks of static IP addresses on locked-down management subnets frequently requires multi-week approval workflows. If an infrastructure team attempts to deploy VCF Automation using non-contiguous IP addresses or fails to reserve the two buffer addresses upfront, the VCF Installer validation engine will fail, halting deployment. Enterprise platform architects must establish collaborative network planning protocols, ensuring that the complete 5-IP or 9-IP address footprint and forward/reverse DNS records are fully allocated and verified in IPAM before initiating installation wizards.

Furthermore, platform leadership must examine the operational discipline required when configuring external enterprise load balancers. While VCF Automation operates out of the box with native embedded load balancing, organizations deploying external load balancers (such as VMware Avi Load Balancer) for multi-site GSLB or external security inspection must understand the dual-tier routing flow. An external load balancer does not replace the native kube-vip/Envoy tier; it functions as an upstream reverse proxy that forwards traffic to the site-local VIP 1. If network engineers configure the external load balancer with aggressive TCP connection timeouts, misaligned SSL re-encryption ciphers, or improper health check intervals, the external appliance can prematurely mark healthy local nodes as down, triggering artificial traffic drops. Platform engineering teams must strictly adhere to Broadcom’s validated load balancer configuration profiles, ensuring that health checks target the dedicated Per-Node VIPs (Node 1 VIP, Node 2 VIP, Node 3 VIP) rather than floating cluster endpoints.

Finally, enterprise leadership must address the critical dependency on dedicated control-plane routing for VCF Management Services. While Broadcom’s architectural guidance establishes that SDDC Manager and VCF Operations must communicate with VCF Automation strictly through the Services Runtime FQDN (VIP 2), enforcing this separation in brownfield networks requires disciplined firewall governance. If network administrators inadvertently route SDDC Manager traffic through the external load balancer or fail to open bidirectional HTTPS (port 443) communication between SDDC Manager and VIP 2 on the local management subnet, automated lifecycle management, certificate rotations, and platform health telemetry will fail silently. Platform teams must validate that internal control-plane traffic completely bypasses external proxies, preserving direct machine-to-machine communication across the private cloud backbone.

Final Thoughts

The release of Broadcom’s technical guidance deconstructing VCF Automation node architecture and load balancing by Shree Das provides enterprise technology leadership with an authoritative, definitive operational blueprint. By clarifying the mathematical necessity of the 5-IP node pool, establishing the architectural separation between the User FQDN (VIP 1) and the Services Runtime FQDN (VIP 2), and untangling the operational relationship between embedded kube-vip/Envoy load balancing and external GSLB appliances, Broadcom transforms private cloud automation deployment from an uncertain administrative hurdle into a deterministic, repeatable engineering discipline.

In an era where enterprise private clouds must match the agility, developer velocity, and self-service consumption experience of public hyperscalers while satisfying rigorous data sovereignty and regulatory governance mandates, the operational stability of the automation tier is paramount. VCF Automation 9.x delivers a resilient, cloud-native foundation capable of sustaining business-critical provisioning pipelines, absorbing high-concurrency user demand, and executing non-disruptive Day-2 lifecycle upgrades without service downtime.

To capitalize on the measurable efficiencies and architectural resilience delivered by this framework, enterprise technology leadership should take immediate, decisive operational steps: audit current IPAM management subnets to pre-allocate required 5-IP and 9-IP address blocks ahead of planned VCF 9.x deployments; configure forward and reverse DNS records for both the VCF Automation FQDN and the Services Runtime FQDN; verify that internal platform management components (SDDC Manager and VCF Operations) route control-plane traffic directly to VIP 2, bypassing external load balancers; and standardize multi-site private cloud architectures on upstream GSLB while allowing native embedded kube-vip stacks to govern local node high availability. By anchoring enterprise automation to a validated, highly available, and structurally sound private cloud architecture, organizations can eliminate operational deployment bottlenecks, empower engineering talent, and build an agile platform for continuous enterprise innovation.

Source

Demystifying VCF Automation Node Architecture and Load Balancing