As a devops engineer working with CF daily, I definitely know where my apps are running, and that moving an app from cloud to cloud or to on-prem is not 'seamless'.

I have moved dockerized apps to public cloud CF to on-prem CF. It all worked because the apps where stateless to begin with. Pivotal appropriating all the merit of easy migration of stateless apps is dishonest at best.

Stateless apps are easy to move. They can be moved from CF to Kubernetes to ECS to Heroku.

Now, let's talk about the state, because that's where the real problem and the lock-in might be?

> Now, let's talk about the state, because that's where the real problem and the lock-in might be?

State is hard, state has momentum. We do what everyone else does: we push it out into a separate parallel space. Heroku do that with their PostgreSQL and Kafka services. We do it with services. IBM, Amazon, Google, Microsoft all do it with services.

Cloud Foundry is agnostic to the services. More agnostic if you use BOSH. Less agnostic if you use a non-BOSH service (like RDS).

Heroku isn't. You're married to their PostgreSQL unless you want to build your own or switch to RDS.

Kubernetes has more of an emphasis on attaching and detaching volumes. I can do that with BOSH; in future it'll be an app-level feature too.

(edited to remove unnecessary grump)

How do you address client concerns about lock-in to cloud foundry? Even as a viable solution it's still a hard dependency your clients do not control.

Cloud Foundry is opensource, so there's "lockin" in the sense that Rails or NodeJS or PostgreSQL have "lockin". Every commercial distribution is required to have a consistent base design.

In terms of quitting Cloud Foundry entirely, you have two ways out.

The first is that you used buildpacks to stage your apps. In that case you stop pushing sourcecode to CF and replace it with whatever build pipeline makes sense for the replacement platform.

The second is that you decided to push container images instead of sourcecode. In that case you push to the replacement platform instead.

That said, you'll need to recreate the other niceties: orchestration, routing, log collection, service injection and service brokers, self-healing infrastructure and a bunch of other bits and bobs.

So. How is AWS lock-in? And Cloud Foundry is not, more so?

If you write a full infrastructure for deploying apps, monitoring apps, service-injecting apps, routing to apps on AWS, then you are probably using their APIs fairly heavily.

All the IaaSes have APIs for fundamental components like compute, storage and network. BOSH provides a relatively uniform layer for them, which is how Cloud Foundry manages to get around to so many platforms.