Let dreamers dream what worlds they please
Those Edens can’t be found
The sweetest flowers
The fairest trees
Are grown in solid ground
We’re neither pure nor wise nor good
We’ll do the best we know
We’ll build our house and chop our wood
And make our garden grow
And make our garden grow
These lyrics, by Richard Wilbur, from the song Make Our Garden Grow almost perfectly reflect my current state of mind around SDN. Yet again I came across them because of an animated children’s film, a bit of a constant theme in my
ramblings writing. This time it was Gnomeo and Juliet and a song in the movie by Elton John: Love Grows a Garden. DuckDuckGo didn’t take me to the correct song lyrics (I entered something stupid like ‘garden grow song’ so it’s no surprise) but what a lucky find these were; all wonderfully random and perhaps a reflection on the rest of this article.
We’ve lived through the biggest year of hype around SDN yet; network virtualization, programmable networks, service chaining, ‘new’ protocols, new products, new economics, employment and careers, company about turns and some big money transactions have all been considered, debated and discussed. So far so good… for the marketing and social departments and agencies, for lots of developers with network knowledge, for those who’ve been bought out and made it big or find themselves in the right place at the right time, through luck or skill. Well done to them all and well done Google and Facebook and the other hyperscale companies that have done some amazing things at a scale far beyond what we mere mortals will ever likely do.
But really, where are we now? I’m not jaded or tired of the hype, I’m really just genuinely asking, where are we in 2014? What can I, or any network engineer who looks after a data centre or two, or ten, or 200 branch offices, do today that we couldn’t a year or two ago? What have we gained? What do we still hope to? Where do the cards lie, what do the tea leaves suggest, how to divine understanding from the unicorn droppings?
In this series of articles I’m going to simply give you my thoughts on these and related matters and call out some good articles that have helped form my views or that are just plain useful.
SDN is Dead, Long Live SDN
We all have an idea of the original definition or perhaps purpose of SDN; the separation of the control and data (or forwarding) planes. OpenFlow and a centralized controller typically played a part too but of course, there’s nothing official; no-one ‘owns’ SDN or its definition (although the ONF has certainly tried). Ethan Banks gives a good overview of the industry background that led to the initial excitement around SDN in his recent SDN basics article at SearchSDN.
SDN wasn’t really a new concept anyway, as Ivan Pepelnjak points out in his We had SDN in 1993 and didn’t know it article and I’ve certainly argued the case that many existing products could easily be defined as SDN. The wash and spin of last year followed that thinking to some extent. The very term SDN is, well, Ivan calls it tautological, I’d probably use some rather less polite four letter words. What network device doesn’t use software in the form of firmware, an operating system and drivers? I think everyone agrees it’s a poor term but we’re stuck with it.
As I’ll cover later, this original SDN vision and model (generation one as Cisco’s @jonisick calls it) hasn’t really gained much traction among vendors and without a large perceived cost benefit, as discussed by Greg Ferro here and by CIMI here, users haven’t bought in to what is a pretty radical and disruptive technology either. What started in academia might just stay there a few years more, despite the progress and promise of the OpenDaylight controller and others.
As last year progressed it became clear that ‘generation one’ has been the catalyst and root of far greater and wider thinking (and re-thinking). Mike Bushong covers this progression and what it means very well in his SDN: Capability or Context article and I’d suggest you go read it. Lets not forget Cisco’s ACI and it’s blend of hardware and software components too; whatever the debate around that, it’s a demonstration that vendors have been rather more practical about SDN and are focused on products that don’t require a forklift approach. Tom Hollingsworth suggests we call this SDN2.0.
Are things settled, stable and well-defined? Far from it; it’s all still up for grabs and subject to change (despite what the media would have you believe), but that’s no bad or unusual thing, this is IT right? If a product that’s ‘SDN’ by today’s wider definition meets your needs, go use it if you can, if it doesn’t, don’t. Weigh up the risks against the benefits as you normally would; Ethan Banks offers some further advice here and Embrane’s John Vincenzo makes the point here that whatever the definition, we should really be more focused on solutions.
I’m just happy that as time moves on what’s available improves and my options to do things better grow. Keep calm and carry on, the foundations have been laid.
To me it feels like we’ve gone full circle in many ways; perhaps because the problems we hope SDN will solve still remain, there’s no magic pill in sight. It’s the nature of the networking beast in some ways; it’s distributed and complex, it’s hard to change and expensive to replace. SDN Also brings its own set of challenges, which you might find bring on a feeling of déjà vu. More complexity, difficultly monitoring, achieving resilience and so on, which I’ll explore in a bit more detail later.
Other things look the same too, only with some (great to have) extras that really didn’t need to wait for SDN (and were already available in some quarters but no-one seemed to care.) Puppet and Python support on the Nexus 9000 for instance, APIs everywhere, on box Linux, tcpdump and so on. Whatever the reasons and the past, life should get a whole lot easier from a configuration and management perspective at least. Hopefully this won’t be outweighed by other challenges. This stuff isn’t new, it’s just new in networking.
It’s worth pointing out that I think agents and APIs are more significant than most people realize. If a developer even thought about writing a network application in the past I’m sure they were soon put off my the poor protocols (and support) that could be used, the proprietary operating systems and hardware etc., what a nightmare. The SDN wash and every manufacturer who didn’t have an API suddenly providing one has considerably lowered the barrier of entry and opens the door of opportunity for developers and users alike.
To sum up, mostly everything we needed already existed, it just took SDN to push it into our industry and our minds. Centralised device independent management, implementation, automation and orchestration are really all we need. There are hardware aspects to this story too but I’m not sure they are significant.
Abstractions & Transparent Complexity
The network becomes an application to better serve the applications that run upon it. The virtual network relies on the physical network, the physical network might rely on a service provided over the virtual. A virtual appliance becomes the gateway between the physical network and the virtual overlay network. As we add layers of abstraction (or anything for that matter) to the network we add complexity. The abstraction makes that complexity transparent, it hides it from you. You can’t see it (QoS and ECMP features with overlays are a sort of exception) but it’s there.
This presents challenges in a whole host of areas from monitoring to troubleshooting, but I’m not sure it’s a significant issue. There are many, many existing abstractions present in any network or even computing device. Who really cares about the firmware on a SSL acceleration card in a load balancer, the same for a NIC on a server or network interface in a switch. As long as the complexity remains transparent and doesn’t need your attention, as long as it remains abstracted, we’re good. I know those examples are poor and a network is very different to single device or NIC but the point still mostly stands.
As ever in the network field, we’ll probably find we need to dive in a bit deeper and understand the complexity underneath the abstraction in more detail than others. We’ll need to be more cautious, keep a closer eye on things and be ready to troubleshoot the next application failure, which isn’t caused by the network. Does your virtual topology match your optimum physical topology. Do your virtual appliances run failover/redundancy protocols independently of the hypervisor’s own? How do you marry together monitoring of your physical and virtual networks. Martin Terpstra considers some of this here and I look forward to seeing solutions to challenges like these.
Assuming there’s interest I’m planning to cover Careers, Monitoring, Service Chaining, NFV, Cost, Appliances, Resilience and more in further articles.
Comments always welcome.