Hash - Desafio de Arquitetura

Clique aqui para acessar o desafio.

Projetos relacionados com a implantação do rollout:

terraform-google-cloud-network: Responsável por provisionar a infraestrutura de rede no Google Cloud para o nosso Kubernetes Engine cluster;
terraform-google-kubernetes-engine: Responsável por criar nosso Kubernetes Engine cluster e os node pools para nossas aplicações;
Monolith: Aplicação que será dividida em dois microserviços independentes, Cart e Checkout;
Cart: Microserviço reponsável pelo carrinho de compras;
Checkout Microserviço reponsável por finalizar a compra.

Abordaremos o canary deployment para realizar o rollout transparente das aplicações, e para isso, utilizamos o Istio como gerenciador da implantação;
Front-end já está desacoplado do Monolith;
Demais microserviços que compõe a aplicação completa já são contenerizados, executados no Kubernetes e configurados com Istio;
Alguns microserviços que dependem do Cart e Checkout serão atualizados no decorrer da migração, mais especificamente, os apontamentos para os services do Kubernetes;
Utilizamos infraestrutura como código com Terraform em projetos distintos entre infraestrutura e aplicação;
Utilizamos o conceito de GitOps para a implementação dos nossos projetos;
Fluxo contínuo de implementação com alguma suposta ferramenta de CI/CD e com pipeline configurada no próprio repositório do código, ativada via branch "main";
Organização e projeto criados no Google Cloud, e com billing account ativo;
Cloud Resource Manager API e Container API habilitados na Cloud;
Database única para o serviço monolith;
Quebramos o Cart e Checkout em dois microserviços independentes;
Não abordaremos a migração dos dados nos projetos.

Terraform;
Google Cloud;
Google Kubernetes Engine;
Docker;
Istio configurado a partir de addons (beta) via Terraform, sem Kiali e Grafana (tínhamos a opção de provisionar via Helm ou manifests do Kubernetes).

Identificamos os módulos e dependências da funcionalidade de /cart dentro do Monolith, tal como comunicação entre os demais serviços, e tabelas/estrutura de banco de dados;
Criamos um novo projeto no GitHub com o código da nova funcionalidade de /cart (API) e refatoramos para uma nova versão do Monolith para adaptar-se à nova estrutura. Assim, temos um novo microserviço utilizando um banco de dados desacoplado da infraestrutura do Monolith e pronto para receber requisição dos demais serviços, lembrando que será necessário refatorarmos os demais serviços que consomem o atual Monolith para apontarem para a nova API;
Com as novas versões atualizadas e no ar, realizamos o rollout do tipo canary, configurando o Istio para realizar o traffic shifting de 95% para o Monolith e 5% para o novo microserviço que passa a lidar com as requisições do /cart. A partir deste momento, desde que bem monitorado e sem impacto no funcionamento das aplicações, aumentamos o traffic shifting até chegar em 100% do direcionamento para o Cart;

Name		Name	Last commit message	Last commit date
Latest commit History 9 Commits
images		images
README.md		README.md