Quote:
Originariamente inviato da Tasslehoff
Pensare a una architettura e a una applicazione scalabile non significa necessariamente scalare o che la scalabilità (mi riferisco a quella orizzontale ovviamente) sia necessaria, perchè come dicevo 9 volte su 10 non lo è assolutamente, almeno dalla mia esperienza (e non parlo del sito della ditta pizza&fichi srl)
Quasi sempre la sofferenza in termini di performance viene interpretata come scarsità di risorse e necessità di scalare, quando invece i problemi nella maggior parte dei casi hanno natura applicativa, dalle classiche query scritte a "membro di segugio", indici mancanti, eccezioni non gestite, utilizzo di risorse di terze parti scorretto o che rappresentano colli di bottiglia, oppure analisi mal fatta.
Pensiamo ai classici casi da clickday, ok l'idea di base è assurda ma ahimè capitano.
Già solo pensare di affrontarli pensando prima di tutto alla scalabilità significa perdersi dei pezzi fondamentali e creare delle solide fondamenta ad un disastro annunciato.
Al mio gruppo di lavoro è capitato di affrontare casi del genere, con benefici fiscali (leggasi soldi regalati) ad una platea fino a un paio di milioni di potenziali utenti e la logica di base (assurda) era "chi prima arriva meglio alloggia, gli altri si attacchino al tram e urlino in curva".
In quel caso già solo disaccoppiare la fase di prenotazione della domanda per definire l'ordine di arrivo (es stacco il biglietto col numerino dal salumiere) dalla presentazione della stessa (complessa finchè vuoi ma "spalmata" su un lasso temporale più gestibile) ci ha permesso di affrontarla in totale scioltezza.
Scalabilità? Giusto due application server per garantire quel minimo sindacale di ridondanza, ma il carico era ampiamente gestibile con uno solo.
E parliamo di un caso limite, quanti gruppi di lavoro si trovano ad affrontare scenari da clickday? Pochissimi (e spero sempre meno in futuro, ma solo perchè spero che chi ha potere decisionale risavisca un po' visti i flop clamorosi osservati).
Poi ragazzi, onestamente negli ultimi 15 anni non ho più visto un progetto da Roma a Milano dove le risorse siano oggettivamente scarse (tolto forse lo storage, ma quello più per ragioni quantitative che prestazionali).
Posso capire finchè si parla del boom del web dei primi anni 2000, quando si un server scaccione, assemblato alla buona con pezzi di fortuna si doveva far girare tutto e il contrario di tutto, ma oggi oggettivamente i problemi per scarsità di risorse bisogna proprio andarseli a cercare (appunto con le rogne applicative di cui sopra).
|
E invece io questi problemi li ho visti. Ho lavorato in una startup passata da 30 a 400 dipendenti in 12 mesi, fatturato, volume di richieste e traffico letteralmente esploso. Database postgres in fiamme, query lente e caricamenti massivi di dati che impiegano ore, disperata ricerca di db admin esperti per capire come ottimizzare il tutto. Db scalato verticalmente fino al top possibile e poi solo molta pazienza da parte dei clienti.
Per non parlare della ridondanza. Con OVH che ha preso fuoco siamo ancora convinti che vogliamo avere codice e dati in un solo datacenter?