Cutting through the Complexity: Does SDN really simplify the network?

In my recent post on the Cisco Perspectives blog, I ruminated on the question “Does SDN really simplify your network?” The answer I give to that question is a typical techie one, but in short, “it depends” seeing as the key decider lies in your perspective. But why, I hear you cry, is that the case? Let me explain…

The complexity of a network mirrors the business it supports, simply because it has to support the data flows that businesses generate – so often out of necessity, the network itself isn’t simple.  As more features are developed that enable the business to operate better and faster, another layer of configuration is needed and so it goes.

SDN techniques allow us to address this partly through abstraction.  The complexity is still there, but it’s hidden under the hood accessible to the network techies to enable them to see what’s going on and troubleshoot if necessary.  As this technology has developed, we are now able to provide a single portal through which the business can control policies that the network enforces, and receive feedback on how the network is performing for those critical applications.

Each networking element will have its own controller (be that DNA Centre for SD-Access, APIC-EM for IWAN, vManage for the Viptela SD-WAN, NSX Manager, or APIC for ACI for example) and each of those will require separate configuration to interpret business policies.  The need for box-by-box configuration with these newer products may be gone but how many businesses will complete the migration to those environments quickly, and how many will only have one of those elements in the grand scheme of things?  There will still be a need to integrate with legacy networks, and there will always be a need to orchestrate workflows across multiple SDN elements which also introduces another layer of complexity.

ANS’ approach to this is to work with the business to understand the requirement and the depth of complexity acceptable to the operations teams.  We take an end-to-end view and create an architectural model for the network which includes:

  • A resilient network transport throughout, scaled and available as appropriate to location, user and application;
  • Centralised policy – be that user or application, security or QoS;
  • Orchestration capability – tailored to suit the business’ operational environment;
  • Network and application telemetry, reporting and capacity management.

If a business is very data-dependent, they may have a specific need to understand the nuts and bolts of every device in their network to ensure that data and applications are delivered optimally.  They may already have invested in a significant networking skillset and require visibility so that they can maintain their network to suit very specific needs, and respond to events in a timely fashion.  In this case, certain features of SDN products such as low-touch provisioning, centralised configuration changes and lifecycle management for example, would be useful if only to maximise operational efficiency and allow technical teams to focus on the things that make a real difference.

In these environments, there may also be significant use of DevOps methodologies, with teams of developers making regular high demands of the network teams.  Ansible, Puppet, Chef, Salt or any of the other myriad of orchestration tool sets could be used to build workflows across the whole IT environment – including the network – or exposed APIs for the network controllers can be used from programming languages such as Python.  Monitoring tools would sit in the background tracking usage, reporting errors and maintaining configuration backups.

On the other hand, a large proportion of businesses have little need to understand the finer details of configuration, and have a simpler operational requirement – the secure delivery of a set of business-critical applications to groups of users with a particular performance SLA for example.  In this situation, a fully managed service may be more appropriate.

There are many Managed Service Providers out there and while I’m conscious I don’t want to turn this into a sales pitch, I can’t pen this blog without mentioning why ANS are different.

With a fully managed service from ANS you’ll receive:

  • Network devices that are centrally managed and monitored
  • Application performance which is measured and reported on
  • Changes are simplified, built into workflows and orchestrated
  • Standard configuration applied to all network devices that refers to the central policy engine for its security rules.  The policy engine might refer to the business’ AD infrastructure to represent groups of users and what they have the rights to do on the network for example.

Still sounding similar to other Managed Service Providers? Think again.

Our automation and orchestration tools provide both ANS and our customers with several well-known, industry standard benefits however, the additional benefit comes from integrating all these tools into our service management platform, ANS GLASS. This portal allows our customers to easily consume our digital network services, whether that is to obtain a real-time status of operations, make a change, diagnose a fault or deploy a new service. An automated service, allows our customers to realise the benefits of digitisation faster, efficiently and drive relevant business outcomes.

So there we have it, I’m going to stop writing now before I get carried away. But on a closing note, I just need to stress that the key takeaway here is that there is no “one size fits all” and SDN products can be leveraged by all businesses regardless of operational requirements.

If you just can’t get enough of SDN, or if you’d like to find out more about how ANS can help, why not check out our “Developing the Software Defined Managed Network” blog written by ANS’ Head of Enterprise Networking.

Innovation Hub

Check out some other blog