Tener éxito en multicloud implica adaptar tu arquitectura a las necesidades específicas del portfolio de workloads de tus aplicaciones. Conoce los patrones de despliegue distribuido y redundante que pueden ayudarte.
Sienta las bases del éxito en multicloud con el patrón de despliegue adecuado
Una estrategia multicloud bien pensada ayuda a las empresas a avanzar hacia sus objetivos de negocio. Pero moverse en multicloud requiere un enfoque arquitectónico fino para garantizar la cohesión entre los distintos servicios de nube. Tienes que adaptar tu arquitectura a las necesidades del portfolio particular de workloads de tus aplicaciones, pero, por suerte, puedes apoyarte en algunos patrones comunes.
Estos patrones se basan en un despliegue distribuido o redundante:
- Los patrones de despliegue distribuido ejecutan las aplicaciones en el entorno de cómputo más adecuado, aprovechando las distintas propiedades y características de cada uno.
- Los patrones de despliegue redundante consisten en desplegar las mismas aplicaciones en varios entornos de cómputo para aumentar la capacidad o la resiliencia.
Patrones de despliegue distribuido
Los patrones distribuidos buscan un equilibrio entre lidiar con las restricciones que imponen las aplicaciones existentes y aprovechar el potencial único de cada entorno de cómputo. Al elegir el patrón adecuado, conviene considerar factores como la agilidad, el potencial de escalamiento, la seguridad y la confiabilidad.
Híbrido por capas
Con un patrón de despliegue híbrido por capas, primero llevas las aplicaciones de frontend existentes a la nube pública caso por caso y reutilizas las aplicaciones de backend, que permanecen en su entorno de cómputo privado. Sin embargo, con el tiempo podrías mover también los backend a la nube pública, ya que la proporción de aplicaciones desplegadas en la nube irá creciendo.
Priorizar el frontend tiene sentido porque, mientras que las aplicaciones de frontend dependen del backend, lo contrario no ocurre. Al tener pocas dependencias, el frontend suele ser más fácil de aislar y migrar que el backend. Llevarlo a la nube pública es lógico porque cambia con más frecuencia que el backend y se beneficia de la flexibilidad que ofrece la nube. La nube simplifica la configuración de un proceso de integración continua/despliegue continuo (CI/CD) para actualizaciones eficientes y automatizadas, y funciones como el balanceo de carga, los despliegues multirregionales y el autoescalado mejoran el rendimiento.
Para los backend que manejan datos con requisitos rigurosos de cumplimiento, mantenerlos en un entorno de cómputo privado puede ser una decisión prudente. Muchos países exigen la localización de datos, lo que significa que las empresas deben almacenar y procesar la información de forma local. Por ejemplo, el Reglamento General de Protección de Datos (GDPR) de la UE establece reglas estrictas sobre el almacenamiento de datos personales que pueden cumplirse mejor con una solución on-premises.
Multicloud particionada
El patrón de multicloud particionada te permite mover workloads entre los entornos de nube pública de distintos proveedores. La portabilidad de los workloads es clave para aprovechar la flexibilidad de desplegar cada aplicación en el entorno de cómputo más adecuado. Tendrás que abstraer las diferencias entre entornos para poder mover los workloads entre varios entornos de cómputo.
Los patrones de multicloud particionada te ayudan a evitar el vendor lock-in, ya que no quedas atado a un único proveedor de servicios en la nube. Poder mover los workloads a entornos alternativos cuando lo necesites te protege frente al riesgo de downtime por interrupciones y te permite elegir las funcionalidades más relevantes de cada proveedor.
Mantener la portabilidad de workloads necesaria para aprovechar este patrón también te permite optimizar las operaciones a medida que los mueves de un entorno a otro. Sin embargo, esa portabilidad tiene sus desventajas: exige trabajo adicional de desarrollo, pruebas y operaciones. Diseñar pensando en la portabilidad también puede reducir la utilidad de la plataforma de nube elegida al mínimo común denominador, e impedir que los workloads aprovechen los servicios totalmente gestionados del proveedor. Los costos de egress también pueden dispararse rápido.
La contenedorización facilita la portabilidad de workloads, y Kubernetes se apoya en ella para ayudar a las empresas a evitar el vendor lock-in.
Híbrido y multicloud para analítica y ML
Con este patrón, los sistemas transaccionales permanecen on-premises, mientras que los workloads analíticos se despliegan en la nube y devuelven datos cuando se requiere. Los sistemas transaccionales realizan las operaciones del día a día en áreas como finanzas, comunicación y ventas. Los workloads analíticos abarcan aplicaciones que procesan o visualizan datos para generar insights que respaldan la toma de decisiones. Este patrón aprovecha la separación entre ambos sistemas para ejecutar cada tipo de workload en un entorno de cómputo distinto.
Al ejecutar workloads analíticos en la nube, puedes escalar de forma dinámica los recursos de cómputo y procesar grandes volúmenes de datos rápido, sin el riesgo de sobreaprovisionar recursos. Los principales proveedores de nube también ofrecen servicios integrales para gestionar los datos desde su captura y a lo largo de todo el ciclo de vida.
Híbrido en el edge
La conectividad continua es un requisito para ejecutar workloads en la nube, pero no siempre es posible. Lugares como embarcaciones marítimas, supermercados y ciertas plantas manufactureras pueden no tener acceso confiable a internet, pero también son escenarios clave para el Internet de las Cosas (IoT), donde los sensores y chips integrados necesitan conectividad para transmitir y recibir datos valiosos. Aquí entra el patrón híbrido en el edge: ejecuta de forma local los workloads críticos en tiempo y para el negocio, en el borde de la red, y deja todos los demás en la nube.
Ejecutar localmente los workloads críticos en tiempo y para el negocio favorece la baja latencia y la autosuficiencia. Las transacciones importantes pueden seguir ocurriendo aunque la conexión a internet no sea confiable. Con este patrón sigues aprovechando la nube para una parte importante de tus workloads. Para que funcione bien, conviene minimizar las dependencias entre los sistemas que corren en el edge y los que corren en el entorno de nube.
Patrones de despliegue redundante
Los patrones de despliegue redundante consisten en desplegar las mismas aplicaciones en varios entornos de cómputo para aumentar la capacidad o la resiliencia.
Entorno híbrido
Un patrón de entorno híbrido puede ser redundante o distribuido. Usa entornos de nube pública para desarrollo, pruebas y UAT, y ejecuta los workloads de producción en data centers privados. Las restricciones de regulación y cumplimiento pueden complicar la migración a la nube de los entornos de producción y sus datos, pero no la del resto de los entornos.
Usar la nube pública para desarrollo y pruebas funcionales significa que puedes aprovisionar y desmontar entornos según se necesite. También te permite controlar los costos deteniendo las instancias de máquinas virtuales cuando no se usan o aprovisionando entornos solo bajo demanda.
Híbrido y multicloud para continuidad del negocio
La planificación de la Recuperación ante Desastres (DR) es clave para restaurar los sistemas afectados por desastres naturales o provocados por el ser humano. Un elemento fundamental son los respaldos de datos frecuentes en distintas ubicaciones geográficas para minimizar el objetivo de punto de recuperación (RPO). Mantener sistemas en standby (fríos, tibios o calientes, según su latencia) en una segunda ubicación también ayuda a reducir el objetivo de tiempo de recuperación (RTO).
Sin embargo, un enfoque más rentable es usar la nube pública para el entorno de DR: de ahí el patrón híbrido de continuidad del negocio. Este patrón puede incluso reducir el Tiempo Real de Recuperación si se activa la DR, porque el entorno se puede levantar más rápido con infraestructura como código.
Cloud bursting
El costo de gestionar workloads con picos en entornos on-premises puede dispararse rápidamente, porque tienes que sobreaprovisionar recursos para cubrir los momentos de mayor intensidad. El patrón de despliegue por bursting se apoya en un entorno de cómputo privado para la carga base y solo recurre a la nube cuando necesitas escalar. Por eso se adapta mejor a workloads por lotes que a workloads interactivos. La portabilidad de workloads es clave.
Uno de los principales beneficios de este patrón es que te permite reutilizar las inversiones actuales en entornos on-premises. Incluso puedes hacer un uso más eficiente de tus entornos de cómputo privados, ya que no necesitas sobreaprovisionar recursos para cubrir los picos de demanda.
¿Hacia dónde seguir?
Construir una solución híbrida o multicloud implica decisiones complejas, entre ellas el diseño de la arquitectura adecuada. Antes de tomar cualquier decisión, conviene evaluar la cultura de tu empresa, las prácticas de DevOps y el stack tecnológico. Ninguna solución única cubrirá tus necesidades específicas, pero la respuesta puede estar en alguna variante de los patrones de despliegue distribuido y redundante que vimos. Un partner experto en nube puede orientarte sobre el mejor enfoque para aprovechar multicloud según tus objetivos de negocio.