What’s new and what’s changed with CF technology, April – July 2017
Welcome back to the regular roundup of news from the Cloud Foundry technical community! This post is designed to highlight the interesting activities, announcements and opportunities to get involved in the many Cloud Foundry Foundation projects and surrounding communities.
For anyone looking to keep up with changes between issues, we highly recommend following the cf-dev mailing list, projects on GitHub or joining appropriate Slack channels. In particular, lots of exciting news came out of June’s Cloud Foundry Summit in sunny Silicon Valley.
I. Cloud Foundry Elastic Runtime
The CF Elastic Runtime has undergone many updates geared at stabilizing and simplifying the experience of using the platform. Here is a quick taste of all the activity:
|Diego||The EOL for the Legacy DEA Backend was May 22, 2017. This is a huge deal for the ecosystem, and also represented a major sign of maturity for our community. Over 12 months of transition time was provided to users and downstream distributions.
Previous notices here and here, as well as documentation on how to migrate to Diego
|Operating Systems||SUSE presented a proposal to add support for SUSE Linux as a stack and stemcell option, alongside the current Ubuntu base. More details here.|
|UAA||Starting with UAA BOSH release v35 multiple ERB validations have been added for OAuth Clients.
Please ensure that your UAA BOSH release yml is set up properly as deployment will not proceed without these changes.
|CF-mySQL v35||The manifest has switched to using BOSH links. This supports the work going on in cf-deployment. We’ve also swapped out our fork of route-registrar, preferring instead the official one in routing-release.
To deploy v35, the team recommends you try cf-mysql-deployment v35. Like cf-deployment, we’re learning as we go.
|(Proposal) cf-named-binding||A feature proposal was floated within the community to help in service instance selection.
An application in Cloud Foundry can be bound to multiple service instances, and one service instance can be bound to multiple applications, so the relation is many-to-many. This makes it challenging for some developers to ensure their applications are using the correct service instance. The proposal describes a potential solution.
You can see more on GitHub.
|cf-networking-release v1.0||Operators and app developers can use the CF networking features to enable direct container-to-container communication, configure granular application-level policies and apply policies dynamically without requiring applications to restart.
Project link: cf-networking-release
|Release Integration||The Release Integration team has started planning for the deprecation of cf-release in favor of the cf-deployment project. The team has provided a proposal for this transition here.|
|Infrastructure||A large effort to remove the Consul open source project from the Cloud Foundry platform’s internal architecture is in progress. More information here.
More updates on the CF Runtime’s approach to distribute locking and service discovery can be found here.
As you know, BOSH is designed to offer a tool chain for release engineering, deployment and lifecycle management of large scale distributed services. Here are some of the updates from this cornerstone project of the Foundation:
|BOSH CLI||BOSH CLI v2 is now generally available. CLI v2 incorporates tons of feedback received over the past few years. Some features have been redesigned, some removed, and some hopefully much improved.
You will find docs available on https://bosh.io/docs. Let us know if you find any missing material (I’m sure there is some). Here are some documentation pages worth mentioning:
– https://bosh.io/docs#basic-deploy – cli v2 section on the index page
– https://bosh.io/docs/cli-v2 – all commands
– https://bosh.io/docs/cli-v2-diff – some notable cli v1 vs v2 differences
|Technically a project of the CF Runtime’s Infrastructure team, this is also useful for different BOSH use cases.
The Cloud Foundry Infrastructure team is proposing an inception to plan further enhancements to BBL to support the longer-term needs of system administrators.
III. Open Service Broker API
The Open Service Broker API provides developers, ISVs and SaaS vendors a single, simple and elegant way to deliver services to applications running within cloud-native offerings including Cloud Foundry, OpenShift and Kubernetes.
|v2.12||The first release of the Open Service Broker API was announced at CF Summit in June. The focus of this release was to enable multiple platforms to leverage the API through deprecating platform specific terminology. This clears a path for more platforms integrating with the OSBAPI. Additionally, the specification now leverages RFC2119 keywords, meaning consuming service broker authors and platforms can clearly understand the intent of the specification.
Release notes here.
IV. Cloud Foundry Extensions
The CF Extensions team supports the organic community development of extensions and add-ons around Cloud Foundry technology. Projects that are initially considered extensions may eventually migrate to one of the other PMCs as they mature in both technical implementation and market adoption.
|Kubo||Kubo has become an incubating project within CF Foundation, with initial committers from Google and Pivotal. Read VentureBeat’s coverage. This project may be used in a BOSH environment to deploy and manage Kubernetes clusters.|
|Java Buildpack||Java Buildpack 4.0 is a major focus on improving how the JVM runs in a containerized environment. These improvements have resulted in an updated memory calculator and a new jvmkill Out of Memory agent. Please take a moment to read the release announcement for more detail about how and why we made these changes.
The important thing to note about the Java Buildpack 4.0 release is that it is not 100% compatible with previous application configurations. Because the memory calculator now accounts for memory regions that were not previously accounted for, applications that used to start (but would likely go OoM under a high load) will no longer start. It is possible to tune an application’s memory configuration to run in small containers, but using the JVM defaults means that applications will not start in less than ~700M of memory. The CF default is 1G per container — and applications will start and run nicely in that configuration.
Because of this incompatibility, we’re releasing Java Buildpack 4.0 in parallel with Java Buildpack 3.16. Java Buildpack 3.x will continue to remain the default versions for a short time in order to gather feedback from users and allow a reasonable migration period. We intend for this parallel release system to go on for 3-6 months, but if there are significant difficulties, this can be changed. I highly encourage you to start trying Java Buildpack 4.0 during this period and giving us feedback in the project’s GitHub issues. Your feedback, with production applications, can help influence the ongoing behavior of the memory calculator and jvmkill agent.
|BBR (BOSH Backup and Restore)||BOSH Backup and Restore (BBR) has been proposed and accepted into the Extensions PMC as an incubating project. BBR is a framework for backing up and restoring both BOSH directors and BOSH deployments.
|Buildpacks||After June 1, 2017, new releases created in the following buildpack BOSH release repositories do not supply “offline” or “cached” buildpacks that are packaged with their dependencies (ex. language interpreters, compilers).
Additionally, the java-offline-buildpack-release will be moved to the attic.
V. Ecosystem Projects That Caught Our Eye
The Cloud Foundry ecosystem is filled with interesting projects and products. Many of these have had big news at this summer’s Cloud Foundry Summit. This edition, we’re highlighting a few important announcements:
- Cf-local: CF Local is a community-developed project as part of the CLI work, aimed at giving users a local Cloud Foundry experience. Features include:
- Stage and run Cloud Foundry apps in Docker
- Download pre-staged apps from Cloud Foundry and run them in Docker
- Stage apps in Docker and push them to Cloud Foundry
- Make Cloud Foundry service instances instantly available to Docker apps
- Share a local directory with an app running in Docker, and monitor it for changes
- Rapidly iterate on Cloud Foundry app development with only Docker installed
- Convert Cloud Foundry apps to Docker images that do not require Cloud Foundry or CF Local to run
- Pivotal On-Demand Services SDK: The on-demand services SDK simplifies broker and tile authoring, and is the standard approach for both Pivotal internal services teams and Pivotal partner independent software vendors (ISVs) to develop on-demand services for PCF. Read the docs or read the announcement.
Did we miss anything? We focused on the big changes, but if we missed something, please let us know on Twitter!
Our next Cloud Foundry technology-in-review is scheduled for October. Stay tuned & subscribe to our tag on the CF blog!