¿Cómo puedo garantizar la coherencia entre los nuevos microservicios?

Mi organización está experimentando una explosión de microservicios. Actualmente no tenemos una forma formal de impulsar nuevos proyectos. Estoy descubriendo que un equipo vendrá a mí con un error en su proceso de implementación o construcción, y dedicaré tiempo solo para darme cuenta de que ya lo resolví en otro proyecto. También hay mucha inconsistencia entre los proyectos que me gustaría ver estandarizados.

Los cambios a menudo involucran un solo archivo (por ejemplo, serverless.yml o un Makefile), por lo que una solución que involucra bibliotecas compartidas, por ejemplo, submódulos git no parece viable. Cada proyecto tendrá su propio conjunto de configuración que debe mantenerse, por ejemplo, Dockerfiles o serverless.yml, por lo que las soluciones de administración de configuración centralizada para máquinas virtuales no son realmente aplicables.

¿Cómo puedo asegurarme de que los nuevos microservicios se ajusten a los estándares de la organización e incluyan correcciones de errores / características de los proyectos existentes de una manera que sea fácil e intuitiva para los desarrolladores que desean comenzar nuevos proyectos? ¿Cuáles son algunas de las mejores prácticas para resolver estos problemas?

El flujo de trabajo actual que tenemos es preguntarle a la persona a su lado "¿de qué proyecto debería clonar para usar como plantilla?" y luego elimine todo lo que no es necesario para ese proyecto.

Agregaré una respuesta de cuál es mi solución hasta ahora, pero todavía estoy realmente interesado en escuchar cómo otras organizaciones están resolviendo este problema y las mejores prácticas que tienen.

Para resolver el problema de no tener una base coherente para crear proyectos, mi idea es crear un repositorio (¿repositorios?) De plantillas / plantillas y usar cookiecutter como una herramienta para construir nuevos microservicios. De esta manera, cada proyecto se crea a partir de una base estándar con todas las lecciones que hemos aprendido como organización integradas en él. Cualquier cambio que hagamos se puede integrar en el repositorio estándar. Me imagino que tendremos plantillas para imágenes de Nodejs Docker, SPAs sin servidor, Python lambdas, etc.

Para resolver el problema de los cambios realizados en las plantillas que se propagan aguas abajo para cada proyecto, mi solución es implementar un proceso donde los propietarios de microservicios estén al tanto de los cambios en la plantilla y luego sean responsables de propagar esos cambios a su microservicio.

Utilice un sistema de gestión de configuración / implementación automatizada. Para esto fueron diseñados. Cosas como Kubernetes, Puppet, Chef, Ansible y Salt Stack están diseñadas para este propósito y pueden utilizarse con plantillas Golden Master, scripts kickstart, AMI de Amazon o simplemente un contenedor Docker. Esto le permite usar plantillas base predeterminadas y luego superponer roles adicionales. Esto garantizará que las compilaciones se documenten completamente (como código) y será rápido y fácil de implementar en producción, y se implementará exactamente de manera idéntica a lo que se diseñó o implementará instancias adicionales cuando surja la necesidad de escalabilidad o redundancia o algo se rompa. Los cambios / actualizaciones también se pueden integrar de esta manera. Justo cuando publicas actualizaciones de software, puede lanzar actualizaciones a su configuración y el código de configuración se puede administrar tal como se administra su código de software, en los mismos repositorios y con los mismos flujos de trabajo. Y cuando llegue el momento de la actualización, no hay misterio de cómo se construye la cosa, solo mire el script.

Una forma en que los sistemas de administración de configuración hacen esto es a través del uso intensivo de plantillas para sus archivos de configuración. Por ejemplo, generalmente hay muchas líneas que serán iguales o similares en su entorno. SaltStack utiliza plantillas jinja y el títere utiliza plantillas Embedded Ruby . Usando AWS como ejemplo, es posible que deba establecer una clave, API, rol de IAM, región (o seleccionar aleatoriamente una región de una lista de regiones), una VPC, etc., que es lo mismo en todas las instancias. Pero entonces necesita tener sus funciones y salidas únicas. O mejor aún, podría escribir un módulo títere o una fórmula de sal que defina los "contratos" y usar esos contratos (definiciones de API) para las entradas y salidas evitando que tenga que configurar sus microservicios en dos o tres lugares.

SaltStack, por ejemplo, recientemente tuvo una reunión para discutir este escenario en particular . Además, SaltStack también puede administrar y desplegar contenedores acoplables de forma nativa . (Puppet también tiene un módulo para Docker ) Asimismo Ansible tiene libros de jugadas y documentos para trabajar con implementaciones sin servidor y contenedores Docker .

Además, si desea continuar con su tema / paradigma sin servidor, Puppet , Ansible y saltstack no tienen master o admiten un modo sin master, si desea continuar con este tema.

Esta pregunta es amplia, así que si mi respuesta está un poco fuera de lugar, siéntase libre de agregar contexto y ejemplos específicos para que tenga una mejor comprensión.

El uso de una imagen de máquina como la AMI de AWS le permitiría crear una imagen base o dorada, que luego podría mantener y distribuir o implementar en su entrega continua. Al usar esta arquitectura, se asegura de que cada microservicio se implemente en hardware consistente con una configuración idéntica, de modo que cualquier problema que enfrente esté relacionado con la configuración del microservicio / aplicación.

Puede promover esta inmutabilidad con la adición de herramientas de configuración como Ansible y Packer. Con la administración de la configuración, puede aprovisionar la imagen de la máquina con lo que desee (incluida la aplicación). Packer le permitiría tomar una instantánea de la imagen de esa máquina y cada despliegue sería idéntico.

Con este ejemplo, podría 'hornear' una AMI base con los paquetes, actualizaciones y configuración correctos instalados con la ayuda de Ansible y Packer. Además, puede mirar 'Ansible-Pull' para completar la implementación al extraer el código de la aplicación, realizar cualquier cambio e implementar el microservicio encima de esa imagen base.

Sin embargo, el consejo más importante que puedo dar es simplemente encontrar una solución que toda la organización pueda apoyar y mantener. Vale la pena intentar establecer un SDLC que resuelva su conjunto particular de problemas, coincida con la cultura y la actitud de liderazgo, y abrace las prácticas modernas de arquitectura.

He estado con tres organizaciones y hemos tomado tres enfoques muy diferentes.

¡Buena suerte!