Mondi su mondi, sistemi di sistemi.

Skype, le mode e la reinvenzione della ruota

Non è un mistero che mi piac­ciano le solu­zioni inu­suali, l’ho scritto in pas­sato: a pro­po­sito dell’intervista ad Avy Briant1, lo ripeto ora dopo aver visto que­sta pre­sen­ta­zione dell’architetto soft­ware di Skype2, sem­pre su InfoQ.

Avevo già letto l’articolo3 ma, anche se è stata una delle cose più inte­res­santi degli ultimi mesi, non mi era pro­prio venuta in mente l’intervista, né tan­to­meno que­sto mio post di due anni fa in cui avevo segna­lato que­sta descri­zione sull’architettura di Skype, che è basata su PostgreSQL.4.

Qual è il nesso?

D’accordo, ammesso che in comune ci sia la capa­cità di tro­vare solu­zioni senza affi­darsi a pre­con­cetti, in un modo che potremmo defi­nire con­text dri­ven5, cos’ha di così par­ti­co­lare l’architettura di Skype? Per capirlo, dob­biamo fare mente locale sul con­te­sto attuale.

L’ascesa del NoSQL

In que­sto periodo, diciamo negli ultimi due anni, si è fatta strada l’idea secondo cui non puoi sca­lare vera­mente un’architettura se ti affidi ai data­base SQL, soprat­tutto se par­liamo di sca­la­bi­lità oriz­zon­tale6. Questo è uno degli assunti, forse il prin­ci­pale, che ha por­tato alla ribalta il cosi­detto movi­mento NoSQL7.

Non c’è dub­bio che ci pos­sano essere pro­blemi a sca­lare i data­base “tra­di­zio­nali”, né che siano adatti a qual­siasi uso e nem­meno che ci sia ancora molto da fare per ren­derli più adatti al modo di lavo­rare attuale8 9.

Naturalmente i data­base SQL sono ancora usa­tis­simi ma non mi aspet­tavo di vedere la pre­sen­ta­zione di uno che lavora esclu­si­va­mente con le sto­red pro­ce­du­res10. Ecco per­ché un’architettura come quella di Skype sem­bra così par­ti­co­lare rispetto a quello che oggi fa ten­denza ed ecco per­ché è così impor­tante tenerla presente.

Reinventare la ruota, ogni volta

Siamo sem­pre attratti dall’adottare quello che ha fun­zio­nato l’ultima volta o quello che sem­bra fun­zio­nare per tutti gli altri. A volte è la cosa giu­sta da fare, a volte no, ognuno sba­glia a modo proprio.

Forse è uno scherzo della memo­ria ma credo di ricor­dare che in un’intervista gli svi­lup­pa­tori della Bungie (quelli di Halo, poi com­prata da Microsoft) dice­vano che uno degli obiet­tivi che si pone­vano era pro­prio quello di rein­ven­tare la ruota, per fare piazza pulita delle cose supe­rate. Sembra che abbia fun­zio­nato! 11

  1. Outside the box. ↩
  2. Learning from Five Years as a Skype Architect Andres Kutt discus­ses his expe­rience as archi­tect at Skype for five years, sha­ring some of the les­sons lear­ned: rules of thumb do not always apply, func­tio­na­lity is impor­tant, use sim­ple solu­tions, buz­z­words are dan­ge­rous, the archi­tec­ture needs to fit into the orga­ni­za­tion, and com­mu­ni­ca­tion is impor­tant. ↩
  3. Learnings from Five Years as a Skype Architect: Too often in our work as archi­tects and desi­gners we focus on the task at hand, sel­dom reflec­ting on the past. We should really know bet­ter, how else do you improve? This arti­cle sum­ma­ri­zes six lear­nings from 55 mon­ths as an archi­tec­ture team lead at Skype. ↩
  4. PostgreSQL: ana­lisi dell’architettura di Skype ↩
  5. Context dri­ven testing. Non fatevi ingan­nare dal fatto che si parla di testing, sono con­si­de­ra­zioni di vali­dità gene­rale. ↩
  6. Da Wikipedia: To scale hori­zon­tally (or scale out) means to add more nodes to a system, such as adding a new com­pu­ter to a distri­bu­ted soft­ware appli­ca­tion. An exam­ple might be sca­ling out from one web ser­ver system to three. ↩
  7. Da Wikipedia: In com­pu­ting, NoSQL is a term used to desi­gnate data­ba­ses which dif­fer from clas­sic rela­tio­nal data­ba­ses in some way. These data sto­res may not require fixed table sche­mas, and usually avoid join ope­ra­tions and typi­cally scale hori­zon­tally. Academics and papers typi­cally refer to these data­ba­ses as struc­tu­red sto­rage, a term which would include clas­sic rela­tio­nal data­ba­ses as a sub­set.
    Notable pro­duc­tion imple­men­ta­tions include Google’s BigTable and Amazon’s Dynamo. ↩
  8. I refac­to­ring che coin­vol­gono il data­base riman­gono ancora troppo mac­chi­nosi. In parte è un pro­blema di stru­menti, in parte è un pro­blema di metodo di lavoro per­ché, forse più che in altri con­te­sti, le ope­ra­zioni da fare sul data­base sono molto spe­ci­fi­che. ↩
  9. Bisogna anche far notare che sotto l’ombrello della defi­ni­zione NoSQL ci sono realtà molto diverse, alcune sono pen­sate per la sca­la­bi­lità (Cassandra, ad esem­pio), altre per modelli di dati che non sono facil­mente ridu­ci­bili all’SQL come i graph data­base. ↩
  10. Anche se, a onor del vero, la pre­sen­ta­zione non riguarda PostgreSQL ma quello che que­sta per­sona ha impa­rato lavo­rando per cin­que anni a Skype ↩
  11. La ten­sione fra riscrit­tura da zero e refac­to­ring è uno dei temi che ricor­rono in que­sto blog, non c’è niente da fare… Dovrò fare una rac­colta dei vari post, un giorno o l’altro. ↩
Scritto il 19/08/10 da giorgio_v.
Tags: , .

Per proseguire

Commenti e trackback sono disabilitati.