February 2016 14:49
To: user@mesos.apache.org
Subject: Re: AW: Feature request: move in-flight containers w/o stopping them
Moving stateless services can be trivial or a non problem, as others have
suggested.
Migrating state full services becomes a function of migrating the state,
including any
Would you be able to elaborate a bit more on how you did this?
From: Mauricio Garavaglia [mauri...@medallia.com]
Sent: 19 February 2016 19:20
To: user@mesos.apache.org
Subject: Re: AW: Feature request: move in-flight containers w/o stopping them
Mesos is not only
Mesos is not only about running stateless microservices to handle http
requests. There are long duration workloads that would benefit from being
rescheduled to a different host and not being interrupted; i.e. to
implement dynamic bin packing in the cluster.
The networking issues has been proved
Moving stateless services can be trivial or a non problem, as others have
suggested.
Migrating state full services becomes a function of migrating the state,
including any network conx, etc. To think aloud, from a bit of past
considerations in hpc like systems, some systems relied upon the
Agreed, vMotion always struck me as something for those monolithic
apps with a lot of local state.
The industry seems to be moving away from that as fast as its little
legs will carry it.
On 19 February 2016 at 11:35, Jason Giedymin wrote:
> Food for thought:
>
> One
Food for thought:
One should refrain from monolithic apps. If they're small and stateless you
should be doing rolling upgrades.
If you find yourself with one container and you can't easily distribute that
work load by just scaling and load balancing then you have a monolith. Time to
enhance
Question is if you really need this when you are moving in the world of
containers/microservices where it is about building stateless 12factor apps
except databases. Why moving a service when you can just kill it and let the
work be done by 10 other containers doing the same? I remember a talk
7 matches
Mail list logo