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