Post Top Ad

Your Ad Spot

jueves, 20 de agosto de 2020

¿Cuál es la diferencia entre monolitos y microservicios?

En el mundo de la programación, hay pocos términos tan discutidos (y mal entendidos) como monolitos y microservicios . A menudo posicionado como un precedente y un antecedente en competencia, la relación entre los dos conceptos es más complicada de lo que parece.
Hoy vamos a definir qué son los monolitos y los microservicios. También veremos algunas ventajas y desventajas de ambos, así como discutiremos la tendencia actual del movimiento empresarial hacia los microservicios desde la perspectiva de la complejidad de la base de código.

¿Qué es un monolito?

El monolito se considera un "método clásico" de desarrollo de servicios. El paradigma en sí es un vestigio de la era de los mainframes y los clientes, donde las interfaces individuales dependían de una única aplicación empaquetada distante en un mainframe. Este mainframe era abrumadoramente poderoso en comparación con los sistemas relativamente raídos de esa época. Con un sistema único y poderoso en la red que atiende a múltiples clientes, solo tenía sentido desarrollar en una pila vertical .
Es mejor pensar en los monolitos como una solución no distribuida . En este paradigma de diseño, todo existe en un solo cuerpo, con las bases de datos, la aplicación y la interfaz ocupando una posición dependiente. La interfaz de usuario, la lógica empresarial, los soportes de datos y las aplicaciones existen como una sola entidad dentro de la red más amplia. En la práctica, esto esencialmente significa que un monolito es una entidad autónoma , una estructura gigante con todo en construcción lineal.
Sin embargo, el problema con el enfoque monolítico es que nada es verdaderamente modular. Desde el principio, el objetivo fue desarrollar un servicio especialmente diseñado para proporcionar una función. Se prestó poca atención a la idea de dividir estos componentes en piezas individuales reutilizables. La principal advertencia negativa es que el monolito presenta mayores dificultades a medida que aumentan la complejidad del problema y la capacidad de cálculo. En cierto punto, el monolito puede volverse demasiado grande y difícil de manejar.
Además, tener una sola máquina haciendo lo que muchas máquinas distribuidas pueden hacer (y posiblemente mejor) se convierte en un desperdicio en una era de pequeños dispositivos de computación de alta potencia. Sin embargo, el enfoque monolítico tiene algunos aspectos positivos, razón por la cual todavía domina los círculos del desarrollo.

¿Qué es un microservicio?

La arquitectura de microservicio se concibió en parte para resolver los problemas subyacentes de un enfoque monolítico centralizado. En pocas palabras, los microservicios se distribuyen . Un problema central que subyace al enfoque monolítico es que todo está centralizado y, como tal, la elección de adoptar microservicios es esencialmente un camino opuesto. Los microservicios son una colección de pequeños servicios, cada uno desarrollado como su propio segmento como parte de un grupo colectivo de servicios. Un microservicio puede ser autónomo, pero normalmente funciona como uno de los muchos servicios que conforman el proceso central general.
Una forma de pensar en la arquitectura de microservicios es imaginar un organismo. Cada parte de la colección de microservicios es un ojo, un dedo, un oído: todos estos órganos especializados funcionan en conjunto entre sí. Si bien es cierto que un ojo puede realizar su función independientemente del resto del cuerpo, es mejor aprovecharlo con otros aspectos del organismo más grande.
Para una analogía más real, imagine el entorno de software de un hotel. Si el hotel estuviera utilizando una base de código monolítica, todo existiría en un solo sistema de silos. El sistema de reservas, la base de datos de los clientes actuales, la entrega de entretenimiento, el servicio a la habitación: todo dependería de un único sistema centralizado y una única interfaz. Esto agregaría cantidades increíbles de complejidad: ¡imagine ser el único desarrollador responsable de todo el código base!
Sin embargo, en un entorno de microservicios, todo se divide en segmentos más pequeños . Si bien el usuario final aún puede usar una única interfaz, sus solicitudes se enrutan al microservicio apropiado según la naturaleza de su aplicación y el resultado resultante. Las partes individuales de ese sistema se pueden cambiar, reutilizar , iterar e incluso reemplazar, sin afectar el medio ambiente total. Las API se aprovechan para la comunicación para permitir que ocurra este desacoplamiento , y cada microservicio representa un alcance definido con una función específica.

Ventajas del monolito

La ventaja más significativa del monolito es que crea un control directo sobre todos los aspectos del servicio. Cuando todo es un solo silo, no hay variaciones. Lo que se le hace al servicio se le hace al servicio en una relación uno a uno . Esto simplifica el desarrollo (al menos al principio), ya que lo único que debe codificarse y desarrollarse es la relación singular entre los componentes del servicio y su interfaz externa.
Además, esto hace que la implementación sea bastante fácil siempre que la implementación sea ​​pequeña. El servicio es una entidad y, como tal, un cambio que afecta a todo el servicio se puede implementar con bastante facilidad. Con un monolito, el escalado horizontal es técnicamente factible y se reduce a "poner más recursos al servicio".
Tener un control total sobre todos los aspectos de un servicio en una forma única y empaquetada es una razón clave por la que los monolitos todavía existen. Los monolitos tienden a ocupar escenarios donde los microservicios distribuidos son demasiado complejos o una exposición demasiado amplia. Por esta razón, los monolitos son más comunes entre los usuarios empresariales de alta seguridad .

Desventajas del monolito

Desafortunadamente, dependiendo del caso de uso, el monolito puede tener muchas más desventajas que ventajas. La implementación y el desarrollo simplificados son válidos cuando la base de código sigue siendo liviana, pero a medida que aumenta la complejidad, también lo hace la dificultad tanto en la administración como en la iteración. A medida que el monolito crece, rápidamente se vuelve demasiado pesado, lo que requiere más recursos y esfuerzo para administrar la funcionalidad principal.
Como resultado, la escalabilidad se ve afectada a medida que aumenta la complejidad. Escalar un monolito es básicamente "dedicar más recursos al problema y equilibrar la carga del resultado", pero esto tiene rendimientos decrecientes. Más concretamente, hay una cantidad limitada de recursos que se pueden dedicar a un problema. En un monolito, la lógica empresarial se refleja en términos de complejidad. Con cada aumento en el volumen de datos, esta complejidad se agrava aún más.
Con un monolito, los cambios en la base de código (ya sea en términos de administración o iteración) generalmente significan una implementación masiva en todo el monolito. Si los desarrolladores no abstraen el código en partes más pequeñas, una actualización singular debe afectar cada punto de los estratos más grandes. Las implementaciones unificadas masivas pueden dañar fácilmente la agilidad y causar lanzamientos más lentos .
Los monolitos también pueden ser difíciles de mantener. Cuando un error afecta un solo aspecto de una base de código monolítica, afecta a todo. Cuando un microservicio fuera de línea puede afectar solo a una o dos aplicaciones, un monolito podría significar un tiempo de inactividad generalizado . Los errores pequeños pueden tener un impacto desproporcionadamente grande y las pruebas para mitigar estos errores se convierten en una carga.

Ventajas del microservicio

El beneficio principal de un enfoque de microservicio es que el costo de implementación, desarrollo e iteración se reduce significativamente con el tiempo. Desplegar elementos en piezas en lugar de como un todo trae muchos efectos prácticos positivos.
En primer lugar, los microservicios aíslan errores . Dado que los servicios están segmentados por diseño, los errores solo afectarán una parte del código base. Por tanto, son más fáciles de arreglar. En general, los microservicios permiten un control más granular. Cada microservicio se puede controlar como una sola entidad, lo que permite reparaciones, iteraciones y actualizaciones más rápidas.
Si bien la complejidad aumenta de hecho debido a la naturaleza de tener muchas partes independientes, la complejidad de codificar un aspecto singular a menudo se reduce. Dado que el proceso de codificación es independiente (o está completamente desacoplado) del ecosistema de microservicios más amplio fuera de los simples ganchos o puntos finales, las interacciones individuales son mucho más sencillas. Si bien las capas adicionales necesarias para habilitar la funcionalidad de microservicio agregan complejidad, a menudo pueden ser más simples que los requisitos inherentes al desarrollo del monolito en sí.
Otro beneficio significativo de los microservicios es la extensibilidad mejorada Imagine tener que reemplazar un juego de llaves cada vez que necesite reemplazar solo una, eso es similar a la experiencia monolítica. En microservicios, si su llave de 10 mm está rota, puede simplemente reemplazar esa llave. Esto también se aplica a la sustitución de tecnologías en el ámbito de los microservicios. Mientras que los monolitos suelen estar vinculados a un único marco tecnológico, los microservicios pueden albergar una amplia gama de tecnologías o lenguajes dentro de un ecosistema. Esto permite una innovación más natural, creación rápida de prototipos y cambios más rápidos en la lógica empresarial.

Desventajas del microservicio

Sin embargo, los microservicios no están exentos de desventajas. Dado que estas advertencias a menudo se subestiman cuando se enmarcan en el monolito, merecen una consideración específica.
Los microservicios añaden complejidad a las redes . Con los microservicios, debe averiguar cómo se vincula cada servicio entre sí a nivel macro. Si bien el desarrollo de unidades individuales es mucho más simple, el sistema general se vuelve más complejo.
Si esta complejidad es igual, menor o incluso mayor que el monolito, se requiere una investigación de su situación actual. Adoptar microservicios para una aplicación de implementación única y de uso único, por ejemplo, podría ser fácilmente más complicado y justificaría un enfoque monolítico. Todo se reduce al alcance del proyecto En general, los microservicios serán menos complicados a nivel micro, pero igualmente sofisticados en general.
¿Qué pasa con los cambios que afectan a todo un sistema? Un monolito se puede actualizar en su conjunto porque todo está unido inexorablemente. Sin embargo, dado que se distribuye una arquitectura de microservicio, las actualizaciones en todo el sistema (como adoptar una nueva versión de un idioma o protocolo elegido) pueden ser más costosas. Está actualizando tanto el microservicio como las partes interconectadas que hacen que todo funcione. Resolver estos problemas a escala empresarial probablemente requerirá una capa de gestión . La contenedorización y la malla de servicios, por ejemplo, permiten entornos distribuidos y un plano de control unificado.

¿Reemplazarán las tendencias de desarrollo empresarial el paradigma monolítico?

Tendemos a ver el desarrollo monolítico como un precursor de los microservicios. Sin embargo, esto no es del todo exacto. El monolito tiene una razón para existir y, en muchos casos, sigue siendo una solución adecuada. El monolito se hizo popular por una razón: para empezar, sus requisitos eran pequeños y su rendimiento a menudo era excelente debido a la naturaleza de la demanda singular de memoria y procesamiento.
Si bien el monolito se ha vuelto menos popular debido a las dificultades de implementación e iteración, todavía hay muchos casos de uso en los que este es un enfoque apropiado. Sí, un monolito está esencialmente acoplado . Pero, cuando una aplicación está destinado para un solo propósito y ha de ser acoplada, esto no es un punto negativo.
Todavía tiene valor construir un monolito. Por esa razón, es mejor considerar la relación entre monolitos y microservicios similar a los estilos de diseño de API. SOAP, REST, gRPC y GraphQL son enfoques diferentes para diferentes propósitos. Como hemos definido antes , todos estos estilos pueden funcionar bien en sus circunstancias dadas. Del mismo modo, aunque muchos usuarios empresariales se han movido del monolito a la colección de microservicios, no es correcto decir que uno es mejor que el otro.

Conclusión

Los monolitos y microservicios tienen su lugar en el mayor espíritu de diseño de las API y cada uno es apropiado para propósitos particulares. Si bien el monolito ofrece cierta simplicidad y facilidad de desarrollo en lo micro, lo macro a menudo se beneficia de un movimiento hacia los microservicios. El tamaño de la aplicación y los elementos constitutivos cambia los beneficios derivados de cualquiera de las soluciones . Por lo tanto, el alcance del proyecto merece una consideración ardiente al juzgar las dos opciones para cualquier base de código.
¿Qué opinas de los monolitos? ¿Todavía tienen un lugar en el desarrollo moderno o son una reliquia de una época pasada? ¡Háganos saber en los comentarios a continuación!

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas