4 ms·
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 'seamle
by smashed 10y ago
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?
- jacques_chester 10y ago> 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)