Retos de la migración a la nube (y II)

¿Qué retos van a ser los principales a la hora de afrontar de forma seria un modelo cloud? ¿La nube híbrida es la mejor de las opciones?

Con lo expuesto en el artículo anterior, la primera parte de la pregunta está respondida, pero lo resumimos en personal cualificado escaso, business cases insatisfechos y el cambio cultural. Además hay un riesgo de volver al Shadow IT que tanto ha costado ir eliminando en las organizaciones, ya que la democratización de la tecnología y el acceso a soluciones SaaS hace que las unidades de negocio puedan desarrollar sus capacidades al margen del gobierno de TI establecido.

 La nube híbrida es en la mayoría de los casos un estado obligatorio durante los procesos de migración a cloud, o estacionario si responde a una estrategia empresarial o un imperativo regulatorio o tecnológico. Cómo se implemente esa nube híbrida también influye a la hora de suavizar el modelo. La nube híbrida puede ser:

•  Interoperatividad a nivel de servicios web, consumo de API en ambos sitios y transferencia de datos para el procesado en nube. Cada entorno mantiene sus servicios de forma nativa y perimetrada y se aprovecha lo mejor de ambos mundos.
• Reparto de cargas mediante la extensión de la red en capa 2 de comunicaciones con la nube, haciendo una extensión de los datacenters y utilizando servicios lo más adecuados en cada entorno
• Implementando una plataforma de ejecución y gestión común entre el mundo on-prem y cloud mediante plataformas como Red Hat Openshift para contenedores y cargas virtualizadas o VMWare para cargas clásicas virtualizadas

También se considera en muchas ocasiones la nube híbrida como un Disaster Recovery de los sistemas On-Prem, pero es un modelo complejo de implementar y tener operativo al 100% (normalmente si una carga es ejecutable en nube junto con las interdependencias de la propia aplicación se migra a la nube de forma definitiva liberando recursos locales e implementando el DR en cloud de forma nativa)

 En general, las empresas se manejan con múltiples provedores, ¿gestionar un entorno multicloud es cada vez más difícil? ¿Cómo se puede un CIO manejar en un entorno cada vez más complejo?

La filosofía inicial de desarrollo nativo cloud “you build it, you run it” acuñada en 2016 por el CTO de Amazon, parece muy acertada pensando en un modelo DevSecOps. Sin embargo, tras unos años de diferentes implementaciones, sin unas estrategias de Landing Zone, FinOps, CCoE y control arquitectural las empresas se encuentran con aquello de lo que huían, los silos no ya entre desarrollo y sistemas sino entre diferentes equipos de desarrollo, cada uno con diferentes modelos de gestión y ciclo de vida de sus aplicaciones, convirtiéndose, por tanto, en antipatrones de Devops.

Es preciso, desde un modelo de control arquitectural, definir los servicios comunes y homogéneos a consumir (logs, seguridad, proveedores de identidad, modelos de HA…) y fundamentalmente, implementar una observabilidad obligatoria extremo a extremo que permita no sólo detectar y corregir problemas de infraestructura y de aplicación, sino de predecir y anticipar los fallos mediante AIOps. Sumando la automatización extrema de las operaciones, se podrán obtener eficiencias mucho mayores, llegando incluso a un modelo NoOps.  

Los entornos complejos implican una estandarización y homogeneización, además de un control. Por ello, volvemos a incidir en plataformas como Red Hat Openshift que dan precisamente esa visión uniforme de gestión y ejecución, por ejemplo con Advanced Cluster Management, para la gestión de cargas en cualquier sitio (desde el On-prem hasta el Edge) y herramientas de FinOps como puede ser Klarity o Apptio. 

En definitiva, el control sigue siendo necesario para no caer en la anarquía tecnológica, aunando el cambio cultural con la torre de control de la observabilidad.