Lifting the Veil of Mystery around the Cloud Foundry Bits-Service

We have been in stealth mode for quite a while, trying to hide as much as possible of our development and activity around the Bits-Service. Of course, some information leaked here and there, where we couldn’t avoid it. But overall, we managed to keep it secret quite well.

That is of course non-sense. The Bits-Service has been developed in the open like any other true Open Source project, and is being developed as a Cloud Foundry Incubator project. What is true, though, is the fact, that there hasn’t been much information out there about the Bits-Service and what problem it solves, except for some Youtube videos from past Cloud Foundry Summits.

This is about to change soon, however, as we are getting closer to becoming a standard component of Cloud Foundry. That of course begs the questions “What is, in fact, the Bits-Service?” and “Can you start using it in your Cloud Foundry deployment today?”

The answer to the latter question is “Yes, you can use it!” And the rest of this post explains how and why you should use it.

What is the Bits-Service and Why Use It?

To explain that, let’s first get a bit of context. Over time, the Cloud Controller has acquired quite a few responsibilities. Some might say “it got a bit bloated”. In an effort to separate out some of the responsibilities currently being held by the Cloud Controller, we decided to extract the handling of bits into its own service, the Bits-Service. What are “bits” in this context? Anything dealing with files: your source code, aka package, droplets, buildpacks, etc.

So, on the one hand the Bits-Service really is a design hygiene effort, which allows us to have an independent team working on Cloud Foundry bits-handling, avoiding to expand the CAPI team (which develops the Cloud Controller) to a bigger team, meaning we just followed good microservice architecture best practices.

On the other hand, extracting the bits-handling out of the Cloud Controller opened up new and interesting opportunities to make Cloud Foundry more performant. Why is that?

The Cloud Controller currently serves (among other things) two purposes:

1. It responds to short-lived requests such as cf apps, which is simply querying the database and returning a response immediately.
2. It responds to long-running requests such as uploading package bits, or downloading droplet bits.

The latter requests are expensive for the Cloud Controller, because they block valuable threads which could be used to serve short-lived requests instead. Of course we could simply scale up the number of Cloud Controllers and solve any bottlenecks. But that would be a waste of resources, as Cloud Controllers require “fat” machines, while bits-handling can be handled with much more light-weight machines.

Now with bits-handling extracted, we can have the cf CLI start talking to the Bits-Service directly. That frees the Cloud Controller from that responsibility and let’s us see real performance gains.

For small Cloud Foundry deployments, such as test environments, a lot of the above doesn’t matter that much. However, in a Cloud Foundry deployment of the scale of the IBM Cloud, where we have a massive number of Cloud Controllers and a heavy load on bits-handling, this “refactoring” actually makes a difference.

Since we are in the middle of this migration, the performance improvements are not there yet. But by enabling the Bits-Service in your Cloud Foundry deployment, you’re making space for the above described performance improvements that we expect to introduce iteratively over the coming months.

With that, how can you start using it?

Enabling the Bits-Service in Cloud Foundry

The guide below is geared towards developers who are already familiar with the deployment of a vanilla Cloud Foundry using BOSH.

The new and recommended way to deploy Cloud Foundry is through cf-deployment. cf-release is soon going to be deprecated, so I won’t explain the approach there.

Thanks to cf-deployment’s modular structure, there is actually not much to do, except for including a couple of experimental BOSH Ops files and setting necessary Ops variables, assuming there is already a valid cloud-config on the BOSH director as explained incf-deployment’s documentation.

Our Concourse pipeline e.g. deploys Cloud Foundry with Bits-Service into several environments, covering IBM Cloud, AWS and Bosh-Lite.

The BOSH manifest generation command for our IBM Cloud deployment looks more or less like:

bosh interpolate cf-deployment/cf-deployment.yml \
    --vars-store deployment-vars-cf.yml \
    -v system_domain=cf-deployment.dynamic-dns.net \
    -o cf-deployment/operations/experimental/bits-service.yml \
    -o cf-deployment/operations/experimental/enable-bits-service-https.yml \
    -o cf-deployment/operations/experimental/bits-service-s3.yml \
    -o cf-deployment/operations/scale-to-one-az.yml \
    -v 'aws_region="eu-west-1"' \
    -v 'blobstore_access_key_id="AKIAIOSFODNN7EXAMPLE"' \
    -v 'blobstore_secret_access_key="wJalrXUtnF...EXAMPLEKEY"' \
    -v 'resource_directory_key="ci-bits-service-blobs"' \
    -v 'buildpack_directory_key="ci-bits-service-blobs"' \
    -v 'droplet_directory_key="ci-bits-service-blobs"' \
    -v 'app_package_directory_key="ci-bits-service-blobs"'

Obviously, you need to adjust the parameters system_domain, blobstore_access_key_id,blobstore_secret_access_key, and *_directory_keys to match your specific environment.

Now bosh deploy this and that’s it! Seems simple? It is!

You’ll see that there is now a new job called bits-service in the deployment. This is what now takes care of the bits-handling.

Note that you can do this in an existing Cloud Foundry deployment, given that you use the same storage configuration for the Bits-Service as you have used for the Cloud Controller. The migration is seamless and you can always go back. We have taken great care to make sure you can enable the Bits-Service in an interruption-free manner in your existing Cloud Foundry deployment.

Conclusion

The Bits-Service is there and it’s real. It’s soon going to be a standard part of Cloud Foundry and hence, we encourage people to try it out. In this post I have explained why we made the Bits-Service and how anyone can start using it today.

Excited about all things Cloud Foundry and want to know more about the Bits-Service? The Bits-Service is being developed in the IBM-Lab Boeblingen, Germany and we usually hang out on cloudfoundry.slack.com in #bits-service. Come and talk to us!