Cloud Foundry Advisory Board Meeting, Apr 2018: Kubernetes Casts Its Shadow

by Roger StrukhoffApril 19, 2018
A conversation about how Cloud Foundry and Kubernetes should co-exist—side by side or as vertically integrated layers—dominated the call at the summit in Boston.

Discussions about Kubernetes

Dave Nielsen

Kubernetes has cast a long shadow over the Cloud Foundry community this past year and continued to do so in the early hours of the Cloud Foundry Summit 2018 in Boston and at this month’s Community Advisory Board (CAB) call.

The summit was preceded by a traditional “unconference” the night before, led as usual by Dave Nielsen from Redis Labs. Kubernetes, its features, and its role for Cloud Foundry developers was prominent in the conversation there.

Dr. Max

The CAB call, led right from the summit by Michael Maximilien (aka Dr. Max) of IBM, did not follow a specific agenda, but did continue the Kubernetes conversation. Nestled amongst a lot of technical talk about droplets, interfaces, and container-related issues, two main themes emerged from this conversation:

  • what roles Kubernetes capabilities should play
  • how the community should view the integration of Cloud Foundry and Kubernetes

 

Side by side or layered?

Dr. Julz

Julian Friedman (aka Dr. Julz) of IBM took what one could call a descriptive approach, outlining how “many users have Kubernetes now” and seem to prefer its features. Dr. Julz said he continues to think of the two technologies existing side by side, each with capabilities that are proving popular among developers. “If users like a certain Kubernetes feature, then great, there’s no reason to argue about whether Cloud Foundry can and should do it better,” he noted.

Dr. Max told he likes to think of Kubernetes and Cloud Foundry as vertically integrated layers, reinforcing a point several people had also made at the Unconference that Kubernetes should be thought of as an infrastructure, not as a platform. He expressed a concern that adoption could impede Cloud Foundry’s innovation, something he does not want to see within an open-source community that by its nature should be innovative and collaborative.

“If you integrate too closely, then you can lose the value of both technologies.”
—Michael Maximilien, IBM

Eric Malm

Eric Malm from Pivotal noted that “layering blows up everything” when it fails, in contrast to keeping problems in discrete areas when Kubernetes and Cloud Foundry are envisioned and constructed to run side by side.

Serverless architectures also entered into the conversation, along with the observation that there is still a lot of “stateful stuff” within enterprise IT, and it needs to be managed.

 

Headache caused by Cloud Foundry? Day 2 Operations assistance

Wishing for a unified user experience

Dr. Max also asked attendees to talk about something on their Cloud Foundry “wish list.” A unified user experience emerged on this list, even as Kubernetes and Cloud Foundry are clearly two different tools. Dr. Julz continued a line of thought that he had brought up at the Unconference about considering that there are two specific personas in this world, one focused on application development and one on the infrastructure. To him, the side-by-side view is the preferred view.

Eric Malm, Dr. Max, and Dr. Julz at the CAB call during the Cloud Foundry Summit 2018

The still-new Cloud Foundry Container Runtime (CFCR) was also part of the discussion, as it is used to deploy and manage Kubernetes clusters with BOSH. CFCR was previously known as Kubo and represents an effort by the Cloud Foundry community to accommodate Kubernetes and its most popular usage.

The quick rise and fall of Docker within the context of modern IT gets mentioned now and then in Cloud Foundry conversations as it did during the call. Participants noted that Kubernetes has seemed to wrap it into its world over the past year. As a result, Max noted, “it’s losing the value of Swarm,” which is Docker’s way of deploying and managing clusters.

 

How critical are things, really?

Bret Mogilefsky

As the discussion wound down, I raised the question as to whether everyone was really talking about an existential problem for Cloud Foundry and whether it was seriously threatened by the rise of Kubernetes over the past year. No one would go that far, but Bret Mogilefsky suggested that this is a good time for the community to create a map of the most worthy areas to pursue versus those that should perhaps receive less attention at this point.

Probably, this will be on the agenda at a future meeting. It seems that Cloud Foundry is approaching a crossroads, if it hasn’t reached one already, and its future direction is worthy of deep discussion among developers and customers alike. The end-state of this conversation reverts to the beginning, in there was an agreement that no one wants to have to master two separate products to achieve a single goal, in this case the deployment of modern applications.

Therese Stowell and Eric Malm at the CAB call during the Cloud Foundry Summit 2018

Thus, this conversation should not be perceived as an “either…or” discussion, but also not as a metaphysical debate about how many angels can dance on the head of a pin. The issues are real, and realizing that the cliché of eternal, continuous change within the technology business is also real, it’s clear that the future of Cloud Foundry is neither easily determined, nor pre-determined. The community, as always, has the power and responsibility to determine its future.

 

What’s next?

The next CAB call will resume in its standard format and is scheduled from 8 a.m. to 9 a.m. Pacific Time on Wednesday, May 16. As always, the call is open to anyone who is interested in listening or participating. Connection details and the monthly agenda appear on the Cloud Foundry Slack channel a few days before the call.

Interested in how to effectively use the Kuberneres CLI to manage your deployment? Download our kubectl cheat sheet!

To stay tuned with the latest updates, subscribe to our blog or follow @altoros.

  •  
  •  
  •