Lessons Learned from Cloud Foundry
Cloud Foundry was going to create an open source alternative to Heroku, as well as replace how Enterprise companies built software. But change is never easy. Looking back, what can we learn from the lessons of Cloud Foundry?
SHOW SPONSOR LINKS:
- Get started with the JumpCloud Directory Platform today
- Interested in a free JumpCloud T-Shirt? Email firstname.lastname@example.org.
- See how O’Reilly online learning can help your tech teams. Request a free demo now.
CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotw
CHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"
- Cloud Foundry Launch (Part I) - 2011
- Cloud Foundry Launch (Part II)
- Cloud Foundry history (Wikipedia)
- Cloud Foundry Foundation (launched in January 2015)
- Understanding the Cloud Foundry Foundation (Sam Ramji, Eps.186)
- Structured vs. Unstructured Platforms (Wikibon, Gracely, 2015)
- Architectural Considerations for OSS PaaS and Container Platforms (2016)
HOW DID CLOUD FOUNDRY EVOLVE?
An open source, programmable cloud application platform (PaaS). Heroku (2007), Google AppEngine (2008) existed before Cloud Foundry (April 2011). OpenShift launched in May 2011. Apcera was launched in 2012 by Derek Collison
- Open Source, Multi-cloud
- Multiple languages, frameworks
- Automation for the infrastructure (BOSH)
- Integrated Logging, Tracing, Routing, GUI
- Data Services live off the platform, via Service Broker
- Very heavy platform footprint (up to 50 VMs)
- Diego container scheduler
- Warden container runtime
Many large vendors got involved once it became a foundation.
- IBM, SAP, Intel, Cisco, EMC/VMware
- Many end-user customers joined (great for recruiting)
- None of the Cloud providers, other than an infrastructure stem-cell
By 2016-17, most large Cloud Foundry vendors were shifting their focus to Kubernetes
LESSONS LEARNED FOR THE FUTURE
- Single-vendor led communities are difficult, especially if a foundation is created.
- Technology transitions are hard, oftentimes impossible. Cloud Foundry chose to downplay Docker and Kubernetes as “just for infrastructure”, even within their own community.
- Make it simple to get environments/clusters (Managed Kubernetes services, Cluster API, laptop-level environments (minikube). Needs to be a managed cloud service on good clouds.
- Platform-aware, Infrastructure automation is important (e.g. like BOSH, except that it works)
- Industry is mixed on if stateful / data services should run on-platform or off-platform. Having to also manage the off-platform is difficult.
- Email: show at thecloudcast dot net
- Twitter: @thecloudcastnet