Líderes de opinión

Por qué su sitio de comercio electrónico necesita un enfoque multi-nube activo-activo esta temporada de vacaciones

mm
Añade Unite.AI a tus fuentes preferidas en Google

Para los líderes de comercio electrónico, las vacaciones traen dos certezas: un gran aflujo de compradores y un mayor riesgo de interrupciones de los proveedores de nube. Las interrupciones importantes de la nube parecen estar volviéndose más comunes y más devastadoras. La región AWS US-East-1, por ejemplo, tiene un historial de interrupciones significativas durante la temporada de vacaciones. De manera similar, cada año alrededor de enero, Microsoft Azure tiende a tener problemas de latencia de red o interrupciones de red debido a su plan de lanzamiento o pruebas en ciertas regiones. Y solo necesitamos mirar hacia atrás a este pasado junio, cuando una interrupción importante de Google Cloud impactó una amplia variedad de aplicaciones, para recordar que ningún proveedor individual es inmune.

Si usted es responsable de una operación de comercio electrónico, no quiere descubrir que aunque tiene todo configurado correctamente, algo ha dejado de funcionar durante el momento más crítico del año. Estas tendencias de interrupciones y problemas de los proveedores de nube pueden no estar en su radar, y francamente, no deberían estar. Si usted es un ingeniero de confiabilidad del sitio, no debería preocuparse por si una interrupción de la nube impactará su aplicación, ni debería intentar ajustar su infraestructura sobre la marcha durante un problema. En su lugar, debería reexaminar lo que sabe sobre la nube multi-nube.

Aplicaciones multi-nube

Si su organización paga las tarifas de AWS, Azure y GCP, de hecho tiene las tres nubes a su disposición. Dicho esto, aunque puede estar utilizando las tres, es importante examinar qué sucede cuando se va un nivel más profundo. ¿Algunas de sus aplicaciones son específicas de AWS, Azure o GCP? ¿Seguirán funcionando si un proveedor de nube está caído y necesita cambiar rápidamente a otro?

Su aplicación debe funcionar perfectamente en cualquiera de las nubes. Eso es lo que es una configuración multi-nube real. Si desea ser agnóstico de la nube, no puede simplemente pagar por multi-nube; debe asegurarse de que sus aplicaciones también sean multi-nube.

Además, depender de un solo proveedor introduce restricciones inherentes en la capacidad de cómputo, la limitación de la tasa de API y la disponibilidad regional. Una arquitectura multi-nube real aumenta su poder de cómputo agregado y proporciona resistencia contra estas restricciones. Desbloquea su capacidad para escalar a pedido más allá de los límites de un solo proveedor, expandir rápidamente la capacidad en diferentes geografías y garantizar un rendimiento consistente durante los días pico de compras. Pero tener una aplicación portable y agnóstica de la nube es solo el primer paso; el siguiente es implementarla en una arquitectura verdaderamente resistente.

Escalando a un enfoque activo-activo

Esto requiere una preparación seria por parte de DevOps. Es increíblemente difícil tener una estrategia de recuperación de desastres de continuidad de negocios (BCDR) al 100% precisa, ya que cuando se trata de ejecutar sus operaciones en vivo, hay múltiples puntos de falla. No quiere probar su estrategia de BCDR en una interrupción, así que puede sentir que todo lo que realmente puede hacer es predecir posibles escenarios y luego prepararse en consecuencia.

Mi consejo a los ingenieros de confiabilidad del sitio es arquitectar para el fallo por defecto. Esto significa tener una nube secundaria o incluso terciaria que se ejecuta en un estado activo. Una estrategia de BCDR confinada a un solo proveedor es un punto de falla único; si el proveedor falla en su plano de control o red de respaldo, todo su plan de recuperación se vuelve inútil.

Durante la temporada de vacaciones, es común que el número de visitantes aumente repentinamente, lo que fuerza a su plataforma o aplicación a comenzar a funcionar con una capacidad reducida. Si ya ha creado una copia de su aplicación en funcionamiento, una secundaria, puede cambiar a realizar equilibrio de carga para que pueda desviar algunas solicitudes a la otra instancia de su aplicación.

Este enfoque activo-activo significa que tiene su producto completo duplicado, ejecutándose en otro lugar. Si su proveedor de nube principal experimenta una degradación o interrupción severa, puede cambiar sin problemas el 100% de su tráfico al proveedor secundario a través de DNS o un equilibrador de carga global, convirtiéndolo en el punto de entrada principal sin interrupción para sus clientes.

El costo real de no ir a la nube multi-nube

Si bien el costo de ejecutar una nube secundaria no es trivial, es insignificante en comparación con el impacto comercial de una interrupción importante: disculparse con los clientes después de un fallo de confiabilidad, tratar de asegurarles que no volverá a suceder y convencerlos de que no los abandonen por uno de sus competidores. También no olvidemos todos los ingresos perdidos por las ventas que no se pueden recuperar. En FluidCloud, he visto que esta situación se reproduce una y otra vez: las empresas invierten mucho en un solo proveedor, solo para encontrarse en el lado equivocado de una interrupción sin recurso inmediato.

Dicho esto, es difícil controlar sus costos incluso si solo está utilizando un proveedor de nube; sus costos de nube probablemente parezcan un gráfico exponencial. Si adopta múltiples nubes, ese gráfico exponencial solo se verá aún más empinado.

Cuando duplica su infraestructura desde su nube principal, naturalmente no quiere que sus costos se dupliquen. Por lo tanto, recomiendo centrarse en nubes más baratas que ofrezcan un rendimiento competitivo a un precio más bajo. Si tiene una nube secundaria que se ejecuta en una nube más barata, aún tendrá redundancia activa-activa completa, pero a un costo más bajo. Es una situación en la que todos ganan.

Pensamientos finales

Ejecutar sus aplicaciones en un enfoque activo-activo en múltiples proveedores de nube no significa simplemente crear una copia de seguridad. Significa construir para la resiliencia en tiempo real, garantizar que su negocio no tenga un punto de falla único y poder ofrecer velocidad consistente incluso durante los picos de tráfico.

Esta temporada de vacaciones, no solo espere la confiabilidad. Constrúyala. Ingenieere sus sistemas para que funcionen consistentemente, sin importar qué proveedor de nube o región falle. Ofrezca una experiencia del cliente impecable adoptando una arquitectura multi-nube activa-activa real.

Harshit Omar es el Co-Fundador y CTO de FluidCloud, donde está construyendo el futuro de la infraestructura en la nube, permitiendo a las empresas migrar, replicar y optimizar las cargas de trabajo de manera fluida en entornos de nube múltiple. Anteriormente, fue el primer ingeniero en Accurics, donde lideró los esfuerzos de desarrollo principal en su motor de políticas y plataforma de seguridad en la nube.

Con una profunda experiencia en Go, Kubernetes, Terraform y cumplimiento en la nube, Harshit ha pasado más de una década diseñando sistemas resilientes en AWS, Azure y GCP.

Su misión ahora es eliminar el bloqueo en la nube y hacer que la infraestructura sea tan portable y resiliente como el código.