Para comprender los microservicios, debemos comprender qué son las aplicaciones monolíticas y qué nos llevó a pasar de las aplicaciones monolíticas a los microservicios en los últimos tiempos.
Aplicaciones monolíticas
Si todas las funcionalidades de un proyecto existen en un solo código base, entonces esa aplicación se conoce como aplicación monolítica. Todos debemos haber diseñado una aplicación monolítica en nuestras vidas en la que se nos dio un enunciado del problema y se nos pidió que diseñáramos un sistema con varias funcionalidades. Diseñamos nuestra aplicación en varias capas, como presentación, servicio y persistencia, y luego implementamos esa base de código como un único archivo jar/war. Esto no es más que una aplicación monolítica, donde «mono» representa el código base único que contiene todas las funcionalidades requeridas.
Pero si ya estábamos usando aplicaciones monolíticas, ¿qué nos llevó a los microservicios?
Desventajas de las aplicaciones monolíticas:
- Se vuelve demasiado grande con el tiempo y, por lo tanto, difícil de manejar.
- Necesitamos volver a implementar toda la aplicación, incluso para un pequeño cambio.
- A medida que aumenta el tamaño de la aplicación, también aumenta su tiempo de puesta en marcha e implementación.
- Para cualquier nuevo desarrollador que se una al proyecto, es muy difícil entender la lógica de una gran aplicación Monolítica, incluso si su responsabilidad está relacionada con una sola funcionalidad.
- Incluso si una sola parte de la aplicación se enfrenta a una gran carga/tráfico, debemos implementar las instancias de toda la aplicación en varios servidores. Es muy ineficiente y consume más recursos innecesariamente. Por lo tanto, el escalado horizontal no es factible en aplicaciones monolíticas.
- Es muy difícil adoptar cualquier tecnología nueva que sea adecuada para una funcionalidad particular, ya que afecta a toda la aplicación, tanto en términos de tiempo como de costo.
- No es muy confiable, ya que un solo error en cualquier módulo puede derribar toda la aplicación monolítica.
Ventajas de las aplicaciones monolíticas:
- Fácil de desarrollar en relación con los microservicios, donde se requieren desarrolladores calificados para identificar y desarrollar los servicios.
- Más fácil de implementar ya que solo se implementa un único archivo jar/war.
- Relativamente más fácil y simple de desarrollar en comparación con la arquitectura de microservicios.
- Los problemas de latencia y seguridad de la red son relativamente menores en comparación con la arquitectura de microservicios.
- Los desarrolladores no necesitan aprender diferentes aplicaciones, pueden concentrarse en una aplicación.
Microservicios
Es un estilo de desarrollo arquitectónico en el que la aplicación se compone de servicios más pequeños que manejan una pequeña porción de la funcionalidad y los datos comunicándose entre sí directamente mediante protocolos ligeros como HTTP. Según Sam Newman, “Los microservicios son los pequeños servicios que funcionan juntos”.
La arquitectura de microservicios tiene un impacto significativo en la relación entre la aplicación y la base de datos. En lugar de compartir una sola base de datos con otros microservicios, cada microservicio tiene su propia base de datos. A menudo da como resultado la duplicación de algunos datos, pero tener una base de datos por microservicio es esencial si desea beneficiarse de esta arquitectura, ya que garantiza un acoplamiento flexible. Otra ventaja de tener una base de datos separada por microservicio es que cada microservicio puede usar el tipo de base de datos que mejor se adapte a sus necesidades. Cada servicio ofrece un límite de módulo seguro para que los diferentes servicios se puedan escribir en diferentes lenguajes de programación. Hay muchos patrones involucrados en la arquitectura de microservicios, como descubrimiento y registro de servicios, almacenamiento en caché, puerta de enlace API y comunicación, observabilidad, seguridad, etc.
Principios de los microservicios:
- Responsabilidad única: Es uno de los principios definidos como parte del patrón de diseño SOLID. Establece que una sola unidad, ya sea una clase, un método o un microservicio, debe tener una y solo una responsabilidad. Cada microservicio debe tener una única responsabilidad y proporcionar una única funcionalidad. También puedes decir que: la cantidad de microservicios que debes desarrollar es igual a la cantidad de funcionalidades que requieres. La base de datos también está descentralizada y, por lo general, cada microservicio tiene su propia base de datos.
- Construido alrededor de las capacidades comerciales: en el mundo actual, donde existen tantas tecnologías, siempre hay una tecnología que es la más adecuada para implementar una funcionalidad particular. Pero en las aplicaciones monolíticas, fue un gran inconveniente, ya que no podemos usar una tecnología diferente para cada funcionalidad y, por lo tanto, debemos comprometernos en áreas particulares. Un microservicio nunca se limitará a adoptar una pila de tecnología adecuada o un almacenamiento de base de datos de back-end que sea más adecuado para resolver el propósito comercial, es decir, cada microservicio puede usar una tecnología diferente según los requisitos comerciales.
- Diseño para fallas: los microservicios deben diseñarse teniendo en cuenta los casos de fallas. Los microservicios deben explotar la ventaja de esta arquitectura y la caída de un microservicio no debería afectar a todo el sistema, otras funcionalidades deben permanecer accesibles para el usuario. Pero este no fue el caso en las aplicaciones monolíticas, donde la falla de un módulo conduce a la caída de toda la aplicación.
Arquitectura orientada a servicios (SOA) vs arquitectura de microservicios:
Steve Jones, MDM de Capgemini, dijo una vez: «Los microservicios son SOA, para aquellos que saben qué es SOA». Entonces, los que saben de SOA, la mayoría piensa que son lo mismo, o la diferencia no está mucho más clara en su mente. Tampoco les podemos culpar, si hablamos de una tarta y un pastel, encontraremos más similitudes que diferencias. Así que tratemos de entender las diferencias entre los dos.
SOA evolucionó para hacer frente a los problemas de la arquitectura monolítica y se hizo popular a principios de la década de 2000. En SOA, la aplicación grande se divide en varios servicios más pequeños que se implementan de forma independiente. Estos servicios no se comunican entre sí directamente. Solía existir un Enterprise Service Bus (ESB, un middleware o servidor con la ayuda de servicios que utilizan diferentes protocolos o estándares de mensajes que pueden comunicarse entre sí fácilmente) donde estos servicios se exponen y se comunican entre sí a través de él. Además, no había una directriz para tener una base de datos independiente para cada servicio.
La arquitectura de microservicios es una evolución de SOA. La gente también considera a SOA como un superconjunto de microservicios. En términos simples, los microservicios son una SOA detallada. Aquí, los microservicios se comunican entre sí directamente y no existe una dependencia central para la comunicación como ESB en SOA. Además, hay una guía para tener una base de datos separada para cada microservicio. La idea fundamental de la evolución de los microservicios de SOA es reducir la dependencia entre los servicios y hacerlos acoplar libremente con las pautas mencionadas anteriormente.
Ventajas de los microservicios:
- Es fácil de manejar ya que es relativamente más pequeño.
- Si hay alguna actualización en uno de los microservicios, debemos volver a implementar solo ese microservicio.
- Los microservicios son autónomos y, por lo tanto, se implementan de forma independiente. Sus tiempos de puesta en marcha y despliegue son relativamente menores.
- Es muy fácil para un nuevo desarrollador incorporarse al proyecto, ya que necesita comprender solo un microservicio en particular que proporcione la funcionalidad en la que estará trabajando y no todo el sistema.
- Si un microservicio en particular enfrenta una gran carga debido a que los usuarios usan esa funcionalidad en exceso, entonces debemos escalar horizontalmente solo ese microservicio. Por lo tanto, la arquitectura de microservicios admite el escalado horizontal.
- Cada microservicio puede usar una tecnología diferente según los requisitos comerciales.
- Si un microservicio en particular deja de funcionar debido a algún error, entonces no afecta a otros microservicios y todo el sistema permanece intacto y continúa brindando otras funcionalidades a los usuarios.
Desventajas de los microservicios:
- Al ser un sistema distribuido, es mucho más complejo que las aplicaciones monolíticas. Su complejidad aumenta con el aumento de una serie de microservicios.
- Se requieren desarrolladores calificados para trabajar con la arquitectura de microservicios, que puede identificar los microservicios y administrar sus intercomunicaciones.
- La implementación independiente de microservicios es complicada.
- Los microservicios son costosos en términos de uso de la red, ya que necesitan interactuar entre sí y todas estas llamadas remotas generan latencia en la red.
- Los microservicios son menos seguros en relación con las aplicaciones monolíticas debido a la comunicación entre servicios a través de la red.
- La depuración es difícil ya que el control fluye sobre muchos microservicios y señalar por qué y dónde ocurrió exactamente el error es una tarea difícil.