From networks to clouds – automation is very much in the air right now

Intent-Based Networking is a significant advance towards tomorrow's self-operating data centers, and it is available today in ever more sophisticated offerings. Putting "software first" allows much greater flexibility, more agile deployment and maintenance and avoids the negative implications of vendor lock-in, says Mansour Karam, CEO, Apstra

Take a look at Amazon's newly announced Prime Air delivery drone. It sounds like such a simple idea – deliver and drop off packages by air without all the hassle of truck roll-outs and traffic jams – but the complexity of the prototype and what it must achieve is quite astonishing.

They are not simply addressing the major aerodynamic challenges – if the thing didn't fly the project would be a non-starter. It's also the regulatory hurdles; it has to navigate faultlessly for US FAA (Federal Aviation Administration) approval, let alone all other nations' regulations. Despite the drone's exceptional navigational skills, a human or animal might still leap across its path: so it has to have an infrared sensor to recognise heat signatures, as well as shielded propellers to minimise collision damage. It also has to recognise subtle hazards like phone lines and washing lines as it makes its backyard drop – amazing when you think how birds, with all their intelligence, still occasionally fly into power lines. To achieve such exceptional reliability, the drone's control system layers multiple sensors and closed-loop systems to minimise the risk of anyone system failing.

Anyone who tried flying previous generation model helicopters will have a taste of the aerodynamic challenges, and how things are changing with the onset of automation. When we reach the limits of what humans can manage under pressure, at speed, and over long durations, then automation is the only solution. But initially, it takes real courage to learn to trust the system.

In the IT world, networking is the peak of complexity. What goes on inside a silicon chip is also highly complex, but it is a closed box whereas the network is a structure subject to change, additions and evolution. The word "architecture" is appropriate in a networking context, and over the decade's network managers have had increasingly greater headaches trying to keep the whole heterogeneous mix running smoothly. One consequence has been the delivery of a "bottom-up" service: constrained by what the network can do, rather than being driven by business need. Meanwhile, the field engineers struggle to configure the growing ranks of equipment, knowing that a single human error could take days to diagnose.

But now network automation is coming to the rescue. With the addition of increased intelligence, networks are beginning to reduce the burden of highly repetitive tasks such as configuring hundreds of switches. The most sophisticated level of automation is what is called "Intent-Based Networking" (IBN).

Intent-Based Networking 

Taking the Amazon drone as an example: Amazon's "intent" would be to deliver the packet to a specific customer. But of course the customer must specify a particular delivery address, so the intent-based operator would formalise the instruction to: "Packet XXX should be delivered to Location Coordinates LAT - LON at time MM:SS". Without automation, that simple intent would have to be translated into a hugely complex set of instructions about managing the drone's six motors, taking bearings, avoiding obstacles, etc. What's more, a sophisticated intent-based system would update in real-time to allow for changing conditions or even a customer on the move.

In the case of an enterprise network, the business intent might be to accelerate the system's response to customers. We are a long way from systems that could respond to such a human intent, but we do have network managers that can distil the business desire into a realistic interpretation of that intent in IT terms. It might boil down to a more technical description, such as: "We must deploy an EVPN leaf/spine network to support our enterprise application, as well as the policies required for the various application tiers, and the specific SLAs for that application, which include latency and packet loss requirements".

Without automation, that simple intent could spell weeks of work from a small team of engineers, not only installing and configuring but also sorting out the inevitable complications of integrating equipment from different vendors and troubleshooting human errors. What's more, there is usually a negative-honeymoon period when users start complaining about bad service and the fault must be traced back to some setting or device defect.

But today's most advanced "software first" IBN installations will, in just a few minutes, translate that same intent into a software blueprint containing all the configuration data across multiple vendors' hardware, with precise wiring instructions for rapid installation. And, should any performance problems occur, the system's intelligence would trace back to pinpoint the root cause of the problem and suggest how to repair it – updating itself and the blueprint in real-time as the changes are made.

Significant competitive advantage 

The above comparison suggests an enormous boost to the enterprise's agility – the rapid response to business pressures because days of labour have been saved by those few minutes on the IBN control screen. But often the far bigger saving comes from the resulting reduction of human error – because so much tedious and repetitive manual work is now performed automatically to strictly defined instructions. Weeks of employee and customer frustration can be by-passed by automating routine operations.

The same control screen allows the network manager to set up ongoing monitoring and analysis of the completed network – anticipating the sort of performance problems that those pesky users will take such delight in complaining about! Unlike the users, however, the IBN will use its complete understanding of the overall network and its real-time performance to not just flag a problem but analyse and pinpoint the root cause and what must be done to rectify it.

In terms of OpEx and CapEx, of course the actual savings will depend upon the size of the network and the nature of the task – the larger the job the bigger the saving. But, as an indication of how much can be saved, notably in man-hours worked by skilled technicians, Yahoo Japan noted an overall 72.7% saving when building a leaf-spine network. This breaks down to: 24% saving at the Requirement Scoping stage; 73% saving at the Design stage; 82% saving at Implementation and Test stage; and 75% on Operation. The same company reported 83% saving on a switch replacement operation.

In the long term, reliability, agility and simplicity – together with far greater employee and IT satisfaction as well as an accelerated response to business needs – become even more significant business benefits from IBN.

Caveat emptor

The potential business and competitive benefits promised by IBN are so attractive that "intent-based" became a major buzzword last year. So much so, that several vendors jumped on the bandwagon and claimed to be offering intent-based systems.

IBN is a major advance towards the totally automatic, self-operating data center, but it is comprised of many smaller advances. Support for a vendor-agnostic infrastructure or the ability to monitor real-time status regardless of protocol or transport technology are important features, but neither on their own justify labelling the network "intent-based". So what must the buyer insist on when choosing an intent-based solution?

The first vital feature of IBN must be a single source of truth, embracing both the intent and the actual network status – including data on every aspect of the network service lifecycle. Intent-based analytics provide a 'helicopter view" of the system's current status and performance, based on input from a wide choice of "probes" that can be deployed in minutes across a running network and customised to match the business requirements and SLAs.

Without this single source of truth, answering questions like "Which users will be impacted if link x fails or gets congested?" would require an operator to first consult the network map (having checked that the map is up-to-date), then check the operational state of every link… and so on. Even when all the necessary data has been collected and collated, the final answer will still have to be calculated. Whereas a network with a single source of truth has all the necessary data in that one source and, in a truly intent-based system, the answer to those questions can be automatically and speedily calculated and displayed.

Another important question is whether the IBN can enable "root cause identification". Once you have a single source of truth encapsulating in real-time both what the network should be doing and what it is actually doing, then with the addition of closed-loop validation, the IBN can study the incoming telemetry, note any irregularities, outages or performance degradation, and not only report them but also trace them back to the underlying root cause. There is nothing more troublesome than an intermittent fault that works perfectly when the engineer looks at it. The service operator only sees how it is performing during inspection, whereas a proper intent-based system keeps a full ongoing record of when and how things went wrong, together with the full knowledge of the infrastructure and component parts. The combination of a single source of truth plus AI can trace back from erratic symptoms to pinpoint the root cause.

It is also important to know whether your chosen IBN is truly vendor-agnostic across what is often a complex network built up over several years with equipment from multiple vendors. When starting from scratch in a greenfield site, it is very tempting to go for the simplicity of a single vendor proprietary installation – but vendor lock-in can become a long term jail sentence. With a vendor-agnostic solution, you have the choice between opting for less costly but perfectly adequate off-the-shelf network components when suitable, or going all out for the very best-of-breed equipment in critical cases – instead of being limited to what your one vendor can offer. A similar argument applies to cloud services: can the IBN work with any workload on any cloud, or are you trapped with a particular cloud service provider?

More realistically, it is worth considering the true cost of choosing to migrate to IBN on an average legacy network. According to IDC analysts, an enterprise may have over the years installed networking equipment from several vendors: Cisco (as it holds approximately 50% of enterprise network market share), HPE (around 12%), Huawei ( around 8%), Arista and Extreme (each around 3%) as well as many others depending on the needs.

The investment in a vendor-agnostic upgrade would simply equal the cost of the IBN package and its installation. But if a single vendor solution is chosen it could mean having to replace any other equipment that might not be 100% compatible with the single vendor upgrade – not just getting rid of equipment already chosen for very good reasons, but also having to buy their nearest equivalents from the single vendor's catalogue (and consider the consequences of an IBN that limits you to specific cloud services.)

In addition to that greater outlay, you must also allow a longer time for installing and commissioning the network. You will also end up with a system subject to all the long term limitations of locking into a hardware vendor. This will limit the options to the software that this particular hardware vendor supports. Whereas, in the age of multi-cloud, the "service layer"– i.e. the layer through which infrastructure is consumed through APIs – becomes highly critical.

Conclusion

Network automation is coming down to earth, and there is every reason for any business to consider Intent-Based Networking as a means to become more agile, to reduce network downtime and save massively on maintenance and troubleshooting.

The IT industry is moving fast, and intent based systems are rapidly growing more sophisticated and comprehensive, so make sure that you choose the real thing: one that provides self-operating Intent-Based Networking and not some partially automated solution behind an IBN label. In particular, think carefully about the risk of vendor lock-in.

In short: your primary intent should be to keep your feet on the ground and select the best possible long term IBN solution.