8 min de lectura<\/p>\n
Google ha anunciado en el Cloud Next 2026 componentes que convierten el multi-cloud de una teor\u00eda arquitect\u00f3nica en una decisi\u00f3n operativa. Los CIO de la regi\u00f3n DACH que a\u00fan crean que una estrategia cross-cloud fracasa por los costes de egreso y los silos de datos deber\u00edan prestar atenci\u00f3n: la palanca ya no es el c\u00f3mputo, sino d\u00f3nde residen los datos y cu\u00e1nto cuesta moverlos.<\/strong><\/p>\n Quienes en los \u00faltimos tres a\u00f1os han intentado distribuir cargas de trabajo entre dos hyperscalers conocen la reacci\u00f3n instintiva del \u00e1rea financiera: los costes de egreso. AWS, Azure y GCP cobran por gigabyte de tr\u00e1fico saliente cantidades que, en una tuber\u00eda de 80 terabytes al mes, suman r\u00e1pidamente cinco cifras. Estas tarifas no son un error, sino la materializaci\u00f3n del vendor lock-in en una partida contable. Los datos que una vez residen en un bucket salen caros.<\/p>\n La funci\u00f3n de cach\u00e9 cross-cloud presentada por Google en el Next 2026 ataca precisamente este punto. Almacena localmente en la cach\u00e9 del lakehouse los datos que ya han cruzado la frontera entre nubes, de modo que las consultas recurrentes no generan egreso cada vez. Para un sistema de reporting que consume diariamente el mismo conjunto de datos de un bucket S3, esto puede reducir en un orden de magnitud el tr\u00e1fico saliente. La verdad arquitect\u00f3nica detr\u00e1s: el cach\u00e9 no es nuevo, pero cuando un hyperscaler lo ofrece como servicio nativo m\u00e1s all\u00e1 de las fronteras de otras nubes, desplaza radicalmente el c\u00e1lculo de ROI para el multi-cloud.<\/p>\n Un grupo industrial de tama\u00f1o medio que recopila sus datos de m\u00e1quinas en AWS S3 y los analiza con GCP BigQuery registra, seg\u00fan sus propias cifras, unos 12 TB de egreso cross-cloud al mes. Con las tarifas actuales de AWS, esto supone cerca de 1.080 euros mensuales solo por movimiento de datos. Con una tasa de acierto en cach\u00e9 del 70 % para las consultas anal\u00edticas recurrentes, el tr\u00e1fico saliente se reduce a unos 3,6 TB, y la factura a unos 330 euros. A lo largo del a\u00f1o, la diferencia asciende a 9.000 euros para una \u00fanica ruta de datos. Quien gestione varias tuber\u00edas de este tipo habla r\u00e1pidamente de efectos de seis cifras.<\/p>\n El segundo cambio proviene del propio lakehouse. Google denomina \u00absin fronteras\u00bb a la nueva variante: la capa del lakehouse puede referenciar tablas que f\u00edsicamente se encuentran en S3 o Azure Data Lake, sin necesidad de replicar los datos en BigQuery. Para los equipos de ingenier\u00eda, esto significa: menos ETL, menos trabajos de sincronizaci\u00f3n y menos puntos en los que una deriva de esquema pueda romper un informe. Para los CIO, esto implica que la pregunta sobre \u00aba d\u00f3nde pertenecen\u00bb los datos puede responderse de nuevo desde un punto de vista pol\u00edtico y contractual, sin que cada respuesta desencadene inmediatamente un proyecto de migraci\u00f3n.<\/p>\n La otra cara de la moneda: quien controla la capa del lakehouse, controla la l\u00f3gica de consulta. Google se posiciona aqu\u00ed como un mediador neutral, lo que es estrat\u00e9gicamente inteligente, ya que su propio c\u00f3mputo se convierte en el motor de consulta est\u00e1ndar sobre buckets ajenos. AWS y Azure tienen iniciativas comparables, pero est\u00e1n m\u00e1s arraigadas en sus propios ecosistemas. La elecci\u00f3n de qu\u00e9 capa de lakehouse se convertir\u00e1 en el est\u00e1ndar de facto en una empresa DACH es, por tanto, una decisi\u00f3n estrat\u00e9gica con un vendor con una larga vida \u00fatil.<\/p>\n \u00abHasta ahora, la multicloud era una respuesta de cumplimiento. Con las nuevas capas de lakehouse y cach\u00e9, se convierte en una opci\u00f3n arquitect\u00f3nica, pero la elecci\u00f3n de qui\u00e9n lidera la capa de datos sigue siendo una decisi\u00f3n de bloqueo a largo plazo\u00bb.<\/p>\n<\/blockquote>\n La Gemini Enterprise Agent Platform y la Agentic Data Cloud son el anuncio m\u00e1s estrat\u00e9gico. Google agrupa el Agent-Registry, Skill-Registry, Tool-Registry y la gobernanza en una capa dise\u00f1ada expl\u00edcitamente para gestionar conjuntamente cargas de trabajo de AWS, Azure y GCP. Con esto, Google no apuesta por \u00abmigrad vuestras aplicaciones a nosotros\u00bb, sino por \u00abnosotros seremos el plano de control sobre vuestras aplicaciones existentes\u00bb. Desde la perspectiva de un CIO, esto resulta atractivo porque cambia la relaci\u00f3n de inversi\u00f3n: en lugar de financiar un proyecto de migraci\u00f3n de cargas de trabajo, se paga una suscripci\u00f3n abstracta de control.<\/p>\n Sin embargo, esto solo desplaza el riesgo una capa hacia arriba. Quien dentro de dos a\u00f1os descubra que el Agent-Registry y el inventario de herramientas est\u00e1n en Google, experimentar\u00e1 el mismo efecto de bloqueo con \u00abcambiamos el plano de control\u00bb que la multicloud pretend\u00eda evitar. La \u00fanica respuesta sostenible: imponer est\u00e1ndares abiertos para las definiciones de agentes, esquemas de habilidades y manifiestos de herramientas antes de que los formatos propietarios creen hechos consumados.<\/p>\n Lo que a menudo se pasa por alto en el debate arquitect\u00f3nico: el RGPD, la NIS2 y la Ley de IA de la UE no prescriben proveedores de cloud, pero s\u00ed establecen d\u00f3nde deben procesarse los datos y qui\u00e9n puede acceder a ellos. Una capa de cach\u00e9 multicloud que almacene datos personales en una cach\u00e9 de GCP, aunque la tabla maestra est\u00e9 en un centro de datos alem\u00e1n de AWS, no es trivial desde el punto de vista de la protecci\u00f3n de datos. La pregunta operativa es: \u00bfqu\u00e9 categor\u00eda de datos puede almacenarse en cach\u00e9 y d\u00f3nde? \u00bfY c\u00f3mo se documenta el ciclo de vida de la cach\u00e9 cuando la autoridad de supervisi\u00f3n lo solicite?<\/p>\n La respuesta de los proveedores ser\u00e1 el \u00abcach\u00e9 basado en pol\u00edticas\u00bb, es decir, reglas que determinen qu\u00e9 clases de datos pueden cruzar qu\u00e9 fronteras entre clouds. En la pr\u00e1ctica, esto significa que antes de construir la primera tuber\u00eda multicloud en producci\u00f3n, debe existir un esquema de clasificaci\u00f3n de datos. Quien lo posponga, se estar\u00e1 creando un generador de hallazgos en auditor\u00edas.<\/p>\n 1. \u00bfD\u00f3nde se encuentran los datos maestros y d\u00f3nde pueden estar sus copias?<\/strong> El almacenamiento en cach\u00e9 parece una cuesti\u00f3n de rendimiento, pero en realidad es una cuesti\u00f3n de cumplimiento. Sin clasificaci\u00f3n de datos, no hay cach\u00e9 multicloud.<\/p>\n 2. \u00bfQu\u00e9 motor de consulta se convertir\u00e1 en el est\u00e1ndar?<\/strong> Las capas de lakehouse tienen una vida \u00fatil de cinco a diez a\u00f1os. La elecci\u00f3n de si BigQuery, Athena, Synapse o Snowflake se convertir\u00e1n en la ruta de consulta dominante es una decisi\u00f3n estrat\u00e9gica con un vendor, no una decisi\u00f3n de herramientas.<\/p>\n 3. \u00bfQui\u00e9n controla el plano de control de los agentes?<\/strong> Si el Agent-Registry y el inventario de herramientas est\u00e1n en manos de un hiperescalador, la multicloud puede funcionar bien a nivel de c\u00f3mputo, pero a nivel de inteligencia vuelve a estar centralizada. Hay que abordar ahora las discusiones sobre est\u00e1ndares abiertos, no dentro de dos a\u00f1os.<\/p>\n Google no mencion\u00f3 precios de lista independientes durante su presentaci\u00f3n. La l\u00f3gica econ\u00f3mica reside en la reducci\u00f3n de las tarifas de salida existentes; la cach\u00e9 en s\u00ed se factura a trav\u00e9s de reservas de slots de BigQuery o mediante precios bajo demanda, es decir, a trav\u00e9s de la capa de computaci\u00f3n, no mediante una tarifa de cach\u00e9 independiente.<\/p>\n<\/details>\n Actualmente s\u00ed, la implementaci\u00f3n del lakehouse entre nubes requiere que BigQuery sea el motor de consultas. AWS y Azure tienen enfoques comparables (Athena Federated Queries, Synapse Link), que tambi\u00e9n sit\u00faan su motor principal en el centro. La verdadera neutralidad de proveedores solo se logra mediante est\u00e1ndares abiertos como Apache Iceberg, que los tres hyperscalers ya soportan.<\/p>\n<\/details>\n Se vuelve relevante a partir del momento en que una empresa gestiona dos cuentas en la nube de forma paralela, algo m\u00e1s frecuente de lo que se piensa en las pymes de la regi\u00f3n DACH, a menudo debido a adquisiciones o a proveedores de SaaS con backends en la nube predefinidos. Quien pague m\u00e1s de 500 euros al mes en tarifas de salida deber\u00eda calcular el retorno de la inversi\u00f3n.<\/p>\n<\/details>\n Tres aspectos: un esquema de clasificaci\u00f3n de datos con permisos de cach\u00e9 claros para cada categor\u00eda, una decisi\u00f3n sobre qu\u00e9 motor de consultas ser\u00e1 el lenguaje est\u00e1ndar, y un procedimiento de escalada documentado para hallazgos de auditor\u00eda relacionados con el contenido de la cach\u00e9. Sin estos tres puntos, la primera carta de una autoridad resultar\u00e1 dolorosa.<\/p>\n<\/details>\n Una CDN acelera la entrega de contenidos en el borde de la red. El almacenamiento en cach\u00e9 de salida act\u00faa antes: mantiene los conjuntos de datos consultados con frecuencia cerca de la regi\u00f3n de computaci\u00f3n, para que las consultas repetidas entre nubes no generen cada vez costosas tarifas de salida. La ventaja no est\u00e1 en la latencia, sino en la curva de costes.<\/p>\n Fuente de la imagen: generada por IA (junio de 2026), certificado C2PA incluido en la imagen<\/em><\/p>\nLo m\u00e1s importante en resumen<\/h2>\n
\n
El egreso como impuesto oculto de toda idea multi-cloud<\/h2>\n
Un ejemplo de la regi\u00f3n DACH ilustra la magnitud<\/h3>\n
Del silo de datos al Lakehouse sin fronteras<\/h2>\n
\n
Pila de agentes: quien controla los datos, controla las habilidades<\/h2>\n
El cumplimiento normativo llega a la capa multicloud<\/h2>\n
Tres preguntas clave antes del pr\u00f3ximo paso en multicloud<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfCu\u00e1nto cuesta exactamente el almacenamiento en cach\u00e9 entre nubes?<\/strong><\/summary>\n
\u00bfFunciona esto solo con Google como centro?<\/strong><\/summary>\n
\u00bfEs relevante para las pymes de la regi\u00f3n DACH o es un tema exclusivo de grandes empresas?<\/strong><\/summary>\n
\u00bfQu\u00e9 deber\u00eda aclararse antes del primer proyecto de canalizaci\u00f3n entre nubes?<\/strong><\/summary>\n
\u00bfEn qu\u00e9 se diferencia el almacenamiento en cach\u00e9 de salida de una CDN cl\u00e1sica?<\/strong><\/summary>\n
M\u00e1s del MBF Media Netzwerk<\/h3>\n
\n