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 analizar 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.
Un poco de historia
Si intenta hacer una pregunta a los desarrolladores: "¿Por qué necesitamos microservicios?", Obtendrá una variedad de respuestas. Escuchará que los microservicios mejoran el escalado, hacen que su código sea más fácil de entender, mejoran la tolerancia a fallas, a veces escuchará que le permiten "limpiar el código". Volvamos a la historia para comprender cuál fue el propósito de la aparición de microservicios.
En resumen, los microservicios en nuestra comprensión actual surgieron de la siguiente manera: en 2011, James Lewis, analizando el trabajo de varias empresas, llamó la atención sobre la aparición de un nuevo patrón de "microaplicación" que optimizaba SOA en términos de acelerar la implementación de servicios. Un poco más tarde, en 2012, en la cumbre de la arquitectura, el patrón pasó a llamarse microservicio. Por lo tanto, el objetivo inicial de introducir microservicios era mejorar el notorio tiempo de comercialización .
Los microservicios estuvieron de moda en 2015. Según algunos estudios, ninguna conferencia estaría completa sin una charla sobre el tema de los microservicios. Además, algunas conferencias se dedicaron exclusivamente a los microservicios. Hoy en día, muchos proyectos comienzan a usar este estilo arquitectónico, y si el proyecto contiene toneladas de código heredado, lo más probable es que la migración a microservicios se lleve a cabo de forma activa.
A pesar de todo lo anterior, todavía hay bastantes desarrolladores que pueden definir el término "microservicio". Pero hablaremos de esto un poco más tarde ...
Monolito
El estilo arquitectónico versus el microservicio es monolítico (o todo en uno). Probablemente no tenga sentido decir qué es un monolito, por lo que enumeraré de inmediato las deficiencias de este estilo arquitectónico que inició el desarrollo posterior de los estilos arquitectónicos: tamaño, coherencia, implementación, escalabilidad, confiabilidad e inercia. A continuación propongo conocer cada una de las desventajas por separado.
El tamaño
El monolito es muy grande. Y normalmente se comunica con una base de datos muy grande. La aplicación se está volviendo demasiado grande para que un desarrollador la entienda. Solo aquellos que han pasado mucho tiempo detrás de este código pueden trabajar bien con un monolito, mientras que los principiantes pasarán mucho tiempo tratando de descubrir el monolito y no el hecho de que lo resolverán. Por lo general, cuando se trabaja con un monolito, siempre hay algún senior "condicional" que conoce el monolito más o menos bien y abofetea a otros desarrolladores nuevos durante un año o medio. Naturalmente, un mayor condicional es un punto único de falla, y su partida puede conducir a la muerte del monolito.
Conectividad
Un monolito es una "gran bola de barro", cuyos cambios pueden tener consecuencias impredecibles. Al hacer cambios en un lugar, puede dañar el monolito en otro (el mismo "me rasgué la oreja, * @ se cayó"). Esto se debe al hecho de que los componentes del monolito tienen relaciones muy complejas y, lo más importante, no obvias.
Despliegue
Desplegar un monolito, debido a las complejas relaciones entre sus componentes, es un proceso largo con su propio ritual. Este ritual generalmente no está completamente estandarizado y se transmite "de boca en boca".
Escalabilidad
Los módulos Monolith pueden tener requisitos de recursos contradictorios, lo que requiere un compromiso en términos de hardware. Imagine que su monolito consta de los servicios A y B. El servicio A exige el tamaño del disco duro y el servicio B exige la RAM. En este caso, la máquina en la que está instalado el monolito debe ser compatible con los requisitos de ambos servicios, o tendrá que desactivar manualmente uno de los servicios.
Otro ejemplo (más clásico): el servicio A es mucho más popular que el servicio B, por lo que desea que los servicios A sean 100 y los servicios B 10. De nuevo, hay dos opciones: implementar 100 monolitos completos o en algunos entonces los servicios B deberán desactivarse manualmente.
Fiabilidad
Dado que todos los servicios están juntos, si el monolito cae, todos los servicios caen a la vez. De hecho, quizás esto no sea tan malo, al menos no habrá fallas parciales en un sistema distribuido, pero por otro lado, debido a un error en la funcionalidad que usa el 0.001% de los usuarios, puedes perder a todos los usuarios de tu sistema.
Inercia
Debido al tamaño del monolito, es difícil cambiar a nuevas tecnologías. Como resultado, la retención de ese mayor condicional es una tarea separada. El stack tecnológico elegido al inicio del proyecto puede convertirse en un bloque que dificulte el desarrollo del producto.
Conclusión
La próxima vez, hablaremos de cómo la gente intentó resolver estos problemas pasando a componentes y SOA.
Lee mas: