Menu

How SDN and Network Virtualization will enable Hybrid Cloud

I know we are just at the beginning of the network virtualization movement but, I have some pretty high hopes for the technology. I believe IaaS Cloud is one of the “killer” applications for network virtualization. A lot of attention is paid to the orchestration that comes to provisioning networks in the enterprise and within Cloud providers via network virtualization. It’s this orchestration that brings a revolution to the relationship between the Cloud provider and Enterprise that’s most compelling to me.

There is no “special sauce” in the technology used to extend the private network to the public Cloud. Traditional protocols are used be it GRE Tunnels, VXLAN, BGP, OTV and etc. The details of the technology don’t matter. It’s the higher level repeated setup and teardown of the connectivity that’s an issue. Automating this capability and making it self-service via APIs is a barrier of entry to a sustainable hybrid Cloud model.

It doesn’t matter if you are building a Cloud aware app that expands from the private Cloud to the public Cloud or if you are a “devops” engineer providing test/dev resources via a self-service storefront. There is a requirement to seamlessly extend your policy driven network from your private infrastructure onto the public Cloud. It’s even more of a challenge and need when you start to offer rich network options in the hybrid Cloud.

This is where the promise of the “Northbound” API’s of network virtualization come into play. This is the “Software” in Software Defined Networking (SDN). The ability to control the logical network via a programmable interface is an enabler for the hybrid Cloud. Even in private Cloud, orchestration is a difficult nut to crack. For example, networking is one of the fastest changing and challenging components in OpenStack. As things settle down and network virtualization matures so does the enterprise capability. I’m looking forward to a more capable private Cloud that is armed with public Cloud elasticity. Network virtualization will help make this possible.

I’ll make sure to check it out. I just looked at the other vidoes you posted on network virtualization. Pretty good stuff.

I think for providers the setup and teardown already makes sense. I think the enterprise needs some help understanding the long term applicability. I don’t know if it’s clear how much setup and teardown is done. I would venture to say it’s mainly setup and never teardown.

The post on multiple firewalls is a pretty interesting concept. You’ve mentioned the concept before but this is my first time reading an extended write up on the concept. I can see someone like CheckPoint who does a good job of centralizing management of multiple FW’s being able to make this work from an administrative perspective.

I don’t think centralized firewall management is actually whole lot less relevant, the whole point is to have each project/deployed application be managed as a whole with very little interaction between them. Each firewall will end up with very little rules in comparison to what many have now.

Things like IDS and firewall logs analyzes need the overview of all the projects, but centralized management of the firewalls, not so much. Obviously the cloud platform has an API to manage the firewalls, so the IDS can take actions on all the firewalls.

I normally have to look at these things from a compliance perspective. I normally have to go into an environment an tell someone like you to give me a list of all (or sample) of all the rules based on the application’s profile. I then take a look at what controls are in place for validation of existing rules. So, even if they aren’t touched there’s a need for centralized oversight for reporting supporting audits.