Reinforcing the Trust Factor for Cloud Foundry
Up until recently, my place in the software market was on the customer side. Hearing vendor pitch after vendor pitch claiming the software they were offering me was “enterprise-grade,” I became quite jaded. A particularly aggressive vendor would claim its competition didn’t offer “enterprise-grade software.”
So it’s not without a sense of irony that I invoke this same phrase to describe Cloud Foundry.
What makes the phrase “enterprise grade” relevant to Cloud Foundry is trust — specifically, the trust our users invest in our community leads to growth in adoption. That growth has allowed Cloud Foundry to quickly become the platform that billions of dollars of global commercial activity relies on.
The Cloud Foundry community takes its responsibility to support our entire ecosystem quite seriously. For us, “enterprise-grade” boils down to four key themes: It’s a highly secure platform, it integrates well into your existing environment, it’s scalable and high-performing, and it delivers a great experience that frees developers to create amazing software.
Cloud Foundry is taking off in the enterprise. Of the more than 1,650 attendees at the last Cloud Foundry Summit, more than one-third were users representing enterprises such as Allstate, Comcast, Express Scripts, The Home Depot, Verizon and Volkswagen. What we heard from them, over and over, was how their companies are using Cloud Foundry as the foundation for their transformation, developing software more quickly, meeting the challenge of using multiple clouds, and ensuring that their platforms and applications are well integrated. This shouldn’t be news to anyone paying attention to the space, as more than half the Fortune 500 are using Cloud Foundry.
More and more enterprise software is either based on open source or entirely open source. This is a trend that seems to be accelerating, and it’s great to see. However, there’s something unique about the Cloud Foundry technical community: What they produce and submit upstream is a truly enterprise-grade platform, that becomes distributed throughout our ecosystem of distributions and their customers.
The Cloud Foundry community’s efforts to ensure that it’s offering a platform that can be trusted in highly secure environments takes two forms: process and design.
It All Comes Down to Trust
If you tried to build a platform like Cloud Foundry from scratch, integrating a number of different open source or perhaps commercial software components, you would be faced with a massive number of projects and products to track for updates. Software, both open and closed, has vulnerabilities. The question you should ask yourself is whether your organization will be responsive when these vulnerabilities become public knowledge.
The Cloud Foundry technical community has a unique responsibility: to ensure that the complete platform, from operating systems on up, is delivered as a single set of releases — coordinated, tested, frequent, and timely. We track very closely the releases of the operating systems, infrastructure components, databases, and even libraries used to build Cloud Foundry. When a fix comes out, it’s brought into the release process quickly. Our entire ecosystem takes full advantage of this effort, including downstream commercial distributions, online services based on Cloud Foundry, and direct users of the open source platform.
This vulnerability patching approach extends to the languages and frameworks developers use to write their applications on the platform. Users who always deploy apps with the latest buildpacks get the most up to date versions of each language, improving both their security posture and their experience.
On the design side, our community has been focused in two independent areas: easing the burden on developers writing secure applications, and ensuring that our platform has the security capabilities required by some of the world’s most secure environments.
This means all communications are encrypted and appropriately secured, and that applications have reliable identity. This security extends to the container level. Our Garden team has a standing goal of being “the most secure container runtime for multitenant application platforms.” We were among the first communities, outside of Docker, to embrace and fully adopt the runC library from the Open Container Initiative. Building from that industry-standard foundation, we ensure that each container is protected by enabling key kernel-level features by default: resource constraints via cgroups, user namespacing, AppArmor, and seccomp.
As a community, we are incubating a credentials management product that will be deeply integrated into the rest of the platform: CredHub. You need a place to generate, encrypt, store, and even provide credential rotation within the platform and within your application. CredHub allows the administrator, the infrastructure itself, and the applications themselves to access the appropriate credentials based on access control and lifecycle policy.
Thanks to all this focus on security in the Cloud Foundry community, the platform is showing up in highly secure, highly regulated environments, even in a very public way. Take 18F, the technical affairs office of the U.S. Government Service Administration. When 18f achieved FedRAMP accreditation for cloud.gov, which is not an easy task, its people shared publicly how they took this purely open source platform and campaigned for its authorization for use in by government agencies.
Well Integrated in the Enterprise
Enterprises today work in a complex world with multiple platforms, and multiple levels of abstraction — including VMs, containers, the PaaS abstraction, event-driven frameworks. We want those different systems to work really well together, regardless of the choices you make. Because Cloud Foundry was designed to allow the backing services to be sourced from anywhere, we are in a great position to help bridge from old to new. Our Open Service Broker API project allows us to share this key abstraction with other open source communities and ecosystems. This API, whose first official release as a cross-ecosystem effort took place during Cloud Foundry Summit, has been growing in importance across the industry.
Another area that matters deeply to the enterprise is the Microsoft technology stack. Our relationship with Microsoft — now a Gold Member of the Cloud Foundry Foundation — began with IronFoundry, the first implementation of Cloud Foundry on Windows, built to support the .NET Framework. Since then, we have consistently been working to improve support and integration for the entire Microsoft technology stack. BOSH, our deployment and operations layer, now spins up and manages Windows hosts the same way as Linux hosts.
Here’s another example of our focus on integration: Kubo, a project started by Google and Pivotal and now a Foundation project, packages Kubernetes for deployment and management by BOSH. For some workloads, Kubernetes’ focus on the container as the principal abstraction is preferable. Our goal is to ensure that Kubernetes and the Cloud Foundry Runtime are well integrated with each other.
Add to all this the recent integration of Google and Microsoft identity providers with our User Account and Authentication Server ( UAA) module, and Cloud Foundry’s continued trajectory for stronger integration capabilities becomes clear.
High Performance at Scale
It’s clear that the use of Cloud Foundry among large organizations has shifted from departmental interest to business-wide adoption, often organically. For example, Comcast’s involvement with Cloud Foundry started small, but quickly scaled to over 1,000 developers on the platform, with support for over 10,000 applications. This adoption rate is driving our scaling and performance efforts across the community’s project teams.
In late 2016, our community successfully completed scale testing of the platform to reach 250,000 fully operational (i.e., non-trivial) containers, including a variety of application sizes with different characteristics. Many of these test workloads were designed specifically to inject faults into the system, to fail and to shut themselves down. This allowed us to test not only provisioning but the platform’s ability to manage the health of these applications at scale.
Our work with improving performance at scale extends beyond the platform’s control plane, to the data path for applications (our routing tier) and the data path for telemetry (our logging and metrics pipeline). With one release last February, the routing project team managed to improve the routing tier’s throughput by over three times, at 5ms latency. Release after release, this team has successfully gated its pipelines on improving throughput.
A Learning Platform that Delights
Discussions of a software platform’s enterprise readiness are often focused on the functional and non-functional requirements that IT departments demand. Unfortunately, in the push to accommodate the different needs of each potential customer, the user experience typically suffers. How many of us have come across so-called “enterprise software” that is wholly unusable, even though all of the IT requirement boxes were checked off?
Developer experience (DX) is absolutely the Cloud Foundry community’s top priority. After all, our goal to help enterprise developers move faster can’t be achieved if the DX doesn’t delight. Hundreds of thousands of developers around the globe appreciate this focus, but we know we can do more.
One of the main things we have heard consistently, from new adopters all way to experienced users, is that there needs to be a local developer laptop experience for Cloud Foundry. At Cloud Foundry Summit, I had the pleasure of highlighting the community-created project called cflocal. This project integrates the Cloud Foundry experience with your local environment, while at the same time helping you achieve a more productive local development flow. Developers can now stage their applications with buildpacks, including local and remote backing services, and run them locally. They can also push and pull applications from the remote Cloud Foundry environment, aiding with troubleshooting and debugging.
We expect to see a renewed focus on the evolution of the core Cloud Foundry developer experience. As an example, today’s users often make use of CLI plugins to orchestrate complex distributed systems deployment patterns (e.g., canary node deployments, blue/green deployments). The Cloud Foundry v3 APIs are starting to take shape, opening up the potential for the platform to natively support these deployment patterns.
To cite Dieu Cao, the Cloud Foundry Runtime PMC Lead, our community’s new goal is to build off the success of the cf push experience to deliver a “learning platform that delights.” We will do all this while our project remains true to the “enterprise-grade” needs of our ecosystem.
The Cloud Foundry Foundation is a sponsor of The New Stack
Feature image: A power plant under cloudy skies courtesy Max Pixel, released under Creative Commons Zero license.
