Jeremy Schulman was the driving force behind the Puppet agent that Juniper implemented on some Junos switches (one of the first fully supported Puppet-on-a-switch implementations). In the meantime, he quit Juniper and started his own company focused on a network automation product – more than enough reasons to chat with him on Software Gone Wild.

We couldn’t help but start with Puppet agent on Junos:

• Why did Juniper create a Puppet agent on a switch?
• Why was it limited to creating VLANs?
• How can you limit the changes an automation tool can trigger?
• Why is Junos API the same as manually typing the commands?

Jeremy also told us a lot about his new baby:

• What is Schprokits?
• What are the basic ideas and concepts Schprokits uses?
• How is Schprokits different from Puppet, Chef & Co? How is it different from Tail-f NCS?
• Which vendors does it support? How horrible are their APIs?
• Why is it (among other things) yet another template building tool?
• How is Schprokits reducing the execution gap… and what is the execution gap?
• Does Schprokits have an OpenStack demo and why does that question sound like turtles all the way down?
• When will we see the product? Can I download it and play with it?
• Will Schprokits be an open-source product? What’s the go-to-market strategy?

Finally, we couldn’t resist going down a whole field of rabbit holes:

• What is the difference between DevOps and NetOps?
• What is a blast radius and why is it important?
• Why is it hard to use configuration management tools like Chef, Puppet or Ansible in networking?
• What is YAML and why is it better than JSON or XML?
• Why is screen scraping a really awful idea?
• What is the architecture of disagreement in networking?
• Why will we never agree on the northbound API?
• Why is “we have an API to do that” not always the right answer?
• What does “idempotent” mean… and do we really have to learn all these crazy new words?

Enjoy the podcast and don’t forget to subscribe to the Software Gone Wild feed.