As a Managed Service Provider, building complex customer topologies with VMware vSphere® environments is constrained only by the capabilities and topologies that can be built using the network configuration within vSphere together with that of the underlying data center network infrastructure. However, when customers want to change their network configuration, traditional services fall short in two distinct areas. First, while not all customers are capable of designing their own network configurations, those that are have previously had little, if any, access to be able to make changes within the service provider managed environments. Instead, the customer must raise an order, or request the engagement of a service provider solution architect to capture their requirements and provide them to the service provider’s operational teams. The second shortfall in customer experience is that presented with the customer requirements, the operational teams must work out the necessary changes to implement the customer requirements, document the changes, raise appropriate change request or notifications, await approvals and scheduled outage windows before work can commence. After the work starts, coordinating changes across disparate teams and technologies is challenging, testing is complex and time consuming, and recovery planning must account for failures across all areas affected by the change.

Having simplified the delivery of complex customer compute solutions by virtualizing the server environments with vSphere, the service provider can use a similar approach to simplifying the networking layer of a customer solution by introducing NSX to provide software-defined networking (SDN). By making use of a common “underlay” network within the physical data center, NSX allows the service provider to configure complex, multi-customer network topologies and services without the need to reconfigure the underlay network each time. Further, because these services are defined in software, the second of the two shortfalls described earlier can be addressed in several ways. The first, and most straight forward, leverages the fact that a software-defined network can be managed from a single point. While it is possible to automate the configuration of multiple interconnected legacy network devices, this automation is often complex and error prone due in part to the fact that many of these devices were not originally designed with remote configuration management in mind. With NSX, a service provider network engineer can, from a single location, configure, build, deploy, modify, and decommission network connectivity and services for any tenant in the data center. While this central control is a huge help, efficiency and consistency gains are often made through the automation of repeatable tasks. NSX offers a feature-rich API that allows configuration of those same networks and services from external tools. The APIs can be used to create and manage changes, or to “read” the state of a customer environment for monitoring or compliance purposes.

vCloud Director allows the service provider to address the first of the shortfalls mentioned earlier, and the one which is arguably, most apparent to the customer. It provides a portal to allow customers to carry out their own provisioning and changes, store frequently used configurations as templates, and access templates that have been created and shared by the VMware Cloud Provider. vCloud Director is able to control the underlying vSphere environments it manages through the APIs exposed by VMware vCenter Server® and other vSphere components. The introduction of similar API access to the software-defined network layer as noted earlier means that in the latest releases (v8.20 at the time of writing), customers can now manage their environment’s NSX provided networks and services through the same vCloud Director portal and vCloud Director API.