canonical-ci-engineering team mailing list archive

[Joe Talbott <joe.talbott@xxxxxxxxxxxxx>]

On Tue, Dec 03, 2013 at 12:43:22PM -0600, Andy Doan wrote:
> On 12/03/2013 10:07 AM, Evan Dandrea wrote:
> >Attached is the diagram Nick and Liam drew for how we might layout
> >each component. Keep in mind this is for a single microrservice. We'd
> >want this layout for each one. You can ignore the bit at the top for
> >squid. We won't need that on the front of most things. Instead, a
> >simple Apache in front of HAProxy will suffice.
> 
> > http://ubuntuone.com/0w12vBEgDVn4YUMh5JkoMq
> 
> Thinking about this generically, I'm not sure how specific these
> issues relate to Django. ie - all solutions at a minimum are going
> to require some sort of webserver and data-store and/or queue
> system. The specific solutions to make each implementation
> highly-available will differ, but they'll all require something.
> 
> As we start to talk more concretely about high availability, I'm
> starting to wonder if we should first ask "is it worth it?" ie -
> what could we expect our availability to be if we just deployed a DB
> and a couple of web-servers. If the answer is >98%, then is it worth
> the man-hours required to get us to 99.9%?
> 
> from another angle: the ppa-assigner component we have will probably
> have less 100 operations a day. So are the odds of it being down at
> the precise time one of those operations are executed already <1%?
> 
> I'm really not wanting to sound lazy here. But this feels like its
> snowballing to a place where getting a few components demo-worthy
> might be growing too fast. However, if we don't do this now it might
> make it too expensive later.
> 

I thought (perhaps incorrectly) that HA should be invisible to consumers
of a service.  Using that assumption we shouldn't have to design our
services to be HA.  We should be able to treat them as if they are a
single instance.  Which implies we can start with non-HA services and
work toward adding the HA layer for those services that are critical.

Thanks,
Joe