Magari mi sbaglio, ma mi sembra che ormai si associ la scalabilità del software solo all’infrastruttura che lo ospita. Ok, usare kubernetes o fare i microservizi serverless fa molto figo, ma la scalabilità di una applicazione dovrebbe partire (anzi, deve partire) innanzitutto dall’applicazione stessa, non dal suo contenitore.
Vi faccio un esempio concreto (che poi è il motivo che mi ha portato a scrivere questo post): ieri stavo lavorando su un job che impiegava 17 minuti per processare circa 100k elementi. Avevo due opzioni: fregarmene perché “tanto basta dargli più risorse” o fare in modo che il job impiegasse meno, perché sotto sotto sapevo che c’era del margine di miglioramento. Dopo un po’ di ricerche ho trovato, un po’ nascosto in una funzione all’apparenza innocua, un O(N) che, una volta fatto diventare O(1), ha portato i 17 minuti a 5. Lo so lo so è faticoso, richiede di conoscere il dominio dell’applicazione, analizzare la complessità, le query, gli indici…ma non è proprio lì dove dovremmo fare la differenza?
La scalabilità non si può ottenere trattando l’applicazione come una black box a cui possiamo solo fornire più risorse.
Investire su queste attività paga, anche abbastanza rapidamente, perché ci troviamo in poco tempo a riuscire a gestire, a parità di risorse disponibili, il 10, 20, 30% in più di richieste.
Tutto questo pippone per ricordarmi e ricordarci che la prima responsabilità della scalabilità del nostro software sta nel codice che scriviamo e nella nostra capacità di trovarne le criticità e le relative soluzioni, possibilmente anzitempo. Poi, e solo poi, possiamo ragionare anche in termini infrastrutturali, ma prima, dobbiamo fare (bene) il nostro lavoro 🙂
