This is the first of a two part blog describing how Cloud Foundry provides a platform for ISVs, solution providers and application services to integrate with the CF PaaS, how partners can participate in the Cloud Foundry ecosystem, and how to work with Pivotal on our enterprise distribution of Cloud Foundry.
As the partnership and business development lead for Cloud Foundry at Pivotal, I meet a lot of small and large companies who are interested in 1) integrating their software or services with Cloud Foundry and/or 2) partnering with Pivotal to jointly deliver solutions to market. In this post, I will focus on the first part—specifically open source Cloud Foundry and the extensible framework of its architecture. In part 2, I’ll discuss how how partners can work with Cloud Foundry-based distributions, in particular our hosted Pivotal Web Services and our enterprise private PaaS, Pivotal CF.
How Can I Get Involved?
“Cloud Foundry began as an open source project but now has evolved into the basis for a true open platform ecosystem.” – Paul Maritz, Pivotal CEO
This topic has been covered extensively in other places, but if you’re new to Cloud Foundry, here is a quick guide. Cloud Foundry is an Apache 2.0 licensed open source platform-as-a-service. I suggest reading through the “How to Get Involved” section on the project’s community website. It provides rich details on the Cloud Foundry modules, links to each repo on Github, great documentation, referrals to local meetup groups and events, our 2014 Cloud Foundry Summit schedule for June 9th to the 11th in San Francisco (get your tickets now!), access to technical forums on Google Groups, directions on filing bugs, contributing to the wiki, watching the progress of the project on the public Pivotal Tracker, and instructions on how you can contribute to the project. The project is staffed with two full time staff engineers reviewing PR requests, with the option of submitting major projects to the CF Incubator.
Cloud Foundry Foundation
“If You Want To Go Fast, Go Alone. If You Want To Go Far, Go Together” – Old African proverb, repurposed for the Cloud
In February 2014, Pivotal established a formal open governance model for the Cloud Foundry™ open source project, joining forces with enterprise software leaders EMC, IBM, HP, Rackspace, SAP and VMware (with ActiveState and CenturyLink as Gold level sponsors) to create an independent non-profit foundation for the Cloud Foundry project.
The foundation will be dedicated to the evolution and growth of the Cloud Foundry open source project, and the ecosystem and community around it. Foundation membership isn’t for everyone, but contributing members have a voice fostering a healthy, vibrant, collaborative and innovative ecosystem around the Cloud Foundry platform and provide feedback on the Cloud Foundry roadmap and feature advocacy. To learn more about the Cloud Foundry foundation, feel free to contact Cloud Foundry’s Community Advisory Board.
Cloud Foundry Architecture
Integrating with Cloud Foundry is easy. The CF architecture has well documented integrations paths for ISVs, solution providers and application services. These range from apps running on top of Cloud Foundry, local or web-based services attached to Cloud Foundry, embedded modules in the core software, or underlying services consumed by Cloud Foundry directly such as VMs or storage. In addition, services can be 1) explicitly exposed via a catalog or 2) implicitly qualified and instantiated external to a running Cloud Foundry platform.
Cloud Foundry supports virtually any linux-based application (commercial or open source software) that can run in a containerized virtual machine. A PaaS is best suited for stateless horizontally scalable apps that are permissive of ephemeral instances and can scale to N+1 instances for redundancy. Single tenant apps will also run fine on Cloud Foundry, but may experience limited downtime if the underlying instance(s) change state (Cloud Foundry usually detects and restarts a failed app in a few seconds).
Cloud Foundry uses Heroku compatible buildpacks like our Java buildpack to describe the environment, variables and runtimes required for an application. Pivotal Web Services and Pivotal Cloud Foundry support Java, Node.js or Ruby apps by default. Additional runtimes or frameworks are also supported by using the appropriate buildpack. If Pivotal or the Cloud Foundry community hasn’t created one yet, you can build your own.
To find out if a given app runs on Cloud Foundry register for an account on our hosted Cloud Foundry service at http://run.pivotal.io, then push your app to CF using the command line interface. If you have any problems, just post a question on the Google Forums.
Core Functionality: Modules, Buildpacks and more
Cloud Foundry consists of over 20 separate and idempotent modules that comprise the platform. Each module has a specific task or action for which it is responsible (e.g., Cloud Controller, Health Manager, Router, etc). As an open source project, you can fork a specific component and design it with additional capabilities or provide broader interoperability. For example, you may want to add UDP support to the router. As long as you have a signed and approved CLA you can submit proposed modifications via a simple pull request on the appropriate Github repo. Just remember that submission is no guarantee of acceptance and some major PRs may be reviewed by the CAB (Cloud Foundry Community Advisory Board). Ÿ
Buildpacks are a popular way to contribute to the project by providing a complete runtime environment for a specific class of applications. Buildpacks provide portability across clouds and contributing to an open cloud architecture, and are responsible for detecting the application runtime and frameworks, and for compiling the app into a machine executable image. Cloud Foundry accepts community buildpacks via Github. In addition, ISVs, solution or application service provider can build commercial buildpack variants of their own open source versions. For example, IBM contributed their Liberty buildpack to the Cloud Foundry project, however, contributing functionality does not prevent them from later electing to offer a commercial version of the same. Partners can contribute to the ecosystem by developing their own OSS buildpacks and offering commercial support for paying customers.
Services Exposed as SaaS
SaaS services, such as web-based DBaaS (MongoLab, ClearDB, RedisLabs) or APM (New Relic) or Messaging (SendGrid, Iron.MQ, CloudAMQP), can be exposed to Cloud Foundry applications as consumable services. Cloud Foundry’s Service Broker allows users to to create, provision and bind 3rd party services. The Service Broker automates the interaction between users, apps and services. A user can provision any service from a provider (cf create-service) and bind that service (cf bind-service) to a running app.
User Provided Service Instances
The User Provided Service Instance is a useful feature of the Cloud Controller. It allows users and apps to connect to static service instances—services that are already provisioned or do not allow users to provision them as a resource. UPSIs allow users to represent external assets such as databases, messaging services, and key-value stores as a service in Cloud Foundry.
EXAMPLE:
- User obtains credentials (e.g., URI, port number, UID, password, etc.) for communicating with an Oracle database.
- User creates a user-provided service instance to represent the Oracle database.
- The UPSI stores the database credentials, but has no provisioning authority over the DB.
- When the user wants to connect to the Oracle database, they use the same
cf create-serviceandcf bind-servicecommands to connect and bind the Oracle DB to their app.
BOSH Deployed Local Services
In addition to connecting to SaaS-based services, Cloud Foundry can also connect to local services which are deployed via BOSH when Cloud Foundry is installed on-premise or for private PaaS. Local services are not SaaS-based and typically run on the same managed IaaS stack (e.g., vSphere, OpenStack, AWS, Cloudstack, etc) that BOSH uses to deploy Cloud Foundry.
Locally deployed services require two integration components:
- A Service Broker (so that Cloud Foundry users can provision the service and apps can connect to them)
- A BOSH installation package (to locally deploy the service and the service broker).
Colloquially, we call this a BOSH-ified service. Services best suited for BOSH-ification are those than can be compiled from source (OSS software) or have binary packages for the specific 64-bit Linux OS in the BOSH stem cells (currently Ubuntu 10.4, moving shortly to Ubuntu 14.x). Binaries are less flexible as they cannot be automatically updated when the underlying stemcell OS’s are patched, and may not benefit from the persistent benefits of the BOSH health manager. James Bayer has written extensively about the benefits of using BOSH to build distributed system deployments without any external dependencies.
BOSH compiles services (e.g., MySQL database) directly, deploying to machines on the underlying infrastructure in a deterministic fashion, with health and monitoring agents baked into the stem cells. As BOSH manages the local IaaS with admin rights, it takes responsibility for the health of the deployment and can delete and re-spawn any dead/non-responsive VMs.
As with buildpacks, BOSH deployed services are ideal candidates for OSS solutions backed by commercial entities, such as Jenkins (CloudBees), Cassandra (DataStax) and MongoDB (10gen). In this manner, companies deploying Cloud Foundry can use the BOSH-ified offerings of popular services with the benefits of support, maintenance and training included (purchased separately of course). In the second part of this two-part blog post, we’ll details how Pivotal partners with services partners to allow customers to download BOSH-ified services from the Pivotal Network, and automate the deployment and configuration of these partner-provided services using Pivotal Operations Manager.
Integration. Customization. Operation.
The information above focused specifically on “integration” vectors with Cloud Foundry. However, there are also growing opportunities for partners providing customization (e.g., consulting, configuration, product customization and engineering services) and operational services (installation, operation, managed hosting, managed services, monitoring, support, etc).
Summary
Cloud Foundry is an amazing platform for building and scaling web and mobile applications. The extensible architecture provides a variety of different ways for partners to integrate with the platform, and has an open governance model that encourages contributory involvement and leadership. This blog covered some of the more popular ways to integrate with Cloud Foundry and partner with the greater community, including:
- Joining and contributing to the Cloud Foundry community, including the Cloud Foundry Foundation
- Becoming part of the growing eco-system around the platform as an ISV, solution provider or application service
- Providing applications that run on Cloud Foundry
- Creating buildpacks to provide portability across clouds and contribute to an open cloud architecture
- Exposing SaaS and locally deployed services via the Service Broker
- Connecting to existing services with the User Provided Instance (UPI)
- Developing BOSH-ified services which can be deployed on with local Cloud Foundry installations
- Installing, customizing and operating Cloud Foundry-powered clouds
If you have any questions about integrating with Cloud Foundry or providing value added services on top of the platform, please contact us and reference this blog post. If you have any questions, ping me on Twitter @badnima.
About the Author
