The perils of networks that sprout

Andy O’Kelly

Network Solutions News

I’ve had a series of architecture meetings recently with a customer, looking at what their network – with data centre at the core – had organically grown into. It resembled something sprouting in the forgotten corner of a fridge. Every ugly concession against best practice had a story, each with the same underlying plot: we know the capability of our investments is under-used, we know it’s precarious and full of complexity, but the imperative is to get services delivered. Everyone present knew better than to suggest a clean slate. The customer exasperation was clear: after buying lots of software and lots of boxes, why can’t the configuration and management of data centres be smarter and easier to orchestrate?

Where is the control?

The reason for the problem today is that there are different control layers in the data centre – applications sitting on top of virtualisation delivered by a hypervisor like VMWare or HyperV, with a disconnect at the network layer configuration, and security capability desperately disjointed into islands of functionality. This is similar to having different rail track gauges at the junction of two high speed trains. Independent of their speed or luxury, the reassembly of the train is painful. Why can’t these layers co-operate more harmoniously, and act like the ‘system’ we want them to be? As Jack Nicolson says in Mars Attacks,‘why can’t we all just get along?’ The latest in a long line of Holy Grails is Software Defined Networking or SDN, a model that sees the control of network pushing up into the enterprise software layer, where there is more information and decision-making capacity about what the network needs to deliver for applications. If applications are ultimately the VIP passenger, let the VIP passenger set the controls and the itinerary.

Cisco, SDN and Application Centric Infrastructure: ACI

SDN is a hot topic, and on 6th November Cisco – the biggest and best network player – embraced SDN, although as dictated by tradition they have given it a new name and three letter acronym of their own ‘Application Centric Infrastructure‘ or ACI. (See the Cisco ACI Overview video) The initial Cisco work has been on opening up their network devices via a common API. Next there will be an Application Centric Infrastructure Controller that uses this API to talk to the full range of such devices, and offers a ‘system’ level configuration of the network to applications via the Controller. The vision is that these applications – either bespoke, developed by partners, or more than likely an embedded capability in a well-known application suite like SAP or Microsoft SharePoint – can respond rapidly to events detected at the user level, and initiate network changes without requiring in depth device-level configuration capability. This ‘relief from complexity’ is an attractive promise, available to external software. Although the initial focus of API is on data centre, Cisco is looking at ‘end to end’ enablement of SDN across the entire existing network, including the enterprise LAN and WAN.

Potential benefits of Cisco ACI

I recently heard a senior Cisco exec admit that many of the clever and business enhancing features of Cisco software are ‘relatively ominous to implement’ via current configuration. Examples of the types of services that would benefit from the abstraction of an Application Centric Infrastructure Controller could include: – ‘customer steering of traffic’ – directing particular conversations to follow particular paths based on priority as opposed to route availability – Access Control List management (showing what ACL’s are active and when, allowing easier inspection and triggering of rules, or threat remediation through the speed of ‘machines controlling machines’) – Quality of Service classification based on business conditions discerned by enterprise applications – ‘zero touch deployment’ where applications configure devices to their needs, speeding up the creation of services in a cloudy manner. Rather than have SDN reduce the network to bunch of low cost ‘good enough’ boxes as some have predicted, with traditional network features moving to x86 virtual machines and off proprietary ASICs, ACI sees the rich capability and high performance of Cisco’s R&D in enterprise networking made available directly to business applications. There’s a good analysis of the Cisco announcement here on The Reg.

Where is ACI bringing us?

It’s going to take some years to deliver on the full vision, but where does all this lead to? I know a little bit about programming – enough to know that I wasn’t a very good programmer. I’m not alone in this, so programs need to be tested, and tested again. How will we test and validate the results of SDN coding before letting it fire at a controller of a mission critical data centre system? The answer will be best practice code development discipline, encapsulating the network domain. As complexity increases this must become a machine task, independent of human intervention, codifying the experience and problem-solving capacity of network experts. Such automated reaction is something many enterprise customers reject today, with distrust of sloppy or incomplete code or incompatibility between the components of a system the prevailing view. A consequence of the flexibility that SDN will open up into the DevOps method will be the complexity of that testing, and the subsequent monitoring and trouble-shooting of the resulting system operation – skills-wise, the line between Ops and Developer disappears, requiring a new skillset that will be central to capitalising on the new model. In the meantime it’s back to the drawing board, aligning current applications, hypervisors and networks. Andy O’Kelly is Chief Architect at eir and a speaker on IT solutions and innovation. Follow Andy on Twitter, connect on Linked In.