Response: Open Networking: The Whale That Swallowed SDN

Art Fewell, whose views I greatly respect, has written a very good post on Network World entitled “Open Networking: The Whale That Swallowed SDN“. It’s a great historical summary of SDN 2011-present, with some noteworthy areas of concern. I agree with the general thrust of Art’s thesis, yet at many points I found myself thinking “Yeah, but…” I started to write a few comments on the Network World page, but the comments turned into a page, so here we are.

Here’s what I really liked in Art’s piece:

  • Art’s observation that some of the working groups are still caught in 2011 rhetoric is spot on. It’s easy to point fingers and throw rocks, but acknowledgement of the progress made by those who have to execute the original vision is absolutely warranted at this point.
  • The fact the average enterprise is largely unrepresented in these conversations is certainly a problem. There’s a chicken-and-egg question to be kicked around there, but certainly if SDN only gets discussed in fairly unique contexts, it will remain something for most to think about at some point in the indefinite future (if ever). There’s a risk of the promise of the movement fizzling out if it’s confined to corner cases.

Here’s where I differ with Art, not with regard to his observations, but with his conclusions, which seem to come from a curiously hardware-centric perspective. Let me explain:

“Cisco and VMware for example are building comprehensive self-contained SDN/NFV ecosystems that are clearly separate and distinct. Unlike x86 where an investment in software does not create a dependency on an underlying hardware (or virtual hardware) provider…”

That’s because the dependency, the chokepoint, is the OS. It’s not that x86-based application ecosystems aren’t tied to a single vendor (they are–which is why MSFT has faced Anti-Trust so many times), it’s just not tied to a hardware platform. That doesn’t really make it “open”, from either a dev or user standpoint; it just allows the user to optimize the hardware purchase separately (from a still-limited number of options, it must be said) from the choices to be made between competing applications.

“If a vendor’s software doesn’t align with a business need, simply switch out the software leaving the considerable cost and complexity of the physical network, cable plant and topology in place, drastically reduc[es] consumer exposure to the risks of new technologies.”

Again, only from a hardware perspective. And hardware has always been less sticky than software, as discussed above.This is especially true of software that is an interaction point with a human user, and even more so if it governs processes, whether IT management applications or business software, which is why the new form of lock-in is not the NOS, but the layer above–the controller. Once you have rules and processes defined in ways that work within the context of one type of controller, it will be virtually impossible to swap out the software non-disruptively. The Big 4 infrastructure management vendors have been banking on this fact for years.

This does *not* mean that even proprietary controllers can not be developed to if vendors agree to northbound API standards. It is conceivable that a vendor-independent app ecosystem could be built on the foundation of such standards–though I concur that the temptation for any vendor will be to create apps that work especially well with their platforms. All this development work has to be monetized somehow.

“open networking is not the whale that swallowed SDN; SDN was never more than a piece of this much larger goal.”

I agree with second clause, though that was less explicitly articulated by all concerned three years ago than  it is now. Which is why I disagree with the first clause–I think “open” is rapidly engulfing “SDN”. I know quite a few people–enterprise people–who have built their careers around Cisco, for example, but are increasingly convinced “open” is the way forward. This is partly why we keep seeing the debates about the continued value of the CCIE in particular. More than one analyst report has OpenDaylight taking a majority share in the controller market as it matures and while deployed infrastructure management has a very long tail, the energy around OpenStack makes that case fairly compellingly as well.

Overall, I’m more optimistic about this shift than a cynical chick like me normally would be. I think more inclusion of typical enterprises and their concerns is critical to getting this whole thing past the tipping point. As an industry we are frequently guilty of being caught up in tech for tech’s sake with little regard to the context in which the technology would live and the needs of the people who would use it. (Another Network World article on Google Glass provides another vivid illustration of this problem.) But I disagree with Art that the promise of Open Networking is being lost. Fortunately, I’m sure he’d love to be wrong.


2 comments on “Response: Open Networking: The Whale That Swallowed SDN

  1. Great response Lisa! I really dont think we disagree in any area, at least that you have covered.
    I think the mainframe analogy is very powerful and very meaningful, but the reality is that its not 1980 anymore, everything is different. So the key area I wanted to highlight is that regardless of any similarities or dissimilarities of today’s epochal change, I think the key is that it delivered horizontal integration to a much greater extent than the paradigm it was replacing.
    And I think it is sad that here we are 30 years later trying to fight for the same baseline when we should be going much farther. All of the great open things and analogies we think about with mainfraime -> x86 dont fully mesh when you consider the big proprietary OS at the center of it – there was a big step in the right direction that didn’t go far enough. And now there are a lot of things that werent in play back then, software lock-in is a huge beast and I feel like some point to hardware to distract others from noticing just how much vertical integration we have amassed in some of these big software suites. It is apparently a horrible thing if a hardware vendor offers a vertically integrated stack yet if one makes a full faith virtual representation of that hardware it can be completely vertically integrated and thats not a problem? Bollocks.
    I also, despite my concerns share your overall optimism, and I think that is largely because, the best that consumers get from paradigm’s is related to the technological capabilities of a given point in time, and I think today the technology and the groundwork and the possibilities are all there to really do something much more open, not just for networking but also for OpenStack, NFV and disaggregated platform services. A few years ago, almost nobody was that good at strict SOA, but today consider integrations like VMware’s Cisco vswitch integration, really a great showcase of how mature a SOA model can be. And more than that now as API mashups and other web application frameworks make significant evolutions at a rapid pace. I think the groundwork is in place for a lot of great things.
    One of my other favorite articles I have read recently (also from Tom Nolle) was this post on how Amazon is disaggregating platform services in direct opposition to “Cloud OS” type packaging:
    I just think this is really an exciting direction, and it also begs the question, what exactly is the difference between NFV applications and network service applications and platform service applications? If we were to aggregate all of the platform services needed within a given enterprise private cloud and say that there would be a single, common orchestration mechanism for all platform services – including networking and L4-7 services – that would paint a much larger competitive battlefield than a traditional network-centric view may reveal, much bigger competitive dynamics than those that left networking in a monopoly for the past years, and I hope that really helps things become more open. I hope we can keep things as disaggregated and loosely coupled as possible.
    In the past it was a much bigger technology problem to combine the benefits of tight vertical integration with loose coupling between layers, today we have seen this is really a much easier thing with newer web technologies, and SOA is usually even followed (or attempted) between different groups in the same company these days.
    In any case it is important to keep our eye on the ball as SDN/NFV ecosystems take off, these could become completely open, they could ease lock-in by using common service description languages with an ability to translate policy requirements between stacks, or it could be many varying degrees better or worse.
    There are 1000 degrees to which network and cloud systems could become more open or more closed and it seems vendor interest would be to keep lock-in high, but all of the competitive dynamics seem to have really helped the consumer thus far. But that alone leaves me feeling nervous; I am not entirely comfortable that competitive factors alone will produce all the best possible outcomes for enterprises, particularly without them being well represented in standards battles. That was a lot of my motivation behind the blog, I would like to see more concern, participation and vocalization among enterprise consumers, we need more, vendor power is a huge check that needs a huge balance. I think disaggregation, as much as is reasonably possible, really adds to the power of the consumer, at one level at the hardware abstraction, and to your point we need to enforce similar abstractions across software systems, platforms etc. It is great to see so many possibilities on the table today – we just need to keep our eye on the ball and keep pushing forward 

    • “Software lock-in is a huge beast and I feel like some point to hardware to distract others from noticing just how much vertical integration we have amassed in some of these big software suites.” < Well said.

      I would also say that one person's "lock-in" is another's "convenience", so rather than the getting wrapped around the axle about lock-in FUD, a more useful approach to product evaluation would be to consciously think through where and why convenience trumps flexibility within one's architecture, and decide the timeframe for which that will likely remain the case.

      With regard to "loosely coupling" different layers of a vertical stack–I like what Dan Pitt had to say at ONS about a "narrow waist" where standardization must happen (see, but even more what Prodip Sen said in reply: "It’s about the reference model, which will dictate all of the necessary abstractions.”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s