Cloud Foundry’s Vision: A Services Ecosystem that Transcends Containers
“I have this grand vision of a single marketplace of services that are platform-agnostic,” proclaimed Abby Kearns, the executive director of the Cloud Foundry Foundation. “I also recognize that there are advantages of having an open source platform, in order to drive innovation and drive that collaborative approach. But I also need to recognize there are going to be some differentiations that are unique to a platform, as well as for the opportunity to build commercial viability into the outcomes.”
Here in The New Stack, we often talk about promoting the ideal of staging and scaling multiple applications in a variety of contexts, including first-generation virtual machines and Linux-style containers, together on a common platform. But if we’re truly being serious about it, then we need to acknowledge that orchestration is just one tool for bringing this ideal to fruition. Orchestration enables workloads to be staged and deployed. The network overlay is only one more tool, facilitating some means of contact between stateless, RESTful services.
There’s a third critical component — the counterpart to what, for a Java environment, we would call middleware. But exactly what that component should be, is still very much up in the air. Some have proposed the use of streaming message brokers such as Apache Kafka, or the Apcera NATS platform; others have posited the use of messaging protocols for use with queues, such as MQTT.
The contributors to the Cloud Foundry (CF) platform-as-a-service software are now suggesting that a part of their communications system, which they call the service broker, be advanced as a kind of workload agnostic interaction protocol. If you’re thinking to yourself, “Oh, I know what you’re talking about, I’ve read that term before in SOA blogs in my last life,” be warned that we ran out of available, unused, common language phrases for things in the computing realm some six or seven years ago, so we’re just reusing phrases now that we’ve used before.
Brokerage Firm
In the context of Cloud Foundry, the service broker is the component that advertises those services that applications running on CF may perform, for the benefit of other applications that may wish to utilize those services by means of their APIs. CF’s service broker concept has, of course, always been open source. But last week, Kearns’ Foundation made a move to extend that outreach one more step, by effectively declaring its service broker “open” to platforms outside of CF.
As Kearns told The New Stack, her group’s move was inspired in large part, she says, by Google. In a discussion with Google’s engineers earlier this year, she told us, they were having difficulty establishing a sense of binding between services staged in Kubernetes. Specifically, the Kubernetes team needed a way for services being staged on its platform to contact, and bind with, services outside its platform, without both platforms necessarily having to be Kubernetes.
“The Cloud Foundry Service Broker API is quite simple, and it is elegant in its simplicity,” explained Kearns. “Essentially, the API allows you to create, bind, unbind and delete a service. But what it also is, is flexible. It allows you, as you develop a service broker that connects to that Service Broker API, to add in different levels of integration for that service, so that once that service is attached and bound to an application, it can do different things. And you can automate the actions of that based on the application needs, as well as the service needs.”
That’s a very general way of saying that a service broker enables a service to effectively publish multiple versions of itself — different classes of the service, depending on the state or the requirements of the client. In the cloud services market, there’s a concept of a “service-level agreement.” This kind of service instance tailoring is like a small-scale SLA. Instead of the service accepting parameters and adjusting its functionality to suit, the service broker can instantiate the most suitable instance of a service according to the plan submitted in the service request. Kearns calls this made-to-order functionality a bespoke service.
Here’s where the security element comes into play: When the CF broker negotiates each binding for an application, it can check to see whether the service being requested requires credentials. This way, a service key is generated, not unlike a session key in an encrypted Web session. This makes it tremendously more difficult for any malicious component to spoof an already credentialed application; it would have to know, or have access to, the service key generated at the time the binding took place.
Wherefore Art Thou, Middleware?
Over a decade ago, the first Web services were essentially remote procedures built to be communicated with over HTTP protocol. One of the original purposes for having adjusted the concept of the URL into a “Universal Resource Identifier” was to facilitate Web services designed to be contacted through Web addresses. Remember back when parameters were tacked to the end of HTTP identifiers using CGI protocol? Supposedly that was deprecated, except for all those Google searches.
The problem with giving everybody in the world your one address and flipping your window sign to read, “Yes, We’re OPEN,” is that the world not only beats a path to your door, it beats down the door. An exclusive registry for identifying every unique service in the world obviously was not maintainable for very long.
At the turn of the century, Microsoft and IBM began collaborating on a rendition of service-oriented architecture that would resolve the contention issue. Called Universal Description, Discovery, and Integration (UDDI), this class of middleware used an XML schema to describe Web services, the types of bindings made available for them, and the requirements for clients to make contact with them. UDDI introduced the service broker concept (sometimes called a “service registry” by Microsoft) as a mechanism for maintaining a services catalog and granting requesting clients access to that catalog.
This is where the idea of a service catalog became an industry trend unto itself, with analyst firms including Gartner predicting that as enterprises moved their applications into the cloud, they would have to publish cloud-based service catalogs just to remain competitive. But like many things to which fuses have been attached and lit at random, it didn’t take off. At a symposium just last week sponsored by the Society of Information Management, the group revealed that nearly 5 percent greater organizations polled in 2016 said they do not use an IT service catalog [PDF], than those polled in 2014. Only about one-quarter of 2016 firms polled said they currently use service catalogs.
“Undistinguished”
You may be saying to yourself (or shouting to us very loudly, by way of your screen), this service catalog in the SIM survey is not the same as the catalog managed by Cloud Foundry’s service broker. That might have been true last September. But now, Google has formally joined the Cloud Foundry Foundation, and is backing efforts by Red Hat, Pivotal, IBM, and Fujitsu toward a common approach. So what started out as a “service gateway” has become the newest opportunity to build the same market model that UDDI attempted in 2000: a network where resources are identified, tracked down, and located based on what it is that client applications are seeking to accomplish.
It’s the same goal: services everywhere, only this time the notion of platform agnosticism has been extended toward platforms other than just the ones making the claim.
And it would appear the other platforms are making way. Buried in the small print toward the bottom of a blog post from Red Hat’s director of product strategy Brian Gracely on Monday, was an acknowledgment that OpenShift (and Red Hat in general) would be adopting the Service Broker API in 2017.
“Far too often we find that the changes needed to migrate to a more agile, DevOps environment,” wrote Gracely, “get stuck in a chicken-or-egg dilemma between not having the right technology and not being organized to adapt to rapid change. By making the technology side of the equation consistent and container-centric for the entire Red Hat portfolio, Red Hat has eliminated a large portion of the choices that companies must face.”
But what proved to be UDDI’s ultimate undoing, as recorded for history by this white paper by Poland’s Poznan University of Economics [PDF], were the unavoidable by-products of its own design: Its decentralized model meant no one in particular ever maintained it. Thus over time, there was no authoritative means of determining which published services were still current, and which others were, as the telephone operator used to say, “disconnected or no longer in service.”
The Poznan school’s solution to this dilemma seemed downright socialist: the establishment of an entire social network for crowdsourcing the authority of service brokers.
Cloud Foundry may take a different tack, however. From our talk with Abby Kearns, we learned that the ultimate goal of an Open Service Broker API (if, indeed, that’s its final name) may not be to crown individual services as the authoritative, distinguished providers of functionality. Rather, it may allow for the natural distribution of undistinguished, everyday services across the network, and load-balance amongst them.
“What’s the whole point of Cloud Foundry? It’s an abstraction on infrastructure,” stated Kearns. “And really, if you net it even further down, the whole point is to absolve organizations — particularly, traditional, non-tech organizations — from undifferentiating heavy lifting. What that means is, working on things that are not relevant or differentiating for your business.
“So as I think about the point of services and ecosystems, it’s pulling together a broad array of capabilities,” she continued, “that you can make use of and access and that add value to your business but aren’t necessarily differentiating it. I view it more as a continued layer of abstraction, making use of tools and capabilities that exist out there, without having to spend the time and effort on re-creating it just because you can.”
The Cloud Foundry Foundation, IBM and Red Hat are sponsors of The New Stack.
Feature image: The Chicago Board of Trade, 1909, in the public domain.
