Cisco Blogs
Share

If It’s Not Software Defined, It’s Legacy


February 21, 2017 - 2 Comments

According to Wikibon, only 10% of internal IT workloads represent true private cloud. The private cloud is simply a virtualized environment, lacking the characteristics that we associate with public cloud, such as user self-service, automated deployment and utility billing. This is because private clouds are often built on legacy data center networks, rather than software defined architectures.

Since SDN (Software Defined Networking) first emerged in 2012, there has been a lot of criticism on the networking industry focused on it’s inability to keep up with the automation and virtualization advances that we have seen in the server and storage industries. In my opinion, this seems a bit unfair as the distributed nature of networking makes it more difficult to virtualize and automate than servers and storage. These challenges include:

  • Distributed Configuration – Each individual component of the network needs to be configured in harmony with the others to ensure connectivity. This makes the system very brittle and one bad configuration can take down the entire network.
  • Automation – Even if devices are standardized, many will lack an object model and northbound APIs and this makes automation difficult.
  • Heterogeneous Environments – Many data center environments will have multiple vendors, numerous device types and different code versions. As a result, configurations cannot be templated or automated, so significant effort is required and inconsistency is inevitable.
  • Service Insertion – Middle boxes such as firewalls and load balancers sprawl across many data centre environments. These devices reduce performance, make configuration rigid and impede workload mobility.

Up Until now, I have defended the right of the networking industry to take a little longer to solve these challenges. However, now in 2017, both SDN and NFV (Network Functions Virtualization) have matured and there is no longer an excuse.  If your network is not software defined, then it is legacy. Investment cycles indicate that adoption will continue for several years.  If organizations are building data center networks by 2017 and not considering SDN, NFV and automation, they are placing themselves at least five years behind the curve and closing the door on private cloud.

Remember how we were once told that “software will eat the world”? Well, software has allowed the networking industry to solve the challenges discussed above. With SDN, user intent is captured on a central software controller and pushed as configuration to an underlay network fabric or virtualized end-points, depending on the solution. As well as solving the distributed configuration problem, this also solves the automation problem – the SDN controller will have a northbound API and in some advanced cases the solution will be object-oriented, which significantly aides programmability.

Depending on the SDN solution, the underlay will either be consistently one hardware type or a dumb underlay, so the heterogeneous environment problem is also removed. Finally, NFV has also grown up as the younger sibling of SDN and almost all Layer 4 to 7 appliance vendors now provide their solution in a virtual form factor. This virtualization combined with centralized software control of network policy means that services are be inserted into the network with ease and only where required to improve performance.

At Hutchinson Networks, we adopted SDN early and built our public cloud IaaS platform using Cisco’s market leading SDN solution, ACI. We have also adopted NFV for all Layer 4 to 7 components and only use hardware for the most basic components – physical network connectivity, disk arrays and raw compute (CPU and Memory). Using a Software Defined Architecture and Cisco ACI has allowed us to build a true cloud environment. Find out more here: Diversifying Business with Cloud Services.


Guest Blogger: Stephen Hampton, CTO at Hutchinson Networks 

Stephen Hampton is a Network Architect with a proven track record in the successful delivery of large networks. As CTO, he is driving Hutchinson Networks’ technical progress and solutions selling strategy. Stephen is seeking to improve and expand Hutchinson’s service catalogue, bringing new solution sand innovative products to market. Supported b  expert, certified engineers, Stephen is also strongly focused on building a top-class team of technical engineers and architects. He has the enviable ability to rapidly master new technologies and architectures.


 

Tags:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

2 Comments

  1. Great article Stephen! Certainly thought provoking. I've been a proponent of SDN and NFV since the early days, and it has been difficult getting people to understand and accept the change. Virtualizing the DC environment has many benefits, and compelling use cases...especially in large environments. I've been involved in many conversations with other architects, and the prevailing opinion is to keep the hardware implemented in the traditional manner, then allow the intelligence to be handled by an overlay (NSX, Nuage, Contrail, etc). My opinion is that both should be used in tandem, and you will get the biggest bang...that they don't have to be mutually exclusive. As in, why not use ACI to turn your 3 layer DC environment in to a SDN based provider cloud? You can also use MPLS to do something similar with legacy devices (I've been an advocate for enterprise using SP tech to virtualize their network for quite some time). Thoughts?

    • Thanks David There are certainly advantages to the integrated approach - the controller builds both the underlay and the overlay but also, for me a key advantage of Cisco ACI that we leverage in Fabrix is the ability to integrate physical workloads into the SDN solution. I also agree with the enterprise Service Provider model - I have been involved with one organisation who did this and it mostly worked well.