Un único clúster de Kafka on-prem en us-east ingiere mensajes de dispositivos IoT a nivel global. La mala conectividad provoca la creación de lotes en el borde (edge batching) y picos de ingesta, lo que genera problemas de costos y gestión. ¿Qué arquitectura cloud-native recomendada por Google debería adoptar?

La opción correcta es un gateway de IoT conectado a Cloud Pub/Sub, con Cloud Dataflow para leer y procesar los mensajes de Cloud Pub/Sub. Esta arquitectura es la recomendada por Google para la ingesta de datos IoT a escala global. El gateway de IoT gestiona la conectividad y la seguridad de los dispositivos, mientras que Cloud Pub/Sub ofrece un servicio de mensajería global, escalable y duradero que desacopla los productores de los consumidores, manejando los picos de ingesta de manera eficiente. Cloud Dataflow, un servicio de procesamiento de datos sin servidor y escalable automáticamente, es ideal para procesar los mensajes de Pub/Sub. Las otras opciones son menos adecuadas: Edge TPUs son para inferencia de ML en el borde, no para almacenamiento y transmisión de mensajes. Cloud Dataflow conectado directamente a Kafka on-prem no resuelve los problemas de conectividad global ni la gestión de picos de ingesta en el origen. Un clúster de Kafka virtualizado en Compute Engine con Cloud Load Balancing no ofrece la misma escalabilidad global y gestión sin servidor que Pub/Sub para la ingesta de IoT, y sigue requiriendo una gestión considerable.