Cloud Foundry stages a comeback

Practically no developers in their right mind want to write an application from scratch and run it on single server anymore. Instead, they want to tap existing services, keep the original coding to a minimum, and test/deploy the finished application in as automated a fashion as possible on scalable infrastructure.

At the start of the cloud era, PaaS was intended to handle that process, much as the application server handled it in the client/server era. But a funny thing happened: PaaS never really took off. People opted for home-built solutions, with their own scripts and sets of services, and when Docker came along they began figuring ways to dev and test using Linux containers and various container management solutions.

But all that is pretty complicated to set up yourself, which may be one reason why PaaS seems to be making a comeback. From the start the two big PaaS plays have been Cloud Foundry and OpenShift — and they still are (though you can now add Microsoft Azure Service Fabric to the mix). All three now support Docker containers and adhere to the standardized container format developed by the Open Container Initiative.

An open source project with its own foundation, Cloud Foundry is arguably the leading PaaS — though as I discovered in an InfoWorld interview last week, Cloud Foundry Foundation CEO Sam Ramji dislikes the PaaS moniker. “I’m not going to use the PaaS word because it has a historical and failed market,” he says. “[It was] slapped on by analysts who didn’t have anything better to call it and it came out of the NIST definition of cloud computing. It’s not a very good definition. It’s very foggy and it’s constraining.“

Instead, Ramji describes Cloud Foundry as a multicloud, multilanguage application platform that supports continuous delivery. Rather than parse terms, though, Ramji prefers to focus on Cloud Foundry’s growth, with 2,100 contributors and 25 releases in the past year along with a growing list of big customers, including Allstate, BNY Mellon, Citigroup, Daimler, Ford, GE Digital, JPMorgan Chase, Kaiser Permanente, and Volkswagen. Cloud Foundry’s commercial partners include HPE, IBM, Pivotal, and SAP (the Foundation was spun out of Pivotal in 2014).

What accounts for the uptake? In part it’s industry-driven. As with OpenStack, vendors have coalesced around a shared open source code base and are differentiating with their own implementations. In theory, a standardized platform across vendors and clouds reduces fear of lock-in and fosters a bigger talent pool. Ramji also maintains that the ability to set up Cloud Foundry on all the major public clouds as well as on premises helps support customers’ multicloud hedges.

But Ramji thinks the main reason behind the rise in Cloud Foundry adoption stems from a familiar chicken-and-egg cycle:

There’s a real record of enterprise maturity that has made all of these companies now start to get much more comfortable. There is sort of a bowling alley metaphor here, which is it’s the lead pin that has to go down — typically, a very aggressive, technology-centric industry leader like JPMorgan Chase or VW or Ford. They’re quite demanding. But once they go public about it, which is typically 9 to 12 months after it’s actually deployed, then everybody else in the category starts paying attention.

Recently, I spoke with Mike Mason, head of technology for ThoughtWorks, who had a slightly different take on the subject: “I think PaaS-in-a-box offerings like Cloud Foundry have reached a tipping point. Why weren’t they adopted earlier? I think it’s the fact that the capability that they provide is now mature enough.“

When asked about specific feature improvements, Ramji cites BOSH, an open source tool chain for release engineering, deployment, and lifecycle management. Ramji maintains that:

BOSH has gotten radically easier to use. You used to have to tell BOSH every detail of your network in order for it to be able to run Cloud Foundry effectively. Enterprise networks have a lot of details so to just put it in numbers, a BOSH manifest a year ago used to be over 2000 lines. … In the newest version of BOSH, which has been out for a few months, we have something called dynamic routing. Basically the network routes don’t have to be hard-coded. They can be written much more simply. We’ve seen 2000-line manifests drop to 50-line manifests.

Another advance relates to Diego, Cloud Foundry’s container management system, which Ramji says has improved dramatically. But he also points to a qualitative change brought about by the support for containers:

Cloud Foundry is becoming a bit less opinionated over time. It used to be you could only give us code. One of the things that makes it easier is not everything is a 12-factor app. You might need to take an old Java app and reroll it slightly and run it on Cloud Foundry for the scalability and management, but you want to just … build a Docker-based container for that. I think that releases the frustration because there’s not only one true way.

This highlights a crucial developer objection to PaaS solutions: They tend to enforce a certain way of doing things that may or may not suit a given developer — or a given task. The trade-off is that developers who accept those constraints enjoy automation and prebuilt services that in many cases can make them much more productive.

Make no mistake, enterprises like a little governance with their app dev. PaaS, or whatever you want to call it, offers a way to enforce policies and procedures — though if you’re too heavy-handed with that you can lose your best people. For Cloud Foundry and its customers, success will be all about finding the delicate balance between standardization and flexibility.