Cloud Foundry Advisory Board Meeting, Oct 2017: Notes from the Summit
How should Cloud Foundry go ahead?
Dr. Max
“It’s important for Cloud Foundry to move forward and not get stagnant,” said IBM’s Michael Maximilien (aka Dr. Max) at a special Cloud Foundry Advisory Board (CAB) call, held during the summit.
Dr. Max’s observation came in the midst of a tremendous discussion among on-site attendees. The usual agenda items were replaced by a free-flowing discussion about the current state of Cloud Foundry, particularly how it does and should interact with Kubernetes, containers, and third-party applications.
Dr. Nic Williams
Dr. Nic Williams of Stark & Wayne led off the discussion by saying he believed that, with respect to Cloud Foundry, “services are under-discussed, under-reported, and under-considered.” Dr. Nic noted that his opinion came from the viewpoint of application developers who often feel they face too much complexity in working with Cloud Foundry and with its BOSH tool chain in deploying apps and services to various cloud infrastructures.
Drum roll for Kubernetes, please
Dr. Julz
The role of the Kubernetes orchestration system invariably enters almost every Cloud Foundry discussion these days. Dr. Max noted that Cloud Foundry isn’t going to try to solve every problem, and that perhaps Kubernetes “is trying to solve too many problems.”
“The real problem,” according to IBM’s Julian Friedman (aka Dr. Julz), “is not about running those things, but rather it’s (communicating) to people running things outside the platform about how they can do it.”
A long discussion ensued about how adding containers, and the use of Kubernetes, can increase the density of a deployment, and the implications of doing so. Discussing a unified way to handle the inherent complexity, Dr. Julz said, “the only possible unified way is with BOSH.”
“Cloud Foundry developers have designed (deployments) based around BOSH to make it simple to keep a highly available system. There are restrictions, of course. But (when) you put Kubernetes underneath, it you’re not going to get much.” —Julian Friedman, IBM
That said, Dr. Julz also noted that “even though right now we’re using BOSH, the community could decide on using something different in the future.”
And so it went, with contributions from all sitting at the table. In a follow-up note, Dr. Max said that he sees both Cloud Foundry’s Diego container management system and Kubernetes as “providers of container farms,” with containers as “cattle” that can be used as needed. (His reference is to the popular “pets versus cattle” analogy of how to treat computing instances and resources in this age of cloud computing.)
In Dr. Max’s view, “orchestration of these containers is the main duty of Diego and Kubernetes. As such, in my opinion, anything built on top should allow usage any of the farms. So, a pluggable orchestrator provider interface and pluggable implementations/variations would be used as needed.”
Recently, the CF Foundation has released a container report 2017. The paper’s overview states that “we see the same steady growth in interest, but actual adoption of containers has still failed to take off. Most companies’ container adoption remains in the early or limited stages.”
So, what does this all mean?
My high-level take from this long, wondrous discussion is as follows. There are two worldviews: one from the app developer side and one from the operations side. This can lead to different perspectives as to what Cloud Foundry ought to be able to do, and how easily it should be able to do it. However, the respective roles of both Cloud Foundry and Kubernetes are not clear, and need to be sorted out.
There’s an argument to be made over creating a dense, unified stack of sorts with Cloud Foundry as the platform versus a more loosely organized group of Cloud Foundry/Kubernetes/containers that are deployed and managed in different ways, depending on the enterprise’s needs.
There were still some other points made during the discussion. So, Cloud Foundry has a responsibility to talk to external things, and optimizations can be found in how to do this. However, when Kubernetes enters the picture, the health and welfare of Cloud Foundry is restricted by the health of Kubernetes.
Secured service credentials and a new service discovery
At the call, there were two proposals mentioned: the one that introduces a secure workflow for service credentials, and the other suggesting a brand new service discovery for the container-to-container networking.
Dieu Cao
Dieu Cao of Pivotal presented a proposal for securing service instance credentials. According to her, security officers and Cloud Foundry service operators want to meet security best practices and their internal policies with respect to the creation, storage, and delivery of credentials to applications for use in accessing services, while minimizing effects on developer productivity.
The proposal details a workflow and separation of responsibilities, in which service credentials can be stored in CredHub rather than the Cloud Controller component of Cloud Foundry.
A proposed workflow for service credentials (Source)
Usha Ramachandran
Pivotal’s Usha Ramachandran shared a proposal of a polyglot service discovery for container networking. According to the proposal, app developers who want to make use of the container-to-container networking, are now required to bring their own service discovery. The community has furnished all those interested with Eureka- and Amalgam8-based examples. However, the feedback revealed that usage of the container-to-container networking is very difficult, with some common issues emerging:
- Polyglot microservices written in other languages/frameworks but Java/Spring cannot easily use Eureka.
- Clustering applications have a requirement to address individual instances.
- Additional VMs need to be deployed and managed to provide an external service discovery.
So, in order to support all types of apps, languages, and frameworks, the community plans to build service discovery for the container-to-container networking into the platform. With this feature, there will be no need to bring service discovery of one’s own.
A proposed design of the polyglot service discovery (Source)
Other developments this month
The CAB call came amidst a recent flurry of activity within the Cloud Foundry community. A number of developments occur each month through the Cloud Foundry mailing lists, and this month was no exception.
The CF-Local CLI plugin was approved by a vote to become an official part of the CF Extensions. CF-Local is lets developers stage apps locally (say, on a laptop) and is expected to be a boon for developers.
Alex Ley
Alex Ley from Pivotal was named the new chair of the OSB API project management committee. He is replacing Pivotal’s Shannon Coen in this role, though Shannon said he’d continue as a member of the committee for the time being. Alex will act as project liaison with the Cloud Foundry Foundation.
Bret Mogilefsky
A long note Bret Mogilefsky of the cloud.gov team mentioned some problems in getting plugins to be productive. Saying that “plugin code generally gets no (apparent) security audit,” he outlined several general problems in working with community-developed code as found with Cloud Foundry. Chip Childers, CTO at the CF Foundation, thanked Bret for his “great thinking,” and noted that “this needs some deeper thought on how to take meaningful actions.”
Anand Gaitonde
Anand Gaitonde from Orange wrote about the terraform providers for Cloud Foundry and CredHub. “This extends the usual scope of terraform from the IaaS prerequisites for BOSH/CF deployment into PaaS-ops, managing resources, such as security groups, admin buildpacks, and service brokers,” he wrote.
(Anand also made reference to a proposal that indulges into using the Terraform provider to manage Cloud Foundry-related resources.)
CF CLI
Dies Koper
Highlighting updates from a bi-weekly Runtime PMC meeting, Dies Koper and Dr. Julz shared progress of the CF CLI and Garden teams. (Meeting notes are available in the project’s GitHub repo. The log of activities from the most recent meeting, held on October 3, is now available.)
- Released CF CLI v6.32.0 with the experimental v3 commands for multiple processes, granular push control, and multiple buildpack support.
- Added documentation that since the v6.31.0 release, which was built with Golang 1.9, the CF CLI accepts CA certs from the
SSL_CERT_FILEandSSL_CERT_PATHenvironment variables on Linux for TLS validation of API endpoints. - Continuing work on the v3 commands (
v3-create-package -p,.cfignore) and preparation for v3-ssh. - Expecting subsequent releases to apply user feedback, as well as taking advantage of the post-GA CC v3 API improvements.
Garden
Dr. Julz also shared updates on the Garden project. He wrote that Garden “is planning to incept on a feature narrative to bring proper support for sidecar processes to the platform. (Those are processes that share some but not all namespaces and cgroups with the main container process.) According to him, this isn’t a very user-facing feature, but it will make implementing such user-facing features as Envoy proxies, long-running health checks, and custom metrics easier.
- Ongoing: Rootless nearing completion, CATs passing, intend to start running in PWS asap
- Ongoing: OCI Phase 1 unblocked by new grootfs release, now doing final integration and preparing to run benchmarks
- New:
/sys/fs/cgroupnow mounted read-only in containers - Next: Starting work on the experimental “OCI Phase 2” items
- Next: Incepted on Garden Sidecars “Peas” work
The next CAB call is scheduled on Wednesday, November 15. The call begins at 8 a.m. Pacific Time. Anyone interested can join the Cloud Foundry’s CAB Slack channel.
Want details? Watch the video!
