Juniper's Jeremy Schulman learned about Puppet when a customer's networking team asked him for something very impractical.
"We were working with a very large customer, and they said 'we really need to automate our ability to make port and VLAN changes,'" he remembers.
As it turned out, the networking team wanted to put Juniper's professional services team to work building a custom web portal that would allow the operations team to log in, fill in desired changes to network configuration, and apply them with the click of a button. When Jeremy explained that sort of work was out of scope, the networking team was undeterred:
"Why don't you go talk to the sysadmins? They write code. Why don't you go talk to them and ask them to build us that website?"
So he did, not realizing he was also starting down a path that would lead him to presenting a session at PuppetConf 2013.
"I told them what the networking team wanted," he says, but the syadmins weren't interested in building the tool, either.
"They said 'that's nice and all, but that doesn't really help us and we don't really want to build a website for those guys. We've got our own stuff to do."
As it turns out, they had a suggestion of their own:
"Can you just put Puppet on the switch? We use Puppet to manage those servers, then we could just roll out the changes we need to the switch."
That question kicked off a series of conversations within Juniper and its IT organization, also Puppet users.
"I started to realize Puppet wasn't just another config management tool," says Jeremy, "and that people who use the tool actually version control infrastructure. They think about infrastructure differently --- they think of it as code, which is completely a revelation in modeling change control."
At the same time, the Juniper team began to learn about the DevOps community.
"We started attending their meetings and reading their newsletters and learning about other tools that they have. What we started to recognize was that 90 percent of the things networking people want to automate, server admins have already automated. We realized that rather than reinvent tools to do the same things, we could just spend time learning the DevOps toolchain and the way DevOps teams work."
The NetDev Initiative
From that also came a different way of thinking about how networking vendors might want to operate, which led to Juniper's work on NetDev. NetDev was meant to address the very common problem faced by large IT organizations when the sysadmins come in contact with the networking team.
"The NetDev initiative was really an outgrowth of our experience with very large customers who manage very large-scale, complex deployments of servers with Puppet. They had friction between the server sysadmin team and the network team when they needed to make changes to the network --- very simple changes like ports and VLANs --- that were the result of something that was different in the application."
Even simple changes can be hard at a large scale, Jeremy says.
"There's lots of opportunity for error. Things don't necessarily get done when the sysadmins want them to get done. You might put in a change ticket and wait a week, or wait three days, or put in a change ticket and you have to call somebody and tell them 'this is really important, could you do it right now?'"
System administrators might be familiar with the same sort of requests coming from developer teams they support, but they haven't necessarily learned to empathize with networking teams under the same pressure to provide for their own customers with speed and agility.
"Making a change to the network, which is really a communal resource -- like the power grid -- is very different than making a change that has an impact on only a single server," says Jeremy. "Sysadmins aren't networking people. They don't necessarily understand the terminology of networking and they don't really care what the networking is made of. To them it's just a utility, just like you and I think of a plug. We don't care who made the plug, we just want the plug to give us power."
"Customers said,'we don't know what networking gear we're going to be connecting to, and we don't care. All we know is we want there to be a VLAN called 'management' on this port."
So Juniper's NetDev work began from a strange starting point for a networking company.
"The initiative behind NetDev was first and foremost to make it vendor agnostic," Jeremy says, but that isn't easy for networking vendors to hear.
"If you're a networking company, your whole world is about differentiation. How do we do something better and different from somebody else? While people in system administration will take that for granted, and enjoy the abstraction framework that Puppet provides, in networking we don't have anything like that. Our customers want that. They're in a lot of pain around dealing with heterogeneous networks."
And in networking, heterogeneity is the rule.
"Most customers have heterogeneous networks," Jeremy says. "It's not an all-Juniper, all-Cisco or all-HP network. It's a mixture of things because as companies build and grow and buy, it's a mix. It's a really painful experience to manage the network."
The NetDev initiative has passed the most crucial test to its claims of vendor agnosticism, Jeremy says, as it's in use not only by Juniper, but Juniper's networking rival, Arista Networks.
"Both companies have a Puppet module that implements the same types. That's a really amazing thing to see in networking, because we're competitors."
Going to PuppetConf
Jeremy will be speaking about networking and Puppet Labs technologies at PuppetConf 2013, focusing on the automation challenges faced by the networking community and the opportunities provided by the NetDev initiative and other technologies.
He's also looking forward to being a participant.
"By and large, what I'll really enjoy the most is meeting DevOps people and understanding how they approach large, complex automation. Learning not only what they're doing with Puppet Labs technologies and the techniques that they use to do advanced, sophisticated things like external node classifiers and report generators; but learning about the problems they're solving by integrating new technology. My area of interest is to understand how they're applying these things and to see if I can use these same patterns and apply them to networking."
Read Jeremy's own writing on bridging the worlds of system administration and networking.
The recently released Puppet Enterprise 3.0 is built to make software-defined infrastructure a reality, including your networking resources. Download it and try it on 10 nodes for free.