4 ms·

How well does Cloud Foundry play with stateful containers?

by muraiki 11y ago

jacques_chester 11y ago
It doesn't. It's intended to support 12-factor apps[1]. State is handled by services bound to your application. CF injects the connection details into the staging and runtime environments. Applications using buildpacks generally have that connection autoconfigured. For example, Rails apps have database credentials autoconfigured if you have a database bound. Spring apps get a DataSource. And so on. [1] http://12factor.net/ http://12factor.net/
- muraiki 11y ago
  I'm familiar with 12-factor apps, but there are some use cases (usually involving existing / 3rd party software) where it's not really feasible. One thing I like about plain LXC is that you can keep state if you want to. Of course making it HA is a whole other story. :) It looks like k8s has a way to handle volumes, so maybe I'll have to play with that.
  - jacques_chester 11y ago
    Persistent volumes are on the horizon[1], now that Diego has landed. But you'd be surprised how many apps can be ported to some semblance of cloud nativeness. Most of the stuff that Absolutely Must Be Stateful can usually adapted to something else. Sticky sessions go to Redis or Memcache, local files can often be relocated into a shared filesystem/blobstore like Riak CS etc. The big thing about PaaSes is not that they make it a smooth, double-percent-ROI incremental improvement from the status quo. What happens is that unlocking true continuous deployment capability unblocks process backpressure throughout the entire organisation. The value you get from a complete shift in how you develop software swamps the cost of carrying legacy until it can be replaced. Putting it another way: the sucky parts are tactical. The awesome parts are strategic. [1] http://blog.pivotal.io/pivotal-cloud-foundry/case-studies/the-road-to-persistent-data-services-on-cloud-foundry-diego http://blog.pivotal.io/pivotal-cloud-foundry/case-studies/th...

How well does Cloud Foundry play with stateful containers?

by muraiki 11y ago

How well does Cloud Foundry play with stateful containers?

It doesn't. It's intended to support 12-factor apps[1]. State is handled by services bound to your application. CF injects the connection details into the staging and runtime environments. Applications using buildpacks generally have that connection autoconfigured. For example, Rails apps have database credentials autoconfigured if you have a database bound. Spring apps get a DataSource. And so on. [1] http://12factor.net/ http://12factor.net/

muraiki 11y ago
I'm familiar with 12-factor apps, but there are some use cases (usually involving existing / 3rd party software) where it's not really feasible. One thing I like about plain LXC is that you can keep state if you want to. Of course making it HA is a whole other story. :) It looks like k8s has a way to handle volumes, so maybe I'll have to play with that.
- jacques_chester 11y ago
  Persistent volumes are on the horizon[1], now that Diego has landed. But you'd be surprised how many apps can be ported to some semblance of cloud nativeness. Most of the stuff that Absolutely Must Be Stateful can usually adapted to something else. Sticky sessions go to Redis or Memcache, local files can often be relocated into a shared filesystem/blobstore like Riak CS etc. The big thing about PaaSes is not that they make it a smooth, double-percent-ROI incremental improvement from the status quo. What happens is that unlocking true continuous deployment capability unblocks process backpressure throughout the entire organisation. The value you get from a complete shift in how you develop software swamps the cost of carrying legacy until it can be replaced. Putting it another way: the sucky parts are tactical. The awesome parts are strategic. [1] http://blog.pivotal.io/pivotal-cloud-foundry/case-studies/the-road-to-persistent-data-services-on-cloud-foundry-diego http://blog.pivotal.io/pivotal-cloud-foundry/case-studies/th...