Cloud and multicloud are having a significant impact on the future of network control. Managing pools of infrastructure as a cohesive collection of fungible resources requires more changes to operations than to the underlying devices.
What should we now expect in the network control space?
The Demise of Monoliths
Historically, network control has relied on one of two models: either mastering the CLI or purchasing a network management solution. But this is changing. In an age defined by agility, the CLI simply won’t cut it. And as operating environments move away from single-vendor solutions, the days of the network management monolith are numbered.
In the past, as long as networks were homogenous and workflows were contained, network management solutions could evolve just fast enough to keep most users happy. But multicloud is multivendor and multi-domain workflows are more complex, making it impossible for monolithic control solutions to expand fast enough to manage the diverse number of platforms and workflows required for cloud and multicloud.
Similar to how network devices have evolved, network control will have to move from scale-up to scale-out, embracing microservices architectures built on open interfaces in order to evolve with the cloud.
The Role of Platforms
If the future of network control is about composable workflows, then we should expect network control to evolve in much the same way that microservices architectures have.
At the heart of every microservices architecture is a platform that provides the foundational elements required to make the system work. In the network space, this means there will need to be an open platform that houses the fundamental infrastructure components required to support composable workflows and network services.
In networking, these foundational elements are:
- Analytics: The analysis of data to drive insight
- Telemetry: The automated collection of system data
- Orchestration: The coordinated control of multiple network devices, typically via automated workflow
- Management: The administration of individual devices
Building off the elements above, Juniper Networks has renewed our dedication to unifying and solidifying the foundation for at-scale software on a hardened Kubernetes-based platform. Internally, we refer to the platform as ATOM.
Abstraction: More than Just Intent-Based
When introducing centralized control, operations become intent-driven by necessity. That is to say, the rise of controller-based management presiding over heterogeneous environments requires users to elevate above device-specific commands and configuration.
Quite naturally, operations have to take place above the network, replacing vendor-specific syntax with abstracted workflows that allow engineers to focus on real networking domain knowledge rather than rote memorization of device commands and configurations. The SDN controller will serve as both a place to insert intent and as a broker for translating that intent into underlying instructions required for devices to play their designated roles in the process.
Initially, this will look like abstracted commands and configuration—a form of networking pidgin that mashes up common syntactical networking elements. Over time, intent will evolve into something closer to the actual applications and services, where operators specify over-the-top requirements rather than behavioral descriptions.
While it is tempting to think that this will be the end of network engineering, it’s worth noting that the primary motivation behind abstraction is to allow engineers and operators to spend more time on value-driving tasks. Just as autopilot has not eliminated the need for pilots, the need for knowledgeable architects will not be eliminated by abstraction and automation.
Ubiquitous vs. Contextual Workflows
If this network control platform is designed and implemented well, it should serve as the foundation for both vendor-created and user-defined workflows. Network suppliers should effectively leverage their own technology.
For workflows that are ubiquitous—that is, deployed in nearly the same way across many or all environments—vendors will package them as part of the products, essentially delivering automated capabilities. These workflows might be inseparable from the products, but they should use the exact same technology that non-vendor workflows use.
Most workflows will be contextual, varying from network to network as topologies, tools, processes and even people are different. Indeed, the same exact network in two different companies might operate in very different ways. For these contextual workflows, automation will be an end-user practice, requiring operators to define, compose and maintain workflows built on top of the ATOM platform.
Network Reliability Engineering
Leveraging a microservices architecture to deliver composable workflows will drive a shift in operator practice from CLI-oriented to something more like the Site Reliability Engineer (SRE) role. Similarly, a Network Reliability Engineer (NRE) will use DevOps-style tools to deliver a steady stream of smaller, tested changes to the network with the explicit goal of using reliability to improve application velocity, stability and availability. These NREs will effectively serve as operations architects, composing the workflows most critical to the business.
It’s important to note here that workflows aren’t just about actions—that’s only half of a modern operational practice. Truly reliable workflows also include measurement and monitoring. That’s where a platform’s telemetry machinery comes into full effect, steering workflows in real time based on actual network events and performance.
However, not all workflows will be automated; for some, there simply isn’t a strong enough economic argument to move beyond a few keystrokes executed at very specific times. In other cases, the ad hoc nature of infrastructure management will not allow for prescribed actions, forcing operators to improvise at the console.
Generally speaking, the vast majority of network interactions will be through the ATOM platform, leveraging its services to execute workflows in and around the network while monitoring vast sources of telemetry in real time to ensure network changes go as planned.
Embracing the Transition
Our industry has historically found it easier to innovate than to drive adoption. If the industry is to move beyond the CLI—and indeed, it must—then we must both innovate and help users navigate the transition from CLI to workflow-oriented multicloud operations.
At Juniper, we believe this will happen in a few different ways. First, an open platform has to be built that provides the foundational elements described by the ATOM architecture. This is why we have focused so intently on Contrail. While we announced Contrail Enterprise Multicloud as a solution for multicloud orchestration, it was really designed as an open platform. We believe the industry needs a multivendor foundation with ties to the open source world, so we have focused our efforts on both Contrail and its open source variant, Tungsten Fabric.
Additionally, we believe we can leverage this platform to deliver automated products. For ubiquitous workflows, we are committed to building packaged suites we refer to as Automation Bots. These Bots use the same infrastructure we expect operators to use. Essentially, if it is good enough for users, then it should be good enough for us.
Ultimately, though, the future of network control is critically dependent on the people who actually manage networks. It is not the products or even the enterprises themselves that will dictate success. It is the individuals—the network operators and network engineers—who will determine whether the industry moves forward or remains constrained by the CLI. We have invested in an individual, providing free trials of production devices, free labs and exercises that require no prior knowledge, and education and certifications, all hosted on a central automation exchange we call EngNet.
Only when concept and practice come together will network control really evolve. To hear more on what is happening in this space and what individuals can do to get started, follow the conversation with folks from Apstra, Juniper Networks and Packet Pushers.
