Di Andrew Tan
La demo che non ha colpito
Eravamo a diciotto mesi dalla costruzione di layline.io quando abbiamo ottenuto il nostro primo serio potenziale cliente aziendale. Una società di logistica Fortune 500. Il loro team di dati aveva esaminato la nostra architettura, apprezzato l'approccio batch-plus-streaming, e programmato un workshop di un'intera giornata per approfondire.
Ci siamo preparati per settimane. Abbiamo costruito una demo che mostrava tutto: elaborazione di eventi complessi, gestione automatica di backpressure, evoluzione dello schema. Era, secondo ogni definizione da manuale, un'architettura di best practice. Distribuita. Fault-tolerant. Costruita per scalare orizzontalmente. Il tipo di sistema che disegneresti su una lavagna durante una conferenza.
Il workshop è andato bene. Gli ingegneri hanno fatto buone domande. Poi, negli ultimi trenta minuti, l'architetto senior si è appoggiato indietro e ha detto qualcosa che non dimenticherò mai: "Questo è impressionante. Ma noi gestiamo tutto su un singolo server con cron job, e funziona. Cosa guadagneremmo realmente da tutta questa complessità?"
Avevo cento risposte pronte. Scalabilità. Resilienza. Preparazione al futuro. Ma vedevo nel suo volto che non stava chiedendo un confronto tecnologico. Mi stava chiedendo di giustificare perché la sua realtà attuale — noiosa, semplice, funzionante — fosse insufficiente.
Non potevo. Non onestamente.
L'architettura che ho cancellato
Tre mesi dopo, ero in una stanza diversa con un cliente diverso. Questo era una fintech di medie dimensioni. Gestivano un Data Pipeline basato su Kafka da due anni. Stava crollando costantemente. Avevano assunto consulenti, aggiornato l'hardware, riscritto la loro logica del consumatore due volte. Il sistema era "corretto" secondo ogni manuale sui sistemi distribuiti. Era anche un incubo da gestire.
Durante l'incontro, il loro ingegnere capo mi ha mostrato il diagramma dell'architettura. Era bellissimo. Dodici microservizi, tre diversi livelli di persistenza, un data store operativo personalizzato per la gestione dello stato. Avevano seguito ogni schema dal blog di Confluent e dal libro di Martin Kleppmann.
"E se," ho chiesto, "scriveste semplicemente gli eventi su un file e li elaboraste in batch?"
Mi ha fissato. "Questo... non è streaming."
"No," ho concordato. "Ma stai comunque elaborando eventi ogni ora perché il tuo sistema a valle non può gestire aggiornamenti in tempo reale. Stai pagando il costo operativo di un'architettura di streaming per ottenere semantiche batch."
Non hanno acquistato layline.io quel giorno. Ma sei settimane dopo, ho ricevuto un'email. Avevano cancellato l'intera architettura. L'hanno sostituita con un singolo processo che leggeva file e scriveva su un database. Un cron job, praticamente. La loro latenza p99 è passata da 200ms a cinque minuti — il che non importava perché il loro processo aziendale era giornaliero. I loro incidenti operativi sono passati da tre a settimana a zero. Il loro team di ingegneri è passato dal combattere incendi a spedire funzionalità.
L'architettura "sbagliata" era migliore perché corrispondeva ai loro vincoli effettivi, non a quelli aspirazionali.
La trappola delle best practice
Ecco cosa ho imparato da 25 anni di costruzione e vendita di infrastrutture dati: le best practice sono per definizione dipendenti dal contesto, ma vengono commercializzate come verità universali.
L'architettura streaming-first di cui Netflix ha bisogno non è l'architettura di cui ha bisogno una società SaaS di 50 persone. L'approccio ai microservizi che consente ad Amazon di distribuire 10.000 volte al giorno non è ciò di cui ha bisogno il tuo team di quattro ingegneri. Il framework di agenti AI che ha raccolto 50 milioni di dollari in finanziamenti VC non è ciò di cui ha bisogno il tuo ETL basato su cron.
Ma non lo sapresti leggendo i contenuti del settore. Ogni post sul blog dei fornitori, ogni discorso in conferenza, ogni schema di architettura mostra la stessa progressione: inizia semplice, poi "passa" alla complessità man mano che cresci. L'implicazione è chiara: semplice è per i principianti. La complessità è per i professionisti seri.
Questo è sbagliato. La complessità è una responsabilità che dovrebbe essere aggiunta con riluttanza, non un distintivo d'onore da perseguire con entusiasmo.
Cosa significa realmente "funziona per noi"
Ho iniziato a fare ai clienti una domanda diversa nelle prime conversazioni: "Qual è la cosa più semplice che potrebbe funzionare per il tuo carico di lavoro effettivo?" Non il tuo carico di lavoro previsto tra tre anni. Non il tuo caso d'uso in tempo reale aspirazionale che il CEO ha menzionato una volta. Il tuo carico di lavoro effettivo, oggi.
Le risposte sono costantemente sorprendenti:
- Una società sanitaria che elabora un milione di record di pazienti al giorno lo fa con uno script Python a thread singolo che gira per quattro ore ogni notte. Funziona da sei anni senza modifiche. Perché? Perché i record arrivano via FTP alle 2 del mattino, e i medici non guardano i cruscotti fino alle 8 del mattino.
- Una società di vendita al dettaglio che elabora dati di punto vendita da 2.000 negozi utilizza un cluster Kafka a tre nodi. Non perché abbiano bisogno del throughput — potrebbero inserire gli eventi di un giorno in un singolo file — ma perché il loro team esistente conosceva Kafka e non aveva tempo per imparare qualcosa di nuovo durante la loro stagione più impegnativa.
- Una società di logistica che traccia le navi container in tempo reale utilizza... un foglio di calcolo. Il team operativo lo aggiorna manualmente. Hanno provato a costruire una pipeline automatizzata due volte. Entrambe le volte, il sistema automatizzato ha fallito in modi più difficili da debugare rispetto al foglio di calcolo. Il foglio di calcolo è "sbagliato" in una dozzina di modi, ma è ispezionabilmente sbagliato. Puoi vedere gli errori.
Nessuna di queste è una "best practice". Tutte sono corrette per il loro contesto.
Il ciclo di hype degli agenti AI
Se vuoi vedere la trappola delle best practice nella sua forma più aggressiva, guarda come l'industria dell'ingegneria dei dati sta attualmente rispondendo agli agenti AI.
Ogni blog dei concorrenti che leggo ultimamente — Airbyte, Confluent, Kestra — sta posizionando il loro prodotto come "pronto per gli agenti AI". Ci sono approfondimenti su Model Context Protocol, ontologie per agenti, gestione delle finestre di contesto. Il messaggio implicito: se non stai progettando per gli agenti AI in questo momento, stai rimanendo indietro.
Ho chiesto a un cliente la scorsa settimana se stavano considerando gli agenti AI per le loro pipeline di dati. "Abbiamo passato sei mesi cercando di far generare SQL a un LLM," ha detto. "Era accurato al 70% su query semplici e al 30% su quelle complesse. Il 30% era abbastanza sottile da non essere notato fino a quando il CEO ha visto un numero sbagliato in una presentazione al consiglio. Siamo tornati a far scrivere SQL agli ingegneri."
Questo non è un argomento contro l'AI. È un argomento contro il default all'AI perché è la best practice corrente. I team che beneficiano degli agenti AI oggi hanno caratteristiche specifiche: alti volumi di query, schemi relativamente semplici, tolleranza per errori occasionali e risorse ingegneristiche per validare i risultati. Se ciò non descrive la tua situazione, gli agenti AI non sono ancora la tua soluzione — non importa quanti post sul blog dei fornitori suggeriscano il contrario.
Come valutare effettivamente la tecnologia
Quindi, se le "best practice" non sono una guida affidabile, cosa lo è?
Ecco il framework che uso ora, sia per le mie decisioni architetturali che quando consiglio i clienti:
Inizia con i tuoi vincoli effettivi. Quanti dati? Quali schemi di arrivo? Quali requisiti di latenza? Quale dimensione e competenza del team? Quale budget per le operazioni? Le risposte a queste domande eliminano immediatamente il 90% delle architetture "standard del settore".
Ottimizza per il debug, non per l'eleganza. L'architettura che produce diagrammi puliti è spesso quella più difficile da debugare alle 2 del mattino. Preferisci sistemi in cui puoi tracciare un singolo record dalla fonte alla destinazione senza attraversare tre diversi livelli di astrazione.
Misura il costo operativo in termini di attenzione del team, non solo in dollari di infrastruttura. Un sistema distribuito che si gestisce da solo ma richiede un ingegnere senior in reperibilità è più costoso di un singolo server che necessita di riavvii occasionali ma può essere gestito da un neoassunto.
Pianifica la migrazione che farai effettivamente, non quella che dovresti fare. Ogni team ha sistemi legacy che non ritirerà mai. Progetta per una coesistenza armoniosa con la vecchia tecnologia piuttosto che per una sostituzione rivoluzionaria di essa.
In caso di dubbio, inizia in modo noioso. Puoi sempre aggiungere complessità. Rimuoverla è molto più difficile. I team che vedo avere successo sono quelli che aggiungono tecnologia con riluttanza, con prove chiare che gli approcci più semplici sono stati esauriti.
Il contro-argomento che non sto facendo
Voglio essere chiaro su cosa non sto dicendo. Non sto sostenendo il conservatorismo tecnico o contro il provare nuove cose. Alcuni problemi richiedono davvero architetture complesse, distribuite e in tempo reale. Se stai elaborando pagamenti su larga scala, hai bisogno di semantiche exactly-once. Se stai servendo funzionalità di ML con latenza inferiore a 100ms, hai bisogno di streaming. Se sei Netflix, hai bisogno di ciò di cui ha bisogno Netflix.
Ma la maggior parte delle aziende non è Netflix. La maggior parte dei Data Pipeline non deve gestire 10.000 eventi al secondo. La maggior parte dei team non ha un gruppo di ingegneria della piattaforma per gestire il carico operativo dell'infrastruttura dati "moderna".
La scomoda verità è che l'industria ha confuso "ciò che fanno le aziende tecnologiche di successo" con "ciò che dovresti fare". Le aziende tecnologiche di successo hanno risorse ingegneristiche infinite, alta tolleranza per il dolore operativo e modelli di business che richiedono tutto in tempo reale. Probabilmente la tua azienda no. La tua architettura non dovrebbe fingere il contrario.
Dove si inserisce layline.io (e dove no)
Concluderò con qualcosa che potrebbe sorprenderti: layline.io non è la scelta giusta per ogni problema di integrazione dati.
Se hai alcuni lavori batch che funzionano in modo affidabile secondo un programma, e il tuo team è a suo agio con la tua configurazione attuale, probabilmente non hai bisogno di noi. Seriamente. Il sovraccarico operativo di apprendere una nuova piattaforma non vale la pena se la tua realtà attuale è stabile e compresa.
Dove aggiungiamo valore è quando hai superato gli approcci semplici ma vuoi evitare la tassa di complessità di mettere insieme più strumenti specializzati. Quando hai bisogno sia di batch che di streaming nello stesso sistema. Quando il tuo team è stanco di mantenere livelli separati di orchestrazione, trasformazione e monitoraggio. Quando vuoi consolidarti attorno a un unico modello invece di gestire una cucitura di coordinamento tra tre strumenti diversi.
Anche allora, preferirei che iniziassi con una prova di concetto che elabora i dati di un solo giorno piuttosto che con un piano di migrazione ambizioso. Dimostra che l'approccio più semplice funziona per il tuo carico di lavoro effettivo prima di impegnarti in quello complesso.
La best practice è quella che funziona per te. Tutto il resto è solo marketing.
Se stai valutando l'infrastruttura dati e vuoi una valutazione onesta di quale complessità valga effettivamente la pena aggiungere per la tua situazione specifica, contattaci. Ti diremo se hai bisogno di noi o se dovresti mantenere i tuoi cron job.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che in tempo reale su larga scala.
