Why, for many, delivery automation is the Right Thing To Do right now
A couple of months ago, ZeroTurnaround, makers of popular development acceleration tools such as JRebel, halted their foray into the release automation space and killed off their LiveRebel product. ZeroTurnaround's Alex Laats recently followed that up with a post that tried to explain the renewed focus on development tooling by outlining why he felt "the market was not ready for release automation". Since LiveRebel competed with some of what our application deployment tool XL Deploy does (download XL Deploy today if you're interested, and if you're a LiveRebel user looking for a new solution, contact us for our migration programme :-) ), I was obviously curious to hear what he had to say. Looking at the various points raised, I have to say that I'm even more sure than before that, for many teams in organizations large and small, automating the delivery process is exactly the right thing to do. To start with, I think it's fair to say that the tremendous growth in interest in container solutions such as Docker or Apache Mesos, and the continued adoption of tools such as Puppet, Chef, Ansible, Salt, or indeed XL Deploy, clearly demonstrates that automation of the overall delivery process is a hot topic for many, many teams at this point. So, unless you adopt a very narrow definition of what "release automation" is (and the blog post talks both of "release automation" and "release management"), there is clearly significant market potential here. Of course, that does not immediately translate into users or sales figures, but it's a bit of a non-sequitur to deduce from the failure of a particular tool that there is no market for that entire category of products. After all, you wouldn't say that there is no future for photography just because Kodak went bankrupt. Looking at XebiaLabs, more than 100% year-on-year growth in the field of Continuous Delivery and Devops automation is clearly possible...and we are not the only ones. Of course, it is very important to ensure you identify those teams and organizations for whom automating the delivery process really is the most important problem right now. If your development team is in continuous merge hell and can't even get the code to compile most of the team, an amazing Continuous Delivery pipeline is probably not the first thing you need. And it is also very true that, as with any fast-moving space, many users don't actually know exactly what their biggest problems are. We find that helping users understand this is much more important than trying to wow them with all the cool features our tools (whether XL Deploy or XL Release) can offer. A user that doesn't really need your tool is not going to be a happy user, and making sure our users have an excellent experience and love working with our tools is our #1 priority. One "Truth" that specifically intrigued me was the: "Orgs focus on stability, rather than risk-free experimentation". I'm not sure whom Alex has in mind here, but I think this is pretty much exactly the opposite of what we are seeing - in organizations and teams from start-ups to the Fortune 100. Sure, nobody running a production system wants to experiment with that system just for the sake of it - and we would certainly not advise users that XL Deploy or indeed any of our tools is a "License to Try Lots of Stuff Out". The clear trend, however, is that not just Ops teams, but the business itself, realizes that improvement in the way applications and services are delivered and run is essential to the future of most organizations. The driver here is not frivolous experimentation, but plain survival. All in all, the takeaways for me here are clear:
- Identify what your biggest challenges are: automating your delivery process may not be #1 at this point.
- Have a real business reason for investigating release automation and other changes to your delivery process. Just wanting to experiment with new technology is not enough.
- If you are one of the many teams looking at automating your delivery and application deployment process at the moment, have a clear set of goals that your are looking to achieve and evaluate tools (like XL Deploy) against that set.