Come Dropbox è passata dai 2000 ai 200 milioni di utenti

Da quando Dropbox è stato lanciato pubblicamente nel 2008, il servizio è cresciuto apparentemente all’improvviso da appena poche migliaia a centinaia di migliaia,e poi milioni, di utenti .

Ciò è grandioso per una nuova attività, ma presenta alcuni problemi tecnici, in particolar modo nel momento in cui si inizia a pensare di ampliare le proprie infrastrutture per andare incontro alla domanda degli utenti.

Nel caso di Dropbox, la compagnia si è ritrovata ad affrontare una sfida ancora più difficile in quanto si stava vendendo come soluzione di sincronizzazione e memorizzazione in tempo reale. Affinché Dropbox potesse avere successo, gli utenti dovevano avere fiducia nel fatto che il servizio fosse rapido, affidabile e sicuro.

Quindi, Dropbox come ha gestito la scalata? Rajiv Eranki è stato responsabile della gestione server in Dropbox dal 2008 al 2011. E’ stato il secondo ingegnere assunto e sin dall’inizio, il suo lavoro era finalizzato ad agevolare la scalata del prodotto. Durante la sua permanenza a Dropbox, Eranki ha visto crescere la società dai 2000 ai 40 milioni di utenti

Eranki ha condiviso alcune delle sue esperienze riguardanti l’ampliamento di Dropbox nel suo blog e durante la RAMP Conference di inizio mese.


Video streaming by Ustream

 

 

Ecco alcuni punti chiave:

Scegliere Python è stata una buona decisione

Eranki, nel corso della sua presentazione nella RAMP conference, ha spiegato che il team di Dropbox ha usato Python per praticamente qualsiasi cosa. Ciò è stato positivo perché è significato che l’intera piattaforma “poteva arrivare a 40 milioni di utenti senza il bisogno di scrivere migliaia di righe di codice C.”

Questo è stato riaffermato da Ryan Hunter a PyCon 2011. PyCon è una conferenza dedicata al linguaggio Python e Hunter ha tenuto una presentazione intitolata “Come Dropbox ce l’ha fatta e Come Python l’ha aiutata.”

Il vantaggio offerto da Python è stato quello di aver permesso al team una scalata molto più rapida rispetto a quella possibile se fosse stato impiegato un altro linguaggio o gruppo di linguaggi alla base.

Nei primi tempi, quando solo due ingegneri erano concentrati sulla scalata, limitare la complessità costituiva una parte importante per assicurare che il progetto continuasse a crescere.

Allo stesso modo, usando grandi quantità di software popolari, tra cui MySQL e le infrastrutture S3 di Amazon ed EC2, il team ha potuto assicurare che almeno nei primi tempi non era affatto il più grande o più attivo utilizzatore di una tecnologia.

Testa i tuoi potenziali punti deboli

Uno dei punti che Ernaki tocca ripetutamente nella sua presentazione è che è importante che i sistemi che possono fallire siano testati. Di frequente, Ernaki ha affermato che il team difficilmente riavvierebbe i server per vedere cosa accadrebbe. Funziona la strategia di failover? Il processo si riattiva da solo?

Rendendosi conto di come qualcosa non funziona e testando questi sistemi quando le cose stanno andando bene rende gestibili gli errori effettivi.

Ernaki scrive: “Forse suona sciocco eseguire esercitazioni antiincendio sul sito vero e proprio, ma testare gli ambienti non è sufficiente e questa è una assicurazione molto buona.

Mantenere l’hardware coerente

Buona parte dell’ampliamento di Dropbox è significato il bisogno di acquistare nuove componenti hardware. Piuttosto che fare affidamento su diverse configurazioni server e diversi tipi di hardware, il team ha avuto poche categorie di tipi di macchinari con configurazioni coerenti.

Come Ernaki ha puntualizzato, limitare l’ammontare di “capacity planning” aiuta anche a mantenere le cose coerenti nel momento in cui si rende necessario affrontare un problema specifico di una determinata componente hardware.

Usare UTC

Usare il time code UDC tra i server ha evitato a Dropbox di incorrere in potenziali problemi di un server o sistema localizzato in un fuso orario ed un altro in un altro. Dropbox va ancora più avanti non convertendo l’orario al fuso orario degli utenti fino allìultimo secondo, nel browser (o file manager).

Il team Dropbox ha impostato anche il suo orologio da parete su UTC, così che tutti stessero nello stesso orario così come i loro server.

Questo potrebbe sembrare sciocco, ma quando una gran parte del tuo business risiede in una affidabile sincronizzazione dei file, una cambiamento di fuso orario potrebbe potenzialmente significare che i file sono stati sincronizzati in maniera sbagliata.

Aggiornare spesso

Uno dei mantra di Dropbox era, ed è, il rilascio frequente di aggiornamenti. Nei primi tempo di Dropbox, il condice veniva rilasciato lo stesso giorno in cui veniva codificato. Questo significava che i risultati erano immediatamente disponibili e i potenziali miglioramenti aiutavano immediatamente gli utenti.

Anche oggi, Dropbox rilascia ancora aggiornamenti beta per i suoi client Mac, Windows e Linux. Questi rilasci spesso introducono nuove caratteristiche prima di colpire la fascia principale di utenti che vogliono espressamente testare nuove funzioni, pur capendo che potrebbero esserci alcuni bug.

Per quanto importanti i primi rilasci siano, comunque, Dropbox ha dovuto comunque assicurare che solo il codice stabile fosse mandato ai suoi client. Dopotutto, una cartella corrotta ed il lavoro perso sono una delle cose peggiore che possano accadere ad un servizio di memorizzazione e sincronizzazione.

Cosa ne pensi del modo in cui Dropbox è cresciuto?

———-

Orinally Published in: Mashable

Post: How Dropbox Scaled From 2,000 to 200 Million Users

Author: Christina Warren

Share this post

No comments

Add yours