Una de las partes centrales de una arquitectura de microservicio es que cada instancia de un microservicio debe ser idéntica a todas sus demás instancias. No se puede permitir que ocurra un "desvio de la configuración" (algo cambia en un servidor después de que se ha implementado), porque esto puede introducir inestabilidad en las aplicaciones que lo consumen.
Para que esto no suceda debemos integrar la configuración con su infraestructura en el proceso de deployment para que ya no implemente artefactos de software como Java WAR o EAR sino en imagen del servidor virtual. Luego, cuando se deploya el microservicio, se deploya toda la imagen de la máquina virtual. Los patrones que nos ayudan a trabajar de esta manera son :
Build and deployment pipeline : ¿cómo se crea un proceso de implementación y compilación repetible que enfatice las compilaciones y la implementación con un solo botón en cualquier entorno de su organización?
Infraestructura como código: ¿cómo trata el aprovisionamiento de sus servicios como código que se puede ejecutar y administrar bajo el control de versiones?
Servidores inmutables: una vez que se crea una imagen de microservicio, ¿cómo se asegura de que nunca cambie después de que se haya implementado?
Servidores Phoenix: cuanto más tiempo esté funcionando un servidor, mayor será la posibilidad de que la configuración se desvíe. ¿Cómo se asegura de que los servidores que ejecutan microservicios se eliminen de forma regular y se vuelvan a crear a partir de una imagen inmutable?
Nuestro objetivo con estos patrones y temas es exponer y eliminar despiadadamente los cambios de configuración lo más rápido posible antes de que escalen y se descontrole todo.
