Hoy en día, parece que todo el mundo habla de microservicios. Muchos afirman que su plataforma de software es una plataforma de microservicios y (la mayoría) de los demás afirman que están en camino.
¿De qué están hablando todos? Y sobre todo, ¿hay algo que hayamos aprendido que podamos aplicar en este nuevo dominio? Creo que sí.
Expliquemos primero los principios básicos de la arquitectura de un software de microservicios.
Como con cualquier abstracto, sea nuevo o no, altamente hablado sobre el paradigma, la tecnología o el concepto, podrías pedirle a diferentes personas que te lo expliquen y obtener diferentes respuestas.
Sin embargo, la mayoría de las respuestas se relacionarán con las siguientes ideas y características, que describiré aquí.
Despliegue independiente
Para empezar, un microservicio debe ser desplegable independientemente . Su sistema de software puede ser desplegado como un todo, pero no es obligatorio. Los servicios (microservicio) pueden ser agregados (y removidos) del sistema mientras se está ejecutando. Un microservicio debe ser desplegado con sus dependencias, si las hay (por ejemplo, base de datos, componentes de terceros).
Modularidad
Cada microservicio es una pieza de código única , que se ejecuta en su proceso separado , posiblemente alojado en una máquina separada de otros microservicios. Siendo parte de un «rompecabezas» más grande, que sirve a los objetivos de la empresa – es responsable de proporcionar una única «pieza» o «funcionalidad» al sistema.
Comunicación
Los microservicios, cuando son necesarios, deben comunicarse con el «mundo exterior» (por ejemplo, otros microservicios) utilizando un mecanismo de comunicación bien definido, estándar y ligero.He visto (y escrito) sistemas en los que los servicios exponen sus puntos finales sólo a través de HTTP/REST (con Json) y sistemas en los que los microservicios se comunican sólo a través de colas. Y una mezcla de estos, también. Sea cual sea la forma que elija, mantener el «orden» con respecto a los estándares de comunicación va a ser crucial para su éxito.
Tamaño
Lo guardé para el final, aunque quizás esperabas que hablara del «tamaño» primero, como el nombre » micro servicio» sugiere.
El tamaño de un microservicio es algo controvertido. Daré varias opiniones y mencionaré la mía propia. Más adelante, al agregar los principios sólidos a la discusión, tendrá las herramientas para hacer su propia opinión.
La primera opinión es que un microservicio debe ser tan «grande» como sea necesario para realizar la tarea para la que fue diseñado pero no «más grande».
Sin embargo, algunos diseños de sistemas podrían requerir un gran número de microservicios, al adherirse a esta recomendación. Eso se traduce en un gran número de procesos, que tienen sus propios gastos generales.
Ahora bien, si usted está trabajando en un sistema que tiene un requisito para poder funcionar como una solución AIO, podría estar limitado por una «descomposición» demasiado granular de su sistema en procesos.
Sólo algo para tener en cuenta.
Una segunda opinión es que el tamaño de los microservicios está relacionado con el tamaño de su equipo. Según esta opinión, debería construir los microservicios en un tamaño tal que un solo equipo de desarrollo debería ser capaz de mantenerlo.
Ahora bien, si bien este enfoque puede tener beneficios de gestión a corto plazo, no estoy de acuerdo con él y prefiero la primera opción, ya que creo en mantener el diseño del software libre de conocimientos sobre el «mundo exterior».
Por lo tanto, recomiendo el primer enfoque: hacer su microservicio tan grande como sea necesario para realizar la tarea en cuestión. No más grande.