En los últimos cuatro años, mi sitio web MuleSoft ha experimentado tres arquitecturas: monolítica, SOA y microservicios. Este artículo discutirá la evolución de estas arquitecturas y cómo adoptarlas.
Arquitectura monolítica (independiente)
La arquitectura monolítica se puede definir como la primera arquitectura de la mayoría de los sitios web, que son aplicaciones simples y estrechamente acopladas que se ejecutan en una sola capa de aplicación y agrupan todas las funciones en la misma capa de aplicación.
Si queremos acceder a otro servicio o sistema a través de API, necesitamos desarrollar la lógica empresarial y la gestión de errores en la propia aplicación.
La siguiente figura muestra un ejemplo de la arquitectura monolítica de un sistema de gestión de relaciones con los clientes.
Para arquitecturas pequeñas, funcionan bien, pero a medida que la arquitectura crece, la administración y refactorización de aplicaciones se vuelve complicada. Además, la integración continua se volverá complicada, lo que hace que el proceso de DevOps sea casi imposible de completar.
La comunicación entre recursos o aplicaciones de la arquitectura monolítica es directa, sin ningún otro middleware o intervención de ESB. Esto también agrega mucha complejidad al usar ciertos lenguajes (por ejemplo, la conexión entre los servicios Java y SOAP es complicada) para comunicarse con los servicios web.
Arquitectura SOA (de grano grueso)
SOA (orientado a servicios) ya puede tener un mayor desacoplamiento de la arquitectura, puede evolucionar hacia una arquitectura más diversa, también conocida como arquitectura de grano grueso.
Esta es la segunda versión del sistema de estructura de Mulesoft, ESB centraliza toda la lógica empresarial y permite que las conexiones entre servicios y aplicaciones, independientemente de la tecnología o el idioma, sean muy rápidas y sencillas.
Mulesoft proporciona Mule Runtime, similar a Apache Tomcat, se puede usar como un contenedor de Servlet, como se muestra en la siguiente figura.
De esta forma, eliminamos el trabajo innecesario y la mayor parte de la lógica empresarial de la aplicación mediante un sistema de arquitectura única. ESB es responsable de convertir datos, enrutar, acceder a los servicios necesarios, administrar errores, etc. La aplicación de origen simplemente genera un mensaje (si es necesario) y lo envía al ESB a través de una solicitud HTTP.
Sin embargo, todavía hay un problema, es decir, toda la integración del despliegue se introduce a través del ESB, y la arquitectura de acoplamiento y sigue teniendo una naturaleza única sigue funcionando en el mismo sistema. Por ejemplo, cuando la configuración se aplica en tiempo de ejecución, se aplicará a todas las aplicaciones implementadas.
Arquitectura de microservicio (detallada)
A continuación, entran en juego los microservicios con una arquitectura detallada. La arquitectura es muy similar a SOA, pero es un servicio pequeño e independiente. Los microservicios aportan mucha complejidad al nivel de la arquitectura porque involucran muchos roles pequeños, pero la ventaja es que todos son independientes.
Las limitaciones de los microservicios son muy claras y reducir demasiado puede conducir a una arquitectura muy compleja y excesiva. El desarrollo y uso de microservicios requiere que los desarrolladores cambien completamente su forma de pensar, las cosas deben ser simples, con documentación completa y fáciles de ejecutar.
Mulesoft también ha seguido desarrollándose. Ya no es solo el middleware de la arquitectura SOA, sino que también se centra en la arquitectura de microservicio y su plataforma de integración como servicio (SaaS) Anypoint Platform. De esta forma, a través de su plataforma de almacenamiento Cloudhub (integrada con la plataforma Anypoint), los usuarios pueden desplegar aplicaciones para crearlas automáticamente en diferentes instancias sin necesidad de saberlo.
Además, Mulesoft utiliza una API útil y reutilizable para conectar datos y aplicaciones, lo que ayuda a separar la capa de implementación y la API. La conexión guiada por API se divide en 3 capas, la capa de experiencia, la capa de proceso y la capa de sistema. La primera capa es la capa que interactúa con el cliente pero no está implementada. Solo hay API públicas que se pueden administrar y proteger.
La capa restante contiene la implementación y la capa de proceso interactúa entre la API expuesta y la capa del sistema conectada a los servicios necesarios (como bases de datos, SAP, Salesforce, correo, sitios de comercio electrónico, etc.).
Con la ayuda de Anypoint Runtime Fabric y Runtime Manager (integrados con Anypoint Platform), estas aplicaciones se pueden implementar en una infraestructura administrada por AWS, Google Cloud, Azure, máquinas virtuales o clientes en una sola máquina.
También se aplica a los contenedores, aunque requiere cierto conocimiento de Docker.
resumen
Respecto a la adopción de microservicios, mucha gente piensa que es una arquitectura estandarizada, y debe hacerse de manera estandarizada, como Netflix. Sin embargo, el uso de microservicios no es factible ni práctico para muchas organizaciones y es muy probable que provoque fallas.
Para un equipo con una estructura y cultura específicas, debido a diversas limitaciones técnicas y culturales, la visión de los microservicios solo puede llegar hasta cierto punto. Si la organización sigue demasiado el punto de vista normativo en el espacio de los microservicios y los requisitos del producto son incompatibles con los métodos puros, la implementación de la arquitectura del microservicio definitivamente no tendrá éxito.