Microservice Architecture | Arquitectura de microservicios

Qué es Arquitectura de microservicios?

 

El estilo arquitectónico de microservicios es un enfoque para desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno de los cuales se ejecuta en su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP.

El hecho de que los servicios son implementables y escalables de manera independiente, cada servicio también permite que se escriban diferentes servicios en diferentes lenguajes de programación. También pueden ser gestionados por diferentes equipos.

Las aplicaciones creadas a partir de microservicios pretenden ser lo más desacopladas y cohesivas posible: poseen su propia lógica de dominio y actúan más como ltros en el sentido clásico de que reciben una solicitud, aplican la lógica según corresponda y producen una respuesta.

Un servicio es una funcionalidad que se expone para su uso por otros procesos. 

Que otros protocolos puedo usar en los microservicios:

Middleware es un software que se ubica entre otro software y facilita las comunicaciones entre ellos.

los recursos utilizados  se pueden almacenar en caché con muy poco esfuerzo por parte de los desarrolladores o el personal de operaciones.

otro enfoque de uso común es la mensajería a través de un bus de mensajes ligero. La infraestructura elegida es típicamente tonta (tonta, ya que solo actúa como un enrutador de mensajes); las implementaciones simples como RabbitMQ o ZeroMQ no hacen mucho más que proporcionar una estructura asincrónica confiable: la inteligencia aún vive en los puntos finales que están produciendo y mensajes de consumo; en los servicios

Los microservicios prefieren dejar que cada servicio administre su propia base de datos, ya sea diferentes instancias de la misma tecnología de base de datos o sistemas de bases de datos completamente diferentes, un enfoque llamado Polyglot Persistence (plicaciones deberían escribirse en una combinación de idiomas para aprovechar el hecho de que diferentes idiomas son adecuados para abordar diferentes problemas)

El enfoque común para hacer frente a las actualizaciones ha sido utilizar transacciones para garantizar la coherencia al actualizar múltiples recursos.  Elegir gestionar las inconsistencias de esta manera es un nuevo desafío para muchos equipos de desarrollo, pero a menudo coincide con la práctica empresarial. A menudo, las empresas manejan un cierto grado de inconsistencia para responder rápidamente a la demanda.

Control de Errores y Monitoreo

Una consecuencia del uso de servicios como componentes es que las aplicaciones deben diseñarse de modo que puedan tolerar la falla de los servicios. La gestion de los atributos de calidad son vitales en esta arquitectura.

Dado que los servicios pueden fallar en cualquier momento, es importante poder detectar las fallas rápidamente y, si es posible, restaurar el servicio automáticamente. Las aplicaciones de microservicios ponen mucho énfasis en el monitoreo en tiempo real de la aplicación, verificando tanto los elementos arquitectónicos (cuántas solicitudes por segundo recibe la base de datos) como las métricas relevantes del negocio (como cuántos pedidos por minuto se reciben). 

El monitoreo es vital para detectar rápidamente un comportamiento emergente malo para que pueda repararse.

Llamadas sincrónicas consideradas dañinas    

Cada vez que tenga varias llamadas sincrónicas entre servicios, encontrará el efecto multiplicador del tiempo de inactividad. Simplemente, esto es cuando el tiempo de inactividad de su sistema se convierte en el producto de los tiempos de inactividad de los componentes individuales. Usted enfrenta una opción, hacer que sus llamadas sean asincrónicas o administrar el tiempo de inactividad

CONCLUSIONES

1. deben agregarse capas de compatibilidad con versiones anteriores y las pruebas se hacen más complicadas.

Te podría interesar: 

Monolítico vs. Microservicios

¿Cuál arquitectura debo elegir?

Arquitectura de molítica

• Si tu empresa o equipo es pequeño.
• Si quieres un lanzamiento más rápido 

* A pesar que la arquitectura sea monolítica recuerda que las buenas practicas y el uso de patrones se debe si o si realizar ya que vas a necesitar una aplicación estable y fácil de depurar. Además este sistema requerirá más tiempo más adelante para actualizarse, pero el inicio es más rápido.

Arquitectura de microservicios

• Si quieres desarrollar una aplicación más escalable.
• Si su empresa es más grande o planea crecer.

Ventajas e inconvenientes de los microservicios.

Beneficios

• Mejora la escalabilidad y la productividad.
• Se integra bien con sistemas  Legacy
• Desarrollo sostenible
• Funcionalidad cruzada

Inconvenientes

• Más costoso
• Tú catalogo de servicios crecera considerablemente
• La implementación requiere más esfuerzo
• La prueba debe ser independiente
• Difícil de cambiar múltiples microservicios
• La descentralización de la responsabilidad de los datos a través de microservicios tiene implicaciones para administrar las actualizaciones
• Si no se construye limpiamente, se esta trasladando la complejidad y agregando dificultad para controlar.
• Dependes de la habilidad del equipo de desarrollo.

Puedes considerarel siguiente comentario de Martin Fowler: 

"One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. (Although this advice isn't ideal, since a good in-process interface is usually not a good service interface.)"

"Un argumento razonable que hemos escuchado es que no debe comenzar con una arquitectura de microservicios. En su lugar, comience con un monolito , manténgalo modular y divídalo en microservicios una vez que el monolito se convierta en un problema. (Aunque este consejo no es ideal , ya que una buena interfaz en proceso no suele ser una buena interfaz de servicio)."

 

Productos no Proyectos

La mayoría de los esfuerzos de desarrollo de aplicaciones que vemos utilizan un modelo de proyecto: donde el objetivo es entregar algún software que luego se considera completado. Al finalizar, el software se entrega a una organización de mantenimiento y el equipo del proyecto que lo creó se disuelve.

Los defensores del microservicio tienden a evitar este modelo, prefiriendo en cambio la noción de que un equipo debería poseer un producto durante toda su vida útil. Una inspiración común para esto es "usted construye, lo ejecuta", donde un equipo de desarrollo asume toda la responsabilidad del software en producción. Esto pone a los desarrolladores en contacto diario con el comportamiento de su software en la producción y aumenta el contacto con sus usuarios, ya que tienen que asumir al menos parte de la carga de soporte.

Referencias:

https://martinfowler.com/articles/microservices.html