Could Brocade’s StackStorm Deal Be the Start Of Something?

The acquisition of StackStorm by Brocade raises (again) the question of the best way to approach the automation of deployment and operations processes.  We’ve had a long evolution of software-process or lifecycle automation and I think this deal shows that we’re far from being at the end of it.  Most interesting, though, is the model StackStorm seems to support.  Might Brocade be onto a new approach to DevOps, to service lifecycle management, and to software automation of event processing with a broader potential than just servers and networks?

The end goal for all this stuff is what could be generalized as software-driven lifecycle management.  You deploy something and then keep it running using automated tools rather than humans.  As I’ve noted in past blogs, we’ve had a basic form of this for as long as we’ve had operating systems like UNIX or Linux, which used “scripts” or “batch files” to perform complex and repetitive system tasks.

As we’ve moved forward to virtualization and the cloud, some have abandoned the script model (also called “prescriptive”, “procedural” or “imperative” to mean “how it gets done”) in favor of an approach that describes the desired end-state.  This could be called the “declarative” or model-driven approach.  We have both today in DevOps (Chef and Puppet, respectively, are examples) and while it appears that the declarative model is winning out in the cloud and NFV world, we do have examples of both approaches here as well.

One thing that gets glossed over in all this declaring and prescribing is that software automation of any set of lifecycle processes is really about associating events in the lifecycle to actions to handle them.  This sort of thing would be an example of classic state/event programming where lifecycle processes are divided into states, within which each discrete event triggers an appropriate software element.  StackStorm is really mostly about this state/event stuff.

StackStorm doesn’t fall cleanly into either the declarative or prescriptive models, IMHO.  You focus on building sensors that generate triggers, and rules that bind these triggers to actions or workflows (sequences of actions).  There are also “packs” that represent packaged combinations of all of this that can be deployed and shared.  It would appear to me that you could use StackStorm to build what looked like either a declarative or prescriptive implementation of lifecycle management.  Or perhaps something that’s not really either one.

All of my own work on automating lifecycle processes has shown that the thing that’s really important is the notion of state/event handling.  A complex system like a cloud-hosted application or an SDN/NFV/legacy service would have to be visualized as a series of functional atoms linked in a specific way.  Each of these would then have their own state/event processing and each would have to be able to generate events to adjacent atoms to synchronize the lifecycle progression.  All of this appears to be possible using StackStorm.

In effect, StackStorm is a kind of PaaS for software automation of lifecycle processes.  As such, it has a lot of generalized features that would let you do a lot of different things, including addressing virtually any software-based feature deployment and utilizing scripts, tools, and other stuff that’s already out there.  The flip side of flexibility is always the potential for anarchy, and that means that StackStorm users will have to do a bit more to conceptualize their own software lifecycle management architecture than users of something like TOSCA (I think you could implement TOSCA through StackStorm, though).

As a pathway to automating cloud deployment, StackStorm could be huge.  As a mechanism for automating service lifecycle management in SDN, NFV, and even legacy services, StackStorm could be huge.  Played properly, it could represent a totally new and probably better approach to DevOps, ServOps, and pretty much everythingOps.  Of course, there’s that troublesome qualifier “properly played….”

I didn’t find a press release on the deal on Brocade’s site, but the one on StackStorm’s offered only this comment: “Under Brocade, the StackStorm technology will be extended to networking and new integrations will be developed for automation across IT domains such as storage, compute, and security.”  While this pretty much covers the waterfront in terms of the technologies that will be addressed, it doesn’t explicitly align the deal with the cloud, virtualization, SDN, NFV, IoT, etc.  Thus, there’s still a question of just how aggressive Brocade will be in realizing StackStorm’s potential.

The key to this working out for Brocade is the concept of “packs”, but these would have to be expanded a bit to allow them to define a multi-element model.  If that were done, then you could address all of the emerging opportunities with StackStorm.  What would be particularly helpful to Brocade would be if there were some packs associated with SDN and NFV, because Brocade is too reliant on partners or open operator activities to provide the higher-level elements to supplement Brocade’s own capabilities.

It would be interesting to visualize these packs as composable lifecycle management elements, things that could be associated with a service feature, a resource framework, and the binding between them.  If this were to happen, you’d need to have a kind of PackPaaS framework that could allow generalized linkage of the packs without a lot of customization.  This is something where a data framework could be helpful to provide a central way of establishing parameters, etc.

It would also be interesting to have a “data-model-compiler” that could take a data representation of a service element and use it to assemble the proper packs, and thus provide the complete lifecycle management framework.  This would certainly facilitate the implementation of something like TOSCA (and perhaps the ETSI NFV model with the VNF Descriptor) where there’s a data framework defined.

The last “interesting” thing is a question, which is whether something like this could effectively take the “Dev” out of “DevOps”.  Many of the tools used for deployment and lifecycle management were designed to support a developer-operations cooperation.  That’s not in the cards for packaged software products.  Is StackStorm agile enough to be able to accommodate packaged-software deployment?  Could “packs” represent packages to be deployed, perhaps even supplied by the software vendors?  Interesting thoughts.

We may have to wait a while to see whether Brocade develops StackStorm along these lines, or even to see what general direction they intend to take with it.  But it’s certainly one of the most interesting tech M&As in terms of what it could show for the buyer, and for the market.