vRA includes a number of grouping mechanisms. Administrators can use these grouping constructs to organize the compute fabric as well as create business-level grouping to partition services, resources, and users.

Today, applications are running across the globe in hybrid IT infrastructure. We have to extend the private data center into the public cloud as well as with containers. It can also be extended by connecting IoT service providers. ​NSX is a unified networking and security platform for all preceding technologies or infrastructure that allows customers to connect, secure, and operate to deliver services wherever applications may hosted. It has an embedded security engine segmenting the network through micro-segmentation and encrypting data in motion.

 When we talk about the cloud, we basically want to configure and manage a hybrid network environment through just one tool. We don't want each cloud management system operating in a silo, and the same holds for on-premise, which should be oblivious to where the workload is currently hosted and where it will be moving to in the future. We should be able to port security policies along with workloads, immaterial of where they are hosted.

A developer doesn't want us to be in the development path, but we can't leave developers with these new technologies. Operations team has to help development team to get familiar with these new tools. The IT admin has the onus of setting up the firewall and not making sure there are any security vulnerabilities. The developer is not tasked with creating the security policies, they should just consume security groups that are designed by the IT admin. The goal is to have a cloud provisioning solution that has minimal work for the Devops team to do. We have to provide consistent networking and security for applications.

NSX Cloud is an extension of NSX features for public cloud and is not a separate product. When we have NSX loaded for our on-premise environment, we already have 90% of what we need for NSX Cloud. NSX has already abstracted the physical/on-premise network through our logical networking constructs. Now, it comes down to replicating the same for public cloud with NSX Cloud by providing visibility across all clouds for all traffic flows. We can't secure what we can't see. A new VM is created by a developer while the IT admin needs to have a dashboard and some kind of a UI that will make that visible to them. We have to design a unified consistent security policy across on-premise and the public cloud so that we can provide advanced L2/L3 networking capabilities, or if we are creating logical topologies for our on-premise network, then there can be APIs to port network topology from on-premise to the cloud. Management/operation need a single pane of glass for management, since that is at the heart of what we want to do for NSX Cloud. The deployment process or workloads that we use, such as Ansible or whatever else we're using for the deployment workflow for the developer, won't change because we are using NSX. This is one of the key value propositions as we see these options in Azure and AWS—and every public cloud provider, for that matter. However, they come with a bunch of limitations (especially in scale), and that is where NSX differentiates itself. We obviously don't want to get locked into the offerings of one public cloud provider.