In recent months both Cisco and Juniper have been talking about Puppet. In February, Juniper announced an early adopter release of Puppet for Junos OS. At the Network Field Day event, Cisco demonstrated onePK + Puppet. When I hear Puppet, I think sys admin not network operator. Why then the growing buzz around Puppet and networking? If you don’t know, Puppet is one of many configuration programming languages; Chef is another, popular with sys admins for configuring Unix and Windows-based server platforms.
Tools like this have become the defacto workhorse in the datacenter for provisioning, configuration management, and orchestration of VMs. From what I understand, since Puppet is a declarative programming language it encapsulates a larger construct that obfuscates the underlying complexity of programming and gives it a Jean Luc Picard-like power to point & click to “make it so”. This helps lead to more automated deployment processes in the datacenter.
The NOC, in sharp contrast, has remained stubbornly resistant to automation and EMA has research data that supports this phenomenon. One of the major sticking points has been and continues to be change & configuration management of network devices. The process is largely manual, making it slow, inefficient, and subject to errors. This is particularly bothersome for sysadmins, when they make a request to network operations as part of a deployment scenario, say for a new VLAN. The networking component has quickly become the long pole in the tent.
Configuration management and new resource allocation have been a thorn in the network administrator’s side forever. There was a brief flurry of activity around what is commonly referred to as NCCM (Network Change and Configuration Management) tools, but the market evaporated after a series of acquisition by large system vendors. That market struggled to find footing and only the most progressive networking departments appeared to embrace the technology. However, the glaring disconnect between the automated datacenter provisioning, configuring and allocation process and the manual networking one is becoming more problematic. So it is no small wonder that datacenter sysadmins are attracted to the promise of overlay network solutions and the allocation nirvana it hypes.
Could it be Puppet to the Rescue?
Could this be the one language to rule them all? The Puppet language has been designed not only to configure servers, but networking and storage as well. Puppet Labs began incorporating the ability to configure networking devices into its product release around this time last year. In the initial release, support was limited to Cisco devices, however a subsequent blog post here indicates that F5 devices can also be managed using Puppet, through modules that advantage of the iControl API. In January, Puppet Labs introduced a new module for managing NetApp storage devices.
The Juniper Puppet for Junos OS is actually still in early adopter release, and is composed of two software components:
- A native Puppet agent and libraries, which are installed on Junos OS devices. This is distributed as a Junos OS package.
- The netdev Puppet module is a vendor-neutral network abstraction framework developed by Juniper Networks and contributed freely to the DevOps community. The module provides new resource types for basic network abstractions such as VLANs.
The Junos OS devices appear as just another “node” in the Puppet managed infrastructure.
We don’t know yet how network administrators will feel about running Puppet agents on networking equipment, which would give sysadmins the freedom to allocate resources at their whim. However, we cannot ignore the roadblock that network processes are creating in the datacenter and DevOps. It might be time for network administrators to at least become familiar with Puppet, so that they can understand how it works and interacts with networking equipment. Puppet on networking devices is still in the early stages, but I believe its full potential has not yet been realized. It may turn out to be the point at which true convergence can begin. If nothing else, it seems like it might be a good starting point.
The road to true network virtualization is going to be long and arduous. But perhaps some of the first steps are about solving some basic sticking points, so that we can begin to move the conversation forward, rather than having networking be the boat anchor that holds back the rest of IT and the organizations they support.