http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
Moltissimi spunti interessanti conditi con mie considerazioni:
- le cose (server, dischi, schede e apparati di rete, ecc.) si rompono: bisogna imparare a gestire la cosa. Non fare finta che non possa accadere.
- sviluppare servizi "interni", con poche dipendenze, chiare e documentate
- usare "protocolli" (strutture dati) che possono evolvere in modo trasparente per i "sistemi intermedi" (ogni applicazione capisce i propri "tag")
- conoscere i "numeri base" del performance di trasferimento dati in condizioni diverse (memoria, disco, lan, rete geografica, ecc.)
- fare fronte alle richieste degli utenti senza far esplodere il sistema in termini di complessità. Oltre un certo punto, per far fronte a tutte le richieste, il sistema diventa troppo complesso e costoso.
- sviluppare infrastrutture (e software) in base ad esigenze reali e non speculare su possibili esigenze future che, ad oggi, non esistono. Considerare invece come le esigenze attuale potrebbero evolvere.
- la velocità di risposta delle applicazioni è molto importante. Attenzione alla latenza.
Nessun commento:
Posta un commento