Deje de adoptar multinube para lograr la resiliencia de las aplicaciones, dice Charity Majors de Honeycomb

Comentario: Multicloud puede ser una buena estrategia en algunos casos, pero no para brindar resiliencia a las aplicaciones. Este es el por qué.

Para las empresas que aún buscan el santo grial de la multinube, El cofundador de Honeycomb y CTO Charity Majors tiene una sugerencia: seguir mirando. O mejor dicho, no lo hagas.

Para ser justos, Majors no sugiere que la multinube no sea útil para la portabilidad de aplicaciones (aunque Gartner sí lo ha hecho), o que no puede ser una gran herramienta en las negociaciones de contratos (analista de Duckbill Corey Quinn te asegurará que no es). No, el punto de Majors es simplemente que la multinube no producirá un “polvo mágico de duendes” de resiliencia. Dicho de manera más directa, declara, “NO es la forma de solucionar sus problemas de confiabilidad”.

¿Por qué?

VER: Investigación: Gestión de multinube en la empresa; beneficios, barreras y plataformas en la nube más populares (TechRepublic Premium)

Cuando funciona la multicloud

Pero primero, vale la pena recordar que a pesar de todo el revuelo en torno a la multinube, es principalmente la forma en que la TI empresarial funciona y siempre lo ha hecho. Si una gran promesa de la computación en la nube era liberar a los desarrolladores de los engorrosos procesos de adquisición de hardware (“Sí, necesito un servidor para mi aplicación. ¿Puedo conseguirlo para el próximo año? ¿Por favor?”), Esa libertad ha llevado a los desarrolladores a comprar una gama de nubes para acceder a servicios específicos de la nube para crear sus aplicaciones.

Esto es lo que yo llamo “multicloud incidental”. Solo pasa.

También existe la “multinube intencional”, pero donde principalmente veo esto es en los proveedores (incluido el lugar donde trabajo ahora, MongoDB) que necesitan reunirse con sus clientes donde sea que se encuentren. Si un cliente llega a Confluent y quiere ejecutar Confluent Cloud en Microsoft Azure, es una mala estrategia de ventas decirle: “No, solo admitimos Alibaba” (o cualquier nube). Por lo tanto, los proveedores con servicios en la nube pueden admitir multinube para garantizar que los clientes puedan usar los datos almacenados en diferentes nubes para ejecutar una sola aplicación (tal vez almacenando datos en Cloud X por razones de costo u otras razones, pero analizando esos datos en Cloud Y debido a servicios de análisis superiores, sin presionar el cliente para mover manualmente los datos).

Pero ese es el proveedor que se ocupa de ese trabajo pesado para el cliente para garantizar una infraestructura / base de datos / aplicación / cualquier experiencia sin problemas para el cliente. Eso no es lo que Majors llama loco. Para los clientes que asumen la carga de la administración de múltiples nubes con la esperanza de una mayor capacidad de recuperación (“Encadenaré mi aplicación en varias nubes en caso de que una se caiga”), Majors quiere convencerlos de que no lo hagan.

Resulta que el camino hacia la seguridad no es una mayor complejidad.

Haciendo las cosas difíciles aún más difíciles

“Entiendo que no quiero un solo punto de falla. Pero cuando agrega una nube, no obtiene más confiabilidad; es casi seguro que obtiene menos”. Mayores notados. ¿Por qué? Porque agregar complejidad no simplifica las cosas. Majors agregó: “En lugar de preocuparse de que AWS caiga unos minutos al año, ahora debe preocuparse por AWS, GCP, y la impía fontanería entre ellos “.

Esto parece obvio, pero aparentemente no lo es. No para todos, de todos modos.

De hecho, prosiguió, es la plomería la que crea más problemas, “porque estás no mejor que AWS o GCP en sistemas operativos y de construcción. Promesa. “Como se mencionó anteriormente, hay empresas que tienen los recursos para garantizar el funcionamiento sin problemas de infraestructura / servicios particulares entre nubes (continuando con el ejemplo anterior, Confluent promete que puede” automatizar[] construyen y monitorean canalizaciones de datos y aplicaciones de transmisión, al tiempo que alivian la carga operativa de sus desarrolladores “), pero no pretenden ser generalistas que brindan resiliencia y otros beneficios sin importar la carga de trabajo. Están especializados, por lo que la TI no necesita ser .

Multicloud puede ayudar con los problemas de disponibilidad, pero en realidad no es una estrategia para mejorar la resiliencia, no sin ayuda de todos modos. Simplemente hay demasiadas cosas que no se pueden predecir fácilmente en las conexiones entre las nubes (Grandes Ligas: “[I]si estás tratando [multicloud] como una conmutación por error en caliente, no la probará con la frecuencia suficiente para evitar que los tornillos y tuercas salgan volando cada vez “). Nuevamente, si tiene un proveedor con la experiencia para manejar estas conexiones por usted, está bien. Pero tratar de ejecutar cargas de trabajo generalizadas en las nubes por sí solas no son una receta para la resiliencia, es una receta para mucha resiliencia whac-a-mole.

Divulgación: trabajo para MongoDB, pero las opiniones expresadas en este documento son solo mías.