I mentioned yesterday that Google had a new slant on being a competitive cloud provider, one that focused on combining open-source tools to create a true hybrid cloud platform. The move is important, maybe even critical, to both public cloud competition and cloud vendors, but it’s still a bit of a work in progress. I want to take a look at the Google initiative, Anthos, based on the best available information, and see how and when it might impact the concept of enterprise cloud computing overall.
Anthos is a rebranding of Google Cloud Services, but also a reframing of the mission itself. Anthos takes Kubernetes as a starting point, adds in some other important “Kubernetes-ecosystem” pieces, and creates what is effectively an abstraction of container hosting that can be applied to both data centers and public cloud services to create a true and fully integrated hybrid cloud. What’s interesting about the latter option is that Anthos would also work with competing cloud provider’s offerings.
It’s not hard to see why Google would take this tack. Hybrid cloud, meaning the combination of data center hosting and one or more public cloud offerings, is the preferred strategy for enterprises in deploying their current and future applications. While the cloud computing market overall has gone convincingly to Amazon, hybrid cloud is the fastest growing segment of that market and it’s far from owned by any single cloud player at this point. In fact, hybrid cloud may be the most significant driver of premises-centric Kubernetes container ecosystems like Red Hat/IBM’s OpenShift, VMware’s PKS Enterprise, or Rancher.
At a deeper, perhaps more cynical, level, Google has to face the fact that it’s just short of being an also-ran in the public cloud space. If IBM manages to leverage its Red Hat acquisition optimally, it could slip decisively into third place in public cloud computing, and that could doom Google’s own cloud offerings to permanent obscurity. What Anthos does is extend the “hybrid cloud” notion to mean a hybrid of data center hosting with multiple public clouds. That’s likely to be a future requirement, but even in the present it offers a nice and easily explained differentiator. Google’s container cloud is inherently hybrid cloud, and hybrid with anyone and everyone.
Virtually everything related to hybrid cloud these days is linked to Kubernetes, but Anthos adds in two other fundamental elements—Istio for service mesh and Knative for serverless hosting. Neither of these are household words, but Knative’s role in hybrid cloud is probably the best-kept secret in the industry now, so we’ll start with a look at what these two tools offer.
A service mesh is a means of connecting independent microservices so as to facilitate things like component reuse, load balancing, resiliency, and security. Any container-based application set that intends to broadly reuse components really needs a service mesh as much as it needs Kubernetes. It’s interesting to note that both Red Hat and VMware have also just integrated Istio, Google’s service mesh technology, in their own Kubernetes-based container management suites.
Without a service mesh, the use of shared, scalable, resilient microservices is a combination of complex issues. You need to have virtual networking to make connections for the workflows, you need load balancing, service discovery DDoS protection, and of course deployment and redeployment. Service meshes integrate all of this with Kubernetes, which makes the use of true microservices much easier.
Knative is a bit harder to explain, partly because the concept of “serverless” computing has gotten conflated with public cloud services of the same name. It’s probably better to think of Knative as being a kind of logical evolution of containers. Rather than just having containers represent a sort of “portable deployment”, Knative aims for “resourceless” deployment. Containers are still representatives of persistent hosting, and Knative adds a tactical on-demand hosting dimension to the picture. It provides for what’s called a “scale-to-zero” capability, meaning that under very light loads a microservice might have no committed resources at all, and then scale up as load increases.
Kubernetes, Istio, and Knative combine to build a realistic framework for what’s called a “cloud-native” applications deployment model. Hosting is totally abstract, workloads are balanced and resources scaled, through what’s effectively a unified-logically but distributed-physically middleware layer. Underneath this abstraction is whatever you want—data center resources, public cloud, whatever.
One of the nice competitive impacts of an abstraction layer like this is that it renders a lot of stuff invisible, which is what you’d like your competitors to be. If applications are built on the Anthos model, they are fully portable across clouds and data centers, which limits how much others can differentiate themselves. Full portability of applications surely helps an aspiring cloud provider more than it helps a dominant one.
Speaking of competitive impacts, Anthos may be a step toward defeating what could be a blossoming relationship between VMware and Amazon, or Red Hat and IBM’s cloud. By making full abstraction and generalizing of hosting resources, including public cloud, Anthos could make any tighter relationships between cloud providers and premises vendors look limiting and even sinister. It could elevate the hybrid battle from where it is today (cloud providers having a premises solution they link with) to where users would really like it to be (wherever you host, we have you covered).
Anthos could also impact managed container service offerings by the public cloud providers. If users are able to deploy their containers easily across multiple clouds and their data centers, then that weakens the value proposition for managed container services within specific clouds. Cross-cloud elasticity of resources is a user goal, and even mechanisms for cluster federation cross clouds won’t fully realize it with managed container services. Anthos could do that.
All of these changes, of course, depend on Anthos succeeding. Does that mean they all depend on Google gaining the number three (or even number one or two) spot in public cloud? No, only that the abstraction-layer model of hosting that Anthos promotes be adopted widely. Given my earlier comment that both Red Hat and VMware have now introduced Istio, it’s not farfetched to believe that these two companies, and others in the space as well, might frame their own universal-abstraction vision, and even incorporate the same tools. Competition would then drive everyone to build bigger and better ecosystems.
There are implications for this in carrier cloud and NFV as well. The cloud is obviously moving toward a broader container-and-Kubernetes ecosystem that serves both to abstract hosting and to connect elements in a uniform way. These properties would be enormously valuable in carrier cloud and even specifically in NFV. NFV has suffered from the first because it ignored the cloud initiatives that were maturing as it was first introduced, choosing instead to back a continuation of device-centricity in thinking and planning services, even though NFV was supposed to virtualize network functions.
Most of my readers know that I’ve long said that the cloud had to be viewed as a vast distributed platform with its own unique middleware and APIs. I have to wonder whether Google is intending Anthos to be that platform, for both traditional cloud computing and the carrier cloud. Google, recall, has not yet taken any technical steps to grab at the market for carrier cloud, either as a provider of cloud services to operators who don’t want (yet, or ever) to host their own clouds, or as the provider of an architecture on which carrier cloud could be based. Amazon seems to have aspirations in the space. Anthos could be Google’s secret weapon, in which case it could be a very important development indeed.