Di Andrew Tan
Due fatti che continuano a essere mescolati
Apache Kafka rimane un protocollo aperto. Puoi eseguirlo su MSK, su un cluster che gestisci tu, su Redpanda, su Confluent Platform. Il formato wire non è stato acquisito.
Confluent, l’azienda che ha trasformato quel protocollo nello stack commerciale Kafka di default, è un’azienda IBM dal 17 marzo 2026. IBM ha pagato circa 11 miliardi di dollari, 31 dollari per azione. Dal primo giorno, il messaggio non è stato “restiamo l’azienda Kafka indipendente”. Dal primo giorno si è parlato di watsonx.data, IBM MQ, webMethods e IBM Z. Lo Streaming come carburante per una piattaforma dati AI e per l’automazione ibrida.
Trattare questi due aspetti come un unico evento ti farà dormire durante i prossimi 18 mesi di decisioni di prodotto. Separarli rende la prossima conversazione con il tuo vendor molto più utile.
Cosa è stato realmente acquisito
Ho già scritto il confronto tecnico su Kafka. Questo è l’articolo sulla concentrazione.
Il giorno della chiusura, IBM ha sintetizzato la tesi nel titolo del comunicato stampa: i dati in tempo reale come motore dell’AI enterprise e degli agenti. Rob Thomas ha parlato di modelli e agenti che agiscono su ciò che sta accadendo ora. Jay Kreps, ancora citato come CEO, ha parlato di mettere in movimento i dati del mondo alla scala di IBM.
Questa è una scommessa di prodotto diversa da “il miglior Kafka”.
Il miglior Kafka significa ribilanciamento delle partizioni, qualità dei connettori, packaging di Flink, SKU cloud e se la pagina di consumer lag funziona ancora di martedì. La scommessa di IBM significa che Confluent Cloud e Platform vengono attratte verso watsonx, MQ e il mainframe. Il log di Kafka è la rampa di accesso. La destinazione è la suite di AI e integrazione di IBM.
Puoi apprezzare questa scommessa. Molte imprese vivono già in quella suite. Non dovresti fingere che sia la stessa roadmap che Confluent vendeva come società quotata.
Il fondatore se n’è andato. Il protocollo è rimasto.
Il 13 agosto Jay Kreps si è fatto da parte dopo quasi dodici anni. Le transizioni dei fondatori dopo una chiusura da 11 miliardi di dollari sono normali. Ti dicono anche dove viene scritta la storia.
Le roadmap venivano discusse una volta a Mountain View, con i tempi di un’azienda Kafka. Ora vengono discusse all’interno di IBM Software, con i tempi di watsonx e del mainframe. La cadenza dei connettori, il packaging cloud e il significato di “supportato” seguiranno quell’orologio.
Un segnale concreto è arrivato alla fine di ottobre. IBM ha annunciato l’integrazione di watsonx.data per Apache Flink, con una canvas visuale e un SDK Python che invia job su Confluent Platform for Apache Flink. Non è un killer di Kafka. È IBM che avvolge lo stream processing nella linea di prodotto watsonx.data. Se hai acquistato Confluent perché volevi un’azienda di streaming indipendente, rileggi questa frase.
Non sto sostenendo che il prodotto sia peggiorato. Non ho un feed di telemetria su Confluent Cloud. Sto sostenendo che il centro di gravità si è spostato, e lo si può vedere pubblicamente.
Kafka come linguaggio, IBM come editore
Pensa a Kafka come a un linguaggio. Molte persone lo parlano. La grammatica è aperta. IBM ha acquistato la scuola più grande che insegnava il dialetto commerciale, stampava i libri di testo e gestiva lo stand delle certificazioni alla conferenza.
Puoi ancora parlare il linguaggio. Puoi assumere persone che lo parlano. Puoi gestire un cluster che non manda mai un dollaro a IBM.
Ciò che non puoi dare per scontato è che il percorso commerciale di default (Confluent Cloud, Confluent Platform, il catalogo di connettori su cui ti sei già standardizzato) combatterà per l’indipendenza di Kafka. Seguirà la piattaforma dati e AI di IBM. Eseguire in dual-run un topic verso watsonx.data riceverà più attenzione che rendere banale la possibilità di andarsene.
I vendor seguono la loro tesi. Il tuo compito è accorgerti che la tesi è cambiata.
Tre domande che il tuo prossimo QBR dovrebbe contenere
Salta la slide “siete ancora impegnati su Kafka?”. Ovviamente lo sono. Kafka è l’asset.
Fai le domande operative che il comunicato stampa non copre.
Dual-run per i prossimi due anni
Se IBM raggruppa gli SKU, cambia nome alle console o ti sposta su un control plane watsonx, hai bisogno di un periodo in cui il percorso vecchio e quello nuovo producano gli stessi output. Il dual-run è noioso. Il dual-run è il modo in cui sopravvivi a una fusione di vendor senza un cutover di fine settimana.
Replay quando MQ, Z e un data warehouse sono nello stesso incidente
La maggior parte dei team Kafka sa già come riavvolgere un consumer group. Il caso difficile è misto: uno stream, una transazione mainframe, un file ERP notturno e una tabella Iceberg che qualcuno ha già interrogato. Il diagramma di IBM del primo giorno mette tutto questo in un’unica famiglia. Il tuo incidente di martedì sera ha comunque bisogno di una persona in grado di riavvolgere uno senza corrompere gli altri.
Se il batch ha ancora bisogno di un secondo orchestrator
Se la risposta è “usa Airflow per i file e Confluent per i topic”, non hai comprato una piattaforma. Hai comprato una suite di streaming e hai mantenuto la separazione che già avevi. Chiedi loro di mostrarti un workflow che riproduce un file in ritardo e un topic guasto con la stessa ownership.
Se il tuo AE non riesce a rispondere a queste domande senza un solution architect e una settimana di ritardo, hai il tuo segnale.
Il problema che non è stato acquisito
IBM ha acquistato un’azienda di streaming. Non ha acquistato il tuo problema di coordinamento.
Devi ancora recuperare un job batch che ha saltato la finestra mentre lo stream continuava. Devi ancora riprodurre tre ore di messaggi velenosi senza scrivere due volte nel data warehouse. Devi ancora unire una slowly changing dimension a un topic live. Devi ancora dire a un nuovo assunto quale sistema è la fonte di verità venerdì pomeriggio.
Niente di tutto questo vive nel protocollo Kafka. Il logo IBM sulla console di Confluent non lo rende più semplice. Alcune cose diventano più difficili se lo stack commerciale viene riorientato verso agenti e watsonx mentre il tuo workload reale è ancora “fai concordare il file dei pagamenti con il topic delle frodi”.
I team con cui parlo che sono tranquilli su questo non hanno scritto “Kafka è open source, stiamo bene” su Slack. Trattano già il broker come un trasporto e mantengono il runtime (retry, dipendenze, replay, approvazioni) in un luogo che controllano loro.
Dove ci inseriamo noi
In layline.io lavoriamo con team che parlano Kafka e devono comunque consegnare file alle 18:00. Non siamo un sostituto di Kafka e non siamo un’alternativa a IBM. Siamo il runtime che si posiziona tra batch e streaming in modo che il lavoro di coordinamento non viva all’interno della suite del vendor di streaming.
Se la piattaforma di IBM è la casa giusta per te, usala. Solo non confondere “produciamo ancora record Kafka” con “il nostro modello operativo è invariato”. I record possono sembrare gli stessi. La gravità attorno a essi non può.
Se sei su Confluent Cloud o Platform e stai cercando di separare la comodità del protocollo dalla gravità del vendor, contattaci. Abbiamo aiutato team a mappare dual-run e replay tra batch e stream senza aspettare il prossimo rebranding.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, che costruisce infrastrutture di elaborazione dati enterprise in grado di gestire workload sia batch che real-time a scala.
