Separação do source da aplicação da definição de infraestrutura

[ribaptista]

Normalmente uma aplicação bem escrita comunica-se com seus backing services (databases, auth providers etc) através de abstrações de classes (interfaces). Isto possibilita que, através de uma simples mudança na configuração, uma mesma aplicação possa usar:

• tanto um database Postgres quanto um Mysql como backend de dados;
• Okta ou Cognito para autenticação via openid;
• RabbitMQ ou SQS para comunicação assíncrona;
• Redis ou Memcached para caching etc.

Portanto, como pode ser possível anexar os requerimentos de infraestrutura ao repositório da aplicação sem introduzir acoplamento com tipos de backing services específicos (mysql, postgres etc)? Imagino que ao definir os requisitos de infraestrutura da aplicação (na pasta deploy, via terraform) seja necessário especificar o tipo de banco de dados (mysql ou postgres?), o tipo de servidor de cache (redis ou memcached?) etc.

Dito isso, sugiro que o codebase da aplicação (sources em go, node etc) esteja em um codebase separado do código de automação de infraestrutura (terraform).

Desta forma, o mesmo codebase da aplicação pode ser instalado em um cliente X (que usa Postgres e Redis), quanto em um cliente Y (que adota Mysql e Memcached).

O codebase da aplicação seria único e genérico (como qualquer software open source). Os codebases de deploy conteriam a infraestrutura e os detalhes de configuração (dev/qa/prod) de cada cliente/ambiente onde a aplicação foi instalada.

[vflopes]

Primeiramente, muito obrigado, muito bem feitas suas observações, vou só expressar alguns questionamentos para validarmos mais ainda a melhor solução:

Portanto, como pode ser possível anexar os requerimentos de infraestrutura ao repositório da aplicação sem introduzir acoplamento com tipos de backing services específicos (mysql, postgres etc)?

Concordo, mas todos os arquivos no repositório dizem respeito à aplicação ou também dependências da aplicação? Trago essa reflexão para considerarmos a função de um go.mod/Makefile, requirements.txt/setup.py ou package.json como fazendo parte da aplicação, especificando às vezes drivers para backing services, logo, suas dependências.

Imagino que ao definir os requisitos de infraestrutura da aplicação (na pasta deploy, via terraform) seja necessário especificar o tipo de banco de dados (mysql ou postgres?), o tipo de servidor de cache (redis ou memcached?) etc.

Sim seria preciso, da mesma forma que quando for subir ela terá que escolher algum cloud provider.

Mas entendo que o contexto é importante.

Então podemos fazer o seguinte:

• Um repositório para a definição da action (terraform-action)
• Um repositório para a definição dos módulos por provider (terraform-gcp, terraform-aws)

Então poderíamos ter os repositórios em um cenário assim:

• meu-servico-a - que depende de terraform-action e terraform-gcp
• meu-servico-b - que depende de terraform-action e terraform-aws
• minha-infra-compartilhada - que depende de terraform-action, terraform-gcp e terraform-aws

Assim reduzimos o contexto dos codebases em um único propósito.

---

Sobre o segundo ponto do mapeamento do ambiente, pensando em developer experience, pretendo utilizar o lower(nome da branch) como nome do ambiente, realizando um mapeamento direto de uma branch para um apply. Isso vai aumentar muito a qualidade de controle do ambiente em nuvem e integração de forma declarativa com as especificações nos codebases.

[vflopes]

Acabei de renomear esse repositório (terraform-modules => terraform-action) e criar mais dois para a PoC da minha proposta:

• artisan-shared-resources - onde teremos as declarações de infraestrutura compartilhada.
• terraform-gcp - onde teremos as abstrações do GCP.

Caso validemos essa solução podemos partir para o próximo desafio que é o gerenciamento de configuração e pipeline de continuous delivery de uma aplicação serverless.

[vflopes]

https://github.com/UpperGit/artisan-shared-resources/runs/1433700361?check_suite_focus=true

Deu certo :star_struck:

Agora vou atualizar as documentações para o novo modelo.

@ribaptista aguardo seu feedback!

[vflopes]

Acredito que ainda faltem alguns ajustes de nomenclatura (alguns nomes podem passar o limite de 63 caracteres do GCP, temos que ver alguma opção para truncar).

Observe que o main- prefixa os recursos, esse é o nome da branch.