Will Google Cloud Become Cloud Foundry’s Home Base?
The basic infrastructure resources — compute, memory, storage, and bandwidth — are becoming so highly commoditized in the cloud space, that it’s more difficult for the leaders in that space (Google being one of them) to differentiate them against competitors. Price advantages are, like Gen. Patton’s explanation of glory, fleeting.
So these leaders need new ways to reach out, with unique services and, where possible, exclusive or preferred access to customers.
Last week’s formal announcement of the availability of Pivotal Cloud Foundry (the commercial version of Cloud Foundry) on Google Cloud Platform shows Google looking to offer something unique to potential users, or at least raise the bar of what may be seen as a commodity.
“If you look at what Google or Amazon or Microsoft Azure are offering, you can roughly categorize the services that are being offered to anybody to consume, into things that are approaching true commoditization — the infrastructure capabilities,” explained Chip Childers, Chief Technology Officer for the Cloud Foundry Foundation, in an interview with The New Stack. “Then you’ve got these higher-value services that may be entirely unique to that particular platform.”
Raw Materials
Pivotal’s Cloud Foundry environment includes a feature called Pivotal Apps Manager — a kind of internal “apps store” for developers, where they can provision services for integration into the PaaS. In Google Cloud Platform’s case, services such as its Bigtable NoSQL database, its Cloud Machine Learning APIs, and its Cloud Pub/Sub messaging queue, all become visible and accessible through this Apps Manager.
In a demonstration of this provisioning system at the last Cloud Foundry Summit Europe (prior to Google’s official announcement), Google engineers Colleen Briant and Eric Johnson showed how a pairing of CF with GCP results in Google’s services appearing prominently in Pivotal Apps Marketplace. According to Briant, her work with the Service Broker feature enables this pairing, exposing GCP resources to CF applications by way of Google’s existing identity and access management service.
This Google IAM identity management service will sign CF into Google’s system, she said, by way of authenticated service accounts, which are “like user accounts, but meant to be used by your application. It can do anything that a user account can do, so you can still set specific permissions on them. To use the Service Broker, you create basically a root-level service account that has owner permissions at the project level, which gives it the ability to create new service accounts, which are the credentials we will provide to you on a cf bind.”
By that, she’s referring to a service instance binding using Cloud Foundry’s native syntax. Google is actually responsible for contributing CF’s Cloud Provider Interface, which connects an infrastructure provider to CF’s BOSH lifecycle management tool.
What Cloud Foundry’s architects hope to accomplish from this is a shift toward serverless-ness, where CF and Google Cloud recognize and authenticate one another as parts of the same platform, while facilitating customer-class users on a lower tier. A CF developer, under such a scheme, would see the public cloud and PaaS platforms as one big device, which then manages application access for users who authenticate separately. They may perceive a server, but the developer doesn’t have to.
“Cloud Foundry offers the ability to abstract away the underlying infrastructure,” explained Cloud Foundry Foundation Vice President for Industry Strategy Abby Kearns, “giving the developer an easy, simple experience. The abstraction that Cloud Foundry provides allows you as a developer to deploy and manage your application, and have a consistent experience, irrespective of the underlying infrastructure. I say that because that’s the value that Cloud Foundry provides to the enterprise space.
“Cloud Foundry is a platform,” Kearns stated at one point. “What makes a platform endure and successful is a breadth of services. Our goal is to get more applications running on Cloud Foundry, but in order to do that, we need services. Services and apps make up two ends of the platform that allow it to continue to build and drive that network effect.”
“Services are important on a lot of different levels,” she said. “They’re important in that Cloud Foundry is able to package services up, and allow companies that weren’t previously considered ISVs or digitally-centric, to build a business model and offer those services up to others. But it also offers a way to have a broad access to services, in order to make those apps more successful and drive that additional value.”
Interplay
Kearns’ argument points to a third tier of customers: beneath the developer, and one layer lower than the user of the server-side application. With more cloud-based apps becoming the customer-facing part of service providers, they themselves have end users. So Pivotal Apps Marketplace becomes a kind of provisioning model for developers acting on behalf of service providers, who may themselves be provisioning a lower-tiered class of service providers to access functionality.
What Kearns is directly implying here is that, from this point forward, the competitive value of any PaaS will be determined by its self-service portal. This component becomes the catalog for everything the developer can conceivably build, on behalf of everyone else who may then assemble customer-facing apps.
Does this connection between Cloud Foundry and Google Cloud Platform effectively forge the complete PaaS ecosystem? Put another way, are there any interchangeable parts once these two get hitched together?
Example #1: OpenStack. Certainly, CF is hosted on OpenStack in many enterprise data centers, and IBM has been an advocate of doing so. Google has been opening its mindset to the idea of connecting to OpenStack, if not entirely integration. But it has often been developers outside of Google doing the honors first.
Of course, the whole point of OpenStack is to enable virtualization through hybrid deployments. The trick, for now, may be in balancing OpenStack with GCF as different, though perhaps concurrent, deployment targets.
“Where there is difference in those two infrastructure targets,” CFF’s Childers told us, “[and] let’s just assume the performance of the infrastructures are close enough to call them even, the service catalog within each of those Cloud Foundry clusters might be just slightly different. But more interestingly, you could actually imagine scenarios that work quite nicely, where you have your applications being pushed to hosts that happen to be VMs running in OpenStack in your private cloud, but you’re still exposing something like Bigtable to those applications. That is absolutely a viable possibility for an organization.”
That’s not really a single hosting layer, although it is a way for multiple services on multiple layers to interact with one another as though they were on the same layer. Connection, if not yet integration.
Example #2: Kubernetes. Since last year, Pivotal has made it clear that while it embraces the ideal of containerization, it competes against Docker. Recently Kubernetes has found itself maintaining a similar position if not so boldly stated. Cloud Foundry’s orchestration manager is Diego. GCP’s orchestration manager is Kubernetes. But when asked to explain which one wins out in a pairing between CF and GCP, CFF’s Abby Kearns quite emphatically, and even a bit pointedly, reminds The New Stack that Cloud Foundry is a platform.
“Yes, there is some competitive nature between Kubernetes and Diego,” said Kearns. “However, we also see an opportunity to run both, with very different use cases. Depending on what you’re trying to accomplish with your application workload, it may make sense to deploy that on Cloud Foundry with GCP, or it may make sense just to deploy it straight on GCP, depending on what you’re doing.”
But what are those dependencies? Kearns said she believes that, as more enterprises deploy containers at scale, they prefer to rely upon a platform (there’s that word again).
“We found that orchestration tools like Kubernetes, Docker Swarm, [and] Mesos are a small percentage of the toolset used to manage containers,” she said. “Managing containers at a large scale, with critical workloads, with security and compliance and regulatory needs, becomes a very different ball game for these companies. So as we think about the value of running Cloud Foundry on top of something like GCP, it allows these companies to take advantage of the public cloud, but still have the framework and structure necessary to run applications at scale, in a secure and compliant way.”
The Dominant Alpha
So what about Cloud Foundry makes it a better contender for the center of a container ecosystem than Kubernetes? What makes CF on GCP a platform for scalability and security, and Kubernetes (with or without Cloud IAM, which would probably be another of those apps that shows up in Pivotal’s portal) not a platform?
Kearns response began with 1979, and the foundations of chroot and the first isolated namespaces. She made the case that the original purpose of running programs in isolation was to increase the basic problem of increasing utilization through greater density. Today’s containerized environments, she argued, have a very different purpose.
“We’ve seen a shift, even just in the last year, for what containers mean to people,” she explained. “They’re using them less for density, and more for things like versioned runtime, or consistent developer experiences — aspects that speak to the digital transformation shift, where companies are thinking of containers as a stepping stone to enable them to build out continuous delivery practices.”
As our discussion progressed, Kearns’ and Childers’ description of the roles Cloud Foundry and Google Cloud Platform would play, looked more and more as though GCP were a supplementary service provider, as opposed to a host. They want CF to be perceived as the complete platform and GCP as a means of boosting its value through services. Kubernetes would not be among those services.
“As organizations start thinking about the role containers play for them,” Kearns remarked, “they start thinking about, ‘How do I run those at scale, but also leveraging them for what I need?’ Which is, developing the ability to iteratively and continuously develop and deploy applications to a cloud.”
Not “the cloud.” Not any one cloud in particular. Not even Google’s. So if anyone thought last week’s announcement put Google at the center of the Cloud Foundry ecosystem, think again.
Cloud Foundry Foundation is a sponsor of The New Stack.
Title image, “Barbary Lion” by Sir Alfred Edward Pease [1893], in the public domain.
![“Barbary Lion” by Sir Alfred Edward Pease [1893]](https://commons.wikimedia.org/wiki/File:Barbary_lion.jpg){kind=link}