Open Stack

On 14/11/13 12:26, Renat Akhmerov wrote:
>
> On 14 Nov 2013, at 18:03, Zane Bitter <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> wrote:
>
>> What might be a downside is that sharing a back-end may not be
>> technically convenient - one thing we have been reminded of in Heat is
>> that a service with timed tasks has to be scaled out in a completely
>> different way to a service that avoids them. This may or may not be an
>> issue for Mistral, but it could be resolved by having different
>> back-end services that communicate over RPC. The front-end API can
>> remain shared though.
>
> Not sure I’m 100% following here. Could you please provide more details
> on this? Seems to be an important topic to me. Particularly, what did
> you mean when you said “sharing a back-end”? Sharing by which components?

If you have a service that is stateless and only responds to user 
requests, then scaling it out is easy (just stick it behind a load 
balancer). If it has state (i.e. a database), things become a whole lot 
more complicated to maintain consistency. And if the application has 
timed tasks as well as incoming requests, that also adds another layer 
of complexity.

Basically you need to ensure that a task is triggered exactly once, in a 
highly-available distributed system (and, per a previous thread, you're 
not allowed to use Zookeeper ;). Your scaling strategy will be more or 
less dictated by this, possibly to the detriment of the rest of your 
service - though in Mistral it may well be the case that you have this 
constraint already. If not then one possible solution to this is to run 
two binaries and have different scaling strategies for each.

None of this should take away from the fact that the two features should 
be part of the same API (this is what I meant by "sharing a front-end").

Hopefully that clarifies things :)

cheers,
Zane.