Eu resolvi fazer um experimento, que eu já imaginava que iria funcionar, mas mesmo assim achei válido fazer e compartilhar aqui no blog, pois talvez seja uma ideia nova e útil para alguém. O mais importante é o processo e não o experimento em si. O experimento realizado foi o foi o seguinte, a partir de um desenho de arquitetura como código pedi um assistente de IA para fazer o IaC com Terraform deste desenho. Adivinha o resultado?!!

Em minutos, a infraestrutura estava codificada. Organizada em arquivos. Com security groups, subnets, IAM roles. Tudo estava feito, não usei nenhuma ferramenta secreta. Juntei duas coisas que já existem Diagram as Code e Inteligência Artificial.

E o resultado vem me fazendo repensar como a gente trabalha com infraestrutura. Foi um teste simples, talvez em algo mais complexo não funcionasse tão bem assim, pode ser, mas, não deixa de ser uma indicação de mudança na forma como trabalhamos hoje.

A IA não é futuro, é o presente. O futuro, continua difícil de prever

As pessoas que trabalham com IaC, precisam se atualizar com essas novas ferramentas e passar a incorporar cada vez mais as novas formas de trabalho no seu dia a dia, isso é de grande valor e de suma importância para se manter no mercado profissional.

O experimento

Vou te mostrar todo o processo que realizei.

A partir de um código de um diagrama de uma infraestrutura, “perguntei” para uma IA se conseguiria interpretar um diagrama e gerar Terraform. O exemplo que eu usei, com código real é um fluxo completo, do diagrama ao terraform plan. Mostro também o que funcionou e o que precisa de atenção e ao final, mostro para onde essa combinação de IaC e IA está indo. Se você trabalha com redes, sistemas ou cloud, você precisa dar uma lida nisso.

A rotina de fazer IaC ainda dói

Quem trabalha com cloud já sabe, criar recurso pelo console não funciona a longo prazo. Isso é I-N-D-I-S-C-U-T-Í-V-E-L!!! Você cria um security group hoje, semana que vem, alguém cria outro parecido. Mês que vem, ninguém sabe qual é qual. Alguém tenta replicar o ambiente de staging pra produção e descobre que metade das configurações não estão documentadas.

Terraform, Pulumi, CloudFormation são ferramentas que resolveram boa parte desse problema. A infraestrutura passou a ser descrita em arquivos de texto. Dá pra versionar no Git. Dá pra revisar em pull request. Dá pra destruir e recriar sem medo e com bastante confiança.

Mas vamos ser honestos. Escrever IaC ainda leva tempo para criar e dá trabalho para manter, é preciso estudar e conhecer sintaxe HCL. Precisa saber quais argumentos cada recurso aceita, precisa entender a ordem das dependências, precisa lembrar como configurar um target group, um listener, um subnet group.

É trabalho repetitivo. E trabalho repetitivo é exatamente o tipo de coisa que a IA faz bem. #ficadica #ficaalerta

Diagram as code arquitetura em código Python

Antes de falarmos da IA, preciso te apresentar a biblioteca Diagrams do Python. Tem post no blog sobre isso se você não conhece, vai gostar. A proposta é direta. Você escreve código Python descrevendo componentes de infraestrutura e as conexões entre eles. Roda o script. Sai uma imagem com o diagrama da arquitetura. Sem arrastar caixinha, sem alinhar seta, sem exportar PNG manualmente.

Esse foi o código que usei no meu teste:

from diagrams import Cluster, Diagram
from diagrams.aws.compute import ECS
from diagrams.aws.database import ElastiCache, RDS
from diagrams.aws.network import ELB, Route53

with Diagram("Clustered Web Services", show=False):
    dns = Route53("dns")
    lb = ELB("lb")

    with Cluster("Services"):
        svc_group = [ECS("web1"),
                     ECS("web2"),
                     ECS("web3")]

    with Cluster("DB Cluster"):
        db_primary = RDS("userdb")
        db_primary - [RDS("userdb ro")]

    memcached = ElastiCache("memcached")

    dns >> lb >> svc_group
    svc_group >> db_primary
    svc_group >> memcached

Olha o que está descrito aí:

• Route53 como DNS.
• Um load balancer recebendo o tráfego.
• Três serviços ECS: web1, web2, web3.
• Um cluster de banco com RDS primário e uma réplica de leitura.
• ElastiCache rodando Memcached.
• O fluxo: DNS aponta pro LB, LB distribui pros serviços, serviços acessam banco e cache.

Rodei o script. Saiu um PNG com tudo isso desenhado, limpo, organizado. Pronto pra colocar em documentação ou apresentar pro time. E o mais importante, está em código, versionado. Quando a arquitetura mudar, eu atualizo o script e o diagrama acompanha.

Até aqui, nada de IA. Mas foi o próximo passo que mudou, se liga só.

A IA lê o diagrama as code e gera o Terraform

Peguei o código Python do diagrama e passei pra IA. Pedi pra ela analisar os componentes, entender as relações e gerar o Terraform correspondente.

Ela fez exatamente isso. Não veio um template genérico. Veio código que reflete a arquitetura descrita no diagrama. Cada componente mapeado. Cada conexão traduzida em configuração.

O que a IA gerou:

• Rede — Uma VPC com CIDR definido. Duas subnets públicas e duas privadas, em zonas de disponibilidade diferentes. Internet Gateway pra tráfego externo. NAT Gateway pra que os recursos privados acessem a internet. Route tables configuradas.

• Security Groups — Separados por camada. O do ALB aceita tráfego HTTP de qualquer origem. O do ECS só aceita tráfego vindo do ALB. O do RDS só aceita conexão vindo do ECS. O do ElastiCache, a mesma coisa. Cada um no seu escopo.

• Load Balancer — Um Application Load Balancer nas subnets públicas. Target group apontando pros containers. Listener na porta 80 encaminhando pro target group.

• ECS — Um cluster Fargate. Uma task definition com a configuração do container. Três serviços — web1, web2, web3 — cada um rodando uma task. Todos registrados no target group do ALB.

• RDS — Instância MySQL 8.0 como primária. Uma réplica de leitura apontando pra ela. Ambas nas subnets privadas, protegidas pelo security group.

• ElastiCache — Cluster Memcached com um nó, rodando nas subnets privadas. Porta 11211. Acesso restrito ao security group do ECS.

• Route53 — Hosted zone com o domínio. Registro A do tipo alias apontando pro DNS do ALB.

Tudo separado em arquivos: network.tf, security_groups.tf, alb.tf, ecs.tf, rds.tf, elasticache.tf, route53.tf, variables.tf, outputs.tf.

Enquanto gerava fiquei olhando aquilo e pensando, quanto tempo eu levaria pra escrever tudo isso na mão? Uma hora? Duas? Dependendo do dia, mais. A IA levou segundos.

Veja o fluxo completo, passo a passo

Deixa eu organizar para vocês o que aconteceu, o fluxo é mais simples do que parece.

Passo 1: Escrevi o diagrama em Python. Listei os componentes, defini a relação dos componentes e descrevi as conexões com os operadores >> e -.

Passo 2: Rodei o script com python3 diagrama_as_code_cluster.py. Um arquivo PNG foi gerado com o diagrama. Serve pra documentação, pra apresentar pro time, pra discutir arquitetura em reunião.

Passo 3: Passei o código do diagrama pra IA e pedi: “lê esse diagrama e gera o Terraform na AWS”, poderia ser Azure ou GCP sem problemas

Passo 4: A IA devolveu os arquivos .tf com toda a infraestrutura mapeada e organizada. Com variáveis pra dados sensíveis. Com outputs pros endpoints.

Passo 5: Copiei os arquivos pra uma pasta Terraform/. Criei o terraform.tfvars com os valores. Rodei terraform init e terraform plan.

Do diagrama ao plano de execução e criação da infra. Sem pular etapa. Mas sem perder tempo com o trabalho que se repetitivo.

Umas das saídas geradas.

cat  ./Terraform/network.tf
data "aws_availability_zones" "available" {}

##
## NÃO UTILIZAR ESSE CÓDIGO
##

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "${var.project}-vpc" }
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
  tags = { Name = "${var.project}-public-${count.index}" }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 10)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  tags = { Name = "${var.project}-private-${count.index}" }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "${var.project}-igw" }
}

resource "aws_eip" "nat" {
  domain = "vpc"
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id
  tags          = { Name = "${var.project}-nat" }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
  tags = { Name = "${var.project}-public-rt" }
}

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }
  tags = { Name = "${var.project}-private-rt" }
}

resource "aws_route_table_association" "public" {
  count          = 2
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table_association" "private" {
  count          = 2
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private.id
}

O Que Funcionou e onde ter cuidado

Esse fluxo sem a menor sobre de dúvida traz ganhos, veja o que eu percebi de ganho concreto.

• Tempo a parte de escrever HCL deixou de ser gargalo. Sobrou mais tempo pra pensar na arquitetura, discutir trade-offs, avaliar custos.

• Documentação que acompanha o código o diagrama e o Terraform nascem da mesma fonte. Não tem aquele problema de alguém mudar a infra e esquecer de atualizar o desenho no Confluence, já nasce junto.

• Barreira de entrada, alguém que entende de arquitetura mas não domina Terraform consegue contribuir. Monta o diagrama em Python, a IA gera a base, o time de infra revisa e ajusta.

• Aprendizado se você está estudando Terraform, ver o código gerado a partir de um diagrama que você entende ajuda a conectar os conceitos.

• Consistência, a IA aplicou separação de security groups por camada, usou variáveis pra dados sensíveis, colocou recursos de banco e cache em subnets privadas. Coisas que às vezes a gente esquece quando está com pressa.

Onde precisa ter cuidado?

As coisas não são 100% lindas :) com a IA, vja alguns pontos de atenção que eu tenho visto que são bem importantes.

• Revisão não é opcional a IA entrega um ponto de partida. Mas os tipos de instância podem não servir pro seu cenário. Uma instância que funciona pra teste, pode não funcionar pra produção. Você precisa olhar cada recurso e avaliar se faz sentido.

• Entendimento continua sendo seu a IA não substitui saber como as coisas funcionam. Por que o NAT Gateway está ali? Quanto ele custa por mês? Por que o RDS está numa subnet privada e não pública? Se você não souber responder essas perguntas, o código gerado vira uma caixa mágica.

• Dados sensíveis. o Terraform gerado usa variáveis do tipo sensitive pra senhas. Isso é o certo. Mas cabe a você garantir que o terraform.tfvars não vá parar num repositório público. Parece óbvio, parece raro mas acontece frequência.

• Produção pede mais o código gerado é uma base. Pra rodar em produção de verdade, você vai precisar de monitoramento com CloudWatch, alarmes, backups automatizados, multi-AZ no RDS, auto scaling no ECS, certificado SSL no ALB. A IA entrega a estrutura. Você complementa conforme a necessidade do ambiente.

• Custos cada recurso gerado tem um custo na nuvem. NAT Gateway, ALB, RDS, ElastiCache tudo entra na conta. Antes de rodar terraform apply, vale passar o plano por uma calculadora de custos pra não ter surpresa no fim do mês. Lembe-se a AI não está nem aí para os custos se você não mencionar nada no prompt.

Pra onde isso vai

Honestamente é difícil afirmar. Essa junção de IaC e IA está no começo e o começo já está assim. Mas o futuro vai ter IA, vai ter Agents de IA fazendo IaC, skills de IA verificando IaC, vai ter IA com IaC isso já dá para afirmar.

Hoje, a IA lê um diagrama em Python e gera Terraform, vocês viram o exemplo do post. Já existe AI para sugerir mudanças na arquitetura apontar falhas no seu security group. Vai avisar que você pode trocar um componente X por um outro Y e economizar, a IA vai te recomendar uma arquitetura multi-AZ antes de você lembrar de pedir.

Não acho que a IA vai substituir quem trabalha com infra. O contexto do negócio, as decisões de arquitetura, a avaliação de risco isso continua sendo coisa de humano. Mas a parte de traduzir decisões em código, de escrever o HCL, de lembrar a sintaxe de cada recurso essa parte a IA faz bem, e faz rápido.

Jovem, não entre em pânico achando que você vai perder o emprego semana que vem, isso não vai acontecer, fique calmo. Mas #ficadica, comece JÁ!!, não espere, não perca tempo, estude conceitos, ferramentas e faça testes!! Uma outra coisa, que se pode fazer, olhe para os seus processos de hoje e faça a seguinte pergunta, “Em qual dessas etapas IA pode me ajudar a melhorar algo real, se eu a colocar no pipeline??”.

Quem incorporar a IA no fluxo de trabalho de hoje resolvendo problemas reais vai conseguir entregar mais valor para o seu produto e para a sua empresa. Isso já te coloca um passo a frente mas siga dando outros passos.

Abraços!

Vida longa e próspera a todos!!

Referências

• https://infraascode.com.br/diagrama-as-code/
• https://infraascode.com.br/diagrama-as-code-com-chatgpt-p2/
• https://diagrams.mingrammer.com/docs/nodes/c4
• https://www.pulumi.com/
• https://www.crossplane.io/

Entre em contato: