Nota de transparencia: el caso de automoción está en curso — los resultados que cito son objetivos de diseño, no cifras cerradas todavía. El caso de la televisión pública está completado. Lo dejo así de claro porque mezclar ambos sin distinguirlos sería el mismo error que critico en otros artículos: presentar una proyección como si fuera un resultado.
Caso 1 — Visión artificial en la línea de producción (GCP)
Un fabricante global de componentes de interior de vehículo, presente en 25 países con plantas en Europa, Asia y América, genera volúmenes masivos de datos en sus líneas de producción —sensores de maquinaria, cámaras de inspección, sistemas MES— sin una plataforma que los analice de forma centralizada. El proyecto, en colaboración con Google como partner co-sell de GCP, busca resolver tres problemas a la vez: detectar defectos de calidad en tiempo real antes de que el componente avance en la línea, unificar los KPIs de producción de plantas que hoy usan sistemas MES heterogéneos sin integración entre sí, y predecir fallos de maquinaria crítica con suficiente antelación para planificar el mantenimiento.
La arquitectura combina BigQuery como almacén analítico central, Pub/Sub y Dataflow para la ingesta y procesamiento de eventos en tiempo real desde los sistemas MES, y Vertex AI para los modelos de computer vision entrenados con el histórico de imágenes de inspección de calidad del cliente. La pieza que decide si el caso de uso funciona en la práctica es el despliegue en el borde: los modelos de detección de defectos corren en Google Distributed Cloud Edge, directamente en las líneas de producción más críticas, porque ninguna latencia de red hacia la nube central es aceptable cuando la decisión es "¿avanza este componente o se retira?" en tiempo real.
Caso 2 — Emisión sin vendor lock-in (AWS + Red Hat OpenShift)
Una corporación pública de radiotelevisión de ámbito nacional —emisión en directo, plataforma VOD y décadas de archivo audiovisual— afrontaba la primera adopción de cloud público de su historia. El sistema legacy on-premise no escalaba ante los picos de audiencia de grandes eventos en directo, y el mantenimiento consumía recursos técnicos que el organismo necesitaba en otro sitio. La dirección técnica eligió AWS como plataforma, pero con una condición que cambia toda la arquitectura: Red Hat OpenShift (ROSA) como capa de ejecución, para que los microservicios no queden acoplados a servicios propietarios de un único hyperscaler. Un organismo público que gestiona contenido cultural de valor histórico no puede diseñar su plataforma asumiendo que jamás tendrá que migrar de proveedor.
La plataforma se organiza en cuatro dominios de microservicios —ingestión y transcodificación, metadatos, distribución y CDN, autenticación— comunicados vía Amazon API Gateway y Amazon EventBridge para el procesamiento asíncrono. Para la emisión en directo, AWS Elemental MediaLive en modo activo/pasivo entre dos zonas de disponibilidad garantiza que un fallo de infraestructura no se traduzca en un corte de señal — el escenario que ningún responsable de una televisión pública quiere explicar en rueda de prensa. El archivo histórico se migró en dos fases con AWS DataSync, con S3 Intelligent-Tiering para el ciclo de vida automático y S3 Glacier para el contenido inactivo, protegido con Object Lock y cifrado KMS con claves gestionadas por el cliente.
Lo que se repite, independientemente del proveedor
Poner ambas arquitecturas una al lado de la otra es más revelador que cualquiera de las dos por separado. Los nombres de los servicios cambian. La forma de resolver el problema, no:
| Patrón | GCP (automoción) | AWS (broadcast) |
|---|---|---|
| Ingesta en tiempo real | Pub/Sub + Dataflow | Amazon EventBridge + API Gateway |
| Inferencia / procesamiento crítico | Vertex AI en el borde (Distributed Cloud Edge) | MediaLive multi-AZ activo/pasivo |
| Almacenamiento analítico / archivo | BigQuery como data warehouse central | S3 Intelligent-Tiering + Glacier por ciclo de vida |
| Gobierno y control de acceso | VPC Service Controls + CMEK + IAM | KMS CMEK + Object Lock + IAM mínimo privilegio |
| Portabilidad / independencia de plataforma | No es el objetivo del proyecto (co-sell GCP) | Red Hat OpenShift como capa de abstracción explícita |
Por qué el proveedor es la decisión que menos debería definir la arquitectura
Es fácil caer en la simplificación de "elegimos Azure/AWS/GCP y luego diseñamos la arquitectura sobre lo que ese proveedor ofrece". Funciona al revés en los proyectos que salen bien: se define el patrón —ingesta en tiempo real, inferencia de baja latencia, control de acceso con mínimo privilegio, resiliencia ante fallo de zona— y luego se elige qué servicio de qué proveedor lo implementa mejor para ese contexto concreto. El fabricante de automoción necesitaba una relación estratégica con Google más que una funcionalidad específica de GCP. El organismo público necesitaba explícitamente no depender de AWS a largo plazo, y diseñó para ello desde el día uno con OpenShift.
Ninguna de las dos decisiones es genérica. Las dos son el resultado de entender primero el riesgo real del negocio —reputacional y de calidad de producto en un caso, de soberanía cultural y continuidad de servicio público en el otro— y después traducir ese riesgo a arquitectura. El proveedor es la penúltima decisión, no la primera.