I was recently asked by a customer to give my perspective on a number of topics including Software Defined Everything. I will be making a set of blog posts on this and other industry perspectives in the coming weeks. For now – let’s talk Software Defined Everything!
For those running in IT circles there are many different categories of “Software Defined.” Today there is software-defined networking (SDN), software-defined storage (SDS), and software-defined data center (SDDC) to name a few.
One of the best lines that I have ever heard was from Carl Eschenbach – VMWare’s President and Chief Operating Officer – “Software doesn’t run on software the last time that I checked!” This is very true. However software does give us a degree of nimbleness that can ultimately help with solving the business problems. In fact if you look at the Cloud Computing models that are out there today – they are largely due to the agility that comes with software. At a recent event I saw a slide from IDC that accentuated the value of software and openness (recreated below)
The reality is that software coupled with Cloud Computing has enabled new business models like no other. As I visit with many different cloud providers even their own models focus on the ability to capitalize on agility that they have and their competitors don’t. Specifically customers tell me that Software Defined Networking is about “better orchestration and operational efficiency.” This is also synonymous to openness to choose the best solution in the network. Let’s face it – no single vendor is capable of being #1 in all areas.
The other idea around SDE is that you can completely abstract the software from the hardware. While this has been tried with OpenFlow, we haven’t seen it take off in the general enterprise. We also see this with the idea of “white box” switches that run a version of a Network OS. The challenge I see here is how do you handle problems. For instance –
Quanta LY6 switch has memory parity error _soc_mem_array_sbusdma_read: L2_ENTRY.ipipe0 failed(ERR)
Is this a hardware error or a software error? Obviously this is on a Quanta white box switch. How should the software react to this parity error? Is it a single event upset or a more troubling error? In the end parity errors suck! Yes I know that cosmic radiation taking your network down sounds like a story in a science fiction novel, but they do happen. In fact in networks with 15-20K devices they are likely to happen to the tune of 1-2 a week and that is assuming that you have built the device to be as protected as possible. The reality is that software needs to account for these errors and minimize their impact. Otherwise your switch is rebooting or worse yet – hung! So as much as we would like to completely have the hardware abstracted from the software in network switches, the blast radius is often too large – where if you lose a TOR switch at least 48 physical hosts are affected. Worse case the switch having a parity error causes instability elsewhere. Think for a second how much of an impact a chassis that experiences a SEU in the control plane would have.
Lastly a recent article in The Register declared that “software-defined networking is making users grumpy rather than delivering promised benefits.” I have my opinions as to why this is the case and I will share some of that insight with some facts from a recent Gartner poll in the future.
I came back to networking after a hiatus where I spent time in Service Management and Software Architectures at a customer. SDN to me was the perfect storm where a highly programmable network could be achieved without the archaic ways of old with “screen scraping” and antiquated SNMP. I once had a problem in my Cisco days where we wanted to have two links out of a remote office. One link was a DSL link and the other a T1 link. We wanted the delay sensitive traffic to traverse the T1 and backup/bulk traffic on the DSL link provided everything was up. We wanted the mission critical traffic to switch to the DSL link if the T1 was down. In order to achieve this with the CLI, I needed to do GRE tunnels with IPSEC tunnels on a secure T1 and the DSL circuit. Sure we made it work, but troubleshooting it was somewhere next to impossible. The real solution would have been a simple “If Then Else” statement in the logic of the device – but I couldn’t do this because of the CLI. Now as we approach 2016 we are seeing SD-WAN solutions solve this problem and more.
To me Software Defined – is all about programmatic access to be able to extend and grow a solution based upon your needs. Yes this means APIs and even SDKs for every solution. At the end of the day, the customer knows how they want to use a solution. You never know, sometimes customers actually do some pretty cool things that you never expected.
Have a Happy Day!