¿Racionalismo? La realidadde la multi-cloud

¿Puede René Descartes ayudarte con tu estrategia multi-cloud?

El filósofo francés René Descartes (1596–1650),se propuso determinar cómo se podía establecer la certeza. Él pensó que deberíamos:

Dudar sistemáticamente de todo aquello de lo que se pueda dudar, incluidas las creencias más habituales.

Para ilustrar su enfoque,Descartes utilizó la analogía de una cesta llena de manzanas, algunas de las cuales podrían estar podridas. Al haber una manzana podrida, esto se puede propagar fácilmente al resto de manzanas y, por lo tanto, es importante deshacerse de las malas para preservar la salud del resto. La forma de hacerlo no es mirar cada manzana una a una, sino vaciar la cesta y llenarla de nuevo solo con aquellas que estén en buen estado.

‍

Hay un gran revuelo en torno a las nubes múltiples(multi-cloud). Se escriben artículos, se graban podcasts y los proveedores están exagerando mientras intentan vendernos herramientas sofisticadas para construir, implementar y administrar nuestras aplicaciones en entornos multi-cloud.

Su mensaje es: La nube múltiple es la nueva normalidad. Todo el mundo va a utilizar varias nubes. No quieras quedarte atrás, atascado con un único proveedor de nube.

¿Tienen razón o no? En este artículo, intentaré aplicar el método de Descartes al debate sobre la multi-cloud. Vamos a vaciar la cesta que contiene las razones comunes para usar múltiples nubes y verificar cuáles están “sanas” y cuáles “podridas”.

Tipos de implementaciones Multi-Cloud

Multi-Cloud significa diferentes cosas para diferentes personas. Para mí, como jefe de ingeniería en una empresa SaaS de rápido crecimiento (WalkMe), la multi-cloud se trata de:

utilizar los servicios ofrecidos por los diferentes proveedores de nube pública para construir y operar nuestro producto de la manera más fiable, eficiente y rentable.

Cuando se trata de estrategia en la nube, encuentro que hay 4 estrategias que se pueden aplicar a un producto como el nuestro:

Estrategia 1: Nube única para todos los trabajos

El producto entero (todos los servicios) se crea e implementa en una sola nube (AWS).

Estrategia 2: la nube adecuada para cada trabajo

Algunos servicios de productos se implementan en AWS, otros en GCP, otros en Azure, etc. La idea clave aquí es que mientras estamos ejecutando en múltiples nubes, todos los servicios que tenemos siempre están asignados al mismo proveedor de nube.

Estrategia 3: realizaralgunos trabajos en multi-cloud

Todo el producto (todos los servicios) se implementa en AWS, pero algunos servicios también se ejecutan en GCP y/o Azure.Para los servicios que se ejecutan en múltiples nubes, existe un mecanismo de distribución de carga de trabajo que determina qué tráfico entrante y qué cargade trabajo maneja qué nube.

Estrategia  4: realizartodos los trabajos en multi-cloud

Todo el producto (todos los servicios) se implementa en AWS, así como en GCP y/o Azure. En este escenario, tenemos implementaciones completamente separadas de todo el producto en múltiples nubes y, en teoría, cada cliente puede elegir si quiere ser atendido por AWS / GCP / Azure.

Racional vs Realidad

Ahora que hemos establecido el contexto, estamos preparados para examinar “las manzanas”. Analicemos las 6 razones más comunes para optar por una nube múltiple. Las compararemos y calificaremos lo “racional” vs. la realidad, dudando de todo lo que se pueda dudar.

1. Riesgo de interrupción de la nube

·        Racional: las nubes públicas tienen interrupciones. No tenemos control sobre la frecuencia con la que estas interrupciones van a tener lugar o sobre cuánto tiempo le tomará al proveedor de la nube restablecer el servicio. Si queremos garantizar la continuidad de nuestro negocio, no podemos confiar en un solo proveedor de nube.

·        Realidad: Los proveedores de nube pública tienen un concepto de regionesy zonas de disponibilidad. Dentro de una región, cada AZ está aislada en el sentido de que tiene conexiones de red dedicadas y fuentes de energía de reserva. Al implementar clústeres cross-AZ de zonas de disponibilidad de nuestros microservicios estamos reduciendo significativamente la probabilidad de que puedan verse afectados por una interrupción de la nube. No estoy afirmando que nunca se produzcan interrupciones cross-AZ e incluso entre regiones. Aunque son poco frecuentes, estas interrupciones siguen ocurriendo. Teóricamente, querríamos que nuestro sistema funcionara incluso en la ocurrencia de estos eventos raros. La razón por la que digo"teóricamente" es que para lograr este tipo de continuidad, nuestro sistema debe estar diseñado para ello. De hecho, necesitaríamos crear lo que antes llamamos " realizar todos los trabajos en multi-cloud". Además, necesitaríamos diseñar el sistema para soportar la portabilidad total de la carga de trabajo, de modo que una vez que AWS esté inactivo (por ejemplo), podamos enrutar inmediatamente todo el tráfico y las cargas de trabajo a Azure. El problema es que la creación de productos reales que admitan la portabilidad de cargas de trabajo entre nubes es prácticamente irreal.

·        Calificación “fresco vs. podrido”: 🍎 🍎 💩 💩 💩

2. Presencia Global

·        Racional: Nuestros servidores y nuestros datos deben estar lo más cerca posible de nuestros usuarios finales. Esto es necesario tanto por motivos de rendimiento, ya que la latencia de la red afecta la experiencia del usuario final, como por motivos de cumplimiento, ya que algunos clientes no pueden almacenar sus datos confidenciales fuera de su país. Tenemos clientes en todo el mundo, por lo que un solo proveedor de nube no podrá proporcionarnos todas las ubicaciones físicas que necesitamos.

·        Realidad: Actualmente los principales proveedores de la nube tienen prácticamente la misma presencia global. AWS tiene 24 regiones con 77 AZs, GCP tiene 24 regiones con 73AZs y Azure tiene 54 regiones(aunque muchas tienen una sola AZ). Eso no tiene en cuenta la red de distribución de contenido (CDN, content delivery network), que ayuda a abordar posibles problemas de latencia para los usuarios finales en países que se encuentran alejados de las regiones principales. Los proveedores de nube conocen el tamaño potencial del mercado, así como las regulaciones de cumplimiento en diferentes países (específicamente las regulaciones de residencia de datos).Esto significa que, en la mayoría de los casos, los 3 proveedores principales tienen una región en países con un tamaño de mercado significativo y con regulaciones específicas. La única situación en la que recuerdo que estaba considerando usar un proveedor de nube diferente debido a la presencia global fue a principios de 2015 cuando tuve un gran cliente canadiense que no estaba dispuesto a que sus datos se almacenaran en EEUU. (Después del caso de Edward Snowden). Estábamos usando AWS y no tenían una región en Canadá. Microsoft tampoco tenía una región "oficial", pero tenía algún tipo de centro de datos de Azure operado por socios. Comenzamos aplanificar cómo implementar y operar nuestro servicio, solo para descubrir que algunos de los principales servicios de Azure no eran compatibles en esa región. Seis meses después, AWS inició su región "Canadá central". Hoy en día los 3 principales proveedores tienen una región oficial en Canadá.

·        Calificación “fresco vs. podrido”: 🍎 💩 💩 💩 💩

3. Dependencia de un proveedor (Vendor Lock-In)

·        Rational: ¡No podemos poner todos nuestros huevos en una sola cesta! Ser completamente dependiente de un solo proveedor que brinda un servicio que es fundamental para nuestro negocio es peligroso o incluso irresponsable. ¿Qué sucede si el proveedor con el que estamos limitados deja defuncionar? o peor aún, ¿qué sucede si el proveedor al que estamos atados adquiere nuestro principal competidor?

·        Realidad: AWS, Azure y GCP son muy buenos negocios. Es muy poco probable que Amazon, Microsoft o Google los cierren. También es muy poco probable que un proveedor de servicios en la nube te cause problemas, incluso en el caso de que se convierta en su competidor. El mejor ejemplo en el que puedo pensar es Netflix que usa AWS aun que Amazon Prime Video es un competidor directo. En resumen: evitar la dependencia de un proveedor es una buena intención, pero viene con importantes restricciones técnicas. Básicamente significa que tu producto no puede depender de un determinado servicio en la nube a menos que lo ofrezcan todos los proveedores de la nube. Simplemente estád cambiando estar atado a un proveedor por estar atado al mínimo común denominador de múltiples proveedores. No es una buena idea en términos de su capacidad para innovar y actuar con rápidez.

·        Calificación “fresco vs. podrido”: 🍎 💩 💩 💩 💩

4. Optimización decostes

·        Racional: Si solo podemos ejecutar nuestro servicio en una única nube, no hay razón para que el proveedor de la nube nos dé ningún descuento. La nube múltiple nos permitirá trasladar continuamente nuestras cargas de trabajo al proveedor de la nube que nos ofrezca el mejor precio. Esto se convertirá en una palanca para negociar mejores precios con todos los proveedores.

·        Realidad: No funciona así. La idea del arbitraje de precios en la nube solo funciona en teoría. En realidad, las acciones de optimización de costes más importantes dependen de tu capacidad para predecir tu uso futuro en una determinada nube y reservar esa capacidad. Desde la perspectiva de la negociación de descuentos, el nivel de descuento que puedes obtener de un proveedor depende principalmente de tu volumen (gasto total) y de tu capacidad de compromiso previo (gasto mínimo) durante al menos 1año. Al dividir tu consumo general entre varios proveedores de nube, estás reduciendoel volumen por proveedor, así como tu capacidad para predecir tu uso futuro y el poder comprometerte con un gasto mínimo con cada proveedor. Por tanto, no solo no podrás reducir los costes totales de alojamiento en la nube, sino que pagarás más. Mucho más. Como castigo adicional, también recibirás varias facturas cada mes.

·        Calificación “fresco vs. podrido”: 💩 💩 💩 💩 💩

5. Usar lo mejor de cada casa

·        Racional: Algunos proveedores de nube ofrecen servicios únicos. Creemos firmemente en "utilizar la mejor herramientapara el trabajo" y, al utilizar estos servicios, podríamos mejorar la fiabilidad y el rendimiento de áreas específicas de nuestro producto.

·        Realidad: Es completamente cierto, pero hay que tener en cuenta si nos compensa la complejidad de ir por esta vía. De hecho, hay servicios específicos que solo están disponibles en una nube. Para algunos casos de uso, poder aprovechar estos servicios puede cambiar las reglas del juego. Un ejemplo que me viene a la mente es BigQuery deGoogle, que se encuentra en otra liga en cuanto a las soluciones de almacenamiento de datosque ofrecen. Pero como siempre, hay sacrificar algo a cambio. La ejecución de diferentes microservicios en diferentes nubes introduce dos tiposde gastos generales: gastos generales de red y gastos generales de flujo de trabajo. Comencemos con las redes: la comunicación entre servicios que se ejecutan en diferentes nubes es más lenta y más costosa que la comunicación entre servicios que se ejecutan en la misma nube. Los costos de latencia de lared y salida de datos son tan altos que podrían ser un obstáculo para algunos casos de uso. En cuanto a la sobrecarga del flujo de trabajo: ejecutar diferentes partes de tu producto en diferentes nubes significa que necesitas crear y mantener diferentes flujos de trabajo. Hay muchos vendedores (Red Had, VMware, Hashicorp, etc.) y tecnologías (containers, Kubernetes, Anthos, Terraform, etc.) que te pueden ayudar, pero al final deldía, no hay forma de ocultar completamente las diferencias entre las nubes en áreas como IAM, redes, seguridad, implementación, monitoreo, elasticidad, cumplimiento y muchas otras. Tu personal de DevOps y SRE tendrá que adquirir experiencia enmúltiples nubes y puede que algunos no quieran.

·        Calificación “fresco vs. podrido”: 🍎 🍎 🍎 🍎 💩

6. Incentivos comerciales

·        Racional: Los principales proveedores de la nube se encuentran entre las empresas más grandes y de más rápido crecimientodel mundo. Queremos que sean nuestros clientes o, mejor aún, nuestros socios. Son reacios a asociarse con nosotros siempre que nuestro producto esté alojado enla nube de la competencia. La misma lógica se aplica a otros grandes clientes que no son proveedores de la nube, pero consideren el proveedor de la nube en el que estamos alojados como su competidor directo (por ejemplo, grandes empresas minoristas que no están dispuestas a utilizar productos alojados en AWS). Para que podamos ganar estos acuerdos masivos y crear asociaciones estratégicas, no podemos limitarnos a ejecutar en una sola nube.

·        Realidad: Esto es real. Admito que la primera vez que me sucedió me sorprendió un poco o incluso me sentí escéptico ("si realmente necesitan nuestro producto, no debería importarles si se ejecuta en AWS"), pero después de ver que ocurrió en dos empresas distintas de diferentes clientes potenciales, me di cuenta de que es una realidad. Ahora estoyconsiderando esta presión como una señal positiva: si una empresa como Microsoft / Google / Amazon / IBM / Oracle insiste en que ejecutemos nuestros servicios en su nube, debe significar que creen que tenemos la posibilidad de hacer crecer nuestro negocio y convertirnos en un gran cliente.  De lo contrario, ¿Para qué iban a molestarse? En cualquier caso, la mejor manera de manejar esto es tratar de enfocarlo hacia la estrategia #2 (la mejor nube para este trabajo). De esta manera, ambos aprovechamos las fortalezas de cada proveedor, y gastamos lo suficiente con cada proveedor para mantener a todos satisfechos. Otro pequeño consejo que tengo es pedir créditos. Los proveedores de nube tienen presupuestos de crédito dedicados para alentar a las empresas de SaaS de gran crecimiento a migrar a su plataforma.

·        Calificación “fresco vs. podrido”: 🍎 🍎 🍎 🍎 🍎 

‍

Conclusión

Descartes pensó que dudábamos de todo lo que se puede dudar. Cuando se trata de exageraciones tecnológicas como la multi-cloud, debemos tener mucho cuidado. Mi consejo es:

desglosa la información en puntos de valor discretos y examina cada uno en términos de su ROI y riesgo en el contexto de tu producto y tu equipo.

Creo que para la mayoría de los productos y equipos, el resultado de dicho análisis sería optar por la estrategia #1 (nube única para todos los trabajos) o la estrategia #2 (nube adecuada para el trabajo). Si eres uno de los casos especiales en los cuales el análisis te ha llevado a decantarte por la estrategia #3 (usar la multi-cloud para algunos trabajos) o Dios no lo quiera que te hayas decidido por la estrategia #4 (usar la multi-cloud para todos los trabajos), te deseo la mejor suerte y me gustaría mucho saber cómo te ha ido en el mundo real.

‍

traducido por Mireia Alba kesti Izquierdo

‍