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

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

  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

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!

BOSH 2017/2018 — A Year in Review

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

I make things and build stuff. Tech Marketing at Pivotal. @BrianMMcClain