La multinube (del concepto de ejecutar la misma carga de trabajo en múltiples proveedores de nube de una manera completamente agnóstica) es absolutamente algo en lo que debes centrarte, al menos según dos grupos:
- Vendedores en declive que se dan cuenta de que si no te vuelves multinube, no tendrán nada más que venderte. AWS no va a construir un tablero multinube, así que algún proveedor de herramientas onPremise que no ha podido competir en la nube definitivamente construirá he intentará venderte uno.
- "Jugadores de nicho" que se dan cuenta de que si te comprometes solo con un proveedor de nube, definitivamente no serán ellos.
Como no pertenezco a ninguno de esos dos grupos, daré algunas recomendaciones sobre las mejores prácticas (según mi experiencia) y que deberían ser consideradas el lineamiento por defecto. Tal vez algunas recomendaciones no aplican a tu situación y seguro estarás en lo correcto, algunas razones como:
¡El cliente lo exige!
¡Personas morirán si este servicio se cae!
¡La empresa se irá a la quiebra si estamos 5 minutos fuera!
Son los motivos que por lo cual, multinube es la peor practica que debe evitarse por defecto.
¿Que NO es multinube?
Cada empresa es multinube si te esfuerzas lo suficiente, todos somos ornitorrincos, al utilizar diferentes proveedores para diferentes casos de uso
- Microsoft 365 para colaboración
- AWS para infraestructura
- GitHub para nuestros repositorios de código
- Azure Devops para pipelines
- Salesforce para CRM
Esto de ninguna manera es de lo que estoy hablando. Eso es simplemente buen sentido comercial. Si alguien sugiere que te comprometas totalmente con AWS e implica que esto significa usar Amazon Chime, WorkDocs, CodeCommit, CodePipeline, etc esa persona está intentando activamente de sabotear el crecimiento de tu empresa, debes despedirlo inmediatamente.
¿Qué es multinube?
Me refiero es a la idea de construir cargas de trabajo que puedan funcionar sin problemas en cualquier proveedor de nube o tu propio datacenter de igual manera. (ojo que también existen los datacenter on premise conectados con un proveedor de nube pública para equilibrar cargas y esto se llama híbridos"). La vision es bastante buena, convincente y algo que disfrutaría mucho de ver.
Sin embargo, es tan práctico como decir "simplemente escribe código libre de errores" a tus desarrolladores, o realmente intentar encontrar la vaca esférica que en las pruebas de física dicen que debería existir. Es mucho más difícil de lo que parece.
Sí, cada proveedor de nube puede ejecutar contenedores. Esta es la promesa que Kubernetes (un proyecto de código abierto de Google que lleva el nombre del dios griego de gastar dinero en servicios en la nube) ha traído a la vida.
El mínimo común denominador
El problema es que un proveedor de nube se simplifica en “un montón de discos, algunas redes y un montón de servidores para ejecutar contenedores”. Esas primitivas básicas existen en todas partes: AWS, Azure, GCP, Oracle Cloud, IBM "Cloud", y on premise.
Si tratas todos esos entornos como si fueran la misma cosa, eso significa que no puedes ni debes utilizar un servicio adicional que es de cualquier orden superior a estas primitivas.
Los balanceadores de carga funcionan de manera diferente en cada plataforma en la nube, por lo que ser multinube significa que estás debes de mantener el tuyo con nginx, HAProxy, Traefik, etc. La misma historia se aplica a las bases de datos, los sistemas de monitoreo, los modelos de permisos de seguridad, cualquier cosa que sea impulsada por eventos, service mesh, NoSQL, y ¿como haremos con cumplimiento normativo?
Sí, sé lo que estás a punto de decir: la industria en su conjunto ha estado haciendo esto durante mucho tiempo; no hemos olvidado mágicamente cómo ejecutar todas estas cosas nosotros mismos.
Mi punto es que mientras estás pasando tiempo configurando HAproxy para dirigir las solicitudes a los contenedores adecuados cuando se cumplen las condiciones correctas, uno de tus competidores ha configurado un Balanceador de Carga de Aplicaciones para hacer esto con tres líneas de YAML y ahora está avanzando en la construcción de la cosa que realmente importa para sus objetivos de negocio. Ignoraremos por completo el hecho de que la versión administrada del balanceador de carga tiene una disponibilidad, durabilidad, confiabilidad y resistencia mucho mejor que la cosa que harás con tus arquitectos y desarrolladores.
No estás "aprovechando lo mejor de ambos mundos". Estás mejorando tu datacenter a expensas de tu entorno en la nube.
¿Qué pasa con el vendor lock-in?
Otra justificación común para la multinube es evitar el lock-in a un solo proveedor.
Tengo malas noticias para ti: ya estás lock-in.
Tienes lock-in ya sea en las selecciones de tecnología (las bases de datos son un asesino aquí), tienes lock-in “suave” en cosas que no adaptan bien, como por ejemplo la gestion de acceso e identidad, que no es congruente de proveedor a proveedor.
Lock-in “suave”
De ellos, la lock-in “suave” es la única verdadera asesina y, por coincidencia, la que nadie fuera de Ingeniería piensa.
En otras palabras, ¿qué sucede cuando anuncias una migración global de AWS a Google Cloud? Bueno, para empezar, al menos un tercio de tu personal de ingeniería dejará de trabajar en su carrera profesional con sus habilidades existentes en una plataforma que otras empresas están utilizando más profundamente.
Es difícil aprender cómo fallará un nuevo proveedor. Es mucho más fácil profundizar en el ecosistema existente con el que ya estás familiarizado. También es mucho más valioso desde la perspectiva del empleado. Las empresas no quieren contratar generalistas que tengan poco conocimiento en múltiples proveedores; se inclinan por especialistas que son buenos en una plataforma en particular. Esto puede no ser intuitivamente cierto si miras las ofertas de trabajo; pero se vuelve mucho más comprensible si filtras los trabajos que pagan salarios altos.
Como resultado directo de esto, prácticamente todo el crecimiento que los proveedores de nube demuestran en sus ganancias trimestrales no proviene de convencer a los clientes de otros proveedores de nube para que cambien; es una combinación de personas que migran de data center, así como nuevas cargas de trabajo netas.
Es sumamente difícil migrar de un data center a un proveedor de nube cuando tú (al menos en teoría) ya conoces todos los botones y trucos de tu entorno. Ir de nube a nube es al menos diez veces más complicado, y ni las empresas ni los empleados están particularmente entusiasmados por querer hacerlo.
Poder de negociación
"¡Ah!" puedes interrumpir sabiamente. “¡Si tengo dos proveedores de nube, puedo usar a uno para golpear al otro para ofrecer mejores términos y descuento!”
Cada proveedor de nube negocia descuentos en porcentajes basados en el porcentaje de gasto. Reducir tu gasto a la mitad reduce tu base de negociación.
Pero supongamos por un segundo que eres una empresa con cargas de trabajo increíblemente portátiles (¡que existen!) Que de hecho pueden transferir cargas de trabajo a otros proveedores sin problemas.
Cada vez que he visto que esto sucede en mi experiencia, el descuento logrado con esa amenaza es menor que el descuento que el cliente obtendría simplemente al comprometerse con niveles de gasto más altos.
Para dar un ejemplo: $9 millones al año en un proveedor frente a $3 millones al año en tres proveedores da resultados notablemente diferentes incluso antes de que consideres los costosos gastos generales de administración y operación para hacer que esos sistemas funcionen bien juntos, y ahora estás negociando descuentos en base a $3 millones al año ... y lo haces tres veces.
Además, independientemente del proveedor que elijas, una vez que un proveedor de nube ejecuta tu infraestructura de producción, dejan de ser tu proveedor y se convierten en tu socio, quieras o no. Las relaciones adversariales no son tan productivas como las colaborativas.
La multinube no te protege de los cambios de precios
En la práctica, la regla no escrita de la nube es que las cosas se vuelven menos costosas con el tiempo. Hemos visto que cada cambio de precio de cada proveedor respalda esta regla, con la única excepción de Google Cloud, que engañó completamente a sus clientes, tres veces.
La primera vez fue en su aumento de 14 veces para el acceso a la API de Google Maps. La segunda fue cuando comenzaron a cobrar por la administración de clústeres GKE previamente gratuita. La tercera vez cuando decidió subir los precios de load balancer, storage, etc.
Por lo tanto, puedo declarar que GCP es un caso especial del cual realmente quieres tener un plan de salida en caso de que lo necesites.
La multinube no existe en la realidad
En la práctica, cada historia de "somos multinube" que he visto en realidad significa "somos más del 80% en nuestro proveedor principal, luego tenemos una serie de cargas de trabajo en otros".
Cualquier elección que hagas restringe tus opciones. La multinube es la encarnación del ideal "la indecisión es la clave de la flexibilidad". El problema es que vas a pasar tanto tiempo evitando comprometerte con un proveedor que pasarás una cantidad cada vez mayor de trabajo de operación manteniendo tu entorno funcional a un nivel relativamente básico que vas a luchar para innovar realmente como empresa.
Como Ben Kehoe lo expresa, la multinube es como volcar vacas: sabemos que no existe porque no hay videos de volcar vacas en YouTube. En este caso, no hay artículos ni charlas de conferencias de empresas hablando sobre cómo sus exitosas estrategias multinube están dando sus frutos.
Mi sugerencia
Si eres algo como yo, vas a leer esto, creerás que eres un caso especial al que no se aplican ninguna de las advertencias anteriores, e intentarás la multinube de todos modos.
Hazlo.
Solo tengo una sugerencia: antes de irte de lleno a un segundo proveedor de nube, primero inicia un entorno activo-activo en dos regiones de tu proveedor actual, donde tengas compatibilidad de todos los servicios y API entre esas regiones, debería, ser pan comido. ;)