See Schprokits Dance! Demo of Unreleased Code

Schprokits LogoMy 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?

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.

5 Comments on See Schprokits Dance! Demo of Unreleased Code

  1. As a side note, Jeremy Schulman pointed out to me that I had defined policy_list twice in my YAML file, so the first rule was actually going to be ignored. Yep – that was a, erm, deliberate decision to, um, test how Schprokits would cope with an inept user creating data files. Or something. It coped admirably (and actioned the second instance). What I really meant to do of course was to have a single policy_list entry with the two rule numbers within it. Sorry about that!

  2. Great work and we need smth like this for networking, though one cant help but compare “workbook” with “playbook”, “actions” with “tasks”, etc.

    • That’s pretty deliberate. Having things named similar and performing the same types of functions will only make this get adopted quicker. Smart move IMO.

      The networking world definitely needs this. Ansible (and to some extent Puppet/Chef/Salt) are usable, but networks have a different workflow from servers and that’s why this is so important.

Leave a Reply

Your email address will not be published.


*


 

This site uses Akismet to reduce spam. Learn how your comment data is processed.