El multicloud es ya una tendencia clara en los procesos de migración hacia la nube, pero la teoría no siempre se corresponde con la realidad de los casos prácticos que nos encontramos en el día a día. Definir una adecuada estrategia multicloud requiere madurez en áreas como el gobierno, la arquitectura, el desarrollo o las operaciones, funciones que debe asumir el Centro de Excelencia Cloud.
Un modelo multicloud es aquel que combina más de un proveedor de nube pública con el fin de optimizar costes, reducir el vendor locking y aprovechar los valores diferenciales de cada plataforma. De hecho, hay servicios que son únicos de un proveedor, como por ejemplo los de BigQuery y BigTable en GCP, que no tienen una correspondencia directa en su competencia.
Por su parte, hybrid cloud define la combinación de cloud pública y privada, incluyendo datacenters en modelo on-premise. Este suele ser el formato escogido por dos tipos de empresas: las que abordan la adopción del cloud como una extensión de sus capacidades, combinando servicios locales con el uso de la nube, y aquellas que quieren mantener ciertos procesos on-premise por cuestiones legales, de seguridad o como soporte para sistemas legacy imprescindibles para el negocio.
Además, los grandes proveedores cloud permiten establecer conexiones dedicadas y redundantes entre el datacenter del cliente y la red del proveedor, con capacidades mejoradas en cuanto al tiempo de latencia y la tolerancia a fallos con respecto a una conexión estándar. Esto hace que sean entornos estables y confiables.
Proveedor en función del uso
Uno de los retos en este contexto es el de seleccionar los proveedores cloud que más se adaptan a las necesidades de cada empresa, teniendo en cuenta aspectos como los servicios que ofrecen, los costes, las regiones, las disponibilidades, las capacidades o la formación. A esto se suma que, dependiendo del sector, existen diversas recomendaciones y buenas prácticas. Por ejemplo, en el ámbito financiero, un informe del EBA (European Banking Authority) se refiere a la utilidad de usar varios proveedores para así poder definir una estrategia de salida y evitar el vendor locking.
Además, existen diferentes modelos de adaptación. Por un lado, están las empresas que apuestan por un modelo híbrido con solo un proveedor de nube pública; por otro —que engloba a la mayoría del sector financiero y comprende empresas de un tamaño considerable— están las compañías que optan por una implementación multicloud más pragmática, utilizando servicios de proveedores en función del uso. Por ejemplo, emplean las herramientas ofimáticas y de trabajo colaborativo de Google o de Microsoft, pero las cargas productivas se ejecutan en AWS.
Utilizar un modelo multicloud que permita ejecutar aplicaciones independientemente del proveedor es todo un reto
Para la convivencia con sistemas legacy han surgido enfoques de hybrid cloud como el denominado mainframe offloading, que consiste en la extracción de los datos desde on-premise a cloud, normalmente mediante CDC (change data capture) para que sean analizados y transformados sin que ello tenga un impacto en la carga del mainframe. Además, este procedimiento ayuda a que las nuevas aplicaciones puedan ser implementadas en la nube, lo que se traduce en reducción de costes y aceleración del time-to-market.
Otro enfoque es la creación de una capa interna intermedia ubicada entre las aplicaciones internas y los servicios de los proveedores cloud. Esta capa ofrece servicios genéricos de “nube corporativa” tales como almacenamiento, streaming, computación, etc. Se encarga además de facilitar el mapeo con los servicios a un proveedor cloud concreto, aislando la complejidad de la gestión multicloud. Es importante evaluar el valor que aporta esta capa intermedia teniendo en cuenta los continuos cambios de servicios en los proveedores cloud y el alto coste de desarrollo, mantenimiento y operación que dichos cambios implican.
Independencia del proveedor
Utilizar un modelo multicloud, de tal forma que se puedan ejecutar las mismas aplicaciones independientemente del proveedor, es todo un reto. Se ven afectadas diferentes áreas, como las de arquitectura y desarrollo, aprovisionamento de infraestrutura, gestión de operación unificada (DevOps, FinOps), seguridad o gobierno de los entornos cloud.
Arquitectura y desarrollo de aplicaciones. Al diseñar una arquitectura de infraestructura o aplicación hay que tener en cuenta varios aspectos:
- Toda comunicación de datos entre servicios de distintos proveedores (por ejemplo, una aplicación ejecutándose en un Cloud Run de GCP que accede a una base de datos en Amazon RDS) tiene un elevado coste que solo en casos concretos está justificado.
- Cuantos más servicios se usen de un mismo proveedor, mejores costes se consiguen, pero también aumenta la dependencia.
- El desarrollo de aplicaciones de tipo cloud-native reduce esta dependencia y facilita el cambio de proveedor, pero el coste es más elevado que si se enfoca a un proveedor en concreto.
En cualquier caso, para la migración de aplicaciones a entornos cloud, todos los proveedores ofrecen un servicio gestionado de Kubernetes, incluyendo un modo serverless, que permite la ejecución de aplicaciones contenerizadas. Google, Microsoft y AWS soportan la integración de los servicios de los distintos proveedores cloud y on-premise bajo una misma herramienta. Google Anthos, Microsoft Arc y AWS EKS Everywhere son ejemplos que permiten gestionar clústeres Kubernetes de forma unificada. Además, utilizando modelos de despliegue basados en GitOps se obtienen beneficios como la reducción de tiempos de entrega o la mejora del time-to-market de nuevas funcionalidades.
Aprovisionamiento de infraestructura. Para el aprovisionamiento automático en un entorno multicloud son necesarias herramientas que traten la infraestructura como código y que permitan desplegarla en los diferentes proveedores de una manera estandarizada. Herramientas y marcos de trabajo como Terraform, en sus diferentes versiones, y Pulumi son los más adecuados para estas tareas.
No tiene sentido utilizar las herramientas de los propios proveedores cloud —como AWS CloudFormation, Azure Resource Manager o Google Deployment Manager— si realmente se quiere ir a un modelo multicloud. Además, en este tipo de proyectos de IaC (infraestructura como código) se recomienda aplicar las mismas prácticas que se utilizan para el desarrollo de software, como las pruebas unitarias, la revisión de código, la integración continua y los despliegues automáticos.
Operaciones unificadas. Otro reto importante son las diferentes áreas de operación, desde el monitoring y logging unificado y los procesos de DevOps para el despliegue en varios proveedores cloud hasta el control de coste aplicando las buenas prácticas FinOps.
FinOps. La complejidad de la gestión del coste aumenta considerablemente al tener que interactuar con diferentes proveedores, con sus propias interfaces de comunicación y diferentes estándares en las métricas. Por ejemplo, una vCPU tiene un significado en Azure y otro en GCP, por lo que se recomienda emplear herramientas de control de costes que implementen las particularidades de cada proveedor.
Además de la parte técnica, no hay que olvidar la formación y certificación de la plantilla, para lo cual se pueden aprovechar los programas que ofrecen todos los proveedores, accesibles a un reducido coste.
La teoría de estos entornos multicloud es prometedora, pero aún estamos en los inicios. Queda mucho camino para descubrir cómo evolucionarán y cómo será la adaptación final de las empresas.
