Conecta con nosotros

Opinión

Journey to Cloud Tales I: La paradoja de la discoteca vacía

Publicado el

Es obvio que, por múltiples motivos (costes, escalabilidad, inmediatez, innovación, economías de escala, etc.), hoy nos encontramos en un proceso de adopción masivo de este paradigma cloud. Están confluyendo las iniciativas de las grandes compañías tecnológicas, las estrategias de negocio de muchas organizaciones empresariales y hasta los intereses de los ciudadanos, que nos hemos acostumbrado a hacer uso de muchas funciones cloud en nuestro día a día.

Por supuesto que no, soy un creyente en que la nube es un gran avance y que ayuda enormemente en la transformación de las organizaciones. Esta aparente contradicción no debería sorprendernos, ha ocurrido múltiples veces en la historia de la tecnología (básicamente cada vez que ha habido un proceso de transformación digital), basta con recordar la aparición de Internet, cuando ocurrió lo mismo:

Se sobreestimó la facilidad de adaptación subestimando la complejidad de la transformación

En primer lugar, una plataforma cloud nace con la idea de ofrecer servicios novedosos y económicamente muy eficientes. La teoría indica que las nubes se poblarían de dos formas,

  1. Mediante el movimiento prácticamente inmediato de las cargas y aplicaciones actuales.
  2. Mediante el desarrollo masivo de aplicaciones en la nueva plataforma.

En el caso de las cargas actuales y sus posibilidades de moverse a cloud, el problema reside en subestimar los retos de realizar ese movimiento. En concreto existen varios factores a considerar:

  • Existe un elevado grado de obsolescencia tecnológica, la cual impide un movimiento directo e implica un proceso de actualización de versiones para adecuarse a las soportadas en la nube.
  • La existencia de una extraordinaria interconexión entre los componentes de infraestructura, (aplicaciones en el mismo servidor, bases de datos compartidas o que se comunican entre ellas a bajo nivel), haciendo muy difícil desentrañar la madeja e ir moviendo componentes de manera individual.
  • Desde el punto de vista financiero, normalmente se trata de activos ya amortizados o incluidos en contratos a largo plazo que habría que considerar a la hora de estimar los costes y por tanto los beneficios a obtener mediante el movimiento a la cloud.

Estos factores, además de impedir un movimiento fácil y directo de las cargas, han introducido un debate digno de los filósofos griegos y bizantinos.

¿Muevo las cargas y luego actualizo? vs. ¿Actualizo y luego las muevo?

Analizamos el segundo caso, la construcción de nuevas aplicaciones. Es evidente que la mayoría de los clientes no construye aplicaciones de manera masiva por simple evolución tecnológica. Se observan dos claras tendencias positivas:

  1. Desarrollo de aplicaciones que aprovechan funcionalidades específicas de las nubes (por ejemplo, IA, Machine Learning, etc), aplicaciones de alto valor añadido pero que aún representan un porcentaje muy pequeño del total de las aplicaciones de una organización.
  2. El comienzo del desarrollo de aplicaciones corporativas en cloud, proceso lento y que precisa la habilitación de una verdadera arquitectura aplicativa cloud. Se suele obviar que los servicios prestados por una cloud deben seguir las reglas de cualquier aplicación empresarial: uso de servicios corporativos, seguridad, monitorización funcional, integración, intercambio, etc.

Y eso por no hablar de la escasez de profesionales existentes en todo el ámbito tecnológico, muy especialmente en este.

Pero estos temas se convierten en triviales cuando se trata de mover o modernizar aplicaciones a la nube. Y sorprendentemente los principales problemas provienen de ignorar o subestimar que una aplicación es un sistema heterogéneo y muy sofisticado.

Esquema aplicativo de una app

Esquema aplicativo

Otras consideraciones sobre cloud

Existen otra serie de consideraciones que pueden afectar a las posibilidades y esfuerzo necesario de modernización:

  • La conoce y por tanto mantiene y evoluciona un equipo humano determinado, muchas veces sin documentación actualizada ni casos de pruebas formales.
  • Se compone de capas separadas muy sensibles a la latencia.
  • Están hiper acopladas, con miles o decenas de miles de programas interconectados.
  • Demanda unos requerimientos no funcionales muy estrictos.
  • Usan múltiples productos software, así como diversas librerías open-source.
  • Aplican soluciones de arquitectura no aplicables en la nube.
  • Se integran con múltiples sistemas corporativos de base y otras aplicaciones.
  • Precisan el almacenamiento de datos en bases de datos y sistemas de ficheros, en algunos casos locales y en otros remotos.

Asumir que una aplicación se puede llevar directa y rápidamente a una nube es sencillamente un desastre que ha encontrado un lugar para ocurrir. Por tanto, la experiencia recomienda plantearse una serie de cuestiones antes de hacer cualquier movimiento a la nube:

  • Tengo un monolito, ¿qué hago con él?
  • ¿Quién va a modernizarla, el equipo actual? ¿Tiene los conocimientos necesarios? ¿Quién la asume una vez modernizada?
  • ¿Cómo pruebo las aplicaciones modernizadas?
  • ¿La nube elegida ofrece los mismos servicios que usa la aplicación?
    • ¿Servidor de aplicaciones, bases de datos, sistemas operativos, lenguajes de programación?
  • ¿Se quiere ir a contenedores, pero se usa un servidor de aplicaciones pesado o tratamiento statefull de la sesión de usuarios?
  • ¿Existen dependencias de librerías del servidor de aplicaciones, de la versión del lenguaje de programación o de librerías open-source obsoletas o no existentes en la nube?
  • ¿Existen protocolos de comunicación no soportados?
  • ¿Se usan direcciones directas de directorios o ficheros?
  • ¿Se usan urls y protocolos no securizados?

Sin embargo, me gustaría remarcar que es totalmente factible el realizar un proceso eficiente de modernización y movimiento de aplicaciones y cargas a la nube. Eso sí, con un buen método, expertos y herramientas adecuadas, pero eso lo dejamos para el siguiente artículo…

Firmado: José María Silva Application Engineering Services – Practice Leader SPGI IBM Consulting

Lo más leído