Modelos de software en la nube y el impacto en sistemas cognitivos

A estas alturas, creo que es indudable el gran impacto, la gran transformación que a nivel de TI y de todo el mundo digital, ha tenido la nube, el cloud computing.

La evolución del cloud computing

Debo confesar que, cuando hace ya bastantes años oí hablar de este concepto por primera vez, no creí que llegara a ser tan revolucionario...pero sí que lo ha sido y lo va a seguir siendo.

En sus  primeras implementaciones prácticas, el cloud computing puso más énfasis, como heredero de los llamados hosting y housing, en todo lo relativo al hardware y la infraestructura, lo que posteriormente se ha reconvertido en los así llamados IaaS (Infrastructure as a Service) y PaaS (Platform as a Service).

Pero con todo y lo importante que desde un punto de vista de negocio y de operación TI es la externalización de la infraestructura y su paso del modelo de propiedad al de uso, creo que la transformación más profunda y su carácter impulsor de la transformación digital global viene dada por la prestación de capacidades de software desde la nube, una prestación que inicialmente se centraba en el modelo SaaS (Software as a Service), que viene a ser, por decirlo coloquialmente, como el alquiler de una aplicación completa pero que se extiende y completa posteriormente con la visión más orientada a servicios, derivada de la filosofía SOA (Service Oriented Architecture) y que con ingredientes adicionales ha dado lugar a las APIs web (típicamente REST), a los contenedores, a los microservicios y al concepto de Función como Servicio (FaaS, Functions as a Service), generando una panoplia de opciones caracterizadas todas ellas por su prestación desde la nube y en modo pago por uso y unas opciones que cada vez se orienta menos a la aplicación y más al servicio, la función y las APIs.

Modelos de software en la nube

Aunque no es el objetivo principal del libro, me ha gustado mucho, por lo compacto y clarificador, el esquema que al respecto de todas las opciones existentes, plantea Jaume Miralles en 'Proyectos de Inteligencia Artificial' y que, a su vez, se basa en el articulo '¿Qué modelo Cloud es el mejor para los desarrolladores?' escrito por Ana López Mancisidor y José Miguel Ordax en un blog de IBM.

El modelo es el que se muestra en la figura:

En ese modelo se observan 9 niveles de capacidades hardware y software que, de abajo a arriba son:

• Networking
• Almacenamiento
• Servidores
• Virtualización
• Sistema operativo
• Middleware
• Configuración del middleware
• Datos
• Aplicaciones

En esos niveles, se puede ver que los tres primeros (Networking, Almacenamiento y Servidores) se concentran más en los aspectos hardware; los siguientes se concentran el el software de plataforma (Virtualización, Sistema Operativo, Middleware y configuración del middleware) y los dos dos últimos (Datos y Aplicaciones) en las aplicaciones finales.

A su vez, el esquema muestra mediante un código de colores en quién recae la responsabilidad de cada uno de esos bloques (azul oscuro es el modelo tradicional, con responsabilidad por parte del cliente o usuario, y azul claro responsabilidad por parte de un proveedor de servicio).

Y con esas bases, los autores encajan seis modelos, que, en orden creciente de externalización y servitización (que no de orden cronológico de aparición en el mercado) son:

• Tradicional ('on premises'): el cliente usuario mantiene la propiedad y responsabilidad de todos los elementos y en sus propias instalaciones.


• IaaS (Infrastructure as a Service): El proveedor de servicio proporciona ya lo relativo al hardware (Networking, Almacenamiento y Servidores) y algo de virtualización.


• CaaS (Containers as a Service): Se introduce el concepto de contenedor y el proveedor del servicio se hace cargo ya del sistema operativo y el middleware.


• PaaS (Plataform as a Service): El proveedor de servicio se hace ya cargo de todo el software de plataforma, añadiendo al caso anterior la configuración del middleware.


• FaaS (Functions as a Service): En realidad no añade externalización ni servitización de ninguna capa, pero sí es cierto que la capa de aplicación y datos cambia y se convierte, de hecho, en lo que los autores denominan 'acciones y disparadores' puesto que, en el caso de FaaS, no existe una aplicación como tal, sino una serie de funciones autocontenidas.


• SaaS (Software as a Service): Supone la externalización y servitización completas donde toda la aplicación y los elementos inferiores necesarios es proporcionada por el proveedor de servicios.

En este esquema se indica que los modelos más a la izquierda proporcionan un mayor rendimiento y control por parte del cliente / usuario, mientras que los de la derecha tienen a proporcionar velocidades crecientes de desarrollo.

El impacto en sistemas cognitivos

¿Y por qué Jaume Miralles se detiene a hablar sobre cloud computing y los modelos de prestación de las capacidades software cuando su libro trata de inteligencia artificial y de proyectos de inteligencia artificial?

Pues porque el impacto de estos modelos en la nube es enorme en el caso de la implantación y popularización de la inteligencia artificial. Porque, como el autor también explica en su libro, con cierta frecuencia (aunque no siempre), cuando una empresa se plantea realizar un proyecto de inteligencia artificial no desarrolla las capacidades cognitivas por sí mismo sino que se apoya en capacidades ya existentes y disponibles normalmente en la nube bajo alguno de los esquemas mencionados o alguno similar, muy especialmente los esquemas en que el software no se ofrece como aplicación sino como servicios y APIs (como sucede, por ejemplo, en CaaS y FaaS). Esto es especialmente notorio cuando hablamos de capacidades tecnológicamente complejas y que precisan muchísimos datos de entrenamiento como pueden ser las relativas a procesamiento de lenguaje natural.

Cuando se buscan los motivos del éxito actual de la inteligencia artificial se apuntan a aspectos como el aumento de la capacidad de computación (y el uso de las GPUs), la aparición de nuevos algoritmos (sobre todo de deep learning) y la gran disponibilidad de datos. Todo ello es cierto, pero creo que no cabe menospreciar sino, bien al contrario, resaltar, la contribución que estos modelos de prestación de servicios cognitivos desde la nube están teniendo en la democratización de la Inteligencia Artificial poniendo capacidades muy avanzadas casi al alcance de cualquiera.

Doce buenas prácticas para la construcción de software como servicio

Uno de los paradigmas que trae consigo el cloud computing es el ofrecimiento de las capacidades IT como un servicio siguiendo el modelo de utility empleado en agua, electricidad, etc. Una de las formas, quizá la más avanzada, de esa prestación 'como servicio', sea el Software como Servicio (SaaS, 'Software as a Service').

Proporcionar el software como servicio tiene unas importantísimas implicaciones a nivel de gestión TI y de modelos operativos y de negocio, pero también tiene, no lo olvidemos, una base tecnológica. Aunque el cloud computing está alcanzando ya unos niveles de madurez que nos hacen empezar a percibirlo como algo 'normal', lo cierto es que el diseño de aplicaciones para la nube, tiene sus indudables dificultades y problemáticas propias.

Cuando en el post anterior hablábamos del modelo de madurez para aplicaciones cloud nativas propuesto por de Tom Laszewski, Kamal Arora, Erik Farr y Piyum Zonooz, en su libro 'Cloud Native Architectures', mencionábamos, dentro del eje de diseño centrado en la aplicación, una metodología denominada 'los doce factores'.

En este post quisiera ampliar un poco más la información sobre esa metodología. En mi opinión, no se trata realmente de una metodología sino, más bien, de unas buenas prácticas nacidas de la experiencia práctica de los creadores del documento. Eso si, doce muy interesantes buenas prácticas y que creo que recogen muy acertadamente la experiencia de sus creadores y proporcionan buenos sabios consejos.

Las doce buenas prácticas son, muy resumidas, las siguientes:

• Código base (codebase): Utilizar un repositorio de control de versiones y un código base único usado para los diferentes despliegues que puedan ser necesarios.


• Dependencias: Declarar todas las dependencias de forma completa y explícita de forma que una aplicación no dependa nunca de la existencia de paquetes ya instalados.


• Configuraciones: Separación estricta de configuración y código y almacenamiento de la configuración en el entorno.


• Servicios de soporte: Tratar los servicios de soporte como 'attached resources' y tratar de la misma forma los servicios propios y los proporcionados por terceros.


• Construcción, despliegue y ejecución: Separación completa de las fases de construcción, distribución y ejecución.


• Procesos: Las aplicaciones se ejecutan como procesos sin estado y son 'share nothing', es decir, cualquier información que deban almacenar se hará mediante un servicio de soporte (como una base de datos).


• Asignación de puertos: Hacer aplicaciones auto-contenidas sin dependencia de la existencia de un servidor web y, a esos efectos, publicar los servicios indicando los puertos en que escuchan.


• Concurrencia: Preparar la aplicación para escalar con base en una correcta aplicación del modelo de procesos y confiar en el gestor de procesos del sistema operativo.


• 'Desechabilidad': Hacer las aplicaciones 'desechables' es decir, que puedan iniciarse y finalizarse en el momento que sea necesario y teniendo en cuenta cosas como minimizar el tiempo de arranque y la finalización en modo seguro.


• Paridad desarrollo/producción: Minimizar las diferencias (de tiempo, personal y herramientas) entre entornos de desarrollo y producción, facilitando la filosofía del despliegue continuo.


• Trazas (logs): Hacer que la aplicación 'se despreocupe' del enrutado o almacenamiento de los 'logs'. escribiendo en su lugar en la salida estándar y, posteriormente, en cada entorno, haciendo la redirección de esa salida a donde sea oportuno.


• Procesos de administración: Hacer que procesos del tipo de migraciones, scripts, etc se ejecuten en el mismo entorno que los procesos 'normales'.

Estas buenas prácticas, por supuesto, se explican en más detalle que lo aquí mencionado y están accesibles en la web, incluso en español, y también se pueden descargar como documento ePub.

Escritas por técnicos para técnicos, creo que estas doce buenas prácticas pueden resultar muy interesantes e ilustrativas para desarrolladores, arquitectos y operadores cloud.

Los eslabones perdidos del software corporativo

En mi entorno laboral, que se desarrolla con frecuencia en el mundo de los sistemas de información en grandes compañías,  alguna vez he oído hablar de leyendas que apuntan a la pérdida de códigos fuente en algunos de los sistemas de información más antiguos pero, a la vez, probablemente, más importantes, los que forman la columna vertebral de la informática corporativa.

Nunca me lo he creído del todo ni tampoco me lo he dejado de creer.

Por un lado, me parece plausible. Al fin y al cabo, el sector del software creo que sigue sin estar completamente maduro en cuanto a estabilidad y operación y estos casos constituirían, en ocasiones, muestra de negligencia sí, pero, en otras, puros síntomas de esa inmadurez.

Pero, por otro lado, me parece tremendo y de consecuencias difíciles de evaluar el riesgo que supone esa pérdida de código fuente, una pérdida que parece aconsejar la sustitución rápida del elemento de software afectado y la adopción de medidas para evitar que vuelva a ocurrir.

Sin embargo, esas historias de pérdidas de código fuente, esos eslabones perdidos del software cororativo,  deben ser algo más que mitos y leyendas. Leo en el libro 'Executive's guide to cloud computing' de Eric A. Marks y Bob Lozano, la siguiente afirmación:

"The world of the computing in the enterprise is replete with stories of applications for which no source exists; applications for which source exists but the required supporting tools are no longer supported; and applications for which source and supporting tools do and are supported but for which no living person has any reasonable ability to undestand enough about the application to even hope to modify, much less to move the application. This stories are real: these applications exist."

Los autores hablan de la integración (establecimiento de una capa de servicios que recubra el software obsoleto) e interacción (uso de esos servicios por otras aplicaciones) como la forma de convivir con este tipo de aplicaciones. Y considero que son las recetas adecuadas, pero pensando en un corto/medio plazo en que la empresa debe convivir con esta curiosa situación y seguir, sin embargo, evolucionando el resto de sus sistemas.

A largo plazo no parece existir más opción que la sustitución de la aplicación. Opción nada barata ni sencilla, presumiblemente. Pero el riesgo de una aplicación que, en el fondo, es desconocida, que nadie sabe cómo mantener, evolucionar e, incluso corregir, es considerable. La probabilidad de que una de estas aplicaciones falle es muy bajo, puesto que son aplicaciones que llevan años funcionando satisfactoriamente. Eso si, si un día fallan, las consecuencias pueden ser desastrosas.

¿Que ocurriría si, a consecuencia de una migración de CPD, o de la evolución de otra aplicación con la que se mantenían vínculos no conocidos, o por un desastre natural, o por un corte eléctrico, o por cualquier otro fenómeno no previsto, nuestro venerable sistema de información, aquel del cual no existe código fuente o no sabemos ya gestionarlo, aquel sistema de información que, sin embargo, se encuentra en la columna vertebral de nuestra informática corporativa, dejara de funcionar?

Tal vez, evitar este tipo de situaciones, pueda ser un nuevo argumento, por cierto un argumento rara vez esgrimido, en favor del cloud computing y del software como servicio (SaaS).

Lo que la experiencia con ERP y CRM tiene que enseñar al Cloud Computing y al SaaS

Aunque ya olvidada como tendencia, aunque ya integrada dentro del flujo principal de las opciones en tecnologías y sistemas de información, hace ya unos cuantos años, una de las 'buzzwords' dominantes, uno de los santos griales en tecnología, era la existencia e implantación de los grandes paquetes de software empresarial, los paquetes que inicialmente se centraban en el mundo del ERP, incluyendo funcionalidades como la planificación de la producción o la gestión económica y financiera de la empresa, campo al que unos años más tarde se unió el concepto del CRM donde, manteniendo la misma idea en cuanto a concepción del software, el foco funcional se trasladaba ahora a los procesos comerciales y la relación con el cliente: la gestión de la fuerza de ventas, la automatización de las acciones de marketing o el soporte a las labores de posventa.

El planteamiento de estos paquetes empresariales, tanto ERP como CRM, era ofrecer una funcionalidad ya precocinada, una funcionalidad que se suponía recogía las mejores prácticas del sector. La labor de implantación, en teoría, apenas necesitaba desarrollo software y se reducía a una mera parametrización para adaptar esa funcionalidad precocinada a las particularidades de la empresa objeto de implantación y, quizá, a alguna integración con otros sistemas 'legacy'.

Esto debía conducir a una gran agilidad en la disponibilidad de nuevos sistemas frente a la opción de los desarrollos software a medida.

La contrapartida es que la empresa debía amoldarse, en cierta medida, a esas mejores prácticas incluidas en el software empresarial y a la implementación de los procesos de negocio en ellas contenido.

Lo cierto es que esa filosofía no siempre se respetó. Lo cierto es que con demasiada frecuencia no acompañó a la implantación de estas herramientas una reingeniería de procesos y se trasladaron por ello a las implantaciones muchas de las particularidades del funcionamiento de la empresa. Lo cierto es que se llegó a utilizar el paquete software casi como un entorno de desarollo,convirtiendo la implantación en un proceso más cercano al desarrollo a medida que a una parametrización de un software existente.

El resutado: implantaciones muy costosas en tiempo y dinero así como un porcentaje no despreciable de fracasos, y una cierta sensación de que el software empresarial nunca consiguió del todo su promesa de simplificacón, velocidad y eficacia.

Y ahora nos encontramos ante una nueva 'buzzword', ante un nuevo santo grial, ante un nuevo cambio de paradigma. Hablo del cloud computing y del Software como servicio (SaaS).

Bajo este modelo de computación las aplicaciones, el software, son ofrecidas a la empresa desde la nube y, si exceptuamos el caso de las cloud privadas, es proporcionado por un proveedor de servicios TI externo al que lo normal es pagar por uso o por algún tipo de tarifa plana.

Aunque en puridad un modelo de SaaS no excluye la personalización ni el desarrollo a medida, lo cierto es que para que este modelo sea realmente eficaz y, sobre todo, económico, parece que la lógica apunta a que el software ofrecido como servicio sea el mismo, a que exista un fuerte núcleo común ofrecido por el proveedor de servicios y una capacidad suficiente, pero limitada, de parametrización y adaptación a las particularidades de cada cliente o empresa concretos.

Se observa que el patrón es el mismo que el de los paquetes empresariales (que, por cierto, también pueden ser ofrecidos en modo SaaS): un fuerte núcleo común y unas capacidades de parametrización más o menos limitadas.

Si el patrón es común, probablemente el buen o mal uso que de este nuevo concepto se haga, pueda presentar también patrones comunes. En ese sentido, si se desean implantaciones eficaces y económicas de SaaS, probablemente debamos acudir a la memoria de lo ocurrido con los paquetes empresariales tipo ERP o CRM. Probablemente debamos acordarnos de la reingeniería de procesos (caso de ser necesaria) y, sobre todo, de la racionalidad a la hora de exigir cambios y adaptaciones en el núcleo del software ofrecido en modo SaaS.

¿Demostraremos haber aprendido la lección?