Recentemente, conduzi um projeto de migração que uniu eficiência, modernização e redução total de custos. A missão era clara: mover todas as Azure Functions e Container Apps de um cliente para Kubernetes, sem reescrever código, e usando apenas recursos gratuitos disponíveis via créditos GCP.

🎯 O desafio

O cliente rodava sua stack em Azure Functions Premium + Azure Container Apps. O custo médio mensal era de £6.000 e os créditos da Azure estavam acabando.

A stack era baseada em eventos de Storage Blob que disparavam o processamento de arquivos. Nossa meta:

• Reduzir drasticamente os custos;
• Manter o código das functions intacto;
• Tornar a arquitetura multi-cloud e agnóstica;
• Utilizar créditos disponíveis no GCP;
• Manter a experiência serverless com escalabilidade automática.

🛠️ Solução

Optei por mover toda a stack para Kubernetes, utilizando o KEDA como motor de escalabilidade baseada em eventos — que, aliás, é usado internamente pela própria Microsoft para escalar Azure Functions.

Toda a infraestrutura foi provisionada com Terraform, e a estratégia de implantação seguiu uma abordagem GitOps baseada em Blueprints, com ArgoCD estruturado como App of Apps.

✅ Etapas do projeto

1. Containerização das Azure Functions Apenas criei Dockerfiles compatíveis com o runtime de Azure Functions. ➕ Nenhuma modificação no código-fonte.

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS installer-env

COPY . /src/dotnet-function-app
RUN cd /src/dotnet-function-app && \
mkdir -p /home/site/wwwroot && \
dotnet publish *.csproj --output /home/site/wwwroot

FROM mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

ENV TZ=Europe/London
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

EXPOSE 80 10000 10001 10002

COPY --from=installer-env /home/site/wwwroot /home/site/wwwroot

1. Provisionamento

Terraform: Toda a parte de recursos de cloud — K8s clusters, VPC, Nat Gateways, etc, helm do ArgoCD e External secrets.

GitOps com ArgoCD App of Apps: External DNS, Metrics Server, Ingress nginx, ArgoCD, Prometheus, Grafana, Actions Controller, KEDA, Metabase, Cert Manager, Reloader, SonarQube

O Bootstrap do ambiente

No Ambiente HUB
O Terraform cria o rede, cluster, e componentes de Rede, instala o ArgoCD e external secrets,e cria a app of apps no ArgoCD, após isso todo o restante é configurado

Nos Ambientes de Workloads
O Terraform cria os componentes de Rede e o Cluster, quando é realizado o Sync no App of Apps do Workload, toda a estrutura é configurada no cluster.

Se utilizar Crossplane compositions ao inves de terraform o Bootstrap fica no GitOps e ArgoCD pra tudo dos workloads, inclusive os resources de cloud.

Passos

1. Ambiente inicial na Azure (AKS)
   
   Para validação inicial:

   • Subi cluster AKS;
   • Implantei ArgoCD e criei um approach App of Apps;
   • Configurei pipelines CI/CD no
   • Instalei e configure o KEDA integrado com Azure Storage Queue;
   • Usei blueprint GitOps para controlar todos os manifests.

2. Migração para GCP (GKE)
   
   Após validação, repliquei a infraestrutura no GKE, utilizando os créditos do GCP.
   
   ✅ Resultado: stack completa rodando sem custo mensal.

3. Triggers com KEDA
   
   O KEDA escutava o Azure Blob Storage diretamente, usando ScaledObject com blobTrigger.

4. Manutenção do Azure Storage (baixo custo)
   
   O Blob Storage permaneceu na Azure por questões de integração legada, mas gerando menos de £10 por mês.

5. GitOps com ArgoCD + App of Apps
   
   A estrutura baseada em blueprints versionados em Git permitiu replicar ambientes de forma segura, auditável e reproduzível.

6. Escalabilidade inteligente
   
   A combinação KEDA + GKE Cluster Autoscaler garantiu escalabilidade automática e econômica, mantendo o comportamento serverless.

Gitops Approach

Blueprints:

O que são GitOps Blueprints (e como usei em um projeto real)

Se você já trabalhou com GitOps, deve ter percebido que chega um momento em que começa a repetir estruturas e configurações entre ambientes (dev, prd, stg...).

É aí que entram os GitOps Blueprints: modelos reutilizáveis de infraestrutura e aplicações, versionados em Git, que te ajudam a padronizar e automatizar o provisionamento completo de clusters Kubernetes (ou similares).

🔧 O que é um GitOps Blueprint?

Um GitOps Blueprint é como um template de infraestrutura + aplicações que pode ser reaplicado em diferentes ambientes ou clusters com poucas mudanças.

Basicamente, você define:

• Componentes base (KEDA, Prometheus, Grafana, etc);
• Configurações parametrizáveis via Helm ou Kustomize;
• Estrutura de ambientes (ex: DEV, PRD, QA);
• E deixa tudo versionado no Git.

A automação fica por conta de ferramentas como:

• ArgoCD
• FluxCD
• Terraform (opcional, para provisionamento de infra)

💡 Quando usar?

Você deve usar GitOps Blueprints quando:

✅ Precisa criar múltiplos ambientes com a mesma stack;

✅ Quer aplicar boas práticas de IaC e GitOps;

✅ Busca portabilidade entre clouds (Azure, GCP, AWS);

✅ Precisa versionar tudo que está sendo implantado no cluster;

✅ Trabalha com multi-tenant ou multi-cluster setups.

Utilizei applicationsets do ArgoCD podendo usar kustomize, helm ou manifestos raw na mesma aplicação argo, utilizando o approach multiple sources

Main App of Apps

Infrastructure app of Apps

Workloads App of Apps

📁 Estrutura de repositório GitOps Blueprints

terraform
 ├──hub (Terraform code para o HUB)
 └──workloads (Terraform code para os Workloads usando TF Workspaces)
gitops
 ├── applicationsets (argo applicationsets for infrastructure)
 │   ├── infrastructure-azure (applicationsets for Azure)
 │   ├── infrastructure-gcp (applicationsets for GCP)
 │   └── workloads (argo applicationsets for workloads)
 ├── helm-chart (generic template helm chart)
 │   └── templates
 │       └── tests
 └── kustomize
     └── infrastructure
         ├── cert-manager (cert manager overlays)
         │   |── gcp
         │   |   ├── dev
         │   |   ├── hub
         │   |   └── prd
         │   └── azure
         │       ├── dev
         │       ├── hub
         │       └── prd
         ├── external-dns (external DNS overlays)
         │   ├── azure
         │   │   ├── dev
         │   │   ├── hub
         │   │   └── prd
         │   └── gcp
         │       ├── dev
         │       ├── hub
         │       └── prd
         ├── ingress-nginx (Ingress nginx overlays)
         ├── metabase (metabase objects)
         ├── metrics-server (Metrics Server overlays)

ArgoCD applicationset usado para instalar o KEDA em multiplos ambientes

O uso do applicationset ajuda a manter a aplicação instalada em multiplos ambientes e cluster, um applicationset pode ser usado para instalar uma ou várias aplicações em multiplas clouds e workloads

https://argo-cd.readthedocs.io/en/latest/user-guide/application-set/

Scaled Object

https://keda.sh/docs/2.15/reference/scaledobject-spec/

💰 Resultado final

🧠 Lições aprendidas

• O KEDA é confiável, maduro e realmente pronto para produção.
• Arquitetura cloud-native com GitOps e Terraform permite portabilidade real entre clouds.
• Kubernetes não precisa ser caro: com estratégia e créditos certos, ele pode custar zero.
• Muitos sistemas legados podem ser migrados sem reescrita de código — só mudando a forma como são executados.
• Blueprints + ArgoCD oferecem governança e replicabilidade de ambientes em escala.
• Se Usarmos um Crossplane o blueprints fica totalmente resiliente e o provisionamento fica muito rápido, ficando uma estrutura totalmente GitOps

Se você curtiu esse conteúdo ou está pensando em migrar workloads para Kubernetes, me chama no LinkedIn 👋