We live in a world of mobile and cloud, and the Internet of Things (IoT) is driving a new wave of innovation. But beneath the must-have apps and innovative new services, the software running your network is old.
Most network operating systems (NOSs) were designed for and designed in a different era when applications were monolithic and deployed in a classic client/server model. When software was compiled, distributed, and installed on computers, and when everything needed to run the application was contained in that application. And the software was primarily designed for people to use. Those applications and network operating systems had a similar design principle—they were designed for a human to drive them.
Cloud apps are different. New capabilities are delivered frequently in a steady cadence. Applications are constructed from components and micro services that can be used by multiple applications or digital services. The building blocks of cloud apps have well-structured data models and APIs because they’re designed to integrate into other software. The software is used by people—and increasingly machines. The components of a cloud application are built to be composed into larger application and workflows. The design center of a micro-service is that it’s meant to be integrated and driven by other software components or systems.
The Quest for Programmable Networks
In an era of mobile and IoT, the network must become more flexible and adaptable to meet the demands of mobile users and vast numbers of sensors and other IoT devices. A network must be easily programmed by operators to automate manual tasks and adapt to an organization’s unique needs.
The concept of a programmable network is not new. Over the last decade, network vendors have published APIs and pitched their operating systems as a platform for developers. The concept never got traction, for a variety of reasons. Most IT teams didn’t have the development skills—or appetite for risk— for building on-box applications. There wasn’t a big enough revenue opportunity to attract third-party developers. SDKs and NOSs as a platform proved to be misguided for the enterprise network operator.
A Modern Network OS for Operator
In June, Aruba announced the game-changing 8400 core and aggregation switch, and ArubaOS-CX (AOS-CX) is at the heart of the 8400 switch. We developed AOS-CX from the ground up as a modern cloud app for network operators. It just happens to ship in a metal box.
Under the hood, AOS-CX is a collection of modern cloud and computer science techniques, built on a foundation of 20 years of network protocol experience. AOS-CX interacts with workloads, micro services, and components. And it’s optimized for automation and machine communications that are increasingly driving today’s digital world.
AOS-CX essentially is a network-as-a-microservice. Core system applications running inside AOS-CX use a publish/subscribe model to the in-memory state database, and no application on AOS-CX is allowed to have an app-to-app private conversation. All aspects of the system are expressed in the data model, and all apps must adhere to a distributed systems, state-oriented programming model. At compile time, the build system auto-generates a REST API for all objects in the data model. This exposes the features and functions, the statistics—everything—to both internal AOS-CX applications/services and to external software systems.
Why build a NOS this way? First, process restart, clustering, and high availability come along as an outcome of the architecture, not as a feature to be built. A new process, or process restart, simply attach to the database and retrieves both its persistent and ephemeral state. The architecture scales across CPUs and cores simply by virtue of the locale independent nature of publish/subscribe state synchronization. Secondly, and most importantly, the architecture extends itself completely, at compile time, through complete and structured REST APIs. Not REST or XML as basically a CLI transport, but as true machine APIs designed for interfacing with software.
The biggest challenge with intent based networking today is that “intent” implies a final state desired for a network. In the case of most NOSs, that means you need adaptor or shim layers of software to accept the expression of intent, and then translate into the monolithic and event/message-oriented architecture of most NOSs. AOS-CX requires no such translation—it is correct by construction.
Automate and Simplify Network Operations
AOS-CX helps network operators automate and simplify operations. In June, we also announced Aruba Network Analytics Engine, which provides real-time monitoring that speeds troubleshooting with intelligent network insights. Network Analytics Engine is an application that runs on AOS-CX, sitting on top of the data model and using the APIs to monitor the network and troubleshoot faster so you can deliver a better experience for your users.
Let’s say your employees are complaining that their unified communications sessions are dropping or have poor sound quality. Today, the user reports a problem to the service desk, and a little while later, the network operations team begins digging into network flows and logs. But if it’s a transient issue, the information the need to fix the problem is long gone—or was never logged. There’s no evidence of the cause. Maybe it was a spanning tree loop. There’s no way to know.
Network Analytics Engine lets you analyze a problem when the problem is happening. When it detects an anomaly, it can proactively collect additional statistics and data to proactively troubleshoot the problem. It gives you the insight you need to resolve the issue, or even better, it may take corrective action based on established policies. You can easily customize the monitoring to what’s important to your business through Python scripts.
Automating monitoring and troubleshooting with Network Analytics Engine is just one example of an application that takes advantage of the programmability. AOS-CX can function as another component in a software stack, alongside other network components, medical devices, operational applications, or elements unique to an organization.
The benefits of automation and programmable networks aren’t restricted to large enterprises with highly skilled network teams. In fact, the ability to program your network using simple Python scripts and to automate the tedious, manual work of monitoring troubleshooting can give an organization of any size an edge.
No SDK required. AOS-CX is not a development platform for software engineers. It’s a platform for network engineers to improve efficiency, reliability, and productivity.
We can’t wait to see what you’ll automate. Tell us in the comments below how automation and programmability can help you.
Curious to learn more? Watch the demo to see AOS-CX in action.
#8400