Behind The Scenes: Network Orchestration with Aryaka ANMC

The other day, after I talked to a prospective customer, they told me they had read my last blog and that, while I talked about intent-based networking , I had omitted writing about orchestration, which is a key element in intent-based networking. They were right. In my defense, that would have made for a very long blog, but let me correct that omission today.

The great conductor and composer Leonard Bernstein said: “To achieve great things, two things are needed: a plan and not quite enough time.” And he must have known a thing or two about orchestrating. That quote certainly rings true in networking today, as we undergo transformation under the intense time pressure that is common in IT these days. And that leads us to automation and orchestration, which are closely interlinked.

Automation of course is a top priority in IT these days (you can read about it in our State of the WAN Report here and register for the webinar). But what do we mean by “automation”? Depending on the definition, automation is nothing new in networking.

In networking. which is seen as a culprit for obsolete, manual configuration by industry analysts all the time, we have used scripts forever. With scripting we could speed up device configuration tasks that our manager thought would take us much longer! We put some forethought into it, edited our script, ran it and went off to happy hour with our peer network engineers. Definition-wise, something like scripting is known in software science as an imperative approach, meaning that you have to know every detail of the underlying layer’s capabilities to interact with it, and do so with utter accuracy – otherwise it is very unforgiving.

That’s why I don’t think scripts are what we mean when we talk about transformative automation in IT. At the end of the day, the scope of applicability of scripts is very narrow: they are very device specific, and I run them device by device. Tools like scripting are rocket-powered crutches, very effective for a very specific move, but outside that narrow scope we’d rather limp along without hitting the “rocket mode” switch.

Orchestration, on the other hand, is the tool that allows for far more wide-reaching automation. For example, if I want to update a QoS policy globally because I am rolling out a new UCaaS deployment, the way it works for the 2 different automation approaches is as follows:

1. Scripting: If my network has 50 sites, create 50 slightly different versions of my automation script, resulting in 50 site-specific scripts. Then run them individually. If you think this approach preposterous, consider the fact that it’s not unknown to run several hundred CLI commands if you simply log into every node and configure it manually to change local class of service policies. And then add up the likelihood of configuration mistakes if you run hundreds of manually typed commands on 50 sites. Which is why automation by scripting was far more widely adopted in networking than it ever got credit for.
2. Orchestration: I simply define an abstracted policy that states my intent for UCaaS, such as: what traffic priority it has and what my optimal breakouts into the UCaaS cloud are. The orchestration tool translates it using what is called a declarative model in software engineering.

I know a skipped a step there: I didn’t say what “declarative” means. A declarative model is very different to an imperative one. In an imperative model, the elements you try to control expose all the complexity to you. Imagine hiring a cab, and instead of saying “I want to go to Terminal A in San Francisco airport” and doze off after you drive off, you’d have to direct the cab driver every turn of the way… “turn left next, turn right, in 6 miles (that’s about 10km for my metric readers) take the exit..”. Now that’s the imperative model. In a declarative model, you know you have the best cab driver on the planet, and they’ll get you to your destination with accuracy and speed, executing your intent to perfection, and you’ll arrive in Terminal A all relaxed (until you see the check in lines).

I also know I skipped another step in there, you’ll be asking yourself “What does that have to do with Aryaka?”. The answer is that we couldn’t possibly deliver on network transformation for our customers without with an industry-leading orchestration workflow, both for ourselves and over 800 global enterprise customers. Our orchestration tool is called ANMC for “Aryaka Network Monitoring and Control”. It interacts and fulfills 3 main functions I’d like to highlight (but there are more):

1. ANMC is key architectural element in the Aryaka Global Managed SD-WAN architecture that turns intent into automated configuration, following a declarative model. Many SD-WAN vendors talk about intent-based automation, but when you look at the complex policies you have to define, you need a network expert – and you need a month or two of their time, minimum. With the Aryaka model, all you have to do is declare your branch locations, your application priorities, your security posture, your cloud-based XaaS and redundancy needs – and the Aryaka orchestration machine, powered by ANMC, will make it happen for you – anywhere in the world, within 48 hours or less. It resolves high level network design intent into orchestrated commands throughout the Aryaka infrastructure:
   • Step 1: It will orchestrate your specific connectivity, QoS and security configuration across the Aryaka Global Layer 2 core network.
   • Step 2: Whenever you activate a branch device, it will provision it for you in a seamless zero-touch deployment model and provide immediate global, secure and deterministic connectivity.
2. ANMC is also our global visibility machine into everything that is happening within Aryaka’s network-as-a-service infrastructure, for all enterprises that run their network over the Aryaka infrastructure. It provides a global trending tool that allows Aryaka to both plan ahead for its own infrastructure needs, as well as provide customers visibility into their own resources via the MyAryaka customer portal. In terms of intent-based networkingS, this is the crucial feedback cycle that constantly matches original intent with operation reality, and alerts to any discrepancy or potentially disruptive trends.
3. While ANMC is the internal Aryaka monitoring and orchestration tool, it clearly is at the core of multi-tenant capabilities. It provides the architectural foundation for the MyAryaka visibility and self-provisioning customer portal.

Orchestration will be a topic we will regularly revisit, because it is a vital element in the future of enterprise networking. But let me finish with a somewhat personal thought: many of us, having worked in networking for 20 or more years, sit together irrespective of the companies we work for, and collectively wonder “if orchestration and automation take over, what are we going to do?”.

Let me quote Leonard Bernstein yet again: “The most difficult instrument to play in the orchestra is the second fiddle”. The lesson there to me is that in networking we have tried to be soloists too long, we have tried to keep complete control of our domain and think ourselves indispensable. But we also know that, with the needs of the digital enterprise, networking needs to become a tool to an overarching business purpose. I think every second violinist in Bernstein’s super successful New York and Vienna Philharmonic Orchestras was happier than a first violinist in the ensembles they overshadowed.

The IT organization in the emerging digital age unquestionably declares us all second fiddles (in Bernstein’s language) to the first fiddle, which is simply: Business success, for which we have to provide the foundation with an extremely agile, robust network infrastructure that powers the cloud-first enterprise’s needs. And then we can play beautiful music together. Let ANMC be your orchestrator.

Want to learn more? Please book a demo with one of our experts.

About the author

Paul Liesenberg

Paul is a Director in Aryaka’s Product Solutions Team. Paul has over 20 years of experience in product marketing, product management, sales engineering, business development and software engineering in Cisco, LiveAction, Bivio Networks and StrataCom. Paul enjoys scuba diving, motorcycles, open software projects and oil painting.