Rawpixel - Fotolia
One of the complexities of the cloud is the fact that the cloud model has so many variations -- public, private, hybrid -- and many implementation options driven by multiple cloud providers and cloud software vendors. One common element in all clouds is cloud networking, which is always essential in connecting cloud resources to users, and increasingly for making connections among cloud resources and providers. Any enterprise that's building a cloud strategy has to develop a cloud networking strategy, and that strategy has to be versatile enough to accommodate rather than limit cloud choices.
A good place to start is with the notion of network as a service, or NaaS. Public cloud services include NaaS features implicitly (the Internet is an "access NaaS" for most public clouds) or explicitly (with VPN capabilities), and private and hybrid clouds will almost always control network connections using a NaaS model.
NaaS, for a cloud network builder, is an abstract model of a network service that can be at either Layer 2 (Ethernet, VLAN) or Layer 3 (IP, VPN) in the OSI model. A cloud user defines the kind of NaaS that their cloud connectivity requires, and then uses public or private tools to build that NaaS. NaaS can define how users access cloud components, and also how the components themselves are connected in a private or hybrid cloud.
The best-known example of NaaS in the public cloud space is Amazon's Elastic IP address service. This service lets any cloud host in EC2, wherever it is located, be represented by a constant IP address. The Elastic IP NaaS makes the cloud look like a single host. This is an example of an access-oriented NaaS application.
NaaS as cloud connectivity
In the private cloud, the most common example of NaaS comes from OpenStack's Neutron APIs, which let users build models of network services at Level 2 or Level 3 and then add their virtual machine (VM) instances to these models. This NaaS model builds inter-component connections that connect cloud application elements with each other, and also defines internetwork gateways to publish application services to users. Not all private cloud stacks have NaaS or Neutron-like capabilities, though, and where they don't exist it will be necessary to use management/orchestration tools, popularly called DevOps tools, in the cloud to build NaaS services in a private cloud deployment.
For hybrid clouds -- the direction most cloud users expect to be going with their own cloud plans -- NaaS is likely to be a three-step process. First, you'll need to define the public cloud NaaS service, and then the cloud connectivity you'll need for your private cloud, and finally the bridge between them. In most cases, this "hybrid bridge" is a gateway between the two NaaS services in your cloud, but it's often a gateway that operates on two levels. First, it has to provide an actual network connection between the public and private cloud, which in many cases will mean setting up a router device or software-based router. Second, it has to ensure that the directories that provide addressing for cloud application components (DHCP to assign addresses, DNS to decode URLs to addresses) are updated when components are deployed or moved. This is actually a part of cloud integration, and it may be done using DevOps tools or commercial products for cloud integration.
Cloud networking is critical for the cloud's success, and approaching it as the union of NaaS domains is a good way to plan and implement the necessary elements, and keep them running optimally for efficient cloud use.
Separating real NaaS use cases from wishful thinking