Cloud agnóstico es mejor que Multi-Cloud
Multi-Cloud and cloud agnóstico no son la misma cosa, y uno es mejor que el otro.
En aquellos tiempos de mis años rebeldes (una fase que inició al bajarme FreeBSD en una conexión por model a 32K) Microsoft Word era lo que rulaba en el ámbito académico, ya nadie se acordaba de WordPerfect of Lotus 1-2-3, y el producto de Microsoft dominaba el mercado apabullantemente. En los círculos de la resistencia (del software libre), algunos de nosotros hacíamos guerrilla al instalar OpenOffice (el heredero de StarOffice) en cualquier máquina que se dejara. Muchas veces renombrabamos el acceso rápido a Microsoft Word y cambiabamos el ícono, como para que el usuario no se diera cuenta, una acción noble pero inutil cuando el usuario descubría que no podía abrir sus documentos en otra computadora que tenía el verdadero Microsoft Word. A veces, nuestros usuarios (la mayoría familiares o conocidos) aprendían como exportar e importar documentos de OpenOffice a Microsoft Word, pero cuando lo hacían los documentos simplemente no se veían bien, ya sea por formato, márgenes, tamaños o tipos de letra, tablas o impresión, rara vez había perfección, y con justa razón (por cierto mis maestros siempre me devolvían los documentos). El formato binario de Microsoft Word era un formato que requería un inmenso esfuerzo de ingeniería inversa y una vez que la comunidad estaba cerca de entenderlo, Microsoft simplemente lo actualizaba, con nuevas "caracteristicas" que echaban a la borda todo ese esfuerzo de meses en un chasquido de dedos.
Eventualmente, OpenOffice (ahora LibreOffice) fue capáz de entender mejor ese formato propietario, la comunidad creció, la interfaz gráfica mejoró sustancialmente y Linux fue más estable para computadoras de escritorio (este 2021 es finalmente el año de Linux para Escritorio, lo juro). OpenOffice fue entonces capáz de entender multiples formatos, y no puedo más que empatizar e imaginar el inmenso esfuerzo necesario para mantener esa base de código. En ese tiempo XML se usaba para todo, a veces sin justa razón (como ahora los blockchains), OpenOffice propuso un formato abierto ODF. Microsoft por su parte en un movimiento inesperado, decidió crear su propio "estandar" y empujó el OOXML, que eventualmente fue adoptado por ECMA y el ISO. Ahora teníamos dos "estandar" (entre comillas porque en su tiempo ninguno lo era) compitiendo, y mientras no fue lo mejor significativamente mejoró la interoperabilidad (eventualmente hasta el Word habría formatos abiertos).
Esta pequeña historia tal vez no sea la mejor analogía (pero como ya estoy viejo me encanta contarlas), pero intenta ilustrar algunas de las diferencias entre "multi" (que soporta diferentes formatos) contra "agnóstico" (que no es específico a un proveedor, un estandar interoperativo). Las nubes y las herramientas de DevOps no son la excepción, y muchas veces se enfocand en lo "multi" en lugar de lo "agnóstico". Digamos por ejemplo que quieres desplegar recursos en distintas nubes, pero no quieres aprender los formatos específicos de uno u otro provedor (como Azure ARM o AWS CloudFormation), así que decides usar Terraform. Estás muy feliz y todo, porque esta herramienta mágica te v a ayudar a declarar los recursos en un formato que soporta multiples nubes, así que no necesitas aprender un formato propietario. Me pasó, y la primera vez que intenté reusar el código que usaba para desplegar de una nube a otra me encontré que el "reuso" no era posible con 90% de los recursos (esto sin usar un sistema de plantillas excesivamente complejo) y que lo que realmente tenía que hacer era definir mis recursos otra vez para una nube distinta (muchas veces en otro folder). Esto podría tener sentido cuando las implementaciones de un recurso son parecidas pero no iguales (por ejemplo el MySQL de Amazon Aurora contra el MySQL de Azure SQL), pero no tiene ningún sentido cuando para desplegar un cluster K8s de la misma versión tengo que usar dos distintos módulos de terraform (se llaman providers), con dos distintas implementaciones (variables, elementos, etc.) para desplegar un cluster idéntico (en versión y caracteristicas) a Amazon y Azure al mismo tiempo. Esto es solo es esfuerzo excesivo para desarrollar y mantener, que se volverá trizas cuando alguno de los proveedores cambie la implementación de los recursos. (Dicho de otra manera Terraform nunca soporta 100% todas las opciones de despliegue de los recursos, y terminas teniendo que aprender ARM o CloudFormation para hacerlo de forma hacky de cualquier forma).
Otro ejemplo es la telemetría, si quieres implementar observabilidad en un ambiente multicloud en ambientes de producción, tienes que aprender Azure Monitor y AWS CloudWatch, o para el caso de aplicaciones, Azure AppInsights y AWS X-Ray. Lo que realmente necesitamos son implementaciones agnosticas, como OpenTelemetry donde no tengo que aprender o usar características fijas a un solo proveedor, y puedo estar seguro que el esfuerzo, implementación y conocimientos adquiridos pueden ser reusados en diferentes nubes.
Y ese es el punto de este berrinche, enfoquemos más esfuerzos en estándares, herramientas agnosticas, implementaciones agosticas y menos en ese paradigma multi-cloud que solo causa que invirtamos esfuerzos tratando de alcanzar inultimente la zanahoria que se moverá cada vez que salga una nueva versión.