One of the inherent tensions of product marketing is that of push versus pull. On the one hand, product companies tend to want to push their news on the market. On the other, markets have their own interests, and want to pull news related to that from product companies. At times, there is little to distinguish between the two. Often, however, the two are in conflict and competing for supremacy. This is particularly true at large events, where the industry norm is still, even in a world with ever diminished attention spans, to horde announcements in an effort to generate an outsized marketing impression.
There’s no solution to this issue per se. The best that can be hoped for, in most cases, is that those charged with pushing the news are cognizant of the actual interest and demands, not just broadly but on an audience by audience basis.
If it accomplished nothing else at its annual Next event, Google showed an ability to tailor its message to the audience in question. Per a discussion on our internal RedMonk Slack instance, in fact, it’s not clear that we have ever attended an event where the messaging between its analyst day and the main event diverged so dramatically.
As but one example, consider the fact that industry analysts as a group tend to be more interested in enterprise logistics than the average practitioner. The analyst day at Next, therefore, was awash in detail on improvements Google has made to its ability to engage with enterprises – literally down to contract redlining procedures. On the main stage, however, the parade of traditional enterprise brands notwithstanding, the majority of the focus was on the product side.
Whether this was intentional on Google’s part was unclear, but the net was one set of product announcements covered by two materially different sets of messaging, each of which was optimized for its respective audience. It is always difficult to reconcile the push versus pull tension, the delta between what the company wants to talk about and what the market wants to hear, but this year’s Next inarguably featured the best and cleanest messaging in the history of the event.
Setting issues of high level marketing strategies aside, however, the questions to be asked in the wake of this event were obvious: what did Google announce, and what does that mean for the company and the market around it?
It’s difficult if not impossible to concisely summarize an event the size and scope of Next, but here are three important takeaways from the event.
- Anthos and the Middleware Opportunity: One of if not the most significant announcements at Next was the curiously branded Anthos, née Cloud Services Platform. While there was some confusion in terms of exactly what Anthos is, one answer is that it’s middleware for the cloud. As long time market observers might remember, middleware was at one time one of the largest single software markets in the industry. Dominated by the likes of Oracle via its acquisition of BEA and IBM with its WebSphere offering, middleware was a level of abstraction that let you run Java applications without having to concern yourself with what operating system or hardware platform was underneath them.
As cloud infrastructure and the hardware/operating system conflation and development model shifts that implied began to complement and then supplant existing enterprise infrastructure, an appetite for a similar level of insulation between the application and the infrastructure it ran on began to manifest itself. This did not go unnoticed, particularly by veterans of the original middleware wars, and a new crop of software emerged that began to attack this problem. This is why Platform-as-a-Service offerings such as Cloud Foundry, as one example, have historically been characterized here as the new middleware.
Both because the term is unsexy and because large swaths of the current developer population lack the history to be familiar with it, middleware did not appear on any Google slides. But functionally, that’s exactly what the software offering from Google is. It’s a software abstraction based on open source technologies such as Kubernetes, Istio and the like that runs in Google’s cloud, of course, but also on prem or in competitive clouds offered by the likes of Amazon or Microsoft. As classic middleware once decoupled application decisions from operating system and hardware decisions, Anthos is built to render application decisions distinct and separate from questions of the cloud environment – public or private.
Those familiar with the history of the Kubernetes project will recall that part of its purported justification – both in terms of its creation and in terms of it being released as open source software – was providing a similar level of isolation between the container and the environments in which they ran. But Kubernetes’ dramatic rise and inarguable current dominance have not obscured the fact that, by itself, it is not an application platform. There’s a reason that Red Hat’s OpenShift distribution includes software above and beyond what vanilla Kubernetes provides, which is the same justification for Anthos.
Speaking of Red Hat, they’re also an answer to another frequent question at Next, which was why Google devoted such a large share of its time to news about the project. The answer, at least from here, is the size of the market opportunity – at least in theory. There are those who are skeptical of the middleware market, which is fair given both current market conditions and the history of the middleware execution. It is worth noting, however, that of the drivers for IBM’s $34B acquisition of Red Hat, the business with the most projectability moving forward was OpenShift.
From this perspective, the question around Anthos is less market opportunity than its ability to execute. With the exception of recent efforts such as GKE On Prem, Anthos is a very different business from what Google has run previously, and will require very different skills. It is attempting to be not just a hyperscale cloud provider, but an enterprise class software vendor, and while those may have the same customers they are very different businesses to run. Time will tell whether Google has what it takes to run a business like Oracle within its traditional cloud business. And speaking of Oracle and enterprise software businesses… - Google and the Enterprise: This year’s Next was much anticipated in the ranks of industry analysts, at least, because it would mark the debut of Thomas Kurian, brought in to replace Diane Greene. Greene herself was tasked with solving a simple problem: for all of its vaunted technical prowess, Google’s ability to go to market in the enterprise has been comparatively weak. Amazon was the originator of and incumbent in the cloud market, Microsoft was leveraging its massive account presence to shoehorn Azure into second place. Google had no comparable foothold in enterprise accounts, and on top of that had handicapped itself by having thousands fewer feet in the street.
While she made some progress in turning the company’s reputation in this regard around, particularly in the largest, targeted accounts, Greene gave way to Kurian who came in with the expectation that the company would be doubling down on the enterprise footprint. Which, if the analyst day is any indication, is more or less what’s transpiring.
Next was not only a showcase for new products like Anthos, or a detailed discussion of specific improvements in its enterprise go to market: it was an admission of lessons learned from at times negative feedback. Instead of showing up and talking about how to “run like Google,” there was talk from executive after executive of having empathy for the customer and understanding that – even for those that might, someday, have the ambition to live on the cutting edge – given the short lifespans of senior technology executives, most of them had inherited a “mess.” Having attended every one of Google’s Next events to date, the step back from a more or less pure engineering focus to one including candid discussions of what the company and more specifically the sales teams believed they needed to and have addressed was new. And necessary.
Google’s go to market has long been perplexing to industry observers. For a company whose technology is by and large trusted and respected but whose go to market has often perceived publicly and privately as problematic, it’s spent an awful lot of time talking about its technology. Part of that, of course, is the importance of marketing to strengths. But even as the company’s cloud unit matured, its ability to interact with the field at scale was fractured at best, delivering some exceptional outcomes with a much larger number of frustrated users – actual or would be – unable to get the attention they needed.
Those walking away from Next this year can be assured, at least, that Kurian and by extension Google is taking this problem seriously. From high level approach to minute levels of detail, progress is being made. The primary question is less intent, then, than the ability to execute. In spite of record levels of hiring, Google needs to bring on talent even faster still. Historically, the company’s exceedingly high bar has resulted in a narrow enough aperture that teams are constantly short on talent. Reportedly, however, the company has no intentions of adjusting its benchmarks. How it will reconcile its premium standards with a need for volume talent is as yet unclear.
- Commercial Open Source as a Means of Differentiation: As a market competitor, Amazon has tended to leave very little oxygen available for would be competitors. Not only was it first to market, it has declined to rest on its laurels and has instead evolved its product portfolio at a rate and pace not seen before in this industry. From a competitive standpoint, then, there have been few opportunities for potential threats to Amazon to differentiate and outflank it. The release of Kubernetes arguably caught it on the back foot for a moment, but after the briefest of pauses AWS embraced the technology and continued on its way.
If AWS has had one glaring vulnerability, however, it has been open source. The company’s relationship with open source historically has been fraught and characterized by accusations of profiteering and strip-mining. And with notable exceptions such as reseller agreements with companies like Chef, Amazon’s practice of picking up and offering AWS service versions of open source projects such as Elastic, Hadoop, MySQL, Postgres and others – or API-compatible reimplementations such as DocumentDB – has not won the company many friends in open source ecosystems.
A few years ago, however, AWS – in keeping with its perpetual innovation habits – seemed to have self-identified this weakness and worked to close it with the instantiation of an open source programming office led by Adrian Cockcroft. This unit has worked to normalize relations with open source communities, streamlined upstream contribution policies and more. This further reduced the attack surface of open source and AWS.
It notably did not eliminate it, however, particularly in the case of commercial open source providers. Tensions between these smaller software organizations and hyperscale cloud providers generally and AWS specifically have been running high. Whether their fears were reasonable or without evidence as some argue, multiple commercial providers openly broke with open source norms and began actively blurring the lines between open source and commercial software by commingling open and proprietary code, re-licensing their software and more. They did this, amidst major outcries from a variety of open source communities, because they were concerned that AWS would take their software, offer their own branded service and in doing so harm – potentially irreparably – these commercial software organizations.
The difficulty for many of these providers, however, was that AWS was essentially just responding to customer demand. Increasingly, enterprises are choosing to completely outsource the operation of the software over purchasing and running it themselves. Even if commercial open source providers somehow managed to thread the needle and release open source software in a way that made it unpalatable to AWS, the demand from enterprises for managed services like those provided by AWS was present and growing. While some such as MongoDB have managed to spin up their own managed services, for many smaller commercial organizations the prospect of running an enterprise software development business and, simultaneously, a cloud managed service business has been a bridge too far.
In one corner, then, you have had commercial open source providers terrified of AWS, who have great demand for their open source software but many of whom lack the capability to run a managed service business. In the other, you have cloud providers who know how to run a managed service but have comparatively little native demand for their software but who are desperate to compete with AWS. RedMonk has not been, it can be assumed, the only organization pointing this situation out.
Among the commercial open source providers that have been concerned enough about AWS to make changes to their license structure are Confluent, Elastic, MongoDB, Neo4j, and Redis Labs. On Tuesday, Google announced “strategic partnerships” with the same companies: Confluent, Elastic, MongoDB, Neo4j, and Redis Labs – along with DataStax and InfluxData.
To be clear, Google is obviously not the first cloud provider to partner with these or other commercial open source organizations. Microsoft’s Azure team in particular has acquired a sterling reputation for open source partnerships, and commercial project providers sing their praises every year. Even AWS is partnered with a host of organizations through its Marketplace. The partnerships here appear to be more strategic, however, going beyond tablestakes such as unified billing to UI integrations, centralized support and tie-ins with GCP services from StackDriver to IAM.
AWS’ strategy with respect to open source historically has been to provide a platform for all, and in the face of sufficient demand to spin up its own native services around a popular project. This has created an opportunity for would be competitors to position themselves as the preferred platform for smaller, independent commercial open source providers, and indications were at Next that Google intends to pursue this opportunity. Such a move would not have much impact on the overall health of the open source ecosystem at large as has been said, but it could certainly be differentiating for Google and simplify the service go to market for smaller commercial authors of open source software. It could be, in other words, a win for everyone involved.
Disclosure: Google is a RedMonk customer and paid T&E to the event. Amazon, Confluent, DataStax, Elastic, InfluxDB, Microsoft, MongoDB, Neo4j, and Red Hat (OpenShift) are also RedMonk customers. Redis Labs is not a RedMonk customer.
