Como garantir consistência entre novos microsserviços?

Minha organização está passando por uma explosão de microsserviços. Atualmente, não temos uma maneira formalizada de inicializar novos projetos. Estou descobrindo que uma equipe me procurará com um bug no processo de implantação ou compilação, e gastarei tempo apenas para perceber que já o resolvi em outro projeto. Também há muita inconsistência entre os projetos que eu gostaria de ver padronizados.

As mudanças geralmente envolvem um único arquivo (por exemplo, serverless.yml ou um Makefile), portanto, uma solução que envolve bibliotecas compartilhadas, por exemplo, sub-módulos git, não parece viável. Cada projeto terá seu próprio conjunto de configurações que precisa ser mantido, por exemplo, Dockerfiles ou serverless.yml, para que soluções de gerenciamento de configuração centralizadas para VMs não sejam realmente aplicáveis.

Como posso garantir que os novos microsserviços estejam em conformidade com os padrões da organização e incluam correções / recursos de projetos existentes de uma maneira fácil e intuitiva para desenvolvedores que desejam iniciar novos projetos? Quais são algumas das práticas recomendadas para resolver esses problemas?

O fluxo de trabalho atual que temos é perguntar à pessoa ao seu lado "de que projeto devo clonar para usar como modelo?" e exclua todas as coisas que não são necessárias para esse projeto.

Vou adicionar uma resposta de qual é a minha solução até agora, mas ainda estou realmente interessado em saber como outras organizações estão resolvendo esse problema e as melhores práticas que possuem.

Para resolver o problema de não ter uma base consistente para a criação de projetos, minha idéia é criar um repositório (repositórios?) De clichês / modelos e usar o cookiecutter como uma ferramenta para desenvolver novos microsserviços. Dessa forma, cada projeto é criado a partir de uma base padrão com todas as lições que aprendemos como organização integrada a ele. Quaisquer alterações que fizermos podem ser integradas a montante no repositório padrão. Imagino que teremos modelos para imagens do Nodejs Docker, SPAs sem servidor, lambdas em Python etc.

Para resolver o problema das alterações feitas nos modelos que são propagadas a jusante para cada projeto, minha solução é implementar um processo em que os proprietários de microsserviços são informados das alterações no modelo e são responsáveis ​​pela propagação dessas alterações em seus microsserviços.

Use um sistema de gerenciamento de configuração / implantação automatizada. É para isso que eles foram projetados. Coisas como Kubernetes, Puppet, Chef, Ansible e Salt Stack são projetadas para esse fim e podem ser utilizadas com modelos Golden Master, scripts de kickstart, Amazon AMIs ou apenas um contêiner Docker. Isso permite usar modelos de base padrão e, em seguida, colocar camadas em funções adicionais. Isso garantirá que as compilações sejam documentadas completamente (como código) e será rápido e fácil de implantar na produção, e será implantado exatamente de forma idêntica ao que foi projetado ou implantará instâncias adicionais quando surgir a necessidade de escalabilidade ou redundância ou algo quebrar. Alterações / atualizações também podem ser integradas dessa maneira. Assim como você libera atualizações de software, você pode liberar atualizações para sua configuração e o código de configuração pode ser gerenciado da mesma forma que o código do software é gerenciado - nos mesmos repositórios e com os mesmos fluxos de trabalho. E quando chegar a hora da atualização, não há mistério em como a coisa é criada, basta olhar para o script.

Uma maneira de os sistemas de gerenciamento de configuração fazerem isso é através do uso intenso de modelos para seus arquivos de configuração. Por exemplo, geralmente existem muitas linhas que serão iguais ou semelhantes no seu ambiente. O SaltStack utiliza modelos jinja e o fantoche usa modelos Embedded Ruby . Usando a AWS como exemplo, pode ser necessário definir uma chave api, função do IAM, região (ou selecionar aleatoriamente uma região de uma lista de regiões), uma VPC, etc, que seja a mesma em todas as instâncias. Mas então você precisa ter suas funções e saídas exclusivas. Ou melhor ainda, você pode escrever um módulo fantoche ou fórmula de sal que defina "contratos" e use esses contratos (definições da API) para entradas e saídas, evitando que você precise configurar seus microsserviços em dois ou três locais.

O SaltStack, por exemplo, recentemente teve uma reunião para discutir esse cenário específico . Além disso, o SaltStack também é capaz de gerenciar e implantar contêineres de docker nativamente . (O Puppet também possui um módulo para o Docker ) Da mesma forma, o Ansible possui playbooks e documentos para trabalhar com implantações sem servidor e contêineres do Docker .

Além disso, se você deseja continuar com o seu tema / paradigma sem servidor, Puppet , Ansible e saltstack são todos sem mestre ou suportam um modo sem mestre, se desejar continuar com esse tema.

Essa pergunta é ampla, portanto, se minha resposta for um pouco fora da base, fique à vontade para adicionar contexto e exemplos específicos para que eu tenha uma melhor compreensão.

O uso de uma imagem de máquina como a AMI da AWS permitiria criar uma imagem base ou dourada, que você poderia manter, distribuir ou implementar em sua entrega contínua. Usando essa arquitetura, você garante que todos os microsserviços sejam implantados em hardware consistente com configuração idêntica, para que todos os problemas que você enfrenta estejam relacionados à configuração do microsserviço / aplicativo.

Você pode aumentar ainda mais essa imutabilidade com a adição de ferramentas de configuração, como Ansible e Packer. Usando o gerenciamento de configuração, você pode provisionar a imagem da máquina com o que quiser (incluindo o aplicativo). O Packer permitiria tirar uma foto instantânea dessa imagem da máquina e cada implantação seria idêntica.

Usando este exemplo, você pode "assar" uma AMI base com os pacotes, atualizações e configurações corretas instalados com a ajuda do Ansible e do Packer. Além disso, você pode consultar 'Ansible-Pull' para concluir a implantação, puxando o código do aplicativo, fazendo as alterações e implantando o microsserviço na parte superior da imagem base.

No entanto, o conselho mais importante que posso dar é apresentar uma solução que toda a organização possa apoiar e manter. Vale a pena tentar estabelecer um SDLC que resolva seu conjunto específico de problemas, combine a cultura e a atitude da liderança e abraça as práticas modernas de arquitetura.

Estive em três organizações e adotamos três abordagens muito diferentes.

Boa sorte!