It happens to be the case that CF — because it’s an app platform and wants to let the user focus on their code — provides a way to convert code in to containers inside the platform without having to start messing around with Dockerfiles and the like. And this functionality even does some cool things for you like keeping your container OS automatically patched so you don’t have to build CI pipelines to monitor your base images and rebuild stuff.
That’s why I love Cloud Foundry’s Application Runtime. Of course, because of these constraints — the constraints that are why I love it — the App Runtime can’t possibly work for complex stateful services: the whole point is for it not to. And that’s why it’s fantastic that there’s now a Container Runtime (which I wish we’d called a Stateful Services Runtime because that’s how I think of it).
On overview of how Bloomberg is looking at the likes of Pivotal Container Services:
“Many Kubernetes distributions are good on day one, when they’re first deployed,” said Andrey Rybka, technical architect in the office of the CTO at Bloomberg, the global finance, media and tech company based in New York. “But what happens on day two, when something fails? Kubernetes doesn’t [automatically] address things like failures at the physical node level.”
The roadmap for Cloud Foundry Container Runtime includes support for stateful applications based on the StatefulSets feature that became available with Kubernetes 1.7 in June. The foundation also plans to integrate the Istio project, founded by IBM, Google and Lyft in May, which helps to manage network communications between microservices