An Example of an App-to-Cloud-to-Flow Ecosystem

I mentioned in a blog last week that there was some important progress being made in the fusion of cloud development and deployment—what the industry calls “DevOps”.  There are also important developments in the area of cloud networking, another topic I’ve blogged about recently.  One indication of a unified approach to these critical problems was announced today by Big Switch at 11 AM EST, too late for my normal blog.  We’re going to talk about the Big Switch Open SDN announcement here, but first I need to summarize why I think it’s important.

The cloud has preoccupied nearly everyone, but not much attention has been focused on how the cloud changes the model of network services.  In the past, we obtained services by linking OVER the Internet to a URL that represented the capability or information we wanted.  On the surface, the cloud model doesn’t seem too different.  We have stuff hosted “in the cloud” but the stuff is still accessed via a URL.  Sure there are issues that are associated with the way that a dynamic resource is mapped to that URL, but hey it’s not rocket science.  Look deeper, and you see more difference, perhaps enough to create a revolution.

In a cloud future, users’ needs are more dynamic too.  Imagine a Siri-like process front-ending a dynamic resource pool and you get a glimpse of what’s coming.  The user makes a request of a friendly agent in the cloud and the agent marshals all sorts of processing power and information to fulfill it.  That information isn’t delivered directly to the user, but through the agent, and the information paths are internal to the cloud and not external to the user.  That’s cloud networking; the separation of cloud-flow from user-flow.  Content delivery has already taken to a similar model; a CDN is a set of caches (pushed increasingly forward toward the user) and an interior network that delivers data to those caches.  Users connect not with distant content hosts but to local cache points.  It’s a service-network and service-access dichotomy; like the cloud.  Inside the CDN are a limited number of (you got it!) flows.

And enter another flow, OpenFlow.  OpenFlow is an explicit-connection model of networking where flows are authorized not automatic.  For the whole universe of the Internet it doesn’t scale, but for the flows inside a cloud it’s perfect.  Even VPNs likely fit will in the OpenFlow model, and data center networks darn sure do.  The cloud validates OpenFlow, providing that you can get an OpenFlow cloud model built in the real world.

Architecturally it’s not hard to see how to do that, and to create a utopian model of linking applications to explicit network flows.  A switch controller simply creates forwarding rules; that’s the OpenFlow model.  In practice, though, you obviously need to worry about things like how you manage persistent flows, how you create VPNs or VPLSs, how your applications actually drive policies—you get the picture.  The point is that there is a lot of stuff that has to be added to basic standards to create a flow-based future network, and the process has to start with a conceptualization of the problem at an ecosystemic level, from apps to flows.

Some of that could in theory be provided by a model of cloud networking, because the cloud problem is that resources have addresses but applications can’t have them, at least until they’re assigned to resources.  There’s a virtualization layer needed here that players in the OpenStack area, for example, have recognized and are attempting to address through work like Melange and Donabe.  Here we have policies linked to applications and provisioning, but we need to link that to network flows.

Sound like two faces of a common problem, separated by a logical inch or so?  Sound like something we need to get solved?  If you’ve followed my blogs, you know that’s what I think, which is why today’s announcement is important.

Big Switch is a startup player in OpenFlow, one of the early ones in fact.  We wrote about them in our Netwatcher OpenFlow piece in October 2011, in fact. Then, they were a controller play.  What they’re now doing is defining a broader ecosystem, an open structure (called, not surprisingly, “Open SDN”) that is based on open standards, open APIs, and open source.  Their own business model, like that of other open-source players, is to provide professional services and a hardened version of some software for commercial application.

The Open SDN model is a flow from application to switch, focusing on how you build a practical flow network and sustain its operation.  It handles things like multi-tenancy, essential for the cloud, on-demand or policy-based flows, and best of all it handles integration with things like OpenStack.  While Big Switch isn’t asserting direct compatibility with all of the various OpenStack network-related projects, it does have Quantum project involvement and a submission there.  Quantum is an open network-service offshoot of OpenStack’s inherent vision that the network is also a resource in the cloud, and it could be linked to Melange and Donabe for a more cohesive DevOps strategy.  The point is that this makes Big Switch arguably the first player to link all the way from the cloud-resource vision down to an OpenFlow switch.

My view is that all of this is really just the tip of a cloud-network-and-NaaS iceberg.  If you can do cloud networking, then you can do everything that’s part of the cloud, and since the cloud is the abstraction of computing and network-delivered services for the future, you can do what the future needs.  It would be easy to get all excited over the pieces of the network of the future, but we can’t build it by thinking at the pieces level, which is why there’s a real need for a top-down model that links apps to clouds to flows.  At least we now have one such model.

One model doesn’t make a market, usually.  We’re likely to have a lot more action in this space.  As I said in an earlier blog today, Cisco is now rumored to have an OpenFlow spin-in on the drawing board, but I think that’s likely to be a hardware play.  The stuff that acts as the bridge between the application, the cloud, the resource control, addressing, and information flows could be really critical as a competitive point for vendors in the networking space, and even for OSS/BSS developments.  Thus, Big Switch may be like a tiny magician who has pulled a 900-pound gorilla out of a hat instead of a fuzzy bunny.  Can they control their own fate here?  We’ll see.

Leave a Reply