Introducción
La elección de un estilo arquitectónico es una de las soluciones técnicas fundamentales en la construcción de un sistema de información. En esta serie de artículos, propongo desmontar los estilos arquitectónicos más populares para aplicaciones de construcción y responder a la pregunta de cuándo es el estilo arquitectónico más preferido. En el proceso, intentaré dibujar una cadena lógica que explique el desarrollo de estilos arquitectónicos desde los monolitos hasta los microservicios.
La última vez que tratamos con el monolito y llegamos a la conclusión de que el monolito tiene una serie de problemas: el tamaño, la conectividad, el despliegue, la escalabilidad, la fiabilidad y el conservadurismo.
En esta ocasión propongo hablar sobre las posibilidades de organizar un sistema en forma de un conjunto de módulos / bibliotecas (arquitectura orientada a componentes) o servicios (arquitectura orientada a servicios).
Arquitectura orientada a componentes
La arquitectura basada en componentes implica la implementación del sistema como un conjunto de componentes que se pueden utilizar tanto en proyectos actuales como futuros. Al dividir un sistema en componentes, se tienen en cuenta los siguientes factores: su idoneidad para la reutilización, su sustituibilidad, independencia del contexto, extensibilidad, encapsulación e independencia.
Con el uso adecuado de los componentes se soluciona el problema de una “gran bola de suciedad” (gran tamaño + alta conectividad), y los propios componentes pueden ser tanto unidades de montaje (módulos, bibliotecas) como unidades de despliegue (servicios). Las unidades de implementación no siempre se asignan a un proceso en ejecución: por ejemplo, una aplicación web y una base de datos se implementan juntas.
Muy a menudo, los monolitos se diseñan como un conjunto de módulos. Este enfoque conduce a garantizar la independencia del desarrollo, pero al mismo tiempo persisten los problemas de escalado y despliegue independientes, tolerancia a fallos e independencia del conjunto tecnológico general. Por eso el módulo es un componente parcialmente independiente.
El mayor problema con este monolito es que la división en módulos es puramente lógica y los desarrolladores pueden romperla fácilmente. Puede aparecer un módulo central, que gradualmente se convierte en un montón de basura, puede crecer un gráfico de dependencias entre módulos, etc. Para evitar tales problemas, el desarrollo debe ser realizado por un equipo muy maduro o bajo la guía de un "arquitecto" que se dedique a la revisión del código a tiempo completo y venza a los desarrolladores que violan la estructura lógica.
Un monolito "ideal" es un conjunto de módulos separados lógicamente, cada uno de los cuales busca en su propia base de datos.
Arquitectura orientada a Servicios
Si, sin embargo, se supone que organiza el sistema en forma de un conjunto de servicios, entonces estamos hablando de una arquitectura orientada a servicios. Sus principios son: interoperabilidad de aplicaciones orientadas al usuario, reutilización de servicios empresariales, independencia de un conjunto de tecnologías y autonomía (evolución independiente, escalabilidad y despliegue).
La arquitectura orientada a servicios (SOA) resuelve todos los problemas descritos del monolito: un cambio afecta solo a un servicio y una API bien definida admite una buena encapsulación de componentes.
Pero no todo es tan sencillo: SOA presenta nuevos problemas. Las llamadas remotas son más caras que las locales y la redistribución de responsabilidades entre componentes se ha vuelto significativamente más cara.
Por cierto, la capacidad de implementar de forma independiente es una característica muy importante del servicio. Si los servicios se van a implementar juntos, o incluso más en una secuencia determinada, entonces el sistema no puede considerarse orientado a servicios. En este caso, hablan de un monolito distribuido (se considera un antipatrón no solo desde el punto de vista de SOA, sino también de una arquitectura de microservicio).
La arquitectura orientada a servicios está bien respaldada por la comunidad de arquitectura y los proveedores. Por lo tanto, hay muchos cursos y certificaciones, patrones bien desarrollados. Este último incluye, por ejemplo, el bus de servicio empresarial no desconocido (ESB = bus de servicio empresarial). Al mismo tiempo, ESB es el equipaje de los proveedores, no tiene que usarse en SOA.
La arquitectura orientada a servicios alcanzó su punto máximo en popularidad alrededor de 2008, después de lo cual comenzó a declinar, lo que se volvió mucho más agudo después de la aparición de los microservicios (~ 2015).
Conclusión
Después de discutir las posibilidades de organizar los sistemas de información en forma de servicios y módulos, propongo pasar finalmente a los principios de una arquitectura de microservicio y prestar especial atención a la diferencia entre una arquitectura de microservicio y una arquitectura orientada a servicios en la siguiente parte.
