{"id":185,"date":"2015-11-30T17:24:57","date_gmt":"2015-11-30T17:24:57","guid":{"rendered":"http:\/\/www.darrinthomason.com\/?p=185"},"modified":"2015-11-30T17:24:57","modified_gmt":"2015-11-30T17:24:57","slug":"software-defined-everything","status":"publish","type":"post","link":"http:\/\/www.darrinthomason.com\/?p=185","title":{"rendered":"Software Defined Everything"},"content":{"rendered":"

I was recently asked by a customer to give my perspective on a number of topics including Software Defined Everything. \u00a0I will be making a set of blog posts on this and other industry perspectives in the coming weeks. \u00a0For now – let’s talk Software Defined Everything!<\/p>\n

For those running in IT circles there are many different categories of “Software Defined.”<\/span>\u00a0Today there is software-defined networking (SDN), software-defined storage (SDS), and software-defined data center (SDDC) to name a few.<\/p>\n

One of the best lines that I have ever heard was from\u00a0Carl Eschenbach – VMWare’s President and Chief Operating Officer – “Software doesn’t run on software the last time that I checked!” \u00a0This is very true. \u00a0However software does give us a degree of nimbleness that can ultimately help with solving the business problems. \u00a0In 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. \u00a0At a recent event I saw a slide from IDC that accentuated the value of software and openness (recreated below)<\/p>\n

\"StartingTech\"<\/a><\/p>\n

The reality is that software coupled with Cloud Computing has enabled new business models like no other. \u00a0As 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. \u00a0Specifically customers tell me that Software Defined Networking is about “better orchestration and operational efficiency.” \u00a0This is also synonymous to openness to choose the best solution in the network. \u00a0Let’s face it – no single vendor is capable of being #1 in all areas.<\/p>\n

The other idea around SDE is that you can completely abstract the software from the hardware. \u00a0While this has been tried with OpenFlow, we haven’t seen it take off in the general enterprise. \u00a0We also see this with the idea of “white box” switches that run a version of a Network OS. \u00a0The challenge I see here is how do you handle problems. \u00a0For instance –<\/p>\n

Quanta LY6 switch has memory parity error _soc_mem_array_sbusdma_read: L2_ENTRY.ipipe0 failed(ERR)<\/p>\n

Is this a hardware error or a software error? \u00a0Obviously this is on a Quanta white box switch. \u00a0How should the software react to this parity error? \u00a0Is it a single event upset or a more troubling error? \u00a0In the end parity errors suck! \u00a0Yes I know that cosmic radiation taking your network down sounds like a story in a science fiction novel, but they do happen. \u00a0In 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. \u00a0The reality is that software needs to account for these errors and minimize their impact. \u00a0Otherwise your switch is rebooting or worse yet – hung! \u00a0So 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. \u00a0Worse case the switch having a parity error causes instability elsewhere. \u00a0Think for a second how much of an impact a chassis that experiences a SEU in the control plane would have.<\/p>\n

Lastly a recent article in The Register<\/a>\u00a0declared that “software-defined networking is making users grumpy rather than delivering promised benefits.” \u00a0I have my opinions as to why this is the case and I will share some of that insight with some facts from a \u00a0recent Gartner poll in the future.<\/p>\n

I came back to networking after a hiatus where I spent time in \u00a0Service Management and Software Architectures at a customer. \u00a0SDN 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. \u00a0I once had a problem in my Cisco days where we wanted to have two links out of a remote office. \u00a0One link was a DSL link and the other a T1 link. \u00a0We wanted the delay sensitive traffic to traverse the T1 and backup\/bulk traffic on the DSL link provided everything was up. \u00a0We wanted the mission critical traffic to switch to the DSL link if the T1 was down. \u00a0 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. \u00a0Sure we made it work, but troubleshooting it was somewhere next to impossible. \u00a0The 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. \u00a0Now as we approach 2016 we are seeing SD-WAN solutions solve this problem and more.<\/p>\n

To me Software Defined – is all about programmatic access to be able to extend and grow a solution based upon your needs. \u00a0Yes this means APIs and even SDKs for every solution. \u00a0At the end of the day, the customer knows how they want to use a solution. \u00a0You never know, sometimes customers actually do some pretty cool things that you never expected.<\/p>\n

Have a Happy Day!<\/p>\n","protected":false},"excerpt":{"rendered":"

I was recently asked by a customer to give my perspective on a number of topics including Software Defined Everything. \u00a0I will be making a set of blog posts on this and other industry perspectives in the coming weeks. \u00a0For now – let’s talk Software Defined Everything! For those running in IT circles there are […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,9],"tags":[],"class_list":["post-185","post","type-post","status-publish","format-standard","hentry","category-architecture","category-sdn"],"_links":{"self":[{"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=\/wp\/v2\/posts\/185","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=185"}],"version-history":[{"count":4,"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=\/wp\/v2\/posts\/185\/revisions"}],"predecessor-version":[{"id":190,"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=\/wp\/v2\/posts\/185\/revisions\/190"}],"wp:attachment":[{"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=185"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=185"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.darrinthomason.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}