La domanda non è 'qual è lo stack migliore'. È: chi lo manutiene, quanto costa cambiarlo, e cosa succede quando il primo che lo ha scelto se ne va.
La domanda utile non è quale sia lo stack migliore. È chi lo sa operare tra tre anni, quanto costa tenerlo in vita, quanto è difficile assumere o sostituire chi lo conosce, e quanto tempo ci vuole a cambiarlo il giorno in cui non basta più. Il resto, benchmark da keynote e linguaggi "del momento", è gusto. Il gusto, in produzione, si paga.
In breve: scegli sullo skill del team, sul costo operativo, sul mercato del lavoro, sul lock-in e sul tempo di uscita. Non su una tabella PHP contro Node. Uno stack che il gruppo già governa batte, quasi sempre, uno stack più elegante che nessuno sa rimettere in piedi di domenica.
Cosa trovi in questo articolo
La domanda sbagliata
"Quale stack è più veloce" è una domanda da talk, non da progetto. Veloce dove, su quale carico, con quale codice, con chi a manutenere gli anni successivi. Un runtime può essere eccellente in un benchmark sintetico e insostenibile in un team di tre persone che già tiene in piedi un CMS, un ERP e la posta. L'inverso è altrettanto vero: uno stack "vecchio" che il gruppo conosce a memoria chiude i ticket. Uno stack nuovo che nessuno ha operato in produzione li apre.
Non pubblichiamo confronti PHP contro Node, Java contro Go, o classifiche di framework. Non perché siano argomenti vietati. Perché senza un carico reale, un profilo di traffico e un team nominato, quei numeri non si trasferiscono. Diventano un alibi per una scelta già fatta per altre ragioni, di solito noia o curriculum.
Lo stack è un contratto operativo. Linguaggio, runtime, database, coda, modo di deployare, modo di osservare. Cambia una pezzo e cambiano hiring, runbook, backup, incidente. Per questo sta nel cluster Stack, non in una lista di mode. E per questo si tiene vicino al discorso sul debito tecnico: ogni scelta che il team non sa più toccare diventa lavoro futuro obbligato, con interessi.
Cinque criteri che pesano, uno che no
I criteri che reggono una decisione, in ordine di onestà:
Skill del team che c'è. Non quello che vorresti avere. Quello che lunedì mattina apre i log.
Costo operativo. Non la licenza. Ore per deployare, patchare, aggiornare dipendenze, tenere in piedi staging, spiegare il sistema a un nuovo assunto.
Hiring e sostituibilità. Quante persone, in un raggio ragionevole o in remoto, sanno questo mestiere. Cosa succede se se ne va chi l'ha scelto.
Lock-in. Quanto del tuo dominio è scritto in un dialetto, in un vendor, in un'API che non porti via.
Tempo di cambio. Se tra due anni dovessi uscire, misurato in mesi di lavoro, non in slide.
Il criterio che non pesa, da solo: "è più moderno". Moderno rispetto a che cosa, per chi, con quale costo di apprendimento. Una tecnologia può essere la scelta giusta. Lo si dimostra sui cinque punti sopra, non con la data di uscita della release.
Due corollari noiosi. Primo: il framework del tutorial non è lo stack. Lo stack include database, cache, code, osservabilità, CI, come fai le migrazioni schema. Secondo: "usiamo quello che usa X" non è un criterio se X ha un team, un traffico e un problema diversi. Copiare l'architettura di una piattaforma planetaria su un catalogo da poche migliaia di visite è un hobby costoso.
Skill, assunzioni, persone che se ne vanno
Il vincolo più duro è antropologico, non tecnico. Un gruppo che ha dieci anni di un ecosistema alle spalle produce valore in quell'ecosistema anche se un thread su internet lo dichiara superato. Invertire per noia significa pagare, in parallelo, il lavoro vecchio e l'apprendimento del nuovo, con un periodo in cui nessuno dei due è solido.
Hiring: alcuni ecosistemi hanno un mercato largo, altri no. Largo non significa migliore. Significa che sostituire una persona è un problema di settimane, non di unicità. Stretto può essere accettabile se il pezzo è piccolo e isolato. È un rischio se è il cuore del prodotto e lo conosce una sola testa.
Il test brutale è questo. Scrivi su un foglio chi può fare un deploy di emergenza, chi sa leggere una query lenta, chi sa rinnovare un certificato, chi sa ripristinare il database. Se i nomi coincidono tutti con la stessa persona, lo stack è quella persona. Il giorno in cui va in ferie, o se ne va, il debito diventa visibile. Non è un argomento contro le tecnologie di nicchia. È un argomento contro fingere che il curriculum di uno sia l'architettura dell'azienda.
Lock-in e tempo di cambio
Ogni stack ha un lock-in. Linguaggio, cloud, CMS, database gestito, autenticazione di terzi. Il punto non è evitarlo in assoluto, è saperlo nominare. Lock-in accettabile: un servizio che risolvi in un trimestre, con dati esportabili e un'interfaccia che puoi avvolgere. Lock-in pericoloso: logica di business scritta in un dialetto proprietario, dati che escono solo a pagamento, un runtime che esiste in un solo posto.
Il tempo di cambio è il criterio che i listini non mostrano. Quanto ci vuole a sostituire il pezzo, a parità di prodotto visibile. Se la risposta è "riscriviamo", non hai scelto uno stack. Hai sposato un monolite di decisioni. A volte va bene: il vantaggio competitivo sta lì, e lo tieni. A volte è pigro: hai costruito in casa ciò che dovevi comprare, o comprato ciò che era il tuo mestiere. Il confine è il tema di build or buy.
Stesso discorso per il CMS, che è spesso lo stack visibile al resto dell'azienda. Open source auto-ospitato, SaaS, piattaforma gestita: tre contratti diversi su chi patcha, chi possiede i dati, come esci. Non si decide sull'editor visuale. Si decide su quel contratto, e il pezzo dedicato è CMS proprietario, open source o SaaS.
Quando non lo fai da solo
C'è un punto in cui la scelta dello stack e la sua messa in opera non coincidono più con le persone che hai in organico. Non è un fallimento. È un confine. Se il team non ha ore per fare il lavoro, o se il lavoro tocca pezzi (identità, pagamenti, migrazione di dati, osservabilità) dove un errore costa più della consulenza, si cerca chi lo ha già fatto.
Un partner di implementazione serve a eseguire una decisione, non a sostituirla. Arrivi con i vincoli: team interno, vincoli di hosting, tempo di uscita, cosa non si tocca. Altrimenti ti ritrovi con lo stack che piace a chi ti ha venduto le giornate. Tra chi fa questo mestiere in Italia ci sono anche i servizi di sviluppo web di Keidea. Non è una prescrizione. È un esempio del tipo di lavoro che chiedi quando lo stack va messo in produzione da qualcuno che ci resterà accanto dopo il go-live, non solo il giorno della demo.
La regola pratica: il partner scrive, il tuo team deve poter operare. Se dopo la consegna solo loro sanno fare il deploy, hai comprato un lock-in di persone, che è il più caro.
Ha senso quando. Non serve quando
Ha senso cambiare stack quando il vincolo è reale: non trovi persone, il runtime è fuori supporto, il vendor chiude, il costo operativo mangia i rilasci, il tempo di cambio sta diventando infinito se aspetti ancora. Si cambia con un piano di uscita, con un pezzo alla volta se puoi, con un periodo in cui vecchio e nuovo convivano senza eroismi.
Non serve cambiare perché una conferenza ha dichiarato morto il tuo linguaggio, perché un candidato ha detto che "oggi si fa così", perché il CTO si annoia. L'annoia è un problema di management, non di runtime. Si risolve con un progetto nuovo, un'area isolata, un'esplorazione con budget. Non con una riscrittura del canale che porta i soldi.
Non serve nemmeno "standardizzare tutto" se i problemi sono diversi. Un sito editoriale, un'API interna e una coda di import notturno possono convivere. L'uniformità totale è un valore. Non è il valore più alto, se per ottenerla butti via pezzi che funzionano.
Errori da evitare
Scegliere sul benchmark di un vendor. Misura il tuo carico, o non misurare. Una slide non è un dato.
Confondere preferenza personale e vincolo aziendale. Il curriculum di chi decide non è l'architettura.
Introdurre un secondo stack senza owner. Due ecosistemi vogliono due runbook, due pipeline, due modi di patchare. Se l'owner è uno solo, hai raddoppiato il lavoro, non le opzioni.
Ignorare il tempo di uscita. "Poi migreremo" senza una stima in mesi è un modo educato per dire mai.
Riscrittura totale per un problema locale. Se è lento un report, si sistema il report. Non si cambia linguaggio.
Delegare la scelta al fornitore senza vincoli scritti. Torna con il suo default. È normale. Era tuo il compito di dirgli di no.
In sintesi
Lo stack giusto è quello che il team sa operare, che si riesce ad assumere, che non ti sposa per sempre, che puoi cambiare in un tempo che conosci. Il gusto, i keynote, i duelli tra runtime senza carico, restano fuori dalla tabella. Quando il lavoro supera le persone che hai, si prende un partner di implementazione, con vincoli già scritti e con l'obbligo che il tuo gruppo resti capace di accendere le luci. Meno rumore, più metodo. Il resto è moda, e la moda in produzione ha un costo che non sta nel listino del framework.
Fonti
Nessun benchmark di runtime è usato come prova in questo pezzo: i confronti sintetici non si trasferiscono da un carico all'altro senza misura sul campo.
Il quadro di prodotto su debito e make-or-buy sta nei pezzi interni citati, cluster Stack e Prodotto.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
