Cloud computing has been around now for several years. To set the stage for the problem I’ll discuss in this post, here’s what has happened so far:
- Everything was physical, leading to silos of expertise and lots of wasted resources (CPU, memory, network, and disk)
- VMware’s vSphere, Microsoft’s Hyper-V, Red Hat’s KVM, etc., came along and virtualized those four key resources for each VM, but while CPU and memory have virtualized and scaled well, network and disk provisioning have lagged behind. In addition, VMs were manually deployed as requested after networking and storage were prepared and configured as needed. Storage was somewhat simplified by using virtual hard disks, but networking remained a bigger issue as VLANs and other settings needed to be set up.
- Cloud computing came along and automated much of the process for provisioning a new VM, giving control to the end user or administrator or developer (self-service provisioning). While that made VM deployments much simpler and faster, they were often held up with networking issues. Often, the system could pick from a pool of available VLANs, but that really limited scalability (there are just over 4,000 VLANs possible).
Enter Software-Defined Networking (SDN). With SDN, networking can be defined in software instead of waiting for a network administrator to configure the requisite settings and copy those settings to all the affected switches and other network gear. SDN typically utilizes a centralized SDN controller, which can not only make changes, but also propagate those changes to all the necessary devices. Many cloud platforms can integrate with various SDN implementations to make this much more seamless.
We still have the scalability problem though: We may need more VLANs for larger companies, cloud service providers, etc. Another problem is that the next VM a customer deploys may need to be able to speak to a VM already deployed, but those VMs may get created in different physical locations. The VM administrator thinks they are local to each other and assigns IP addresses accordingly, but they can’t communicate as they are physically on different subnets. How to solve these issues?
In a word: Overlays.
There are several overlay protocols available (Q-in-Q, VXLAN, STT, NVGRE, etc.), but they all accomplish the same basic function: to abstract physical locations so that two VMs appear to be local to each other while physically residing anywhere. They also expand the VLAN concept from approximately 4,000 IDs to more than 16 million IDs.
But wait. There’s still the problem of creating tiers of applications on different subnets, antivirus scanning, intrusion detection, load balancing, and on and on. How can those necessary networking and security functions be automated as well?
In an acronym: NFV. Network Functions Virtualization (NFV) virtualizes routers, switches, load balancers, etc. Once virtualized, cloud platforms can create, deploy, manage and remove them as needed. I’ll cover more about that in my next blog post, NFV and How It Relates to SDN.
To summarize until then, SDN and its cousin NFV provide the networking capabilities to truly automate cloud computing.
Related Courses
SDN Essentials: The Future of Networking
SDN Planning Workshop: Demystifying Vendor Solutions