[PT-BR](https://hetrodo.dev/blog/post/hetrododev--estrutura-e-funcionamento-ptbr-8eb88b51f6) [EN-US](https://hetrodo.dev/blog/post/hetrododev--structure-and-inner-workings-enus-863cd66df2) Já passei por várias reestruturações e provedores diferentes ao longo dos anos, já paguei caro em maquinas virtuais, mas recentemente estruturei minhas aplicações de uma forma barata e eficiente que pretendo manter por um bom tempo.  >Diagrama da estrutura atual (09/2023), todos os códigos fontes se encontram no GitHub, e são implantados automaticamente no [Cloud Run](https://cloud.google.com/run?hl=pt-br) com a ajuda da minha CI/CD que fica no [CircleCI](https://circleci.com/), os serviços que se encontram na google (Cloud Run, Artifact Registry e o Domain Mappings) são mantidos utilizando o [Terraform](https://www.terraform.io/). ## Entendendo a fundo O serviço "api.hetrodo.dev", assim como a maioria dos outros serviços, é uma API Restful, desenvolvido em [NodeJS](https://nodejs.org/en) com o framework [NestJS](https://nestjs.com/), o código fonte fica em um repositório privado do GitHub linkado a uma pipeline no [CircleCI](https://circleci.com/). Quando o [CircleCI](https://circleci.com/) identifica que alterações foram enviadas para o repositório ele gera uma nova imagem Docker com as alterações, que é enviada automaticamente para o [Artifact Registry do GCP](https://cloud.google.com/artifact-registry?hl=pt-br) e implantada logo em seguida na respectiva instância do [Cloud Run](https://cloud.google.com/run?hl=pt-br) . >Basicamente todas as APIs e serviços seguem esse mesmo fluxo, porém quando se trata dos sites, uma manobra a mais é realizada. Tomando o site "hetrodo.dev" como exemplo, quando alterações são enviados para seu repositório privado no GitHub, assim como nas APIs, o CircleCI gera uma nova execução na pipeline, porém ao invés de criar uma imagem Docker logo de cara, ele pega os arquivos estáticos do site que foram gerados na execução e envia para outro repositório especial chamado "hetrodo-nginx-docker", que como é possivel de se imaginar pelo seu nome, lá temos uma imagem Docker com um servidor do NGINX, meu [proxy reverso](https://www.f5.com/pt_br/glossary/reverse-proxy#:~:text=Um%20proxy%20reverso%20%C3%A9%20usado,e%20inspe%C3%A7%C3%A3o%20profunda%20de%20conte%C3%BAdo.), a partir disso o fluxo se torna bem parecido com o dos serviços, o [CircleCI](https://circleci.com/) detecta esses novos arquivos do site, gera uma imagem Docker que é enviada para o [Artifact Registry](https://cloud.google.com/artifact-registry?hl=pt-br) e é implantada na instancia "hetrodo-nginx" no Cloud Run, aonde todos domínios dos sites apontam e são roteados pelo NGINX. Essa "manobra" de enviar os arquivos para outro repositório faz com que a implantação demore mais o menos o dobro do tempo (que está em torno de 3 minutos), porém facilita na bastante ao criar um novo WebApp ou a publicar um site ou protótipo rapidamente, já que um único servidor central para distribuição de arquivos já existe e é necessário apenas fazer o apontamento do domínio e o envio dos arquivos. ### Custo O trafego mensal dos meus sites são bem baixos para não dizer que são nulos, porém estão online sempre que acessados, tirando quando eu esqueço de pagar a Google (desculpa ai 😅). Sabendo disso a maior parte do valor que eu pago mensalmente vem do armazenamento das imagens Docker no Artifact Registy, eu não tenho a necessidade de manter essas imagens, mas ainda não tenho uma automação para limpar elas depois de um tempo, porém imagino que meu custo cairia com isso. Então levando em consideração esses dois pontos e depois de validar essa estrutura por mais de um ano, posso dizer que meu custo mensal fica em torno de cinco reais (R$ 5,00), mas imagino que caso eu tivesse um bom trafego isso aumentaria em alguns centavos. (É possível fazer uma estimativa com essa [calculadora de custos da google](https://cloud.google.com/products/calculator))