This presentation was actually co-hosted by Guido Appenzeller, the CTO for the NSBU and Scott Lowe who hardly needs any introduction anymore. In this session they elaborated further on how NSX will bridge clouds together and gave live demonstrations on how it all works!
Note: I scheduled this session without actually knowing what to expect. Often these kind of sessions tend to be loaded with marketing talk which doesn’t interest me in the least. However this session in reality was a true gem.
The guiding principles
The guiding principles for a multi cloud network are that software really has to be independent from the hardware, the software had to evolve to a new model and some form of cloud networking is needed of course.
Let’s have a look at the evolution.
We have come a long way: from mainframes to the PC revolution and today we have the cloud which basically runs on software. While the compute revolution was happening fast and hard, networking evolution didn’t change that much. Devices have changed but how networking works now is basically still the same as it was 10, 20, 30 years ago.
Recently though networking has changed, networking has been moving from a hardware platform to a software platform and network virtualization was born. Although we still need a physical network a lot of the networking can be done in a software defined overlay network. If you look at what is happening on the enterprise level VMware’s NSX is taking over the software layer in spades while ACI is taking over hardware platform. Although there is a good business case why you could use ACI and NSX together, ACI is not the subject in this post so we will switch back to the software layer.
But how did the applications evolve? Traditionally an application used to run on a single server but nowadays applications are build on top of different layers, spanning multiple containers, networks and databases. Applications now are distributed and are actually micro services running from or in containers. These new apps are called Cloud Native Apps.
The most secure way to run containers is by nesting them into a VM, in that way containers can be protected in a better way. But how can you connect them? How can you provide networking for containers? You can accomplish this by creating a networking container (logical switch). For example an NSX gateway.
Scott Lowe from his end presented the integration between containers and NSX in a live demonstration. He demonstrated how you can create new NSX networks (Logical switches) and objects from Kubernetes and Docker command line. After running the necessary commands new containers had been created a new Logical switch had been created and the containers had been added to the right firewall policies on NSX. What had been configured for networking in Docker and Kubernetes was indeed created as an object in NSX and visible in the NSX manager as well! Total awesomeness!
Cloud networking means you are not responsible for the underlying hardware (which would be owned by cloud providers, networking providers, etc) but you would still be responsible for the networking because ultimately your overlay network connects your data center objects.
So what are the difficulties with multi-cloud networking?
Each cloud provider has their own networking apps which are not always the same apps as the apps the competitors use. This makes integrating networking across clouds very hard unless you have another layer which you can use as a bridge. For example, if one provider has a firewall app but the other provider does not, how will you firewall your app across clouds?
NSX bridges that gap!
So how can NSX bridge that gap? Each VM will have an agent installed and OVS. Now NSX can be deployed in the cloud as a service on top or in a VPC as a gateway and as such can you create an overlay network across clouds. The NSX manager ties in to all components: agents, gateways and other NSX managers which have been installed.