11.01.13 Engineering Progress Report for Firefox Accounts and Sync.next

Chris Karlof ckarlof at mozilla.com
Wed Nov 6 10:19:34 PST 2013


On Nov 6, 2013, at 4:47 AM, Lloyd Hilaiel <lhilaiel at mozilla.com> wrote:

> A single-region short term milestone sounds fine.  I would urge you to schedule MySQL based multi-region soon after.  API access latency alone is a good reason to have servers on a couple continents.

Gene is already in skunkworks mode on this.

> Also, given this, it seems like decoupling of API server and Content Server [1] is smart.  Especially if jelly serving is stateless (client side secure cookies), we can mitigate API latency with a low complexity multi-region deployment of 
> 

Table stakes for this decade. We're starting with a proper service oriented architecture, not like some monolith Rails app from 2007 held together with years of duct tape (https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/).


> Also, recent versions of mysql supposedly have much better tools for HA multi-region deployments.  I’d urge you to talk with jared and gene to from the start use a stable, but modern version.
> 

Gene is a principal on this effort, and I trust he'll take us in the right direction on this.

> Sorry for all the backseat driving here, but these topics are close to my heart.
> 

Np.

-chris


> <3,
> lloyd
> 
> 1: https://wiki.mozilla.org/Identity/Firefox-Accounts#Architecture
> 
> On Nov 6, 2013, at 1:17 AM, Ryan Kelly <rfkelly at mozilla.com> wrote:
> 
>> On 6/11/2013 9:58 AM, Chris Karlof wrote:
>>> On Nov 5, 2013, at 3:51 AM, Lloyd Hilaiel <lhilaiel at mozilla.com
>>>> 
>>>> Is C* off the table? Where can I learn about our learnings?
>>> 
>>> http://howfuckedismydatabase.com/nosql/
>> 
>> To be fair: http://howfuckedismydatabase.com/mysql/
>> 
>>> 2) Our team can support MySQL in their sleep, but I can't say that for C*
>>> 3) The node driver for C* is immature.
>> 
>> That pretty much sums it up.  We're aggressively slashing risks and
>> unknowns all around this project.
>> 
>>> As temporary or permanent as anything else. We have no timeline or
>>> criteria to replace it. Danny and Ryan wrote the data store abstraction
>>> layer in the Auth Server to not rule out C*, but that's just because
>>> they're too wimpy to burn bridges. :)
>> 
>> :-P
>> 
>> FWIW I'm still bullish on Cassandra as a great fit for this problem.
>> But I'm even more bullish on getting something ready to ship sooner
>> rather than later.
>> 
>>>> Finally, what is the sanest multi-region strategy available to us
>>>> leveraging our mysql learnings from persona?
>>> 
>>> 2) Multi-master mode, slaving each other. (I don't know anyone with
>>> experience with this in production. If you do, speak up.)
>> 
>> I've previously spoken against this on complexity grounds, but thinking
>> about the shape of our data model, ISTM it could actually work OK.  It
>> would turn out like some Rube Goldberg approximation of a Cassandra
>> cluster with consistency-level=1.
>> 
>> Anyway.  A setup equivalent to current persona.org, with a single write
>> master and slaves in other regions, should work fine for us for a long time.
>> 
>> 
>> Ryan
>> 
>> _______________________________________________
>> Dev-fxacct mailing list
>> Dev-fxacct at mozilla.org
>> https://mail.mozilla.org/listinfo/dev-fxacct
> 
> _______________________________________________
> Dev-fxacct mailing list
> Dev-fxacct at mozilla.org
> https://mail.mozilla.org/listinfo/dev-fxacct




More information about the Dev-fxacct mailing list