Hi Daniel,

Thank you very much for your additional questions. Let me try and answer some of them from my perspective (this is me talking, not necessarily the “official voice” of my employer):

> It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it?

We actually approach the topic from a different angle: We have much more to manage than „just“ CF – but many other services – and so the question for us is which common layers we establish as basis for our offering. One decision SAP has taken (and I hear that VMware, IBM, and Suse aren’t maybe that much different) is to use Kubernetes as one such layer. And taking that decision at our scale means a huge task in managing many clusters anyways. Our answer for this is Gardener (shameless advertisement for an SAP-initiated Open Source project: https://gardener.cloud/), but YMMV.

> Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

> […]

> I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

I believe I referred to this topic during our CF Summit panel discussion: I think there’s more than one group of end-users to consider:

• People using CF today that are happy with it: I think they are in the “let me continue to `cf push` my apps” camp and I believe they require feature parity to the BOSH-managed world to continue doing what they do. I also think they don’t care about Kubernetes as an underlay similar to how they didn’t care about BOSH managing CF’s lifecycle before.
• People that tried using CF but couldn’t build their scenarios. Some of these people have what I would call a “mixed workload”: Things that could run on CF and things that can’t. For them, the question is if they want a “hybrid” model where they `cf push` their stateless apps to one system and `kubectl apply` the other parts of their workload to a different system or if they – once they have taken on the more difficult part of learning Kubernetes anyways – also move over their stateless workloads to Kubernetes directly. For this group of people, I feel, a value prop of “just having the CF API next to kubectl” as an access point to their cluster is a good thing. That’s also part of the reason why I’m suggesting to remove as much of the CF control plane from the “workload cluster” in my document. It’s their cluster and probably they want to do non-CF stuff with it as well.
• People that approach the topic coming from a Kubernetes background: Here, we keep seeing projects over projects essentially re-inventing PaaS (some of them with an added Git-Ops flavor on top). Things that are non-Kubernetes or things that can be deployed on Kubernetes but “feel” non-K8s-native will not get them engaged. Which is why a Cloud Foundry on Kubernetes will need to feel K8s-native to be successful with this – probably very big – group.

> The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads?

Not for us, because it would still leave us with both BOSH-based deployments as well as having to manage a huge fleet of K8s-clusters, so all of the work with none of the benefits.

Regards,

Bernd