NOTE: Due to the epic fail of my previous blog hosting service provider, tsoHost, I've had to recover this post from the Wayback Machine.  Consequently some of the links and formatting might be off.  Sorry about that.

Well, not quite... but at first glance this was my exact reaction whilst watching the Brocade presentation on the Network Field Day 12 (NFD12) 1 live stream, and it's not really that far from the reality.  In case you are not aware, IFTTT 2 is "If This Then That"; you create "Recipes" that give you some control between apps and internet connected devices.


I'm going off on a tangent from the topic at hand, but to give you a quick example, a recipe I have written 3 uses the "Date and Time" channel, along with the Philips Hue 4 one. You drag and drop these together to create your recipe, and configure a couple of parameters that IFTTT gives you control of. Behind the scenes, these channels are effectively scripts that call various APIs of the devices and applications in their catalogue.

Tech Field Day


Before I go on, let me just mention the fantastic work the Tech Field Day 5 team are doing, putting these events together, and for sharing them via livestream. You'll be able to see all the recordings of the NFD12 event as well, subscribe to their YouTube channel 6 for more.


I highly recommend checking out the schedule of upcoming events; NFD13 7 is already in my calendar for November!

Event Drive Network Automation


Brocade 8 closed out NFD12 with their presentation on Brocade Workflow Composer 9 aka StackStorm 10. Brocade purchased StackStorm a few months back 11, with a view it would seem to build in the networking use case... which is where Brocade Workflow Composer comes in.


What made their presentation so interesting for me was that in years gone by this would have been entirely the wrong audience to be presenting the product on show. It's a sign of the times that DevOps, ChatOps 12, and NetOps (if I may be so trite) can be conflated into a single platform, and discussed to a room full of multi-CCIEs.

Whilst it was obviously tongue-in-cheek with the #SDNoIOT, given the overuse of both acronyms these days, I'm actually starting to that this isn't too far from the mark either.


As the presentation continued, I struggled with real network use cases. I suppose it needs a viewpoint shift, which I wasn't making, however Ethan Banks co-founder of PacketPushers, (who produce the best networking podcasts available BTW), had some interesting ideas. They network demo covered deploying an IP fabric (based on BGP EVPN overlay):

But building an IP fabric isn't the exciting part of @Brocade Workflow Composer. Seeing fabric build as merely a POC. #NFD12
— Ethan Banks (@ecbanks) August 12, 2016

A couple of ideas he had that made me think about what could be achieved:

.@Stack_Storm use case I can imagine. Link in a port-channel starts throwing errors. Alert. Shut down link. #NFD12
— Ethan Banks (@ecbanks) August 12, 2016

OK, that sounds pretty cool... but how about:

.@Stack_Storm use case I can imagine. Environmentals start going wacko on a switch. Alert. Bleed off traffic. #NFD12
— Ethan Banks (@ecbanks) August 12, 2016

I really like this idea, it had me thinking about a matrix of symptoms that you could build into the code that drives this, with different recovery actions depending upon the information gathered. In some cases you might start shutting down interfaces, or perhaps costing out links in your routing protocols for example. It would make recovery actions predictable, and scripted.


Before we go any further, let's take a quick look at the StackStorm and Workflow Composer platforms. I won't do the product justice by trying to describe it here, and you'll get tired of reading! There are 2 short YouTube clips that, if you've reached this far and you interest is piqued, are well worth a little time.

StackStorm


The first goes through the general functionality and power of the platform. I think you'll see why it seems to be more about a broader DevOps methodology:


You'll notice things like Github, YAML files, and lots of code blocks. The GUI is there to help visualize, and simplify some of the tasks of managing code. When all's said and done though, the code (and workflows) are what add the functionality, and it's down to you to do this.


One thing I picked up on, around the 4 minute mark, is the the workflow around mitigating actions for an alert for low disk space on a server (clearing logs in the example). This chimes with some of the ideas in the tweets above. So are we starting to get closer to the network use cases...?

Brocade Workflow Composer


What has this got to do with networking then? Well, with some NETCONF and YANG under the hood, Brocade are working to make StackStorm/BWC the one stop shop for workflows that involve the manipulation and automation of network infrastructure.


Whilst the focus is on developing this for their own kit, since it is standards based, any vendors that supports NETCONF and YANG could also be configurable too.


Sadly there is no narration on this video, but you'll hopefully get the picture; this is more or less just an example to show what can be done.


The onus is on the network developers to add workflows here, becoming part of the community and sharing scripts on Github... I'm being facetious here to make the point about NetDevOps 13, and emphasise the sea change in the industry required to make this all a reality.


What I took away from this is that it seemed too manual. making modifications to the script to build each switch. When you consider scale out of fabrics like ACI is more or less that the controller senses the new leaf/spine, and adds it into the fabric automagically. The thing is, BWC is not really an SDN controller, and that's the thing that I keep struggling with.

Competitors?


I'm not sure there are any real competitors, in so much as this seems at first glance to be the first platform of it's type that is actively trying to push towards networking. It's certainly a bold move by Brocade, and that is to be applauded.


In some respects it feels like a souped–up Puppet, that reaches into the realms of post deployment/delivery of the infrastructure. In fact the goal as was described was to figure out what "day 2" systems should look like, by speaking to biggest players (Amazon, Netflix, Facebook etc.) in the DevOps and Internet world.


There are possibly a couple of mainstream products which offer some similar functionality, but are not really the same thing. Not least, of these differences being the free "community" offering that is available from StackStorm, in the spirit of open source.

I've been looking at CliQr 14 aka Cisco CloudCenter 15, recently, and whilst I'll save description for a later post, it's not too far away from a similar solution, but the feeling you get is far less DevOps.

One that I haven't really had a lot of time to look at would be VMware vRealize 16.

Positives (From a Network Perspective)


As I mentioned above, I think this is a very bold move by Brocade, and that is to be applauded. I think they are well ahead of the curve.


There are very real benefits for anyone brave enough to start steering their technology teams, and specifically network design and operations teams towards this style of delivery. Basic network automation around provision servers, new switches, allocating IPs and so on would be valuable to the teams that require the agility. Repetitive data gathering tasks when alerts are received in the NOC could be easily automated, to allow the engineers spend their time more effectively, and coming to conclusions on root cause more quickly.


Just building out the capabilities in those network teams would be beneficial, even if it never went to production. As a learning platform for network engineering teams, this would be a fantastic addition to any lab. The requirement for these types of skillsets is coming, so time spent playing in sandboxes slowly winning hearts and minds, and collaboration between across the teams will definitely invaluable. "Full-stack engineers" are what companies should be striving for, networking has been left in a silo for too long.


As far as I can tell, there is no real like-for-like competitor; and there is a free version with a ready made community! My view is that there is more appetite than there has ever been for multi-vendor/vendor-agnostic environments these days, so companies would be more likely to consider Brocade as their DC switch provider should this prove to be the right value proposition.


The biggest players are already doing this (albeit with their own homegrown solutions). If it's good enough for Facebook and Amazon, it's good enough for anyone... right?


Built with NETCONF and YANG standards! I'd love to see all vendors move to this as the defacto, and create the groundwork for even more innovation.

Not-So-Positives (From a Network Perspective)


I genuinely don't feel like there are "negatives" to talk about; it's too early for that from a number of different perspectives. Before I start, let me say this - I cannot wait to be proven dead wrong, and I hope I am (it would make my job a lot easier!).


I also would like to spell out, that none of this is a reflection of the technology itself; quite the opposite! It is very impressive, and likely very powerful with the right people building the right workflows. Essentially my views here are just a reflection of what I see as an industry that, whilst it is slowly becoming less so, is naturally resistant to change.


I see this as Brocade delivering what they have early into the market, and just see what happens in the wild, what questions and requests come back, feedback they receive and growing a community. This is a very standard practice is software development these days of course, but that is just not how network teams operate right now.


One of it's strengths is also one of the issues, given the industry today. The onus is on the customer to write the workflows, whether that be DevOps teams or indeed network engineers. In my opinion, Network Engineers would generally err on the side of caution on most things, and NOC teams are generally trained to be cautious of changes on the network. I cannot see that mindset changing in the near future, such that we would realistically be looking an automated recovery actions on any network infrastructure.


I see this kind of approach as being limited to labs, universities/research institutions, and very cutting edge technology companies who don't employ network engineering luddites :-). Migrating to an infrastructure with this kind of approach is very unlikely at this stage in my opinion, indeed it's a struggle enough convincing companies of the capabilities of what I see as very mainstream technologies like VMware NSX and Cisco ACI!


To do this in production in the real world, would need significant testing environments too. What happens when a bug in a bit of code, corrupts a number of workflows, and a false positive in one part of the network gives rise to a domino effect of mitigating actions that cause havoc across the network?
Whilst companies are adopting DevOps and moving forward with things like OpenStack, the network industry I know is still steeped in ITIL processes and change management controls that are antithetical to the deployment model that these platforms offer.


I still feel like this is a very DevOps-centric solution, that will have some useful capabilities in automation of spinning up new infrastructure and providing some network connectivity. The trouble is that isn't where the value is to be found.

Next Steps


I'm downloading a trial as we speak. Not only is this right up my street from a personal geek's perspective, there is no doubt in my mind this is the direction we are headed, I am just not sure the industry as a whole is ready yet.


What are your thoughts on this? Is this viable in the network in the near future, or hype that'll never see the inside of a real NOC? I'd love to hear your thoughts and examples, if nothing else but to help me with ideas for workflows I might be able to try out in the lab...

Links/References

  1. Network Field Day 12 page on Tech Field Day ↩
  2. Tech Field Day Twitter ↩
  3. Tech Field Day YouTube channel ↩
  4. Network Field Day 12 is coming in November! ↩
  5. What is IFTTT? ↩
  6. A collection of IFTTT recipes I have made ↩
  7. What are Philips Hue Smart Lighbulbs ↩
  8. Brocade ↩
  9. Brocade Workflow Composer ↩
  10. StackStorm ↩
  11. Brocade Buys DevOps & Automation Startup StackStorm ↩
  12. What is ChatOps? ↩
  13. NetDevOps: Networking Methods with a DevOps Mindset ↩
  14. CliQr Solutions ↩
  15. Cisco CloudCenter ↩
  16. VMware vRealize ↩