Lessons From The “Demise” Of CloudFoundry
Recently CloudFoundry announced that they are replacing their container orchestration engine Diego with Kubernetes. This brings an end to the CloudFoundry Project as a standalone platform and the remnants from the project will remain for sometime supporting existing customers. But this announcement marks an end to the once promising open source Platform as a Service (PaaS) offering, initially open sourced by VMware and eventually maintained by Pivotal with the help of CloudFoundry Foundation. In this post, let us discuss the lessons we can learn from the demise of CloudFoundry because it could reshape the discussions we have in the industry about higher order abstractions. It will also cut down the marketing noise that usually dominate these discussions. Keep in mind that when I use the term demise, I imply loss of relevance in the industry. I want to once again highlight that the remnants of the project will be around for quite some time, till all their users move over to a Kubernetes platform. Heh, OpenStack Foundation is still around and they keep running conferences. Don’t expect them to shut the shop and vanish.
First some history. CloudFoundry came into existence to meet the enterprise needs for an open source Platform as a Service offering. At the time of the project’s inception, cloud services like Heroku and Google App Engine dominated PaaS. Enterprise customers were wary of the lock-in risks associated with these services. Red Hat had just acquired Makara to offer their own PaaS offering (which was later released as OpenShift). VMware released CloudFoundry at the right time and it gained popularity fast. Eventually, VMware spun out Pivotal Software, and they continued with the CloudFoundry project which was later taken over by CloudFoundry Foundation. Then Kubernetes came over and it transformed the landscape making CloudFoundry irrelevant in today’s container centric market.
CloudFoundry started with their own container format (Garden in its most recent incarnation) and their own orchestration engine.(Diego). Once Docker gained steam and became the de facto standard for the container runtime, CloudFoundry supported Docker (and OCI compliant containers). But, they encapsulated Docker containers with Garden to make it work under Diego orchestration engine. Even though customers could bring Docker containers into CloudFoundry, the way out of CloudFoundry to other orchestration engines was not straightforward. Similarly, end users preferred Kubernetes as a standard way for orchestrating containers as it gave them more flexibility in supporting a diverse set of applications, stateless to stateful. CloudFoundry couldn’t meet these customer needs and the result is the move away from Diego to Kubernetes. Once you take the container runtime and container orchestration out of the equation, whatever remains from the original CloudFoundry platform has very limited relevance (keep in mind that Concourse CI project has been moved out of CloudFoundry into a Pivotal Project sometime back).
With the “demise” of CloudFoundry project, it is important for the industry to do a postmortem so we can avoid some of these mistakes.
- Standards Matter: While Docker was gaining momentum, CloudFoundry required users to embrace platform specific container engine. Similarly, when industry was converging on Kubernetes as the standard for container orchestration, CloudFoundry was pushing a platform specific orchestration tool called Diego. If the last 2–3 years have shown anything, industry loves platforms made of standardized components. CloudFoundry is open source but it could not emerge as a standard at the platform level because the barriers to standardization are high at higher level abstractions. The use cases supported by CloudFoundry are too restrictive for a standardization to emerge at the platform level
- Opinionated Platforms Are Risky: The CloudFoundry platform was more opinionated than some competing platforms in the market. In fact, the biggest debate between CloudFoundry and its direct competitors was about whether customers need opinionated platforms or not. CloudFoundry only supported 12 factor applications whereas platforms built on top of Kubernetes could support both stateful and stateless (12 factor) applications. CloudFoundry is not the first platform to take the opinionated route and struggle. Google App Engine, which was one of the first cloud services, couldn’t gain traction because it was too opinionated. Let us be clear here. All platforms are opinionated to some extent but when a platform is highly opinionated, like Google App Engine and CloudFoundry, it is tough to gain customer traction. This becomes more clear with enterprise customers who are not comfortable with rip and replace approach. Enterprises prefer a more seamless on-ramp to modern application architectures and Kubernetes based platforms gave them the flexibility to deploy legacy applications, modern stateful applications and stateless applications. The biggest reason for the demise of CloudFoundry is the insistence on supporting only stateless applications. When you have industry standards based platforms supporting both stateful and stateless applications, opinionated platforms lose out
- Hyper-marketing doesn’t help: From day one, hyper-marketing has been the go to market strategy for CloudFoundry, initially as a VMware and Pivotal project and eventually under an open source foundation. I believe that hyper-marketing helps in getting some initial traction. We could see that from the initial traction for the CloudFoundry project. But, they did not build a solid community behind the project. Instead, the foundation focussed more on the marketing part. This is clear from the code contributions to the project. Pivotal is a single largest contributor to the project and other contributions paled compared to Pivotal’s. Enabling a more diverse community not only helps in the long-term sustainability of the project but also in bringing in a fresh set of ideas. By allowing Pivotal to be the largest contributor with limited contributions from other vendors in the space, CloudFoundry Foundation sped up the fall of the project. Let me be clear here. Pivotal has some of the smartest engineers in the industry. Their contribution to the project was critical and of great technical value. But the direction of the project was more in sync with Pivotal’s market needs than evolving based on the market needs. Such a domination by a single vendor and lack of vibrant community of contributors is risky for any open source project. CloudFoundry Foundation didn’t do much to increase the number of vendors monetizing by distributing CloudFoundry as a part of their platform. This would have ensured that CloudFoundry is in more places through multiple vendors than through one dominant vendor. CloudFoundry project was not a “too big to fail” project because few vendors relied entirely on CloudFoundry for their survival. If you look at the Kubernetes project, the code contribution comes from multiple vendors and many vendors depend on the survival of the project including large cloud providers like AWS, Microsoft and Google. Any OSS Foundation behind any OSS project should focus on building a diverse community (as reflected in the number of vendors actively contributing a significant amount of code to the project) and they need to build an ecosystem where there are many vendors who distribute the software either as a software that can be deployed anywhere or as a service.
As we go into a future where Serverless is seen as the next level of abstraction for applications, we need to understand that
- The platform should support a continuum of services and it should not require a complete rip and replace
- The higher order abstraction should be built on top of standardized lower level components so that the on-ramp to the abstraction is a continuum than a steep barrier
- If you are doing OSS, build diversity in contribution and business around the OSS project. Marketing helps all the time. Hyper-marketing might help in initial stages but not all the way. Focussing on hyper-marketing and not building a diverse community will hurt the OSS project more than helping them flourish
Future of Pivotal Platform
The biggest impact of CloudFoundry’s “demise” will be on Pivotal as they have invested heavily on the project. However, they are smart enough to see this coming and have embraced Kubernetes as the container orchestration engine for PKE much before CloudFoundry project and they were also smart enough to change the direction of Project Riff (their Serverless offering) by betting on KNative. They are well positioned to become a pure Kubernetes platform supporting a continuum of applications, from web applications to Microservices to Serverless Functions. They are positioned to support all these workloads under a single developer centric platform covering both Day 1 and Day 2 needs.