Amidst all the hype around OpenFlow and then software-defined networking (SDN), what is getting lost (as things often do) is the fundamental problem that we have collectively set out to solve for cloud computing: the rapid deployment of applications onto networks. Bringing IT and IP together to realize DevOps. To provide true business agility with operational simplification without sacrificing what CIO's care about most: speed and security with full control and visibility across all their workloads, in both private and public clouds.

Instead, all the attention is on whether OpenFlow and OVSDB are supported on the virtual switches and/or hardware switches. Whether there is separation of control plane and data plane. And whether a certain encapsulation is supported. Additionally, some vendors seem eager to be turn back the clock and offer solutions that the networking industry has already experimented with and abandoned as suboptimal. For example, virtual routers for each tenant running independent control planes, or dedicated servers for replication of broadcast and unknown traffic at Layer 2, or new protocols for federation of controllers. Better solutions are not only available, but already deployed in large scale for the past decade in the WAN.

And while debate on relative merits of the nuts and bolts of the solution rages on, the DevOps teams and IT users who want rapid deployment of applications on the cloud couldn't care less. Their prime concern is simple: “What has your network done for my application lately?”

With that in mind, let's talk about what the network must do for the applications.

Sales wants to add web servers dynamically and quickly as hits on web servers increase due to a hot-selling product during the holidays. Product management wants to introduce new applications quickly to get valuable time-to-market advantage over competition. Developers need the ability to instantly deploy applications that they have developed, so they can complete timely testing and debugging.

While virtual compute resources can be instantly powered up as needed through a self-service portal, network provisioning for those resources is another story. Unfortunately it takes days (if not weeks or months) for network connectivity to be provisioned. The datacenter network has fallen behind. For the promise of cloud computing to be realized, it is critical for the networking industry to deliver a way to automate existing data-center networks and make them as consumable as the compute has become.

For applications to be deployed rapidly, all of the appropriate servers and appliances within and across data centers must be connected together at Layer 2 and Layer 3 with Layer 4 enforcement, regardless of whether they are virtualized or bare metal assets. This means the network must be highly automated. For users to on-board applications rapidly, service templates that draw on proper network abstraction are imperative, making it easy to specify network behaviors in simple, IT-friendly language. In addition, the ability to have the same consistent treatment for the application in terms of connectivity, QoS, and most importantly security within and between datacenters with proper end-to-end policy and control framework is essential. Finally, network visibility with analytics capability is crucial for measuring and reporting on the behavior of applications, for performing show-back & charge back, and most importantly for troubleshooting the network.

Network automation is the key to making data-center networks self-service. The networking industry was presented a very similar challenge of automation for mobile networks, and it delivered. Today, mobile devices can be connected instantly anywhere, any time and to any network. Why can't we do the same for virtual machines? If we can maintain the same mobile ID and have the same SLA consistently enforced anywhere, any time, over any network, then why can't virtual machines have the same IP address and move anywhere within or across datacenters, or over to a private cloud over the WAN, all under a common policy framework?

Imagine the following: A directory server with repository of service templates. Oracle applications, Microsoft Lyncs applications, SAP applications, disaster recovery applications, Web Tier applications, and so on. IT admin customizes the relevant application template, attaches compliance and security rules. IT admin attaches permissions on usage by users. IT admin now publishes the templates for use in a directory. That simple.

Applications based on the published service templates can then be deployed multiple times by permitted users across all workloads and all data centers instantly. Deployed in seconds, with full enforcement of security and all desired network attributes, without requiring any device-by-device configuration. Fully automated, eliminating any chance of errors.

Underneath, the network is doing the heavy lifting to ensure that each virtual machine (VM) for each application is “plumbed” correctly: that it is in the right network, it is assigned the correct IP address, and that the virtual switch that the VM connects to is programmed with all the necessary forwarding information. The VM's reachability information is then conveyed to all other relevant VMs for that application. This is all done automatically and instantly when the VM comes up – just like in the mobile network. The network does this not for few hundred VMs or a few hundred tenants, and certainly not within the confines of a single data center, but rather for millions of VMs and thousands of tenants within and across data centers and over WANs to include all branches of all tenants. Automated provisioning of the network is the only way it is possible to support this level of scale and ensure that the provisioning is timely and error-free. This is why it is critical to have the right networking engine powering an SDN solution.

CIO's see the potential of cloud in the business agility it can offer. However, gains in business agility cannot come at the cost of losing control over users, applications, and sensitive data. It is imperative for CIOs and IT admins to have complete control over their slice of compute and network regardless of the type of workload (virtual or physical) and regardless of the type of cloud (private or public). This guarantees that any user can only access and consume resources based on the permissions granted, and that any application that is deployed is in line with the security and compliance rules set by the CIO and the IT admin. Without this control, enterprises are unlikely to move to cloud computing in a truly meaningful way.

How are my applications performing? How hot is my network running? Where are the hot spots in the network? What are the proactive and reactive operations, administration, and maintenance (OA&M) tools available to me at the application level, at the network level, and at the tenant level? What tools are available for show-back and charge-back, by tenant by application? Bottom line: How do I deploy, operate and manage my private and public cloud infrastructure as one?

These are the key questions that CIOs and IT admins want answered. Rich OA&M tools at the application layer and the tenant layer, accompanied by analytics capabilities that allow for collection of data that measure the behavior of each application, are imperative for any solution to be complete.

To truly fulfill the promise of cloud computing, the compute and network have to be in sync. For enterprises to adopt cloud services, it is imperative that the network can be consumed as rapidly as the compute. To provide true business agility and help enterprises deploy applications very rapidly, the network must provide abstraction and automation along with control and visibility for all applications of all tenants, and it must do this within and across data centers.

In the end, if it is not dead simple for DevOps teams or users to deploy applications instantly through a self-service portal on any cloud, any time, they want we haven't solved anything.

After all, it truly is (all about) the application, stupid.