Di Andrew Tan
I costi nascosti della creazione di un proprio livello di integrazione Batch-Streaming
Con la programmazione assistita dall'AI, costruire i propri data pipeline sembra più economico che mai. Ma i veri costi non sono nella costruzione iniziale: sono nella manutenzione, nei turni di reperibilità e nella complessità accumulata che si aggrava nel tempo.
Ecco una conversazione che continua a verificarsi:
Responsabile Ingegneria: "Abbiamo bisogno di un nuovo data pipeline per il progetto di analisi dei clienti."
Ingegnere Senior: "Posso occuparmene io. Con Cursor e Copilot, posso completare la logica di base in un paio di giorni."
RI: "E per quanto riguarda la manutenzione?"
IS: "È solo uno script Python con un po' di orchestrazione Airflow. Quanto può essere difficile?"
Tre mesi dopo, l'ingegnere che l'ha costruito è in vacanza, il pipeline sta fallendo silenziosamente e nessuno riesce a capire perché i conteggi dei segmenti dei clienti non corrispondano al sistema sorgente. Il "semplice script Python" è cresciuto fino a 2.400 righe, tocca tre diversi database e non ha assolutamente alcuna documentazione su cosa dovrebbe effettivamente fare la logica aziendale.
La rivoluzione della programmazione AI ha reso la decisione di costruire quasi gratuita. Ciò che non ha cambiato è la decisione di possedere — ed è lì che risiede la maggior parte del costo.
La Contabilità Onesta
Quando i team stimano il costo di costruzione del proprio livello di data integration, di solito modellano qualcosa del genere:
| Voce di Costo | Stimato |
|---|---|
| Sviluppo iniziale | 2-3 settimane di tempo ingegnere |
| Infrastruttura | Cluster Kubernetes esistente |
| Manutenzione | "Basta tenerlo in funzione" |
| Costo totale del primo anno | ~$30K caricato |
Ecco come appare effettivamente il foglio di calcolo dopo dodici mesi:
| Voce di Costo | Reale |
|---|---|
| Sviluppo iniziale | 4 settimane (aumento del campo) |
| Infrastruttura | $8K/anno in calcolo, storage, rete |
| Onere di reperibilità | 15-20 ore/mese di paging, debugging, fix |
| Incidenti di deriva dello schema | 3 maggiori, 8 minori (fallimenti di qualità dei dati) |
| Gestione dei tentativi falliti | Costruito ad-hoc, mai del tutto corretto |
| Debito di documentazione | Ancora zero, ora critico |
| Rischio di silo di conoscenza | Un ingegnere lo comprende |
| Costo totale del primo anno | ~$85K caricato + costo opportunità |
Il divario non è dovuto al fatto che gli ingegneri siano pessimi nelle stime. È perché il foglio di calcolo cattura solo il lavoro che si può vedere in anticipo. I costi reali si accumulano invisibilmente: le chiamate alle 2 del mattino, le "correzioni rapide" che diventano permanenti, la sottile corruzione dei dati che richiede giorni per essere rilevata.
Il Problema dei Due Pipeline
Esiste una modalità di fallimento specifica che colpisce i team che costruiscono la propria infrastruttura batch-streaming: il problema della divergenza.
Si inizia con il batch. È semplice. Si scrive un job che viene eseguito ogni ora, estrae i dati, li trasforma, li carica da qualche parte. Funziona bene.
Poi l'azienda chiede il real-time. "Possiamo ottenere questi dati in secondi invece che in ore?"
Quindi si costruisce un Data Pipeline di streaming. Kafka, magari Flink o Spark Streaming. Consuma gli stessi dati di origine e li consegna alla stessa destinazione. Ma la logica di trasformazione è diversa — lo streaming ha vincoli diversi, diversa gestione dello stato, diverse modalità di fallimento. Non si può semplicemente trasferire il codice batch.
Ora si hanno due Data Pipeline che fanno più o meno la stessa cosa. Producono risultati leggermente diversi perché il join batch è esterno e il join streaming è interno, o perché il job batch gestisce i dati in ritardo in modo diverso rispetto alla finestra di streaming. Quando qualcuno chiede perché i numeri non corrispondono, bisogna fare il debug di entrambi i sistemi.
Dopo sei mesi, si ha:
- Due codebase da mantenere
- Due set di infrastrutture da monitorare
- Due modalità di fallimento da comprendere
- Due turni di reperibilità (o una persona molto infelice)
- E una domanda persistente: perché non possiamo avere solo un pipeline?
La risposta onesta: perché batch e streaming sono paradigmi genuinamente diversi, e la maggior parte degli stack fai-da-te non è costruita per unificarli.
I moltiplicatori nascosti della complessità
Oltre ai costi evidenti, ci sono tre moltiplicatori di complessità che non compaiono nelle stime iniziali:
Evoluzione dello schema
Il tuo sistema sorgente cambia. Una colonna viene rinominata. Un tipo viene ampliato. Appare un nuovo campo nullable. In una piattaforma gestita, questo viene gestito. Nel tuo pipeline personalizzato, è un cambiamento di codice, un deployment e una preghiera che non hai rotto i consumatori a valle.
Il vero costo non è il cambiamento in sé. È il coordinamento: notificare ogni team che consuma questi dati, aggiornare i loro schemi, testare l'integrazione, fare il rollback se qualcosa va storto. Un cambiamento di codice di due ore diventa un progetto di due settimane.
Gestione dei fallimenti su larga scala
Un semplice ciclo di retry è facile. Backoff esponenziale, una coda di messaggi morti, qualche avviso — puoi costruirlo in un pomeriggio.
Ma la gestione dei fallimenti in produzione è frattale. Cosa succede quando la destinazione è inattiva per un'ora? Cosa succede quando un messaggio è troppo grande? Cosa succede quando una discrepanza di schema causa un errore di parsing? Cosa succede quando lo stesso evento viene consegnato due volte? Cosa succede quando le partizioni di rete creano situazioni di split-brain?
Ogni caso limite necessita di gestione. Ogni gestore necessita di test. Ogni test necessita di manutenzione. La "semplice logica di retry" cresce in una preoccupazione di sistemi distribuiti in cui nessuno del team ha una profonda esperienza.
Lacune di osservabilità
Devi sapere: il pipeline è in esecuzione? Sta tenendo il passo con la sorgente? Gli eventi vengono elaborati o persi? Qual è la latenza? Qual è il tasso di errore? Qual è il costo per milione di eventi?
Costruire questa visibilità non è solo aggiungere un endpoint di metriche. È progettare le metriche giuste, costruire i dashboard, impostare gli avvisi giusti (non troppo rumorosi, non troppo silenziosi) e formare il team a interpretarli. È un altro sistema da costruire, mantenere e debug.
Quando Costruire Ha Davvero Senso
Voglio essere equo. Ci sono situazioni in cui costruire il proprio strato di integrazione è la scelta giusta:
Hai requisiti estremamente specifici che nessun fornitore gestisce bene — formati di dati insoliti, vincoli di sicurezza personalizzati, ambienti di distribuzione esotici.
Hai il team adatto — ingegneri di sistemi distribuiti che hanno operato Kafka su larga scala, che comprendono le semantiche exactly-once, che hanno risolto problemi di backpressure alle 3 del mattino.
È un vero differenziatore — il livello di elaborazione dei dati è fondamentale per il tuo prodotto, non solo infrastruttura. Non stai costruendo una pipeline; stai costruendo un vantaggio competitivo.
Sei a una scala in cui i costi dei fornitori superano i costi di costruzione — anche se sii onesto su cosa include il "costo di costruzione". La maggior parte dei team sottostima di 2-3 volte.
Per tutti gli altri, il calcolo di solito favorisce l'acquisto — se si tiene conto del costo totale di proprietà.
La Valutazione del Fornitore che Conta Davvero
Se stai confrontando i fornitori, la matrice delle funzionalità non è il punto di partenza giusto. La maggior parte delle piattaforme ha capacità simili sulla carta. Ciò che conta è il modello operativo:
Come gestiscono il problema delle 2 del mattino? Quando qualcosa si rompe in produzione, chi viene avvisato? È il tuo team a fare il debug della loro infrastruttura, o il loro team a fare il debug del tuo Data Pipeline?
Qual è il percorso di migrazione se decidi di cambiare? I Data Pipeline sono difficili da spostare. Comprendi quanto costa estrarre la tua logica e trasferirla altrove.
Unificano batch e streaming? O finirai comunque con due pipeline, solo nell'infrastruttura di qualcun altro?
Qual è il vero TCO? Includi formazione, tempo di integrazione, il costo di aspettare le funzionalità di cui hai bisogno e il costo opportunità del tempo di ingegneria speso per gestire la piattaforma.
Dove si Inserisce layline.io
Non pretenderò che questa sia una visione imparziale. In layline.io, abbiamo costruito una piattaforma specificamente per i team che hanno fatto un'analisi onesta e hanno deciso che costruire non è la scelta giusta.
La scommessa principale: batch e streaming non dovrebbero essere pipeline separate. Dovrebbero essere gli stessi Workflows, gli stessi strumenti, lo stesso team. Quando hai bisogno di real-time, non ricostruisci. Regoli una configurazione.
L'onere operativo è a carico nostro. Evoluzione dello schema, gestione dei fallimenti, osservabilità — questo è il compito della piattaforma, non il tuo. Il tuo team si concentra sulla logica aziendale, non sull'infrastruttura dei sistemi distribuiti.
È più economico che costruire da soli? Dipende da quanto onestamente consideri i costi di costruzione. Se stai contando due settimane di sviluppo e lo consideri finito, probabilmente no. Se includi la rotazione di reperibilità, il carico di manutenzione, gli incidenti di deriva dello schema e il costo opportunità degli ingegneri che non costruiscono funzionalità di prodotto — allora di solito, sì.
La Domanda da Porre
Prima che il tuo team si impegni a costruire, chiedi questo:
"Se lo costruiamo noi stessi, chi possiede la pagina delle 2 del mattino quando si rompe tra sei mesi? E sanno a cosa stanno andando incontro?"
Se la risposta è chiara e tutti comprendono l'impegno, procedete con la costruzione. Se c'è esitazione, o se la risposta è "lo capiremo più tardi", fate un onesto calcolo. I numeri potrebbero sorprendervi.
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.
