Di Andrew Tan
Le spese che nessuno include nel budget di migrazione — e perché il vero costo del passaggio al real-time non ha nulla a che fare con le licenze software
Il budget che non ha superato il primo contatto
Un VP di Ingegneria che conosco aveva previsto un budget di 180.000 dollari per la migrazione del suo team da batch a streaming. Era dodici mesi fa. L'ultima volta che abbiamo parlato, il progetto aveva consumato 640.000 dollari e mancavano ancora sei settimane alla produzione.
Cosa è successo? Non frode. Non un aumento del campo d'applicazione nel senso tradizionale. Semplicemente non hanno considerato i costi che non compaiono nei preventivi dei fornitori: il ritardo di sei settimane mentre assumevano un ingegnere Kafka che comprendesse la semantica exactly-once. I tre mesi trascorsi a eseguire batch e streaming in parallelo perché nessuno si fidava ancora del nuovo pipeline. L'intervento di consulenza d'emergenza quando la loro aggregazione in streaming ha prodotto numeri diversi rispetto al report batch e il CFO se ne è accorto.
Il software stesso era economico. I costi nascosti li hanno divorati vivi.
Ho visto questo schema ripetersi in aziende di ogni dimensione. I team prevedono un budget per l'infrastruttura e le licenze. Non prevedono un budget per l'incertezza, il rifacimento e la tassa operativa di mantenere due sistemi mentre uno sostituisce l'altro. Quando si rendono conto di cosa sta succedendo, il progetto è già fuori budget o sotto-deliverato — a volte entrambi.
Ecco cosa costa realmente quando si passa da batch a streaming.
Costo #1: Il talento che non hai ancora
L'ingegneria batch e l'ingegneria stream sono correlate come la falegnameria e la produzione di mobili. Stesso materiale grezzo, mestiere completamente diverso.
Il tuo team esistente conosce i cron schedules, le scansioni delle tabelle e la confortante finalità di un lavoro che inizia, si esegue e finisce. Lo streaming chiede loro di pensare in tempo di evento, gestire lo stato illimitato e fare il debug di sistemi che non smettono mai di funzionare. Alcuni dei tuoi ingegneri si adatteranno rapidamente. Altri no — non perché siano cattivi ingegneri, ma perché l'elaborazione distribuita dei flussi è veramente difficile e non tutti vogliono specializzarsi in essa.
Questo crea un costo nascosto in tre forme:
Assunzione: Un ingegnere senior di elaborazione dei flussi a Londra o New York costa tra i 160.000 e i 220.000 dollari di stipendio base in questo momento, più i quattro mesi di tempo medio per l'assunzione per quella specialità. Se ne hai bisogno di due, sono quasi mezzo milione in stipendi prima che abbiano scritto una riga di codice di produzione.
Formazione: I tuoi ingegneri esistenti devono apprendere nuovi concetti: watermarking, consumer lag, partition skew, operatori stateful, at-least-once versus exactly-once. Non sono argomenti da workshop pomeridiano. Sono mesi di apprendimento pratico in cui la produttività è inferiore al normale e gli errori sono più costosi del solito.
Turnover: Alcuni dei tuoi migliori ingegneri batch se ne andranno durante la migrazione — non perché non possano imparare lo streaming, ma perché non si sono iscritti per diventare specialisti di sistemi distribuiti. A loro piaceva il lavoro sui dati. Andranno da qualche parte che lo fa ancora nel modo che apprezzano.
La voce di budget per il "talento" nella maggior parte dei piani di migrazione copre la formazione. Raramente copre i ritardi nelle assunzioni, la perdita di produttività o il turnover imprevisto.
Costo #2: Il periodo di operazione parallela
Nessuno ne parla abbastanza. Non puoi semplicemente spegnere il batch e accendere lo streaming. Non se tieni al tuo lavoro.
Per un certo periodo — tipicamente da tre a sei mesi, occasionalmente di più — gestirai entrambi i sistemi. Il pipeline batch continua a produrre i report di cui tutti si fidano. Il pipeline streaming funziona accanto a esso, producendo risultati che teoricamente dovrebbero corrispondere ma spesso non lo fanno, almeno non all'inizio.
Questo significa il doppio dell'infrastruttura. Il doppio del monitoraggio. Il doppio degli avvisi. E un team di ingegneri che passa le giornate a riconciliare due set di numeri invece di costruire nuove funzionalità.
Una società di e-commerce con cui ho lavorato ha gestito sistemi paralleli per otto mesi. Il loro stack batch costava circa 4.200 dollari al mese in cloud computing. Il loro stack streaming costava 7.800 dollari al mese. Per otto mesi, hanno pagato entrambi. Sono 96.000 dollari solo di infrastruttura — senza contare il tempo ingegneristico speso a indagare perché il conteggio in streaming degli ordini di martedì era 347 in meno rispetto al conteggio batch.
Il periodo parallelo non è opzionale. È un'assicurazione. Ma come tutte le assicurazioni, è costosa, e la maggior parte dei team sottovaluta il premio.
Costo #3: L'archeologia dei dati
I tuoi pipeline batch contengono anni di logica aziendale accumulata. Da qualche parte in uno script Python di 400 righe che gira alle 2 del mattino c'è una condizione di join che esiste a causa di un'eccezione di prezzo del 2019. Nessuno ha documentato perché è lì. La persona che l'ha scritto se n'è andata nel 2021. Ma se lo rimuovi, i numeri di ricavo cambiano dello 0,3% e la finanza invia email arrabbiate.
Migrare a streaming significa comprendere ognuno di questi artefatti. Non puoi semplicemente portare il codice. La logica deve essere reimplementata per l'elaborazione continua degli eventi, il che significa che prima devi capire cosa fa e perché. Questa è archeologia dei dati — tediosa, lenta e impossibile da stimare accuratamente perché non sai cosa troverai finché non inizi a scavare.
Un'azienda di servizi finanziari che ho consigliato ha trascorso cinque settimane su un singolo pipeline. L'implementazione in streaming ha richiesto tre giorni. Capire perché la versione batch produceva un output specifico in un caso limite ha richiesto gli altri trentadue giorni. La logica aziendale era codificata in una procedura memorizzata scritta da tre persone diverse in quattro anni, con commenti come "correzione per bug Q2" e nessuna ulteriore spiegazione.
Costo #4: La tassa di complessità operativa
I pipeline batch falliscono in modo visibile. Un lavoro si blocca. Ricevi un avviso. Lo ripari. Lo esegui di nuovo. Tutti capiscono cosa è successo.
I pipeline streaming falliscono in modo sottile. Il consumer lag si accumula nel corso delle ore. Gli state store crescono finché non raggiungono i limiti di memoria. I watermark si spostano e improvvisamente le tue aggregazioni in finestra stanno perdendo eventi in ritardo. Quando te ne accorgi, hai prodotto risultati leggermente errati per mezza giornata.
Anche gli strumenti operativi sono diversi. Non stai solo monitorando se un lavoro è finito. Stai monitorando le distribuzioni di latenza, le pendenze di throughput, i segnali di backpressure e le dimensioni degli state store. I tuoi runbook esistenti non si applicano. I tuoi avvisi esistenti non catturano le nuove modalità di errore.
Costruire questa maturità operativa richiede tempo ed errori. La prima volta che il tuo pipeline streaming lascia cadere silenziosamente il 2% degli eventi per sei ore, investirai pesantemente in una migliore osservabilità. È un costo necessario. Ma quasi mai è nel budget iniziale.
Costo #5: Il costo opportunità che nessuno misura
Mentre i tuoi migliori ingegneri stanno facendo il debug del ribilanciamento delle partizioni e riconciliando gli output batch versus streaming, non stanno facendo altro lavoro. Le richieste di funzionalità si accumulano. Il debito tecnico si accumula. I concorrenti rilasciano cose che il tuo team avrebbe costruito se non fossero stati immersi fino al collo nella migrazione.
Questo è il costo più difficile da quantificare e il più facile da ignorare. Non c'è una fattura per esso. Ma è reale.
Una società SaaS ha sospeso tutto lo sviluppo di nuovi prodotti di dati per nove mesi durante la loro migrazione streaming. Quando hanno finito, avevano costruito un pipeline real-time tecnicamente impressionante — ma il loro principale concorrente aveva rilasciato tre funzionalità di analisi nello stesso periodo e guadagnato quote di mercato. La migrazione è stata un successo tecnico e un ritardo strategico.
Perché continuiamo a sottovalutare
Parte del problema è il messaggio dei fornitori. Le piattaforme di streaming vendono la destinazione: intuizioni in tempo reale, reazioni istantanee, vantaggio competitivo. Non pubblicizzano il viaggio: l'assunzione, i sistemi paralleli, l'archeologia, la curva di apprendimento operativa.
Un'altra parte è il bias dell'ottimismo. Ogni team di ingegneri crede che sarà l'eccezione. Il loro codice è più pulito. Il loro team è più intelligente. I loro requisiti sono più semplici. A volte è vero. Di solito non lo è.
Il risultato è un divario persistente tra il costo preventivato e il costo effettivo. Ho visto rapporti di 2:1, 3:1, persino 5:1. Non perché qualcuno fosse disonesto — perché i costi reali sono invisibili finché non ti sei già impegnato.
Come fare un budget onesto
Non puoi eliminare questi costi, ma puoi tenerne conto. Ecco come consiglio ai team di pensarci:
Aggiungi un buffer del 40% alle stime dell'infrastruttura. Il periodo parallelo, gli ambienti di test, i deployment ombra — aggiungono tutti calcolo e storage che non prevederai con precisione.
Prevedi un budget per almeno sei mesi di operazione duale. Se finisci prima, festeggia. Se non lo fai, non dovrai spiegare sforamenti al tuo CFO.
Assumi o contratta uno specialista di streaming prima di iniziare, non dopo che ti sei bloccato. Il costo di portarli in anticipo è alto. Il costo di portarli dopo tre mesi di falsi inizi è più alto.
Accetta che alcuni pipeline dovrebbero rimanere batch. Non tutto beneficia del real-time. Report giornalieri, analisi storiche, pipeline di addestramento ML — questi sono spesso carichi di lavoro appropriati per batch che non giustificano il costo della migrazione. Sii esplicito su cosa non stai migrando.
Un modo diverso di pensare alla transizione
I team che gestiscono bene questo condividono un tratto: non lo vedono come una migrazione. Lo vedono come l'aggiunta di una capacità.
Invece di "stiamo passando da batch a streaming," dicono "stiamo aggiungendo streaming dove crea valore, e mantenendo batch dove funziona ancora." Questo sembra semantica, ma cambia completamente l'economia. Non sei più impegnato a spostare tutto. Puoi valutare ogni pipeline per i suoi meriti: requisiti di latenza, complessità, valore aziendale, costo della migrazione.
Alcuni pipeline si spostano. Altri no. Quelli che si spostano giustificano il loro investimento. Quelli che rimangono non generano costi inutili.
Questo è il motivo per cui una piattaforma unificata è importante. Se stai eseguendo strumenti separati per batch e streaming, ogni pipeline affronta la pressione di migrare perché mantenere due piattaforme è costoso. Se puoi eseguire entrambi i modelli sulla stessa piattaforma — stessi workflow, stesso team, stesso approccio operativo — la pressione scompare. Aggiungi real-time streaming dove si guadagna il suo mantenimento e lasci batch da solo dove sta già funzionando.
Questo è l'approccio che abbiamo integrato in layline.io. Non perché batch sia cattivo — è spesso esattamente giusto — ma perché costringere i team a scegliere un approccio e abbandonare l'altro crea costi e rischi artificiali. I team che dormono bene la notte sono quelli che non hanno cercato di bollire l'oceano.
La conclusione
Il costo nascosto del passaggio da batch a streaming non è il software. È tutto il resto: le persone che devi assumere, i sistemi che devi gestire in parallelo, la logica legacy che devi scavare, la maturità operativa che devi costruire e l'opportunità che perdi mentre ti concentri sull'infrastruttura invece che sul prodotto.
Prevedi un budget per questo. Tienine conto. Sii onesto su quali pipeline devono effettivamente essere spostate e quali no.
L'obiettivo non è essere real-time ovunque. L'obiettivo è essere real-time dove conta, senza andare in bancarotta per arrivarci.
Cosa fare dopo
Se stai pianificando una migrazione da batch a streaming, inizia con un audit onesto. Elenca i tuoi primi dieci pipeline. Per ciascuno, chiediti: qual è il costo effettivo della latenza? Qual è lo sforzo stimato per la migrazione? Qual è l'aggiunta di complessità operativa?
Se i numeri non giustificano il trasferimento per un determinato pipeline, lascialo stare. Concentrati sulla tua energia sui due o tre dove il real-time crea un valore aziendale misurabile.
Per i team che valutano le piattaforme, la Community Edition di layline.io è gratuita da esplorare. Puoi prototipare un pipeline streaming accanto al tuo workflow batch esistente e vedere quale sia la realtà operativa prima di impegnare il budget.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che real-time su larga scala.
