Juniper has not been a strategic or positioning giant, in my view. That makes its recent decision to acquire HTBASE harder to read, because HTBASE just might be a very strategic company. Does Juniper see the reality behind HTBASE or is it just floundering around for something to boost its revenue and market position?
HTBASE is a player in what I’ve been calling the “infrastructure abstraction” space. The biggest problem in the automation of application lifecycles (and service lifecycles, for that matter) is the lack of homogeneous infrastructure in the resource pool. You need hosting, data, and connectivity to support applications, and these can be provided in a bewildering number of different ways. All that diversity is the enemy of operational efficiency; the more different ways there are to do something, the less likely anyone will do it efficiently, or even correctly.
When you try to apply software tools to lifecycle management, differences in infrastructure mean that individual tools will at the least require custom plug-ins to work with the various types of infrastructure that might be in the pool, and at worst it may be difficult to adapt the same overall lifecycle processes to all the possible infrastructure elements. Custom integration lies in the middle, and that’s what often happens.
The alternative to having plug-ins associated with lifecycle management (orchestration) tools is to have an abstraction layer harmonize all infrastructure to look the same. Now one setting for the toolkit works everywhere, because “everywhere” is harmonized to an abstract infrastructure model set (hosting, data, connectivity). Large-scale virtualization has used this approach through Apache Mesos, DC/OS, and Mesosphere, and I’ve said many times that Kubernetes, the go-to-strategy for container orchestration, is heading toward that.
HTBASE’s product, Juke, is an infrastructure abstraction tool that creates a control/data fabric across a very wide variety of infrastructure, wide enough to include multiple diverse public cloud providers as well as a variety of data center platforms. Juke is arguably the additional ingredient needed to turn Kubernetes (or other orchestrators with suitable APIs) into the futuristic orchestration layer I’ve been saying will develop for all public and hybrid cloud services.
Given that Kubernetes is today’s strategy, and given that “rich orchestration” is the strategy of the future, HTBASE and Juke have the potential to be incredibly strategic, which begs two questions. First, how did these guys stay independent for so long? Second, how did Juniper, hardly the king of the strategic hill, figure it out? The answers may be related.
Juniper’s press release on their intent to acquire HTBASE is a masterpiece in obtuse wording, or perhaps thinking. “HTBASE’s unique value is its platform’s ability to make the complete infrastructure layer (compute, storage and networking) transparent to applications, without impacting the operating system or architecture.” What the heck does that mean? How can applications not know about infrastructure? The simple answer is that they have to know, and that’s the problem that really needs solving and that HTBASE solves. It’s not making applications unknowing that’s the goal, but making them only know about one model of infrastructure when the real-world pool is already incredibly diverse and getting more so every day. Abstraction doesn’t make something disappear, it makes everything look the same.
How does that answer the questions, though? Well, the first piece is that the industry has never gotten its head around the whole notion of abstraction as a tool in harmonizing and simplifying things. Even HTBASE’s own website says it builds a “multi-cloud control and data fabric”, which isn’t much of an explanation for the value proposition. It’s the classic mistake of talking about what you do and not why somebody cares. HTBASE thus has an impenetrable story, and like most tech companies, ineffective positioning of its real assets. Combine this with a media world driven by sensational claims, and you have a prescription for being missed. So they were, and everyone else in the space has been similarly unable to tell their story. Thus, no story and no market awareness.
Juniper then found HTBASE by being incredibly clever? If that were the case, their press release would have positioned them intelligently. No, they found HTBASE because Juniper had previously been pushing multi-cloud as their differentiator (particularly for Contrail, which is mentioned in the HTBASE release), and so HTBASE’s notion of being a multi-cloud control and data fabric probably hit Juniper right between the eyes.
Should we call this “serendipity” then? That presupposes a happy outcome. The concept of serendipity is often described as “digging for worms and finding gold”. Digging for worms and finding worms wouldn’t qualify. Digging for worms, finding gold, and sticking the gold on a hook to catch catfish would qualify even less. The question with Juniper and HTBASE is really the same as the one with IBM and Red Hat—does the acquiring party know what they got and what to do with it?
Fewer than 5% of business public cloud users are likely multi-cloud users, though the number rises to about 25% of enterprises. However, all enterprise public cloud users and over 80% of business public cloud users are likely hybrid cloud users. Hybrid cloud is clearly the market direction to follow, and if the numbers don’t prove that consider the fact that hybrid cloud is the universal market target for the cloud providers themselves.
Abstract infrastructure for application deployment, if tied to hybrid cloud, is very smart. If tied to multi-cloud, it’s a niche, particularly since multi-cloud in nearly all cases is a special case of hybrid cloud (we found zero users in surveys, other than social media or video startups, who were multi-cloud without hybrid cloud dimensions). Juniper’s positioning targets the niche, not the market.
Part of the reason may be that according to users themselves, the companies in the best position to sell hybrid cloud are companies who sell data center technology. IBM and Red Hat, however improbable it may be that the combination gets their direction and positioning right, are at least in a position to exploit their strategy if it’s correct. Can Juniper, who has a fairly dismal M&A record and a very narrow profile of strategic influence in the data center, leverage HTBASE even though it’s the right answer? Does Juniper even know that it is?
History says Juniper will boot this, and certainly there’s no signal in the press release that they have any idea what they have or what they could do with it. But they blundered into a good M&A, and maybe they’ll stumble into a thoughtful positioning and marketing strategy for HTBASE. I still have a lot of friends there, so I can only hope.