Strumenti & Stack

Quando si sviluppa un sistema software, ogni componente (il linguaggio di programmazione, il database, l'infrastruttura cloud, gli strumenti di deploy) deve essere scelto, configurato e fatto funzionare insieme agli altri. L'insieme di queste tecnologie si chiama stack. Non è una lista della spesa: è un'architettura di scelte che determinano quanto un sistema sarà affidabile, manutenibile e scalabile nel tempo. Uno stack ben costruito passa inosservato. Uno stack mal costruito diventa il problema principale dell'azienda nel momento meno opportuno.

Il nostro stack non è un dogma. Cambia in funzione del contesto del cliente, dei vincoli tecnici e delle competenze del team che dovrà mantenere il sistema. Quello che segue è l'insieme di tecnologie che utilizziamo più frequentemente, con le ragioni per cui le preferiamo. Quando il progetto lo richiede, usciamo da questo perimetro senza esitazione.

Questa pagina non è un badge wall. Non elenchiamo ogni libreria che abbiamo toccato, ogni servizio cloud che abbiamo configurato, ogni linguaggio in cui sappiamo orientarci: sarebbe una lista lunga e sostanzialmente inutile. Preferiamo dichiarare l'insieme ridotto di strumenti che usiamo come default, quelli che conosciamo abbastanza a fondo da prevedere come si comportano sotto carico, in produzione, dopo due anni di evoluzione. Per ogni voce c'è una ragione di metodo, non di moda. Quando manca una ragione solida, la voce non entra nello stack.

Il principio operativo è quello della boring technology: a parità di funzione, scegliamo lo strumento più maturo, con la comunità più ampia, con il maggior numero di problemi già documentati e risolti. PostgreSQL invece dell'ultima novità NoSQL, Django invece del framework lanciato sei mesi fa, Python invece di un linguaggio emergente che promette il dieci per cento di performance in più. Un'azienda ha un budget limitato di novità che può sostenere senza pagarne il costo in stabilità: lo investiamo solo dove serve davvero, tipicamente sul dominio specifico del cliente, mai sull'infrastruttura di base. Le tecnologie nuove entrano nello stack quando risolvono un problema concreto che le mature non risolvono, non per il piacere di averle in CV.

Va detta anche una cosa importante: non vincoliamo i clienti al nostro stack. Se un'azienda ha già investito in un ecosistema diverso, lavorando con tecnologie che il suo team conosce e mantiene, il nostro compito è inserirci in quel contesto, non sostituirlo. Una migrazione tecnologica si propone solo quando i benefici giustificano il costo di transizione, e nella maggior parte dei casi non lo giustificano. Lo stack che segue è il nostro punto di partenza quando si parte da zero, non un requisito di ingaggio.

L'assenza è una scelta tecnica come la presenza. Non proponiamo blockchain per problemi che non sono di blockchain, perché un database condiviso con controllo degli accessi risolve quasi tutti i casi reali a un costo operativo molto minore. Non costruiamo sistemi di produzione su piattaforme no-code o low-code: vanno bene per prototipi e flussi interni semplici, diventano una trappola quando il caso d'uso evolve oltre quello che la piattaforma prevede. Restiamo cauti sulle ondate di strumenti AI che promettono autonomia operativa senza maturità di osservabilità, valutazione e controllo: li sperimentiamo, ma li portiamo in produzione solo quando esiste un modo serio per misurarne il comportamento. Lo stack si difende anche per sottrazione, non solo per addizione.