The Network Manager’s Dilemma: Wading Through the Acronym Soup
Jun 11, 2013
Recently, Juniper’s been “straight talking” a lot about automation tools, orchestration plugins, open source consortiums, ecosystem partnerships and, of course, software-defined networking. All of this activity (and the various acronyms that go along with it) is enough to make even a seasoned networking expert’s head spin.
When I speak with customers, there is uncertainty about how these various solutions fit together. Does it work with OpenStack? How does it integrate with the Puppet software that my sysadmins are using? Does it work in a multi-vendor environment? What types of overlays and protocols will it support? And by the way, the “it” in all of the previous questions changes depending on “who” you ask. This is a small sample, but it underscores the confusion and lack of consistency. What’s not confusing is the customer pain point. Those same customers can universally agree that managing the network is time-consuming, costly and error prone.
Management and orchestration of the network is the next difficult problem to solve. Three years ago, the conversation was centered mainly on the network topology and how the network needed to change to handle east-west traffic. Today, the conversation is shifting to how the network needs to adapt to changing application needs. For a cloud provider, it’s going to be spinning up resources, apps or services for their end users. For an enterprise, it’s going to be bringing a new corporate productivity application online with the right policies across their entire employee base. Either way, the network is key, and the network that’s easiest to manipulate will be the front-runner.
From that standpoint, it’s easy to see the rationale behind all of Juniper’s investments. We were already trailblazers in simple, flat fabric architectures. Now we are doing the same thing with network management operations. We see three tracks emerging and Juniper is playing major roles in each:
Single-vendor network automation – pretty much anything you can do to make the life of a CLI jockey easier. These solutions range from SDKs and APIs on the OS to scripting support, to even external management tools to automation configuration such as Junos Space Network Director.
SDN – dynamic application-based control and management of the network through an externalized controller. With the market still early and in flux, we know that customers need a choice. Even though we introduced our own SDN controller in May, our network solutions will continue to work across different controllers, overlays and protocols.
Orchestration systems in the data center – tying in multiple elements of the data center infrastructure – server hardware, compute, storage and network into an orchestrated and automated provisioning system. Automating network change in these systems is critical to taking the next step in simplifying network management operations, and Juniper is heavily involved in this area through tools like OpenStack and Puppet.
The one final, albeit extremely important, note is that these tracks are not mutually exclusive. Whether it’s one, two, or all three, customers are looking to solve their network management pain point and achieve levels of agility and value today – without having to wait for the dust to settle. So yes, Juniper is in the conversation (and very much open to listening) when it comes to management, automation and orchestration. It will be fascinating to see how this area plays out over the couple of years.
 Fabrics, or characteristics of fabrics are a well-accepted requirement in data center networking. The industry realized years ago that legacy architectures weren’t going to work, and as such, we’ve seen a glut of fabric solutions that, while different in architecture, feature support, latency, scale and capacity, address the same problem.