Recently, ZeroTurnaround did what very few high-growth companies have the freedom to do. We terminated a product line. On top of that, we are more than happy to talk about the reasons why. In short, we have come to the conclusion that, in the world of software, the business opportunity for the next 3 to 5 years is to provide tools to DEVELOP quality software faster. In short, it’s all about developers. More on that later.
When we decided to gracefully end the life of our LiveRebel product and provide all of our customers not only with a refund of their money but also support and assistance for a full year in order to help with transition to an alternative solution. Even though we built a great product that is easy to download, install and use for automated release management, the market simply isn’t ready for it.
We’ve learned a lot about the software development industry over the years and feel pretty comfortable sharing some of these ideas here. So came up with a reasonable list of 5 things that led to the early retirement of LiveRebel. If we have time later, we’ll dive deeper into each one of these.
Inconvenient Truth #1: The market for release management is too immature and chaotic
A lack of standards, widely-used “early stage” best practices for managing releases in production and a general lack of concrete details around this critical process is what we have today. For example, how would you, compared to your competitors, define “release automation”? With the exception of “risk free”, you might find yourself with completely different ways of explaining it all.
Inconvenient Truth #2: No one knows what “release automation” means
That seems off: why isn’t there any widely-used process or set of standards for release automation? Well, it seems that the average organization is dealing with worse problems than not having a picture perfect, automated release pipeline, and therefore the luxury of defining a process still seems like a non-priority. As Jevgeni put it:
“Release management was not anywhere near the top problems for a typical potential customer. Release management provides little value if you don’t have automated builds, provisioning and a well-defined release process and unfortunately most potential customers would have none of those.”
Most of our potential customers were just getting used to Continuous Integration and using mocking frameworks, and here we are talking about fully-automated release management at the click of a button. It’s like being given a spaceship to go to the mailbox.
Inconvenient Truth #3: The few tools utilized are often not meant for release management
In response to the lack of great solutions for release automation, some adventurous Ops teams (or Devs in Ops clothing perhaps) started seeing what could be achieved with some proven developer tools. Tools traditionally created by devs for other devs, like Jenkins, Vagrant, Puppet & Chef have started appearing in the Ops space, often being used in creative, in not originally-intended ways. Jevgeni writes:
“Virtual images, microcontainers, configuration management and build servers were all used for release orchestration. Even then, our typical competitor was still just a bunch of bash scripts with a wiki.”
From a short-term solution perspective, why not? But all this does little for defining a set of reliable standards and processes for tooling to embrace and enhance. The margin for error is higher with tools not designed for release management, and so taking risks with productions systems is usually frowned upon–and this has defined an additional factor in Ops culture: lack of risk-free experimentation.
Inconvenient Truth #4: Orgs focus on stability, rather than risk-free experimentation
Without a good set of standards and the tools needed to follow best practices, it’s hard to try new things out. In the end, any sane organization would take stability over experimentation–but the need to evolve is unavoidable, so eventually even those out there using Java 1.4 still will need to grow.
Maintaining separate, mirrored environments for sandboxing new tools and processes is nothing especially novel, but until release automation can become better defined and safer to manage, then the likelihood of iterative improvements through experimentation will likely be a barrier to improvement efforts. If only there was some supportive, creative community for Ops to turn to…
Inconvenient Truth #5: An impactful, global community, like Java User Groups, doesn’t exist for Ops
Software engineers, especially those coding for the JVM, have long enjoyed an incredibly impactful community that is so complex that our own RebelLabs is preparing a 30-page report about the overall Java community ecosystem.
Being a much younger but increasingly critical segment of the industry, production teams in Operations are not only considerably fewer in population (at ZT the ratio is about 9:1 :: Dev:Ops), but also lacking a great, centralized community. The DevOps movement is still around, yet still not taking the community by storm.
Without the blessing and involvement of the enormous developer community, the next 3-5 years are expected to be a formative period for operations communities.
Conclusion: Developers will lead the future and initiate change
With the situation as it is and our predictions for the market in the next 3-5 years, we believe Development tools and practices will become more influential and eventually serve as the foundation for Operations tooling and best practices. Along the way, it should be strengthened by a “developer user-group” style of community and culture. It’s with this in mind that we decided to put the majority of our brainpower towards JRebel and XRebel, two revolutionary tools for developing quality software faster. Our goal is to encourage developers to carry forward their momentum in order to reach the goals also shared by Operations teams and entire organizations.