Franco Geraci è Head of Engineering per Bitrock, dove, insieme al suo Team, mantiene ed evolve Waterstream – oltre ad aiutare le aziende a svincolarsi dal lock-in cloud. Quando non sta liberando i Clienti da architetture ostaggio, probabilmente sta spiegando perché no, la blockchain non risolverà neanche questo problema.
La realizzazione
Era una di quelle giornate che ogni architetto software conosce bene. Il cliente seduto di fronte a me aveva appena finito di descrivere la sua infrastruttura IoT: 50.000 sensori industriali, milioni di messaggi al secondo, requisiti di latenza sotto i 100ms. “Ovviamente useremo Kafka,” aveva concluso, come se fosse l’unica opzione possibile.
Ho annuito, ma dentro di me qualcosa non quadrava. Non per la prima volta, mi trovavo di fronte a quella che chiamo la “Kafka Default Syndrome” – l’assunzione automatica che Kafka sia la soluzione per qualsiasi problema di streaming.
Quella sera, tornando a casa, ho fatto i conti. Per gestire quei 50.000 dispositivi con Kafka avremmo avuto bisogno di:
- Un cluster Kafka con almeno 5 broker per garantire ridondanza
- Zookeeper o KRaft (che comunque aggiunge complessità)
- Un layer di traduzione MQTT-to-Kafka custom
- Un team dedicato solo per mantenere il tutto in piedi
- Un budget cloud che avrebbe fatto piangere il CFO
Ma il problema vero non erano i costi. Era la complessità inutile che stavamo per vendere al cliente.
Il Problema che tutti conoscono ma nessuno ammette
Lasciatemelo dire chiaramente: Kafka non è stato progettato per l’IoT. È stato progettato per data pipeline tra sistemi enterprise. È come usare una Formula 1 per fare la spesa – tecnicamente possibile, praticamente assurdo.
I dispositivi IoT parlano MQTT. È il loro linguaggio nativo. MQTT è leggero, efficiente, progettato per connessioni instabili e dispositivi con risorse limitate. Kafka parla… Kafka. È potente ma pesante, progettato per server con GB di RAM, non per sensori con KB di memoria.
In Bitrock abbiamo implementato decine di questi bridge negli anni. Sappiamo esattamente cosa significa:
- I dispositivi inviano messaggi MQTT a un broker MQTT
- Un componente custom legge da MQTT e scrive su Kafka
- Le applicazioni consumano da Kafka
- Un altro componente legge da Kafka e risponde via MQTT
Ogni passaggio aggiunge latenza. Ogni componente aggiunge un punto di failure. Ogni traduzione perde qualcosa nel processo. E noi continuavamo a vendere questa complessità come “best practice”.
La trappola del Lock-in Cloud (Agosto 2025 Edition)
Nel 2025, ogni cloud provider ha la sua “soluzione”:
AWS IoT Core + MSK: Ti promettono integrazione seamless. La realtà? Paghi per GB di dati in ingresso su IoT Core, poi – per lo streaming verso MSK, poi per il processamento. Un cliente è passato da $5K a $45K al mese solo aumentando i sensori del 3x. E provare a migrare? Buona fortuna con le API proprietarie.
Azure IoT Hub + Event Hubs: Microsoft ti vende la “sinergia” con il resto dello stack Azure. Ma i loro SDK proprietari, il formato dei messaggi custom, e l’impossibilità di fare un export pulito dei dati ti tengono in ostaggio. Un nostro cliente ha impiegato 8 mesi per migrare via. Otto. Mesi.
Google Cloud IoT Core + Pub/Sub: Oh wait, hanno dismesso IoT Core nel 2023. Se avevi costruito su quello, auguri. Ora ti dicono di usare Pub/Sub direttamente, ma indovina? Non parla MQTT nativamente. Serve un bridge. Siamo al punto di partenza.
Oracle Cloud IoT + Streaming: Nemmeno commento. Se sei finito lì, hai problemi più grandi di MQTT vs Kafka.
Il pattern è sempre lo stesso: ti attirano con prezzi entry-level, poi quando hai 100K dispositivi in produzione, i costi esplodono e la migrazione diventa impossibile. È lock-in by design.
La scoperta che ha cambiato tutto
Fu durante una due diligence per l’acquisizione di Waterstream da parte di Fortitude Group che ho veramente capito cosa avevano costruito. Non era solo “un altro broker MQTT”. Era la soluzione al problema che tutti fingevano di non vedere.
Waterstream è un broker che parla sia MQTT che Kafka nativamente. Non traduce. Non fa bridge. Parla entrambi i protocolli come lingua madre. I dispositivi si connettono in MQTT, le applicazioni consumano via Kafka API, e nel mezzo… niente. Letteralmente niente da gestire, debuggare, o che possa rompersi alle 3 di notte.
Da Utilizzatori a Maintainer: La Svolta
Quando Waterstream è entrata nel gruppo Fortitude, non abbiamo solo acquisito un prodotto. Il team originale ha passato completamente il testimone a noi di Bitrock. Oggi manteniamo, evolviamo e supportiamo Waterstream direttamente.
Questo significa che quando un cliente ha un problema alle 2 di notte, non deve aprire un ticket e pregare. Chiama noi. Quando serve una feature per un caso d’uso specifico, non deve convincere un product manager in Silicon Valley. Ne parliamo al caffè e la implementiamo.
In questi mesi abbiamo:
- Rilasciato il supporto per MQTT 5.0 completo
- Ottimizzato le performance per deployment edge (sub-millisecondo di latenza)
- Aggiunto integrazione nativa con OpenTelemetry
- Implementato multi-tenancy enterprise-grade
Ma soprattutto, abbiamo mantenuto la promessa originale: semplicità. Ogni feature aggiunta deve semplificare, non complicare.
I risultati concreti nel 2025
Cliente Logistics (migrato da AWS IoT Core):
- Prima: $38K/mese AWS, vendor lock-in totale
- Dopo: $8K/mese infrastruttura, Waterstream on-prem
- Migrazione: 2 settimane (di cui 10 giorni per convincere il management che era davvero così semplice)
Cliente Energy (migrato da Azure IoT Hub)
- Prima: 6 componenti Azure, SDK proprietari ovunque
- Dopo: Waterstream su Kubernetes, loro scelta di cloud
- Libertà di spostare workload: da zero a totale
Cliente Manufacturing (migrato da architettura custom)
- Prima: 12 microservizi per gestire MQTT-to-Kafka
- Dopo: 1 deployment Waterstream
- Team DevOps: da 4 persone a 0.5 FTE
Perché Non le Alternative (Versione Brutalmente Onesta)
- HiveMQ: Costa come un’auto di lusso tedesca. Enterprise license per 50K dispositivi? Preparati a piangere. E poi ti serve comunque Kafka a parte.
- EMQ X: La versione open source è ok. Poi vai in produzione, serve supporto, e scopri che costa quanto HiveMQ. Ah, e l’integrazione Kafka? Un plugin che nessuno vuole toccare.
- Confluent MQTT Proxy: È. Un. Proxy. Aggiunge latenza, è un altro componente da gestire, e costa come Confluent Platform. No grazie.
- Eclipse Mosquitto + Bridge Custom: L’abbiamo fatto tutti. Funziona per 1000 dispositivi. A 10K inizia a scricchiolare. A 50K è un incubo di maintenance.
- RabbitMQ con MQTT Plugin: Carino per progetti hobby. In produzione con milioni di messaggi? Buona fortuna.
Il Futuro che stiamo costruendo (letteralmente)
Ora che Waterstream è nelle nostre mani in Bitrock, la roadmap 2025-2026 è chiara:
- Q3 2025: WebAssembly plugins per trasformazioni custom senza fork
- Q4 2025: Edge computing mode per deployment su Raspberry Pi
- Q1 2026: AI-powered anomaly detection nativo
- Q2 2026: Federation multi-region con consensus automatico
Ma la filosofia resta: ogni feature deve eliminare complessità, non aggiungerla.
La lezione per l’Industry
Dopo anni di “best practice” che erano solo workaround accettati, ecco cosa ho imparato:
- Il lock-in non è inevitabile: Puoi avere cloud convenience senza vendor prison
- La complessità non è sophistication: È debito tecnico mascherato
- I bridge sono ammissioni di fallimento: Se serve un bridge, l’architettura è sbagliata
- Il TCO vero include la libertà: Quanto costa NON poter cambiare?
Oggi, quando un cliente mi dice “Useremo Kafka per l’IoT,” la mia risposta è semplice: “Perfetto. Le mostro come farlo senza impazzire.”
E poi deploy Waterstream. Un container. Dispositivi in MQTT. App in Kafka. Zero drama.
La rivoluzione non è sempre rumorosa. A volte è solo un sistema che funziona come dovrebbe.
Autore: Franco Geraci, Head of Engineering @ Bitrock
