Internet ha cambiado la manera en que las aplicaciones se desarrollan y se despliegan. La arquitectura en tres capas basada en una base de datos, conectada a una capa de lógica de negocio y con una capa de presentación por encima ha quedado obsoleta.

Repetimos incesantemente el mantra del Internet scale, queriendo decir que el número de dispositivos que hoy se conectan a una aplicación a la vez pueden colapsarla en cualquier momento si todavía usa la arquitectura en tres capas. Esta arquitectura, basada en una base de datos, conectada a una capa de lógica de negocio y con una capa de presentación por encima, ha sido abusada hasta principios de este siglo, y ha quedado obsoleta.

El primer desafío fue la escalabilidad: hacer que una aplicación pudiera soportar miles, millones o miles de millones de conexiones concurrentes. Ahora se supone la escalabilidad de cualquier aplicación, a pesar que estos requisitos nunca lleguen a ser reales. Hoy en día la escalabilidad no es más que una consecuencia de un buen diseño.

Pero la escalabilidad es cómo un sistema reacciona ante picos de carga de trabajo. Uno espera que si la carga de trabajo se duplica, la única consecuencia práctica para mantener la calidad del servicio sea duplicar los recursos. Tenemos numerosos ejemplos de aplicaciones dando servicio a millones de usuarios utilizando miles de servidores. Pero los requisitos de los backends modernos han ido más allá del rendimiento.

La “Mesh App and Service Architechture” (MASA) se refiere al diseño de soluciones que combinan aplicaciones móviles, online, de escritorio y los dispositivos IoT

En un uno de sus últimos informes “Top 10 Strategic Technology Trends”, Gartner introdujo una nueva palabra clave en la arquitectura de aplicaciones, que enmarca bien lo que representa la punta de lanza de la innovación en IT.

La “Mesh App and Service Architechture” (MASA) se refiere al diseño de soluciones que combinan aplicaciones móviles, online, de escritorio y los dispositivos IoT junto con sus datos, independientemente de que sean para un usuario final o por fines operativos, en una red de servicios back-end para crear lo que un usuario ve como una “aplicación”.

MASA introduce una nueva medida para el diseño de arquitectura: la complejidad. Cualquier aplicación que escala sin problemas bajo una enorme carga de trabajo puede tambalear cada vez que hay que añadir una nueva funcionalidad, como una nueva fuente de datos o publicar otra interfaz RESTful a uno de esos avanzados interfaces programados en Javascript. Cualquier problema de disponibilidad, latencia, excepciones o bugs son inmediatamente penalizados por los usuarios, cuyos estándares de calidad mínimos no paran de crecer. Uniendo a todo esto el hecho que los ciclos de desarrollo son cada vez más cortos, es obvio por qué la complejidad ha pasado a ser el nuevo desafío.

MASA se ha utilizado como una razón para introducir la arquitectura basada en microservicios de manera masiva, pero la justificación es errónea. La arquitectura basada en microservicios es la combinación lineal de aplicaciones que siguen la clásica arquitectura en triple capa conectadas a la misma red. Es una clara mejora, pero no resuelve muchas de las dificultades que se han expuesto.

La arquitectura basada en microservicios hace un gran trabajo escondiendo la complejidad al desarrollo del frontend, dado que el backend se separa en partes con una funcionalidad específica. Sin embargo, cada una de esas partes puede complicarse por sí misma.

La complejidad no se gestiona directamente, simplemente se esconde en niveles más profundos dentro del backend. Los problemas difíciles no siempre se pueden resolver como una combinación lineal de problemas sencillos, y esto es precisamente lo que propone la arquitectura basada en microservicios.

Hace un año, Nfq decidió afrontar este desafío de administrar la complejidad en la arquitectura con PALM, y pylm que es su implementación en Python. Incluso antes que el acrónimo MASA apareciera por primera vez.

El objetivo de PALM es el de administrar la complejidad permitiendo que componentes estándar puedan comunicarse con un flujo de comunicación más versátil. Pylm soporta el balanceo de carga, la suscripción a colas de mensajes, comunicación a través de múltiples protocolos y muchos otros patrones orientados soportar sin problemas casos que eran infrecuentes hace pocos años, pero que ahora son requisitos de las arquitecturas complejas.

Pylm es software libre (https://github.com/nfqsolutions/pylm), puede instalarse con un único comando en Windows, Linux y MacOS (pip install pylm), y dispone de una extensa documentación (http://pylm.readthedocs.io). Está lo suficientemente maduro como para haber sido puesto en producción, y será un componente clave en los futuros desarrollos de Nfq.