Meet the Photon Platform BOSH CPI
Today, we’re excited to continue addressing the needs of developers by announcing the release of the Photon Platform BOSH CPI. We’re building upon the recent release of v0.8 of Photon Controller: a distributed, multi-tenant and elastic platform purposefully-built for modern applications.
BOSH was designed to address the challenges in building both small and large distributed system. A BOSH CPI, or Cloud Provider Interface, is an API that is used to interact with an underlying IaaS to create and manage objects on an infrastructure, including images, VMs and disks.
How To Bill on Cloud Foundry
This is a guest blog post by Greg Cobb, Ben Watts, Michael Smykowski and Dieu Cao from Pivotal.
As a Cloud Foundry operator, you may wish to monetize your application runtime and services usage. While Cloud Foundry does not include a built-in billing system, it does provide features to allow operators to construct their own billing tools that meet their individual needs and requirements.
Cloud Foundry exposes usage events for both applications and services. These usage events detail when Cloud Foundry users start, stop, and upgrade apps and services. These events contain additional information about the resource usage of the apps and services. Usage events are guaranteed to only appear for operations that have successfully completed and to be in chronological order.
Garden and runC
Today, Julz Friedman (an engineer from IBM and the Anchor for Cloud Foundry’s Garden project) posted an important update from the Garden project team to the cf-dev mailing list about the future of the Garden project’s approach to the Linux container runtime. TL;DR here is that the Garden project will be transitioning from it’s own backend for Linux containers to using runC from the Open Container Initiative.
As he says in his email, the team did an initial prototype as part of this decision (fair warning, that repo is a spike).
The Forklifted Application
This content was originally posted on the Pivotal blog and is part of the upcoming book – on Cloud Native Java – that I am writing with Kenny Bastani on building cloud native applications with Spring and Cloud Foundry. –Josh
Community and customers alike are moving as much of their workloads to platforms like Cloud Foundry as possible. Cloud Foundry aims to improve velocity by reducing or at least making consistent the operational concerns associated with deploying and managing applications. Cloud Foundry is an ideal place to run online web-based services and applications, service integrations and back-office type processing.
New Fellow Travelers Join the Cloud Foundry Foundation Mission
Pivotal CEO Paul Maritz wrote about Cloud Foundry back in February when we announced our intention to form the non-profit Cloud Foundry Foundation. The Foundation aims to formalize Pivotal’s commitment to the open governance of a new platform that serves businesses in a multi-cloud world, anchored around Cloud Foundry.
I’m delighted with Pivotal’s announcement of the eight new Gold level members who have stated their intention to join the Cloud Foundry Foundation when it launches this Fall. They include Accenture, BNY Mellon, Capgemini, Ericsson, GE, Intel, NTT and Verizon, bringing the total level of Platinum and Gold members to 17.
Software continues to disrupt every aspect of the consumer and enterprise experience.
Packaged and Offline Buildpacks
With the recent addition of the cf create-buildpack and cf update-buildpack commands, we’ve been looking into changes to how the Java Buildpack is deployed on Cloud Foundry. There is a move afoot to remove the buildpacks from the DEAs in favor of using those commands (with an automated initial install to preserve user-experience) and an outcome of this was the need to more easily create ‘packaged’ buildpacks. In the process of delivering these packages we also realized that we could also deliver “offline” buildpacks. To understand why “offline” buildpacks are interesting, it helps to understand why the buildpack is designed to look for dependencies on the Internet in the first place.
Wrapping libyaml in go
We recently released version 6.0.0 of cf, the command line client for Cloud Foundry. cf was previously written in Ruby, and we have rewritten it in Go. This allowed us to package cf as as a single binary and simplified our deployment strategy enormously.
The YAML problem
Two weeks before our release, we realized that the go YAML library we were using, goyaml, is distributed under the LGPL license. This makes it unusable for cf. We had to quickly find another way to parse YAML in cf.
The definitive YAML implementation is a C library called libyaml. We knew that Go had good support for interfacing with C libraries, so we decided to write our own go bindings to libyaml. This felt a bit risky given that we were releasing in two weeks, so we named our creation ‘gamble’.
HM9000: Ready for Launch
Cloud Foundry (CF) is a platform-as-a-service that, once deployed, makes it easy for developers to deploy, run and scale web applications. Powering this elegant PAAS is a complex distributed system comprised of several interoperating components: the Cloud Controller (CC) accepts user input and directs Droplet Execution Agents (DEAs) to stage and run web applications. Meanwhile, the Router maps inbound traffic to web-app instances, while the Loggregator streams log output back to developers. All these components communicate via NATS, a performant message bus.
It’s possible to boil CF down to a relatively simple mental model: users inform CC that they desire applications and Cloud Foundry ensures that those applications, and only those applications, are actually running on DEAs.
Remote Dependencies, Convenience, Risk and Other Considerations for Operating Distributed Systems
One deeply held principle by experienced distributed system operators that I have worked with is that you should have no external dependencies to your software other than the ties to minimum requirements of the OS such as common system libraries, utilities, and the kernel of the base OS. This approach should enable recreating a distributed system deployment without any dependencies on the outside world. When something goes wrong, you should have control over your own destiny. Reliance on any external dependency that is managed or hosted by someone else introduces risk that something outside your system can affect your ability to restore and recreate the system any time you need to.
Migrating a Cloud Foundry PaaS to Run on OpenStack
The following is a guest blog post by Julian Fischer (firstname.lastname@example.org, @railshoster) founder and CEO or AnyNines, a Cloud Foundry and Rails hosting service operated by Avarteq GmbH in Saarbrücken, Germany.
Cloud Foundry is well known for simplifying application portability from one CF-based PaaS to another, but how simple is it to move an entire, live, Cloud Foundry installation from one underlying IaaS to another? We asked the team at Pivotal, who recounted their experience moving the Cloud Foundry instance at run.pivotal.io from one Amazon AWS availability zone to another in 40 minutes.