Hola, Habr. En este momento, OTUS está aceptando inscripciones para un nuevo grupo del curso . Antes del inicio del curso, quiero compartir con ustedes mi artículo autoral.
Introducción
La elección del estilo arquitectónico es una de las decisiones técnicas fundamentales al construir un sistema de información. En esta serie de artículos, propongo analizar los estilos arquitectónicos más populares para la construcción de aplicaciones y responder a la pregunta de cuándo es preferible un estilo arquitectónico en particular. A lo largo de la exposición, intentaré establecer una cadena lógica que explique el desarrollo de estilos arquitectónicos desde monolitos hasta microservicios.
Un poco de historia
Si intentas preguntar a los desarrolladores: «¿Para qué sirven los microservicios?», recibirás las respuestas más diversas. Escucharás que los microservicios mejoran la escalabilidad, simplifican la comprensión del código, mejoran la tolerancia a fallos, y a veces, se menciona que permiten «limpiar el código». Vamos a remitirnos a la historia para entender qué objetivo perseguía la aparición de los microservicios.
En resumen, los microservicios, en nuestra comprensión actual, surgieron de la siguiente manera: en 2011, James Lewis, al analizar el trabajo de diversas empresas, notó la aparición de un nuevo patrón «micro-app» que optimizaba SOA desde el punto de vista de la aceleración de la implementación de servicios. Un poco más tarde, en 2012, en la cumbre arquitectónica, el patrón fue renombrado como microservicio. Por lo tanto, el objetivo inicial de la implementación de microservicios fue mejorar el famoso time to market.
En la «ola del 'hype'», los microservicios estuvieron de moda en 2015. Según algunas investigaciones, ninguna conferencia se llevaba a cabo sin una presentación sobre microservicios. Además, algunas conferencias se dedicaron exclusivamente a microservicios. Hoy en día, muchos proyectos comienzan utilizando este estilo arquitectónico, y si un proyecto contiene toneladas de código heredado, seguramente está en proceso de migración a microservicios.
A pesar de lo mencionado, todavía hay un número relativamente pequeño de desarrolladores que pueden definir el concepto de «microservicio». Pero de esto hablaremos más adelante...
Monolito
El estilo arquitectónico que se contrapone a los microservicios es el monolito (o "todo en uno"). Explicar qué es un monolito quizás no tenga sentido, así que enumeraré de inmediato las desventajas de este estilo arquitectónico que han impulsado el desarrollo de otros estilos arquitectónicos: tamaño, acoplamiento, despliegue, escalabilidad, fiabilidad y rigidez. A continuación, propongo familiarizarse con cada una de estas desventajas por separado.
Tamaño
El monolito es muy grande y normalmente interactúa con una base de datos muy extensa. La aplicación se vuelve demasiado grande para que un solo desarrollador pueda comprenderla por completo. Solo aquellos que han pasado mucho tiempo con este código pueden trabajar bien con el monolito, mientras que los nuevos gastarán mucho tiempo tratando de entenderlo y no hay garantía de que lo logren. Normalmente, siempre hay algún "senior" (condicional) que conoce el monolito más o menos bien y controla a los nuevos desarrolladores durante un año o año y medio. Naturalmente, este senior condicional es un único punto de fallo, y su salida puede llevar a la caída del monolito.
Acoplamiento
El monolito se asemeja a un "gran bulto de barro" (big ball of mud), donde los cambios pueden tener consecuencias impredecibles. Al realizar cambios en un lugar, se puede dañar el monolito en otro (es como rascarse la oreja y que @* se caiga). Esto se debe a que los componentes del monolito tienen relaciones muy complejas y, lo más importante, poco evidentes.
Despliegue
El despliegue del monolito, debido a las complejas interrelaciones entre sus componentes, es un proceso largo con su propio ritual. Este ritual normalmente no está completamente estandarizado y se transmite "de boca en boca".
Escalabilidad
Los módulos del monolito pueden tener necesidades conflictivas de recursos, lo que obliga a buscar un compromiso en términos de hardware. Imagínese que su monolito consiste en los servicios A y B. El servicio A es exigente en cuanto al tamaño del disco duro, mientras que el servicio B lo es en cuanto a la memoria RAM. En este caso, la máquina en la que se instala el monolito debe satisfacer los requisitos de ambos servicios, o bien será necesario desconectar 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 deseas tener 100 instancias del servicio A y 10 del servicio B. Nuevamente, hay dos opciones: o desplegamos 100 monolitos completos, o en algunos de ellos tendremos que desactivar manualmente los servicios B.
Fiabilidad
Dado que todos los servicios están juntos, si el monolito falla, todos los servicios caen de inmediato. En realidad, esto puede no ser tan malo, al menos no habrá fallos parciales en un sistema distribuido, pero por otro lado, debido a un error en una funcionalidad que utiliza el 0.001% de los usuarios, podrías perder a todos los usuarios de tu sistema.
Rigidez
Debido al tamaño del monolito, es difícil adoptar nuevas tecnologías. Como resultado, se plantea la tarea de retener a ese senior condicional. La pila tecnológica elegida al inicio del proyecto puede convertirse en un obstáculo que impida el desarrollo del producto.
Conclusión
La próxima vez hablaremos sobre cómo las personas intentaron resolver los problemas mencionados al pasar a componentes y SOA.
Leer más:
Fuente: habr.com
