Open Stack

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 <zabolzadeh at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>