“[Caesar’s] purpose always was to keep his barbarian forces well scattered. During all of his campaigns in Gaul, he had a comparatively small army. His only means of success, therefore, against the vast hordes of the Gauls was to ‘divide and conquer.’”
– Harry F Towle, “Caesar’s Gallic War”
Throughout Roman history, and indeed the history of every large empire the world has ever known, divide and conquer has been one of the most reliable strategies for expansion and conquest. A tactic that exploits human nature’s preference for independence and autonomy, it is always more practical to engage with part of a whole rather than the whole itself. Conversely, populations that cannot unite will remain vulnerable to those which can. As Abraham Lincoln put it in a speech given in Springfield, Illinois on June 16, 1858, nearly two millennia after Caesar’s campaign in Gaul, “a house divided against itself cannot stand.”
The question of who is playing the part of the Roman empire today is an interesting one for the technology industry. Typically, when you speak with those shipping traditional on premise software today, their acknowledged competition is other on premise software companies. Much as the Gaul’s enemies, at least until Vercingetorix, were other Gauls.
At the OpenStack Summit last week, when posed the simple question of who they regarded as their primary competition, an executive representing a technical platform answered succinctly: “AWS. No question.”
That candid answer, while correct, remains surprisingly rare. It may not be for much longer, as the contrast in financial fortunes between Amazon’s cloud business attracts more and more notice, even amongst conservative buyers. For most of the past ten years, AWS has been hiding in plain sight, but its ability to sustain that below the radar success is being actively compromised by its success within the public market.
The story of Amazon’s ascent has been well chronicled at this point. As then Microsoft CTO Ray Ozzie acknowledged in 2008, Amazon had already by that point spent two years being the only ones taking the cloud seriously. Microsoft, to its credit, eventually followed fast but for them and every other would-be player in the market second place was the only realistic goal, at least in the short to medium term.
The less explored question is how those shipping on premise software might compete more effectively with the Amazon’s of the world. The answer of how not to compete, of course, is clear from both world history and recent financial history.
On a purely technical level, fragmentation is systemic at the moment, the new norm. Pick a technical category, and there are not just multiple technologies to select from, but increasingly multiple technical approaches. Each of these must first be deeply understood, even if they’re entirely new and thus difficult to conceptualize, before a technology choice can be made. And there are many such approaches to be studied and digested, at every level.
All of which is problematic from a vendor perspective. Making matters worse is that the commercial backers of these technologies are equally fragmented, which is to say they’re divided.
Consider the following chart on the microservices ecosystem from Sequoia:
"open source projects without a dedicated commercial effort are italicized" (from sequoia) pic.twitter.com/nA0YFCyIBk
— Chris Aniszczyk (@cra) March 15, 2016
Assuming one can properly understand the categories, and the differences in approaches between the technologies that populate them, and can evaluate the projects that match those approaches, what next? If you select NGINX, Kubernetes, Docker, Chef and Mongo, for example, what assurances do you have that these all work reliably together?
The answer, outside of rigid formal partnerships or broader packaging (e.g. CoreOS Tectonic), is very little. For all intents and purposes, each of the projects above and the commercial entities that back them are independent entities with different agendas and incentives. If you’ve ever tried to resolve a complicated failure involving multiple vendors, you know exactly what this means.
This is how the industry has done business for decades, of course. The majority of the incumbent technology suppliers, in fact, have revenue streams built on managing complexity on behalf of their clients. This complexity is also why strategies like Microsoft’s “integrated innovation” approach proved to be attractive. It’s not that each component of the stack was the indisputable technical leader in its field. It’s that they worked well enough together that long conversations about how to wire everything together were no longer necessary.
What if, in stark contrast to the industry’s history however, a competitive model emerged that abstracted traditional complexity away entirely? What if a growing number of difficult choices between specialized and esoteric software options gave way to a web page and a set of APIs for as-a-service implementations? All of a sudden, managing complexity – think large industry incumbents – becomes far less attractive as a business model. As does accelerating complexity by way of niche or specialized software – think point software products, which are now forced to compete with service-based implementations that are integrated out of the box.
With the advantages of cloud models clear, then, the obvious question is how alternative models compete. One obvious answer is to embrace, rather than fight, the tide. Many on premise software products will find themselves pivoting to become service based businesses.
But for those committed long term to an on premise model, new tactics are required. In a market that is struggling with fragmentation, solutions must become less fragmented. In some cases this will mean traditional formal partnerships, but these can be difficult to sustain as they require time and capital resource investments from companies that are certain to be short on one if not both. History suggests, however, that informal aggregations can be equally successful: the Linux, Apache, MySQL and PHP combination, as one example, achieved massive success – success that continues to this day.
The spectacular success of that particular combination is not likely to be neatly replicated today, of course, because the market has moved away from general purpose infrastructure to specialized, different-tools-for-different-jobs alternatives. There is no reason, however, that ad hoc stacks of complementary software offerings cannot be successful, even if some of the components bleed into one another functionally at the edges. If I was a runtime vendor, for example, I would be actively speaking with orchestration, container and database projects to try and find common ground and opportunity. Instead of pitching my runtime in a vacuum to customers considering public cloud options that offer a growing and far more complete suite of offerings, my offer would be a LAMP-like multi-function stack that customers could drop in and not have to assemble piece-by-piece, by hand. E pluribus unum.
This is not the market reality at present. Currently, vendors are typically heads down, focused on their particular corner of the world, built to viciously battle with other vendors in the same space who are also heads down. They’re divided, in other words, and preoccupied. This approach worked poorly for the Gauls. If history is any guide, it’s not likely to be any more effective for on premise software vendors today facing unified public cloud alternatives.
Join or die.
Disclosure: Amazon, Chef, CoreOS, Docker, MongoDB and NGINX are current RedMonk customers, while Microsoft is not at this time.
