There’s been some potential progress on a couple of fronts in the cloud, SDN, and NFV space (a space I’m arguing will converge to become the framework of a “supercloud”). One is the introduction of Red Hat’s OpenShift PaaS framework as a commercial offering, and the other a proposal to converge two different OpenFlow controller frameworks into one that would provide for a “service abstraction layer”.
Since I think the cloud is the driver of pretty much everything else, we’ll start there, and with its most popular service. IaaS is a bare-bones model of the cloud, one that provides little more than VM hosting and thus really doesn’t change the economics of IT all that much. I’ve been arguing that cloud services have to evolve to a higher level, either to accommodate developers who want to write cloud-specific apps or to broaden the segment of current costs that the cloud would displace. In either case, we need something that’s more PaaS-like. Developing cloud-specific apps means developing to a cloud-aware virtual OS, which would look like PaaS. Displacing more cost means moving up the ladder of infrastructure from bare (if virtual) metal to a platform that at least envelopes some operations tools.
Red Hat’s OpenShift is the latter, a platform offering that’s designed to address what’s already the major cloud application—web-related application processing. You can develop for OpenShift in all the common web languages, including Java, and the development and application lifecycle processes are supported throughout, right to the point of running. OpenShift currently runs as a platform overlay on EC2, which puts IaaS services in what I think is their proper perspective, the bottom of the food chain.
OpenShift isn’t the end of the PaaS evolution, IMHO. I think Red Hat will be a player in deploying further PaaS tools to create a more operationalizable cloud that’s aimed at the web-related application set. The question is whether they’ll take any steps to advance to the other PaaS mission, the creation of a virtual cloud OS. In some ways, Java and perhaps some of the other popular web-linked languages are suitable candidates for distributed package development. What’s needed is a definition of platform services which, added to either IaaS or a development-enhanced PaaS, would create a virtual cloud OS. We actually have a lot of that today, particularly if you add in the OSGi stuff.
OSGi stands for Open Services Gateway initiative, and it’s an activity that implements what many would call a Service Abstraction Layer (SAL), which is the other piece of my potential good news. SAL is an architecture that offers a Java-and-web-friendly way of creating and using Java components in a highly dynamic way. It’s been around for perhaps a decade, and with concepts like SDN and NFV it could come into vogue big time. In the OpenDaylight context, the concept seems to have this original meeting and another besides; a notion that the SAL would provide a common semantic for talking to control elements or drivers (“plugins”) that would then let these relate to the rest of OpenDaylight in a consistent way. You could argue that the models in Quantum are an abstraction, for example.
One of the potential advantages of SAL in OpenFlow Controller missions is creating an organized way to modularize and enhance the controller by providing an easy exposure of low-level features and the binding of those features upward to applications. Without some common set of abstractions, it’s doubtful whether a controller could use all of the possible southbound protocols in the same way, and variability in how they had to be used would then percolate upward and make it harder to build applications without making them specific to the control mechanism at the bottom. Thus, in theory, this SAL thing could bring some structure to how the famous northbound APIs would work, and it could also allow for the easy support of multiple lower-level control protocols rather than just OpenFlow.
The proposal is to make OpenDaylight a three-layer controller architecture with the low layer being the “drivers” for the control protocols, the middle layer being “network services” (kind of the platform services of SDN) and the higher layer being the applications. SAL would fit between drivers and network services and would create a dual OpenFlow/OVSDB interface. Presumably it would be easy to add other control frameworks/languages. This sort of structure seems to play on the benefits of the Cisco-contributed code, which (obviously) can be enhanced to support the ONEpk API.
The biggest impact of this change, if it happens, would be to make OpenDaylight more of an SDN controller and less of an OpenFlow controller. It doesn’t destroy OpenFlow but it would make it easier to develop control alternatives that might make more sense. Recall that OpenFlow was really designed to be an easy way of communicating ASIC-level forwarding rules to hardware, something that is probably not really necessary as SDN evolves. Why? Because likely there would be control logic in the devices that could perform a compilation of forwarding rules from any reasonably expressed structure. That would make it easier to apply SDN principles to protocols/layers that were opaque from a normal packet-header perspective. Like optics.
All this makes one wonder just what Cisco has in mind here with OpenDaylight. As I commented earlier, the controller code seems quite good, and these new concepts seem to advance the controller toward the point where it might actually provide the basic level of utility needed to drive an OpenFlow “purist” network model. But I want to point out that routing and switching are still “applications” to the controller, and most of what we take for granted in networking is thus still up in the Frozen Northbound…APIs, that is!