In my experience building apps that run in OpenStack, you don't give up state. You shift how you handle state.
For example, instead of always routing a user to the same instance and that instance holding the session data there is a common session store for the app (possibly synced between regions). If you store session on each instance and loose an instance you'll run into problems. If sessions is more of a service for each instance than an instance coming and going isn't a big deal. A good database as a service, swift (object storage), and maybe a microservice architecture may be helpful. Legacy applications might have some issues with the architecture changes and some may not be a good fit for cloud architectures. One way to help legacy applications is to use block storage, keep the latest snapshot of the instance in glance (image service), and monitor an instance. If an instance goes offline you can easily create a new one from the image and mount block storage with the data. - Matt On Mon, Jun 9, 2014 at 7:27 AM, hossein zabolzadeh <zabolza...@gmail.com> wrote: > Hi OpenStack Development Community, > I know that the OpenStack interest is to become a cloud computing operating > system. And this simple sentence means: "Say goodbye to Statefull > Applications". > But, as you know we are in the transition phase from stateful apps to > stateless apps(Remember Pets and Cattle Example). Legacy apps are still in > used and how openstack can address the problems of running stateful > applications(e.g. HA, DR, FT, R,...)? > HA: High Availability > DR: Disaster Recovery > FT: Fault Tolerance > R: Resiliancy! > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
