CF Summit Boston — Day 2 Wrap-Up

As day two of CF Summit in Boston wraps up, there’s been a consistent theme that has resonated through the halls of the Boston Convention Center: Growth.

Growth for the technology and the community. Growth for the scope of the types of workloads the platform looks to tackle. Most importantly, growth for users, developers and operators of Cloud Foundry.

T-Mobile reports a 170:1 developer to operator ratio

I’m always a sucker for demos, of which Summit has had no shortage of. From new releases such as CF Dev to PoCs such as rolling app updates, down to the straight up experimental like running Concourse workloads on Kubernetes. It’s incredibly exciting any time I see a shell pop up on the big screen. I wanted to share a few that I particularly enjoyed.

CF Dev

There’s been several iterations of the local development environment for Cloud Foundry over the years. Even years ago when Cloud Foundry was in it’s early days, it was distributed to conference attendees via USB flash drive. Today, however, Steve Levine showed off CF Dev, a full-fledge BOSH director running Cloud Foundry locally, ran with a single command: cf dev start.

While not the first time you’ve been able to run BOSH on your laptop, the ease of getting started has never been better!

Once started, CF Dev will download all of the required resources, spin up the BOSH director and deploy Cloud Foundry. From there, the user can setup their shell environment to point to the newly deploy BOSH environment with the quick eval $(cf dev bosh env) command and even interact with BOSH director just how they would any other environment. This allows users to even deploy services such as RabbitMQ, as Steve demonstrated during this morning’s keynote. Make sure to check out CF Dev and take it for a spin!

Rolling Application Upgrades

Zach Robinson, lead of the CAPI team, gave an entertaining but powerful demo showing of their work on rolling application upgrades. In the past, if users wanted to update their application on Cloud Foundry while avoiding downtime, the process looked like:

1. Deploy the updated application along-side the old version (traffic remains 100% on the old deployment)
2. Map the route for the app to the second deployment (traffic is now balanced between the old and the new versions of the app)
3. Unmap, stop and delete the old version of the application (traffic is now 100% on the new deployment)

It worked, but it can be better. With rolling application updates, however, when a developer pushes a new version of their app, instances are iteratively updated. Instead of stopping all instances of an app and then deploying all new ones, they’re done one-by-one, allowing for easier zero-downtime deployments.

Going a step further, Zach showed that the developer could then run another command to roll back to the previously version of the application, again in an iterative manner. This is means it’s even easier to recover from a situation where a bug is noticed only after deployment and it’s better to go back a version while the bug is fixed.

Concourse Workloads on Kubernetes

Topher Bullock of the Concourse team demonstrated a “Freedom Friday” project he’s been working on, running Concourse workloads on top of Kubernetes. Today, Concourse uses the same technology that Cloud Foundry uses for container management, Garden. Topher points out that as Concourse grows, however, they’re essentially writing major portions of what Kubernetes already does, especially with regard to scheduling. Instead he suggests leveraging Kubernetes to schedule Concourse workloads.

There’s currently an existing RFC for this feature in Concourse, which can be found here. It’s already quite thorough, but Topher and the rest of the Concourse team is looking for feedback and ideas on how to best implement this. Make sure to check out the RFC and provide your thoughts!

RFC: Kubernetes Runtime by topherbullock · Pull Request #2 · concourse/rfcs

BOSH 2017/2018 — A Year in Review

There’s nobody better from the community that I can think to talk BOSH than Dr. Nic Williams. While it wasn’t a demo of shiny, new features, Dr. Nic’s talk did provide a good overview of everything that has been added to BOSH over the last year, which is incredible to hear all listed out in one giant list. Features such as internal and external variables, BOSH DNS, multi-CPI support and ops files. Also by the way, if you’re pulling up those docs as you read this, that redesign of the docs site is new as well!

Something that flew completely under my radar personally is the bosh vendor-package command, a way to reuse packages from other releases. Previously, if the BOSH release you were building depended on Java for example, it was very common to go to another BOSH release and rip out the code for the Java package and copy it to your release. Instead, now the BOSH release author can simply point to an existing release, tell it which package it needs, and the BOSH CLI will take care of the rest. There’s even a growing collection of BOSH packages available for just this reason, with packages for common dependencies such as Java, Ruby, Go, etc.

Tomorrow

This hardly covers everything that was shown off today by the community, and we have another action-packed day of keynotes and talks tomorrow. Make sure to follow Cloud Foundry on Twitter as well as the #CFsummit hashtag. Also, keep an eye on the Cloud Foundry YouTube account for when the keynotes and talks are uploaded.