Definición de Microservicios - manu9/patterns GitHub Wiki

Los Microservicios tienes los siguientes rasgos:

1. Los Microservicios tienen un único propósito funcional

Estos tienen una única responsabilidad de negocio, y deben hacerlo bien. Por lo cual si existen cambios en el negocio/funcionalidad/responsabilidad, esto afectaría solo a un pequeño numero de servicios, preferentemente a un único servicio. Si afecta a muchos, es una buena señal de que nuestros micro-servicios no están bien definidos, si un simple cambio en las definiciones requiere un gran numero de despliegue de micro-servicios, algo anda mal.

El micro-servicio debería ser auto-suficiente y autónomo. Representa una completa unidad de trabajo que puede ser ejecutado en cualquier contexto siempre y cuando sus insumos sean correctos y sus recursos disponibles.

Todos los micro-servicios tienen preocupaciones transversales no funcionales, como revisión de estado (health check), control de excepciones/errores, logging, y métricas de rendimiento. Estas preocupaciones son externas a la responsabilidad del micro-servicio, y debieran ser proporcionadas por la arquitectura de la aplicación y reutilizadas de servicio en servicio.

2. Los Microservicios tienen una interfaz estándar sin importar la tecnología que los implementa (Agnostic Technology)

Muchos servicios web usan RESTful, pero otras interfaces estándar trabajan mientras sean tecnología agnóstica, es decir, no le importan si el servicio web esta escrito en Java, Net, Python o cualquier otro. Los servicios SOAP son tecnología agnóstica y satisfacen este requerimiento.

Las interfaces de tecnología agnóstica son necesarias para conservar la independencia de la pila tecnológica. Esta permite una facil migración a otras tecnologias o versiones, y esto significa menos bloqueo para tu pila tecnologica. Las implementaciones que estan en JAVA EJB o servicios RMI no cuentan como interfaces de microservicios ya que son especificas de JAVA. La arquitectura de microservicios debe liberar la pila tecnologica para poder implementar servicios en cualquier lenguaje.

3. Los Microservicios corren en un proceso independiente

En un mundo Java, esto significa que cada microservicio corre en una JVM independiente. En aplicaciones tradicionales no es poco común desplegar aplicaciones en el mismo contenedor, pero con los microservicios esto no deberia pasar. Los microservicios necesitan ser independientes para poder escalar sus necesidades individuales. Por ejemplo un microservicios puede necesitar 3 nodos en el cluster para satisfacer las necesidades de demanda mientras que otro puede necesitar mas nodos, otro puede necesitar mas memoria u otro puede necesitar ser hospedado en otro host diferente a los demás.

Los microservicios corren en un proceso independiente, ellos pueden ser desplegados o reemplazados sin afectar a ningun otro servicio en el proceso.

4. Los Microservicios son a menudo combinados para proporcionar una funcionalidad completa necesaria por la aplicación

Como los microservicios tienen un enfoque tan estrecho, ningún microservicio único puede proporcionar toda la funcionalidad necesaria para la mayoría de aplicaciones. Vamos a ver que es común que los microservicios dependan de otros microservicios para cumplir su funcionalidad. la siguiente figura muestra como se apalancan los microservicios para proporcionar una funcionalidad completa de la aplicación.

Vemos que cada microservicio tiene su propia base de datos. Esto elimina el acoplamiento a nivel de base de datos y asegura que cambiar la estructura de la base de datos no impacte a mas de un servicio. Vemos que la autonomía natural de los microservicios permite la elección de diferentes tecnologías.