March 23, 2017
by Matt Oswalt
StackStorm was proud to once again exhibit at SREcon this year in San Francisco. If you haven’t attended SREcon before, there’s really no better place to get in touch with so many SRE professionals that are pushing the envelope and redefining what it means to run a modern operations team.
This year, we brought a quite nifty, flashy demonstration that one of our core developers Matt Stone put together, involving Raspberry Pis, LEDs, and – of course – StackStorm! (He’s @BigMStone on twitter – tweet at him and tell him to write his own blog post on his creation – it’s really cool!)
This was my first SREcon, and hopefully not my last. I was very pleased at not only the high concentration of talented operations professionals, but also the quality of discussion held throughout the two day conference.
One of the things I noticed right away was the sheer number of attendees who just “got it”. I’ve spent a fair amount of my career advocating for more automated, modern approaches to operations, specifically within network infrastructure. Whenever dealing with new technologies or processes, it’s understandable that not everyone is on the same page, so it’s often useful to spend some time level-setting about the problem space.
However, at SREcon, this was very rarely necessary. Nearly everyone we spoke to was already convinced that concepts like “infrastructure as code”, and “event-driven automation” were useful, and was already looking to practice them. They were clearly dealing with challenges that required these new ways of running operations, and were beyond thinking about the problem – they wanted solutions.
One very common conversation with the audience at SREcon was the subject of where StackStorm fits in the rapidly changing world of operations. We think there are plenty of great tools in the monitoring space, and StackStorm integrates with them – we don’t try to act like a monitoring tool. Similarly, there are some really great configuration management tools out there, and we integrate with those as well. What we like to do is fit right in the middle.
Perhaps the best way of looking at this is to think about your own built-in procedures. I worked in operations, I know there are a multitude of things that an operations team must deal with each day – some planned, some not. For each of these things, there’s almost always a predetermined way of dealing with it. Log in to monitoring system. Analyze logs. View dashboards. Correlate information. Update configs. Restart services. This is a day in the life of an operations professional.
The StackStorm answer, then, is a simple one – commit those workflows to code. Whether it’s writing an Action metadata file so you can get started using your own scripts in StackStorm, or writing full-blown Mistral workflows to automate an entire remediation process, there really is no magic involved here – it is a matter of committing into “code” the same analysis, decision-making, and remediation you’d normally perform yourself, and letting StackStorm perform these tasks on your behalf.
This area of discussion resonated greatly with the audience at SREcon, and it’s clear that if you haven’t explored event-driven automation yet, the time has never been better to get started.
Fortunately for those in the Bay Area, StackStorm and LinkedIn are putting on the next Event-Driven Automation Meetup in Sunnyvale next week. These meetups are great because they focus on the same kind of things I like to focus on, which is the general ideas and concepts behind event-driven automation, with less of a focus on specific implementations. While there’s always a time and a place for getting into the technical weeds, it’s often useful to take a step back and talk about trends, and collaborate on what’s around the corner.
I will be flying in from sunny Portland to sit on the panel – but don’t let that discourage you…I hope to see you there anyways!
Matt Oswalt