My second “Secret Sunday” post back in August introduced Schprokits, a company founded by Jeremy Schulman, previously the Director of Network Automation at Juniper.

I was truly flattered when Jeremy invited me to be part of a small team testing early Schprokits code (and trust me, I am way outclassed by the rest of the testers!), and having had a chance to try out what is probably only a small proportion of the code, I thought I would take the opportunity to share some early impressions of the software.

TLDR: I’m having fun!

What Is Schprokits?

The Schprokits website says that it is “Inspired By DevOps. Built For NetOps.” Jeremy is trying to take the principals behind DevOps and apply them to something that’s usable by people who don’t program every day but want to automate their networks nonetheless. And so it does. Schprokits “coding” is based around Workbooks and those workbooks contain a number of Actions. Workbooks are written in YAML which is probably one of the easier formats to learn as it’s very human-readable. In case you haven’t seen YAML before, what do you think is going on in the code below?

  actions:
    - info: [obfuscated - no spoilers!]
      srx_address:
        state: present
        zone: global
        name: MaryJane-LAPTOP
        ipaddr: 192.168.1.3/32

You can probably guess that this creates a global Juniper SRX address book entry called “MaryJane-LAPTOP”, right? YAML makes it pretty clear what the hierarchy of information is, and that makes it relatively easy to work with, and undoubtedly easier than JSON or XML, I think. Data files and workbooks all use this simple format, which makes them eminently readable and fairly easy to create.

I need to take a moment to emphasize that I’m testing with the CLI aspect of Schprokits. There is an API in development, but for now this is the programmer’s way into automation – simple YAML files being fed to the Schprokits engine.

Integrations

The Schprokits core engine interfaces with a number of “integrations” – Schprokits schpeak for actions that are targeted at particular devices. In the test environment, Jeremy has made available to us integrations for NXOS, Junos, and Junos Security (i.e. SRX). The intellectually scary Jason Edelman has taken this a step further and developed his own integration for BigSwitch Cloud Fabric (please go read Jason’s blog post on Schprokits when you’re done here – his work on this is fantastic!). I couldn’t comment on how easy it was for Jason to develop his own integration, but it does speak volumes about the modular nature of the Schprokits code and the potential to support new platforms going forward.

Since I don’t have Nexus 9k switches available to test, I’ve been playing mainly with the SRX integration and seeing what I can do with that.

SRX Integration – Demonstration

Inspired by Jason Edelman, I was going to make a brief video showing some relatively simple SRX workbooks, because it’s easier to show than to describe. By the time I’d finished recording the demo, I realized I had almost hit 33 minutes. I hope you have time to watch it all though, because it’s kind of interesting I think.

I should add that in this demo I used IP addresses for the lab SRX hosts, but normally I’d use a hostname instead. Hostnames are fully supported by Schprokits (possibly even preferred), and I didn’t want you to get the wrong impression.

It’s pretty cool to watch Schprokits go off and configure stuff automatically. I have written my own perl scripts in the past to implement configurations through NETCONF and I have to say that when using Schprokits it’s nice to worry about defining parameters for an action rather than worry about sending XML RPC calls and interpreting the results for yourself. If there’s one thing you take away from the demo perhaps it’s that amazing things can happen off the back of really quite simple files.

An additional bonus is that if you can deal with the YAML aspect of this, you can apply the same logic to any other integration that’s made available as well. So now we have a multi-vendor solution that, while each action is specific to a vendor (at least, most of them are), the general method remains the same.

More to Come

I plan to revisit this topic as more features are added to the SRX integration, and as I develop my own skills with the Schprokits product. Suffice it to say that this is a refreshing change from doing actual coding, and I can really see the potential power of having some of the nastier stuff abstracted away from the end user, i.e. me!

Now is ze time on Schprockits vhen ve dance!

 

Disclosures

Under a Non-Disclosure Agreement (NDA), Schprokits provided me with a VMware image containing a working Schprokits installation, and this is where my testing has taken place. The demonstration video and this blog post have been reviewed by Schprokits prior to publication for technical accuracy and to ensure compliance with the NDA. However, my views remain my own.