# Rafael Ferreira — orafaelferreira.com
> Rafael Martin Alves Ferreira é um Platform Engineer e especialista em Cloud Azure & DevOps com mais de 10 anos de experiência. Microsoft MVP Azure, MCT (Microsoft Certified Trainer), DevOps Institute Ambassador, Alura Star, Green Software Champion e Platform Engineering Ambassador. Baseado em Florianópolis, Brasil. Mentor, palestrante e criador de conteúdo técnico sobre Azure, DevOps, FinOps e Platform Engineering.
Notas importantes:
- Nome completo: Rafael Martin Alves Ferreira. Também conhecido como: Rafael Ferreira, orafaelferreira
- Especialidades principais: Microsoft Azure, Platform Engineering, DevOps, FinOps, Terraform, AKS, CI/CD, Observabilidade
- Idiomas: Português (pt-BR) é o idioma primário; todo o site está disponível em inglês via `?lang=en`
- Site estático (React + Vite, pré-renderizado no build) hospedado no Azure Static Web Apps; todo o conteúdo está no HTML, sem depender de JavaScript
## Perfil e Bio
- [Home — Bio completa](https://www.orafaelferreira.com/): Apresentação, habilidades técnicas, especialidades e parceiros
- [Prêmios e reconhecimentos](https://www.orafaelferreira.com/premiacoes): Microsoft MVP Azure, MCT, DevOps Institute Ambassador, Alura Star, Green Software Champion, Platform Engineering Ambassador
- [Experiência profissional](https://www.orafaelferreira.com/experiencias): Histórico de trabalho em empresas multinacionais e consultorias
## Mentoria
- [Mentoria Cloud Azure e DevOps](https://www.orafaelferreira.com/mentoria-cloud-devops): Mentoria 1:1 individual com Microsoft MVP Azure. Sessão única de 1h a 1h30 (sem recorrência, sem assinatura). Inclui formulário diagnóstico pré-sessão, plano de ação personalizado de 6 a 12 meses, suporte assíncrono contínuo via contato direto e acesso a grupo exclusivo de vagas com recomendação direta a recrutadores.
Formato da mentoria em detalhes:
- Etapa 1 — Pagamento via plataforma com opções de parcelamento
- Etapa 2 — Formulário diagnóstico: mentorado descreve desafios técnicos, objetivos profissionais e metas de carreira
- Etapa 3 — Sessão 1:1 de 1h a 1h30: reunião estratégica baseada no diagnóstico, foco em decisões concretas e plano de ação
- Etapa 4 — Plano de ação escrito para 6–12 meses + suporte assíncrono contínuo
Descontos por perfil: Open to Work (40% off), Júnior (30% off), Pleno (20% off), Sênior (10% off). Comprovante obrigatório para desconto.
Serviços disponíveis: mentoria individual, revisão de perfil LinkedIn, template de currículo.
Para quem é: profissionais de tecnologia (iniciantes ou experientes) que estudam Cloud Azure e DevOps e não sabem o que priorizar — quais tecnologias estudar primeiro, quais certificações valem, como se destacar no mercado e ter oportunidades chegando até você.
## Artigos e Blog
- Índice resumido: https://www.orafaelferreira.com/llms.txt
- Este arquivo contém o texto integral de 92 publicações, da mais recente para a mais antiga.
## Certificações e Credenciais
- [Programas e reconhecimentos](https://www.orafaelferreira.com/certificacoes): MVP, MCT, DevOps Institute Ambassador, Alura Star, Green Software Champion, Platform Engineering Ambassador
- [Certificados técnicos](https://www.orafaelferreira.com/certificados): 20+ certificações Microsoft (AZ-104, AZ-204, AZ-305, AZ-400, AZ-500, AZ-700 e mais), Kubernetes e outras
## Palestras e Comunidade
- [Palestras](https://www.orafaelferreira.com/palestras): Histórico de talks em KCD, Global Azure, DevOpsDays Floripa, CNCF SC e outros eventos
- [Recomendações](https://www.orafaelferreira.com/recomendacoes): Depoimentos de pares, mentorados e líderes da indústria
## Links externos
- [LinkedIn](https://www.linkedin.com/in/orafaelferreiraa/): Perfil profissional principal
- [GitHub](https://github.com/orafaelferreiraa): Projetos open source e código público
- [YouTube — LowOps](https://www.youtube.com/@LowOps): Conteúdo em vídeo sobre Cloud, DevOps e Platform Engineering
- [LowOpsCast no Spotify](https://open.spotify.com/show/0U4kcZT2Cwn4CqQGg4Ywcj): Podcast técnico
- [Instagram](https://www.instagram.com/orafaelferreira1/): Conteúdo curto e comunidade
## Optional
- [llms-full.txt](https://www.orafaelferreira.com/llms-full.txt): Texto integral de todos os artigos e posts em Markdown
- [Feed RSS](https://www.orafaelferreira.com/rss.xml): Feed full-text com todos os artigos e posts
- [Sitemap completo](https://www.orafaelferreira.com/sitemap.xml): Todas as URLs indexáveis do site
- [Perfil MVP Microsoft](https://mvp.microsoft.com/en-us/PublicProfile/5005188): Perfil oficial como Microsoft MVP
---
# De NGINX Ingress para Envoy Gateway: a migração que a IA liderou
URL: https://www.orafaelferreira.com/artigos/nginx-envoy-gateway
Publicado: 2026-09-05
Categoria: Artigos
Tags: IA, DevOps, Docker
Tempo de leitura: 14 min de leitura
> Como um controller próprio migrou Ingress NGINX para Gateway API sobre Envoy Gateway em Kubernetes multi-tenant, com a IA liderando testes e auditoria.
Quase todo texto sobre trocar de ingress controller fala da arquitetura de destino: por que [Gateway API](https://gateway-api.sigs.k8s.io/), por que [Envoy](https://gateway.envoyproxy.io/), como fica o novo modelo de recursos. Esse aqui fala de outra coisa, menos explorada: **como a migração foi de fato executada**, com um agente de IA operando num loop estruturado em vez de uma pessoa dirigindo cada passo na mão.
### Resumo rápido
- Plataforma Kubernetes multi-tenant sob NDA. Nada de nome de empresa, cluster, tenant ou repositório. O que generaliza é o formato do problema.
- Existe um **controller próprio** que converte continuamente Ingress de classe `nginx` em `HTTPRoute`, `GRPCRoute` e `TLSRoute` ligados a um Envoy Gateway compartilhado.
- A decisão mais importante veio **antes do código**: para toda annotation nginx em uso, o time decidiu o que aconteceria com ela, convertida, redundante, sem efeito, ou marcada para trabalho manual, nunca deixada para trás em silêncio.
- Snippet de nginx é traduzido em regime **tudo ou nada**. Tradução parcial é modo de falha pior que tradução nenhuma.
- O achado que salvou o dia 1 não tem nada a ver com Envoy: dezenas de serviços montavam URL de redirect de OAuth a partir de um header não-padrão que **nunca existiu** naquele ambiente.
- O mecanismo do loop em si, hooks, skills, subagentes verificadores, escada de verificação, eu já detalhei em [Loop Engineering na prática](/artigos/loop-engineering-na-pratica). Aqui ele aparece em recap curto, e só desce ao detalhe onde a aplicação é específica desta migração.
### O problema da migração
O ambiente é uma plataforma Kubernetes multi-tenant sob NDA. O que interessa e generaliza para qualquer time fazendo essa migração é a forma do problema, não os nomes.
Existe um controller que converte, de forma contínua, Ingress de classe `nginx` em recursos de Gateway API ligados a um Envoy Gateway compartilhado. Ele envolve o projeto open source [kubernetes-sigs/ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway) e acrescenta quatro camadas em cima:
- **Rebind de `parentRef`**, para que a rota gerada aponte para o Gateway compartilhado certo em vez do que a conversão padrão inferiria.
- **Parsing de snippet nginx**, o config livre embutido em annotation.
- **Derivação de policy**, quando o comportamento não cabe na rota e precisa virar objeto de política no nível do Gateway. É a mesma ideia que eu defendi em [Platform Engineering e Policy-as-Code que aceleram times](/artigos/platform-engineering-policy-as-code), só que aqui a política não é escrita à mão, ela é derivada de uma annotation legada.
- **Cobertura total de annotation**, que é o assunto da próxima seção e a decisão mais importante do projeto inteiro.
Vale dizer o óbvio que às vezes se perde: a conversão não é um script que roda uma vez. É um controller em reconciliação, porque os times donos das aplicações continuam criando e editando Ingress nginx enquanto a migração acontece. Migração de verdade não tem freeze.
### O primeiro passo: um assessment da frota inteira
Antes de desenhar qualquer contrato, tinha uma pergunta mais básica: **o que a frota realmente usa?** Não a lista de annotations que a documentação do nginx descreve, a lista real, encontrada em produção, com toda variação que cada time introduziu ao longo do tempo.
Foi o primeiro passo do projeto, e não teve nada de manual nele. Um agente varreu todos os Ingress de todos os workloads da frota, um a um, e extraiu cada annotation encontrada, onde ela aparecia, em qual workload, em qual namespace. O resultado saiu num `.csv`, não num documento, porque o próximo passo era justamente decidir, entrada por entrada, para onde cada annotation ia na tradução para Gateway API.
Esse `.csv` é o que faz o contrato da próxima seção ser honesto. Sem ele, a lista de annotations a cobrir teria sido "as que a gente lembrou", montada de memória por quem já trabalhou com o ambiente. Com ele, é "as que existem de verdade", incluindo a annotation rara que um time usou uma vez, dois anos atrás, e que ninguém mais tinha em mente. É o mesmo problema, na escala do assessment inteiro, que o contrato resolve annotation por annotation: o que não é visto, desaparece calado.
### O contrato de cobertura: cinco categorias e nada fora delas
Antes de escrever qualquer código de conversão, a pergunta que precisava de resposta era: **o que acontece com uma annotation que o conversor não conhece?**
A resposta preguiçosa é ignorar e seguir. É também a resposta que faz a migração parecer um sucesso até alguém descobrir, três semanas depois, que o rate limit sumiu.
A saída foi fechar essa lacuna antes de escrever código: para toda annotation `nginx.ingress.kubernetes.io/*`, o time definiu de antemão qual das cinco categorias abaixo ela ocupa, **sempre uma, nunca zero**.
| Categoria | O que significa | Quem resolve |
|---|---|---|
| Convertida | Virou campo de um recurso real de Gateway API | O conversor |
| Coberta por policy | Não cabe na rota, virou objeto de política no Gateway | O conversor |
| Coberta por borda upstream | O comportamento já é entregue por uma camada antes do cluster | Ninguém, é redundância |
| No-op comprovável | Não faz nada naquele contexto, e dá para provar | Ninguém, com evidência |
| `Unconvertible` | Precisa mesmo de trabalho manual | Uma pessoa, avisada |
A quinta categoria é o que faz o contrato valer. **Sem uma categoria explícita para "isso não dá", tudo que não dá vira silêncio.** `Unconvertible` não é derrota, é o mecanismo que transforma um desconhecido em item de trabalho com nome.
O ganho prático de escrever isso antes: o agente não tem espaço para inventar uma quarta via. A instrução não é "converta o que der", é "coloque cada entrada numa categoria e não sobre nada". Objetivo verificável em vez de objetivo simpático.
### Snippet é tudo ou nada
Snippet de nginx é o caso mais desagradável, porque não é uma annotation com valor conhecido, é um pedaço de configuração livre embutido numa string.
A regra que vale a pena copiar: **um snippet só é traduzido quando todos os diretivos dentro dele são reconhecidos.** Nunca nove décimos.
O motivo é o modo de falha, não a pureza. Um snippet traduzido pela metade **parece funcionar**, e continua parecendo funcionar até o dia em que o diretivo que ninguém portou se revela a checagem de autenticação. Um snippet não traduzido, marcado `Unconvertible`, é um problema visível numa lista. É a diferença entre uma pendência e uma armadilha.
A mesma lógica vale para regra de rewrite e qualquer coisa baseada em diretivo. **Tradução parcial é modo de falha pior que tradução nenhuma**, porque destrói o sinal que te avisaria.
### O que o loop virou neste projeto
#### O hook que protege o RBAC gerado
O hook genérico eu já expliquei no artigo anterior. O que muda aqui é o alvo: o RBAC do operator é gerado a partir de marcadores `+kubebuilder:rbac` no código, e editar o arquivo gerado à mão é trabalho que o gerador apaga em silêncio na próxima execução.
```bash
#!/usr/bin/env bash
## PostToolUse — pega edição manual num arquivo de RBAC gerado, antes que ele seja sobrescrito.
set +e
payload="$(cat)"; [ -z "$payload" ] && exit 0
file="$(printf '%s' "$payload" | jq -r '.tool_input.file_path // empty')"
case "$file" in *config/rbac/role.yaml) ;; *) echo '{"continue":true}'; exit 0 ;; esac
if git diff --quiet -- "$file" 2>/dev/null; then
echo '{"continue":true}'; exit 0
fi
printf 'Guardrail: %s e gerado a partir dos marcadores +kubebuilder:rbac.\n' "$file" >&2
printf 'Rode `make manifests` em vez de editar a mao, o gerador sobrescreve isso na proxima execucao.\n' >&2
exit 2 # o stderr volta para o contexto do agente
```
Duas coisas que só a prática ensina, e que valem para qualquer hook desse tipo. Primeira: ele **estreita o escopo antes de opinar**, dispara num arquivo só, não em todo YAML do repositório. Segunda: a mensagem diz **o que fazer**, não só o que está errado. Feedback acionável fecha o loop numa iteração; feedback vago gasta três.
#### A skill do converter: "isto NÃO é um operator genérico"
A skill deste projeto tem uma linha que eu considero a mais valiosa dela, e não é um passo de procedimento, é uma negação:
```markdown
---
name: ingress-converter-operator
description: >
Convenções de trabalho do conversor nginx para Gateway API: regras de git,
build/test/deploy, e decisões de arquitetura já resolvidas por investigação
anterior. Use ao editar internal/converter/* ou internal/controller/*.
Este NÃO é um operator de CRD genérico feito com kubebuilder,
não use `kubebuilder create api` aqui.
---
### Quando usar
### Build e teste
### Limitações conhecidas (leia antes de reinvestigar)
```
Sem a linha de desambiguação, o agente alcança o padrão genérico de scaffolding de Kubebuilder num projeto que deliberadamente arrancou tudo aquilo fora. Ele não está errado por burrice, está errado porque o padrão mais provável do mundo, dado o formato do repositório, é exatamente o que este projeto não é. Dizer o que a coisa **não** é custa uma linha e economiza um dia.
E a última seção importa tanto quanto o procedimento. **"Limitações conhecidas" existe para o agente não reinvestigar "será que dá pra consertar?"** em algo que uma sessão anterior já resolveu que não dá. Sem ela, cada sessão nova paga de novo o custo da mesma investigação, e chega na mesma conclusão, e não deixa registro. O agente esquece, o repositório não.
### Onde a escada encosta na realidade: o degrau que precisa de data plane
Os cinco degraus da escada de verificação estão no artigo anterior. O que esta migração acrescenta é o motivo de o degrau 4 existir, e ele é bem concreto.
O `envtest` sobe um `kube-apiserver` e um `etcd` de verdade, com os CRDs de Gateway API e de Envoy Gateway vendorizados, não com mocks. Isso prova que a lógica de reconciliação funciona. **E não prova absolutamente nada sobre tráfego**, porque o `envtest` não sobe o data plane do Envoy. Ele não move pacote.
Ou seja: tudo que depende de como um header é de fato reescrito **passa no envtest e falha no mundo**. É o tipo de verde que dá confiança errada.
A correção é um degrau a mais, e o detalhe que faz ele valer é chato de propósito: Envoy Gateway instalado localmente, no Kubernetes que vem no Docker Desktop, com **exatamente os mesmos values de Helm do módulo que provisiona o ambiente real**. Não é o chart com defaults, não é um cluster de brinquedo. É o ambiente de destino em miniatura, porque o que você está testando é justamente a configuração, não o Envoy.
Ao lado dele, um backend que só ecoa os headers que recebeu, e um `curl`. É assim que se confirma que um request HTTP simples atravessando o Envoy chega do outro lado com `X-Forwarded-Proto: https`. Não por leitura de código, não por asserção de unidade. Por observação.
Esse mesmo cluster local também roda o **Gateway API** (os CRDs), não só o Envoy. Motivo: simular o Envoy sozinho prova o rewrite de header, mas não prova que o operator chega até lá do jeito que chegaria em produção. O cluster local simula o operator **rodando**, não só existindo.
Isso é o ponto que vale enfatizar: quanto mais o ambiente local imita o real, Helm values, Gateway API incluído, menos surpresa sobra para o cluster de produção. Teste local que só sobe a aplicação não testa o caminho pelo qual a aplicação chega lá, e esse caminho tem tanta chance de esconder bug quanto o código em si.
Vale registrar também que a imagem do operator **não faz parte do ciclo de iteração**. Editar arquivo, reiniciar o pod com a árvore de código montada por hostPath, ver o efeito em segundos. A imagem é construída pelo serviço de build do registry, depois que o comportamento já está validado. A imagem é o resultado do loop, não uma etapa dentro dele.
### A virada de tráfego é uma operação destrutiva
Remover ou rebaixar um Ingress nginx antigo depois que o equivalente em Gateway API está saudável é, tecnicamente, apagar um recurso de produção. Então ela passa pela mesma trava que qualquer outra operação destrutiva do meu setup: para, pede autorização explícita, e não importa o modo de automação em que eu esteja.
Não repito aqui como a trava é construída, [está detalhada no artigo anterior](/artigos/loop-engineering-na-pratica), incluindo a brecha do modo sem prompt que quase me custou caro. O ponto específico da migração é outro: **a palavra que importa é "sempre"**.
Um cutover é exatamente o momento em que a confiança anda mais rápido que a verificação. O loop vem funcionando bem há semanas, as rotas vêm saindo certas, e a tentação de aprovar no piloto automático é máxima justo quando o custo de errar também é. Esse guardrail não protege contra o agente errar, protege contra **o operador aprovando rápido demais**. Falso positivo aí é preço, não defeito.
### O que a auditoria em fan-out achou antes da virada
Rodar a descoberta com agentes em vez de na mão teve um efeito colateral que sozinho pagou o esforço.
A sweep foi em fan-out, um agente por área da frota, seguida de uma segunda rodada com a instrução **invertida**: não confirme o que já foi achado, tente refutar. E o resultado foi desconfortável.
Dezenas de serviços montavam a URL de redirect de OAuth a partir do header não-padrão `X-Forwarded-Scheme`, com fallback para `X-Scheme`, em vez do padrão `X-Forwarded-Proto`.
Repare no que isso significa. **Nem o nginx nem a borda anterior mandavam esses headers.** Ou seja, aquelas aplicações vinham confiando num header ausente e caindo no default `http` na URL entregue ao provedor de identidade. Funcionava porque nada dependia do valor até o momento em que dependeria.
Mover o tráfego para o Envoy sem tocar nisso teria produzido uma onda de callbacks de OAuth quebrados no dia 1, com root cause que não tem nada a ver com Envoy, num dia em que todo mundo estaria olhando para o Envoy. É o pior formato possível de incidente: sintoma novo, causa velha.
**A rodada de refutação é o que torna esse achado confiável.** O primeiro fan-out voltou com cara de completo, e isso por si só foi suspeito para um ambiente que eu sei que é bagunçado. A passada adversarial achou um item que não existia, um atribuído ao lugar errado, e um marcado como desativado que estava vivo em produção. Nenhum dos três aparece se você pedir para o mesmo agente reler o próprio trabalho, ele vai confirmar o que já acredita.
O fix, uma vez achado, foi pequeno: o controller injeta os dois headers não-padrão, **add-if-absent**, na mesma camada onde já reescreve outros headers de request. Add-if-absent importa, porque quem já manda o header certo não pode ser sobrescrito por compatibilidade retroativa.
### O que o processo não pegou: ReferenceGrant no namespace errado
No interesse de não vender o peixe maior do que ele é: **o processo pega classes de falha, ele não é infalível.** E o caso que escapou é instrutivo justamente porque os testes ficaram verdes o tempo todo.
Backend cross-namespace precisa de um objeto `ReferenceGrant` no namespace de destino para autorizar a rota. O teste de unidade provava, corretamente, que o conversor calculava o namespace de destino certo. E isso **não prova que o controller aplica o objeto lá**.
Um passo de carimbo de namespace em outro ponto do loop de reconciliação sobrescrevia aquele destino em um caso específico, deixando o objeto de autorização válido e inútil, no namespace errado. Unidade verde, comportamento quebrado.
A correção é um teste de integração cobrindo conversor e controller **juntos**, que é exatamente o degrau que a suíte original pulava. Ela está escrita na seção de limitações conhecidas da skill, com nome, não esquecida numa conversa. **Um loop com agente é tão honesto quanto o backlog que ele deixa para trás.**
### Para quem vai fazer essa migração
As recomendações genéricas de loop estão no [outro artigo](/artigos/loop-engineering-na-pratica). Estas são específicas desta migração:
- **Escreva o contrato de cobertura de annotations antes do primeiro código de conversão.** Decida de antemão o que acontece com cada entrada possível, para que nada que você não previu desapareça em silêncio. E tenha uma categoria explícita para "não dá".
- **Trate feature baseada em diretivo como tradução tudo ou nada.** Snippet, rewrite, qualquer config livre. Meia tradução é pior que nenhuma, porque parece que funcionou.
- **Verificação local precisa de data plane de verdade.** Uma API do Kubernetes falsa prova sua lógica de reconciliação; só um cluster rodando a mesma implementação de Gateway com os mesmos values de Helm da produção prova que seu rewrite de header acontece.
- **Audite os headers que suas aplicações consomem antes de virar a borda.** Não os que a documentação delas diz que elas consomem, os que o código realmente lê. E rode uma passada adversarial em cima do resultado, porque a primeira volta sempre parece completa demais.
- **Diga na skill o que o projeto NÃO é.** Se o formato do repositório sugere um padrão comum que não se aplica, escrever a negação custa uma linha e evita que o agente reconstrua o que você arrancou fora de propósito.
- **Trate o cutover como operação destrutiva com autorização explícita.** É o momento em que a confiança está mais alta e o custo de errar também.
### Conclusão
O que me deixou confortável nessa migração não foi a velocidade da conversão. Foi que os pontos onde ela poderia ter falhado em silêncio, annotation ignorada, snippet meio traduzido, header ausente, autorização no namespace errado, viraram itens com nome, seja numa categoria, seja numa lista de limitações conhecidas, seja num teste que ainda falta escrever.
O agente acelerou o trabalho. O que decidiu se ele foi confiável foi o contrato escrito antes dele começar, e a disciplina de tratar todo verde não observado como suspeito.
---
# Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU
URL: https://www.orafaelferreira.com/artigos/dod-ctrb26
Publicado: 2026-08-22
Categoria: Palestras
Tempo de leitura: 7 min de leitura
> Relato da palestra Vibe Coding com DevOps no DevOpsDays Curitiba 2026, com Jéssica Mello: IA para criar o site, Terraform e GitHub Actions para o deploy.
## DevOpsDays Curitiba 2026
No dia **22 de agosto de 2026**, ao lado de [**Jéssica Mello**](https://www.linkedin.com/in/jessica-tmello/) (LowOps Consultoria), palestrei no [**DevOpsDays Curitiba**](https://devopsdays.org/events/2026-curitiba/welcome/), um dos eventos mais tradicionais da comunidade DevOps no Brasil, realizado no **Auditório Eny Caldeira do Campus Rebouças da UFPR**.
### Agenda
**Sessão:** Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU
Um estudo de caso sobre como usei IA generativa para criar meu portfólio pessoal do zero, com Terraform, GitHub Actions e boas práticas de DevOps garantiram que o deploy em produção, fosse feito com controle humano.
### A Jornada: Do Prompt ao Deploy
#### O Problema
Meu portfólio pessoal (orafaelferreira.com) estava desatualizado. Eu precisava de um site moderno, minimalista e rápido, mas sem tempo para desenhar e codar tudo do zero.
#### Tudo Começou com um Prompt
Estruturei um prompt detalhado, seções para Home, Sobre, Blog, Palestras, Mentoria e Contato, guidelines de estilo (tema escuro, tipografia moderna, ícones lineares) e requisitos técnicos (SEO, performance, Markdown), e usei o [**Lovable**](https://lovable.dev/) para gerar **100% via IA generativa** a primeira versão.
O resultado: um site one-page, com design moderno e performance ótima. Só que sair de uma one-page para um blog completo era o próximo desafio.
#### Quando a "Vibe" Encontra a Produção
A modularização começou com refinamento contínuo, via prompts refinados e edição manual estratégica, transformando o one-page em páginas de fato (Home, Sobre, Blog, Palestras, Recomendações).
Mas dois problemas clássicos apareceram: **vendor lock-in** (dependência total da plataforma que gerou o código) e **custos de hospedagem**.
#### Assumindo o Controle: Do Prompt ao Repositório
A solução: exportar o código do Lovable, versionar no [**GitHub**](https://github.com/orafaelferreiraa/orafaelferreira-com), refatorar com [**GitHub Copilot**](https://github.com/features/copilot) e adotar **GitFlow** e versionamento profissional.
`git commit -m 'taking back control'`
#### Hospedagem e Migração para Azure
Com o código sob controle, migrei a hospedagem para a **Microsoft Azure**: escrevo o código → GitHub guarda e testa (CI/CD) → publica no Azure → o domínio (www.orafaelferreira.com) responde. Isso envolveu migração de conteúdo (posts, palestras, projetos), adaptação estratégica de layout e configuração de DNS com downtime mínimo.
#### Infraestrutura como Código com Terraform
Toda a infraestrutura é provisionada 100% via código com [**Terraform**](https://www.terraform.io/): criação do Azure Static Web App, configuração automatizada de DNS e domínio, e execução automatizada via GitHub Actions, garantindo consistência e replicabilidade, no lugar do clássico ClickOps manual e propenso a erros.
A arquitetura final: um Resource Group (`rg-site`) com Azure Blob Storage guardando o state do Terraform, um Azure Static Web App (free tier, `eastus2`) e um domínio customizado (`www.orafaelferreira.com`) com TLS automático e validação DNS via TXT record.
#### O Motor de Entrega: GitHub Actions
O pipeline de CI/CD roda em **push to main**: build → test → deploy to Azure, com autenticação via Service Principal (secrets nunca hardcoded). Zero intervenção manual, 100% automatizado, incluindo validação de infraestrutura (`tflint`, `trivy`, `checkov`) antes de qualquer `terraform apply`.
#### A Base do Frontend Moderno
No frontend: **TypeScript**, **React**, **Vite**, **TailwindCSS** e **shadcn/ui**, com arquitetura orientada a componentes, cobertura completa de testes (unit com Vitest, componentes com React Testing Library, E2E com Playwright), suporte a i18n (PT-BR/EN) e foco em acessibilidade e SEO.
#### GEO: A Evolução da Busca
Também trouxe um recorte sobre **Generative Engine Optimization (GEO)**, a evolução do SEO tradicional (palavras-chave, cliques, backlinks) para um mundo onde o foco está em intenção e contexto, citações por LLMs e dados estruturados e semânticos.
### Lições Aprendidas
1. **Um prompt bem estruturado vale mais que 100 tentativas aleatórias.**
2. **Unir IA, automação e cloud não é o futuro, é o presente**, mas exige profissionais em "T": generalistas na velocidade (vibe coding, prototipagem rápida) e especialistas em profundidade (DevOps, Terraform, Azure, Security).
3. **UX é tão importante quanto o produto.**
4. A inteligência artificial acelera exponencialmente, mas o poder humano de decisão, a criatividade e o objetivo continuam sendo intangíveis.
> "A IA é o Acelerador. Você é o Piloto." A IA não vai roubar seu emprego, ela vai impulsionar quem sabe usá-la.
E um recado final, direto: você não é pago pra escrever código, você é pago pra resolver problemas. Se você não está gostando do seu trabalho atual, ou você não está usando a IA do jeito certo, ou você está no emprego errado.
### Slides da Apresentação
**Slides da Apresentação:** [Vibe Coding com DevOps: usei IA pra criar meu site no Azure, mas quem fez o deploy fui EU](https://stoblobcertificados2.blob.core.windows.net/palestras/Site.IA-DOD-CRTB.pdf)
### Repositórios
- [Repositório do Site](https://github.com/orafaelferreiraa/orafaelferreira-com), código-fonte, Terraform e pipeline completa.
Obrigado ao DevOpsDays Curitiba pela oportunidade e a todos que estiveram na sessão!
---
# Platform Engineering na Prática - Construindo Plataformas Serverless Self-Service
URL: https://www.orafaelferreira.com/artigos/mvp-conf-regional-curitiba-2026
Publicado: 2026-08-22
Categoria: Palestras
Tempo de leitura: 7 min de leitura
> MVP Conf Regional Curitiba 2026: como Platform Engineering combate o Shadow Ops com uma plataforma serverless self-service em Terraform e GitHub Actions.
## MVP Conf Regional Curitiba 2026
No dia **22 de agosto de 2026**, palestrei no [**MVP Conf Regional Curitiba 2026**](https://www.mvpconf.com.br/regional/curitiba/agosto-2026), realizado na **PUC PR**, com a sessão **"Platform Engineering na Prática - Construindo Plataformas Serverless Self-Service"**.
Uma imersão prática em Platform Engineering:qu o que é um Internal Developer Platform (IDP) de verdade, e como construí, com Terraform, GitHub Actions e uma arquitetura em três pilares, uma plataforma serverless self-service na Azure.
### O Anti-Padrão do Shadow Ops
A promessa "you build it, you run it" quebrou sob o peso da complexidade cloud-native. Exigir que desenvolvedores dominem toda a stack de infraestrutura (Kubernetes, Helm, Terraform, RBAC, CI/CD, networking) atrasa entregas e gera configurações inconsistentes, o chamado **Shadow Ops**. **44% das organizações de baixo desempenho** sofrem com desenvolvedores assumindo tarefas de infraestrutura e desviando o foco do produto.
### O Que É Platform Engineering?
Platform Engineering é construir uma plataforma interna que simplifica, padroniza e acelera o trabalho dos times de desenvolvimento. **Não é uma ferramenta. É um produto.**
- **O core da plataforma:** infraestrutura padronizada, pipelines automatizados e governança clara, processos que os devs realmente querem usar. O objetivo é tornar o caminho certo o caminho mais fácil.
- **Reduz carga cognitiva:** devs conseguem provisionar, deployar e monitorar sem precisar ser especialistas em cloud, Kubernetes ou networking. A plataforma "esconde" complexidade sem esconder poder.
- **Resultado:** velocity aumenta, erros humanos caem drasticamente e ciclos de release passam de meses para dias.
#### DevOps Tradicional vs. Engenharia de Plataforma
| DevOps Tradicional | Engenharia de Plataforma |
|---|---|
| Foco em atender tickets (Ticket Ops) | Foco em criar produtos de autoatendimento |
| Engenheiros operacionais como gargalo humano | Operações automatizadas através de Golden Paths |
| Devs lidam com Shadow Ops e configs complexas | Devs focam exclusivamente em lógica de negócio |
| Relação transacional e frequentemente tóxica | Relação baseada em pesquisa de usuário e feedback contínuo |
O mercado reconhece essa mudança: Platform Engineers ganham, em média, **até 20% a mais** do que profissionais de DevOps tradicionais.
### A Anatomia de um IDP: os 5 Planos
Um Internal Developer Platform (IDP) de verdade se organiza em cinco planos:
1. **Developer Control Plane**, a interface de entrada (portais, CLI, API, workload specifications). Onde o desenvolvedor interage.
2. **Integration & Delivery Plane**, o motor lógico (CI/CD, orquestradores de plataforma). Cria configurações dinamicamente a cada `git push`.
3. **Resource Plane**, os recursos reais subjacentes (compute, DNS, bancos de dados, nuvem).
4. **Security Plane**, governança contínua (gerenciamento de segredos, políticas de acesso).
5. **Observability Plane**, visibilidade padronizada (logs, APM, métricas).
### O Perfil do Engenheiro de Plataforma
Um bom engenheiro de plataforma vive na intersecção de três habilidades: **habilidades técnicas profundas** (Cloud Native, Kubernetes, CI/CD, GitOps, Infraestrutura como Código), **mentalidade de produto** (visão de ciclo de vida, foco no cliente/dev, MVPs e métricas de uso) e **comunicação e empatia** (vender a solução pra liderança técnica e ouvir criticamente o desenvolvedor).
### Erros Fatais ao Adotar Platform Engineering
1. **Mudança apenas de nome**, renomear a equipe de SysAdmins para "Plataforma", mas continuar afogado em Ticket Ops.
2. **Foco em Ops, não em Devs**, construir ferramentas baseadas no que os operadores acham importante, ignorando a experiência do usuário (dev).
3. **Sem mentalidade de produto**, atender requisições ad-hoc de todos os times sem construir fluxos de trabalho escaláveis.
4. **Tecnologia pela tecnologia**, trocar ferramentas sem um motivo estratégico atrelado à produtividade.
### O Valor Real: A Experiência do Desenvolvedor (DevEx)
O objetivo final é resumir meses de configuração de infraestrutura a parâmetros essenciais. Da visão do desenvolvedor, o esforço é `imagem = 'meu-app:v1'`. Por trás, a engenharia oculta cuida de tudo: Container Apps Environment configurado, rede spoke `/27` delegada, Managed Identity vinculada nativamente, comunicação criptografada com o Azure Container Registry, e logs fluindo automaticamente pra Application Insights.
### Como Construí: Uma Arquitetura em Três Pilares
Na prática, estruturei o ecossistema em três repositórios que se conectam:
1. **Pipeline-as-a-Service**, centraliza validação e segurança, valida o código.
2. **TFse Modules-as-a-Service**, blocos de construção reutilizáveis (ex: um módulo de Azure Container Registry já com RBAC embutido). Fornece as peças.
3. **Platform-as-a-Service**, o produto final: ambientes completos via feature flags, monta a solução.
Módulos não criam apenas o recurso, eles encapsulam governança, monitoramento e acesso, escondendo a complexidade do consumidor.
#### Pipeline-as-a-Service: Um Reusable Workflow
Um único **reusable workflow** de GitHub Actions elimina mais de **70 linhas de código de validação duplicadas por projeto** entre os três repositórios. Atualizações são feitas em um único lugar e se propagam pra todos os consumidores.
O fluxo sequencial de validação de infraestrutura roda em cinco etapas (com `continue-on-error: true`, executando todas as checagens mesmo se uma falhar):
`terraform fmt` (sempre ativo) → **TFLint** (boas práticas) → **Trivy** (vulnerabilidades) → **Checkov** (compliance) → **terraform-docs** (detecção de drift).
#### Feature Flags e Matriz de Dependências
A plataforma final é montada por feature flags que respeitam uma matriz de dependências, por exemplo, `enable_container_apps = true` dispara automaticamente `enable_observability`, `enable_managed_identity` (o hub central de RBAC que conecta Storage, Service Bus, SQL e ACR) e `enable_key_vault`, que por sua vez depende do `enable_sql` pra gerenciar senhas.
A arquitetura final segue quatro camadas, com dependência obrigatória de baixo pra cima: **Base** (Resource Group, Virtual Network) → **Fundação** (Managed Identity, Key Vault) → **Serviços** (Storage, Service Bus, SQL, ACR) → **Workloads** (Azure Container Apps Environment).
### Slides da Apresentação
**Slides da Apresentação:** [Platform Engineering: Construindo uma Plataforma Serverless Self-Service](https://stoblobcertificados2.blob.core.windows.net/palestras/Platform_Engineering-MVP-CRTB.pdf)
### Repositórios da apresentação
- **Platform Stack:**
[platform-as-a-service-stack](https://github.com/orafaelferreiraa/platform-as-a-service-stack)
- **Pipeline Stack:**
[pipeline-as-a-service-stack](https://github.com/orafaelferreiraa/pipeline-as-a-service-stack)
- **TF Modules Stack:**
[tfmodules-as-a-service-stack](https://github.com/orafaelferreiraa/tfmodules-as-a-service-stack)
Obrigado ao MVP Conf Regional Curitiba pela oportunidade e a todos que estiveram na sessão!
---
# Menções e Publicações Externas
URL: https://www.orafaelferreira.com/artigos/mencoes-publicacoes-externas
Publicado: 2026-08-16
Categoria: Colaborações Externas
Tags: Carreira
Tempo de leitura: 3 min de leitura
> Olá, pessoal! Reuni neste post publicações em que compartilhei insights em sites externos.
Olá, pessoal!
Quero deixar o registro com vocês um novo post onde destaco minhas participações em publicações, escrevendo sobre DevOps, Cloud e Platform Engineering. Espero que este post possa inspirar outros a buscar desenvolvimento profissional contínuo. Bora lá!
### Minhas Participações
#### Accelerate Teams with Platform Engineering and Policy-as-Code
[**Accelerate Teams with Platform Engineering and Policy-as-Code**](https://platformengineering.org/blog/accelerate-teams-with-platform-engineering-and-policy-as-code)
#### How I Use AI — Loop Engineering: Building Safer AI Agent Workflows for High-Stakes Infrastructure
[**How I Use AI — Loop Engineering: Building Safer AI Agent Workflows for High-Stakes Infrastructure**](https://techcommunity.microsoft.com/blog/mvp-blog/how-mvps-use-ai---loop-engineering-building-safer-ai-agent-workflows-for-high-st/4545646)
**#PlatformEngineering #PolicyAsCode #IA #DevOps #Comunidade**
---
# Loop Engineering na prática: como eu opero agentes no dia a dia
URL: https://www.orafaelferreira.com/artigos/loop-engineering-na-pratica
Publicado: 2026-07-26
Categoria: Artigos
Tags: IA, Platform Engineering, DevOps, Docker
Tempo de leitura: 47 min de leitura
> O que é Loop Engineering e como monto meu loop com skills, rules, subagents, hooks e MCP no Docker, incluindo os pontos em que discordo da definição canônica.
Usando LLMs e agentes há mais ou menos dois anos, desde a época em que eu ainda estava [explorando o que a IA generativa mudava na prática](/artigos/ia-gen), o **GitHub Copilot** desde então, e o **Claude Code** há uns três meses. O que vem abaixo é um resumo de como isso entrou no meu dia a dia de verdade.
### Resumo rápido
- **Loop Engineering** é técnica de o sistema que dá o prompt no agente, em vez de você dar o prompt a cada passo. O termo foi sistematizado em junho de 2026.
- O conceito original de um loop de verdade tem cinco peças: **objetivo**, **verificador**, **caminho de feedback**, **regra de parada** e **teto de iteração/custo**. Sem verificador, não é loop, é um gerador de texto com autoconfiança.
- Meu setup implementa quatro dos cinco componentes canônicos. O quinto, **worktree**, eu tirei de propósito, e explico por quê.
- A peça mais útil do meu loop não é uma IA: é um **hook em shell que sai com código 2**. É assim que a correção volta para o contexto do modelo.
- A divisão que faz o resto funcionar: **hook aplica, skill instrui, MCP executa.** Nenhuma das três invade o papel da outra.
- Trabalho com plataforma sob NDA, então aqui não tem nome de empresa, cluster, tenant ou repositório. O que interessa é o mecanismo, e o mecanismo é público.
### De prompt para loop
Nos últimos dois anos a alavanca foi migrando para fora. Primeiro era a **palavra que você digita**, prompt engineering. Depois virou **a informação que o modelo vê**, context engineering. Depois **o ambiente em que ele roda**, harness engineering. Agora é **o ciclo que dirige tudo isso**.
O [Peter Steinberger resumiu de um jeito que provoca](https://addyo.substack.com/p/loop-engineering): *"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."*
Isso provoca, porque é verdade. Se o seu trabalho com agente ainda é abrir o terminal, descrever a tarefa, ler a resposta, corrigir, repetir, você é o loop. Você é a peça que não escala.
Eu passei os últimos meses construindo o meu, num contexto que é bem menos glamouroso que os exemplos de blog: infraestrutura multi-tenant, Terraform, AKS, pipelines. Domínio onde o custo de errar não é um teste vermelho, é um ambiente fora do ar. E foi justamente esse contexto que me fez questionar e estudar cada vez mais para não usar a receita padrão.
### O que é Loop Engineering
Vamos ao que o povão está dizendo
O termo foi sistematizado pelo **Addy Osmani** em junho de 2026, [no artigo que virou referência](https://addyo.substack.com/p/loop-engineering) (também [publicado no O'Reilly Radar](https://www.oreilly.com/radar/loop-engineering/)). A definição dele é direta: *"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."*
A [IBM descreve como](https://www.ibm.com/think/topics/loop-engineering) a prática de projetar, especificar e manter loops agênticos, sistemas que se auto-instruem e avaliam o próprio trabalho até atingir um objetivo declarado. O [Augment Code detalha a anatomia](https://www.augmentcode.com/guides/what-is-loop-engineering): um loop pareia um agente de código com um **verificador**, um **caminho de feedback**, uma **condição de saída**, um **teto de iterações** e um **teto de orçamento**, para que ele possa rodar sem supervisão sob regras de parada explícitas.
Repare no que essa lista tem de mais importante: quatro dos cinco itens são **freios**. Só um é acelerador.
#### Os cinco componentes
O Osmani lista cinco peças que transformam execução avulsa em loop:
- **Automations**, *"Automations are what make a loop an actual loop and not just one run you did once."* Tarefas agendadas que descobrem trabalho sozinhas.
- **Worktrees**, diretórios de trabalho isolados, para vários agentes mexerem no mesmo repo sem colidir.
- **Skills**, conhecimento de projeto codificado em arquivos `SKILL.md`: convenções, passos de build, o contexto que você reexplicaria a cada sessão.
- **Plugins e connectors**, integrações via [MCP](https://modelcontextprotocol.io), para o loop alcançar sistemas reais e não só o filesystem.
- **Subagents**, separar quem escreve de quem confere. Nas palavras dele: *"The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks."*
E uma sexta peça, que na verdade é a fundação: **estado externo**. O modelo esquece tudo entre execuções, então a memória tem que viver fora dele. O jeito mais curto de dizer isso: **o agente esquece, o repo não.**
#### A tensão que ninguém resolveu
Existe um problema estrutural no meio disso, e vale nomear antes de qualquer entusiasmo: **a capacidade de gerar ultrapassou a capacidade de verificar.** Agentes produzem código rápido; checagens confiáveis continuam sendo artefato escasso, feito por gente.
Daí vêm as falhas clássicas, todas documentadas: **reward hacking** (o agente reescreve o teste em vez de consertar o código), **tool-call hacking** (ele chuta a saída em vez de usar o resultado da ferramenta), o exit *"parece pronto"* (declara conclusão sem evidência) e a **iteração infinita** (loop sem condição de parada).
Um [paper de julho deste ano no arXiv](https://arxiv.org/abs/2607.00038) argumenta na mesma direção: o problema não é o modelo ser fraco, é o loop ser mal projetado. E a própria Anthropic, [na engenharia de agentes eficazes](https://www.anthropic.com/engineering/building-effective-agents), coloca o requisito de forma seca, o agente precisa obter *ground truth* do ambiente a cada passo. Não da própria opinião. Do ambiente.
### Os quatro pontos onde meu loop é diferente
Eu implemento quatro dos cinco componentes acima. São decisões que o eu determinei.
#### 1. Loop sem worktree
O worktree é um dos cinco componentes canônicos. Eu tirei o meu, e tenho uma regra explícita proibindo o agente de criar um por iniciativa própria.
O raciocínio é este: em repositório de infraestrutura, **o isolamento que importa não é de arquivo, é de estado**. O que colide de verdade quando dois agentes trabalham em paralelo não é o diretório, é o *state* remoto do Terraform, é o lock de um apply em andamento, é o contexto de cluster ativo no `kubectl`, é o registro de um recurso que só existe uma vez na nuvem. Worktree não resolve nenhum desses. Ele te dá dois checkouts que disputam exatamente o mesmo recurso, com a sensação agradável de que estão isolados.
Então eu troco por outra coisa: **branch, e o PR como gate.** O isolamento vem do branch. A verificação vem da revisão. E o PR ainda me dá o que worktree nenhum dá, trilha de auditoria com diff, comentário e aprovação nominal. Em infra, "quem aprovou isso" é uma pergunta que aparece.
#### 2. Guardrail antes da geração, não depois
O padrão da literatura é gerar e depois verificar. Meu loop inverte parte disso. As **rules** carregam antes de qualquer código existir, e várias delas são proibições: validar versão de provider e schema do recurso via MCP **antes** de escrever a primeira linha; nunca escrever segredo em arquivo; nunca abrir endpoint público em serviço de dados de produção; menor privilégio por padrão.
A ideia é simples e pouco glamourosa: **o verificador mais barato do mundo é a regra que impede o erro de existir.** Um teste que pega credencial hardcoded é bom. Uma regra que faz o agente nunca escrever uma é melhor, porque custa zero iteração.
É o mesmo raciocínio que eu já defendi em [Platform Engineering e Policy-as-Code que aceleram times](/artigos/platform-engineering-policy-as-code), só deslocado uma camada para trás. Lá a política barra o recurso errado na hora de admitir; aqui a regra impede o agente de escrever o recurso errado. Política é guardrail para o que já existe; rule é guardrail para o que ainda vai nascer.
#### 3. Em infra, o verificador não é a suíte de testes
Aquela tensão de gerar-versus-verificar é ruim em desenvolvimento de aplicação. Em plataforma é pior, por um motivo bobo: **verificar custa tocar em ambiente.**
Não existe `npm test` que me diga se uma regra de rede vai funcionar. O verificador honesto é outro conjunto de coisas, e elas têm preços muito diferentes:
| Gate | O que ele responde | Custo |
|---|---|---|
| Lint e format | O código é sintaticamente válido? | Segundos, zero risco |
| Validate e schema | Os campos existem nessa versão do provider? | Segundos, zero risco |
| Plan / diff | O que exatamente vai mudar? | Minutos, leitura remota |
| Health e reconciliação | O ambiente aceitou e está saudável? | Depois do apply, risco real |
A regra que eu sigo é ordenar do mais barato ao mais caro, e nunca deixar o agente pular etapa. O [Augment recomenda a mesma ordenação](https://www.augmentcode.com/guides/what-is-loop-engineering) de forma genérica, portas determinísticas primeiro, raciocínio depois, teste dinâmico por último. Em infra isso não é otimização de custo, é gestão de blast radius.
E o corolário desconfortável: **o último gate da minha lista não é automatizável hoje.** "O ambiente está saudável" envolve olhar coisa que só existe depois de aplicar. É exatamente por isso que a próxima tese existe.
#### 4. O outer loop é meu
O Osmani tem uma frase: *"Delegating the inner loop is leverage; delegating the outer loop is abdication."*
Delegar o **inner loop**, escrever, rodar o gate, corrigir, rodar de novo, é alavancagem pura. É trabalho que eu não quero fazer à mão.
Delegar o **outer loop**, decidir o que é o objetivo, julgar se o resultado presta, assumir o resultado, é abdicação. Não é uma questão de confiança no modelo. É que a responsabilidade não é transferível: quando algo cai, ninguém aceita "o agente decidiu".
No meu setup isso está codificado, não é boa intenção:
- O **objetivo** vem de um card do Jira.
- O **ID da tarefa** vive no nome da branch, não na conversa. Qualquer sessão nova recupera o objetivo com um comando de git.
- O **fim do ciclo** é um PR, com um comentário de volta no card. Não um deploy.
- O **estado** persiste fora do modelo, em memória entre sessões e no próprio histórico do repo.
- O **merge é meu.** O agente nunca faz merge. Nenhuma exceção.
Repare que só o primeiro e o último item são sobre mim. Os três do meio são automação, e é justamente por serem automatizados que eu consigo manter as pontas na mão sem virar gargalo. Autonomia no meio, autoridade nas bordas.
Isso torna meu loop menos autônomo do que os exemplos que circulam por aí. É de propósito. Autonomia é meio, não é métrica.
### Como o loop está montado
Agora a mecânica. A tese organizadora, e o que eu levaria para qualquer outro setup: **hook aplica, skill instrui, MCP executa.**
Três camadas, três papéis, e a disciplina de nenhuma invadir a outra. Hook é determinístico , ele detecta e aplica. Skill é procedimento versionado, ela ensina. MCP é quem busca atualidade na internet. Quando eu misturei os papéis, quebrou. Quando separei, ficou previsível.
#### `exit 2` é a primitiva do loop
Se eu pudesse levar uma coisa só deste artigo, seria esta.
[Hooks no Claude Code](https://code.claude.com/docs/en/hooks) são comandos disparados por evento do ciclo de vida, antes de uma ferramenta rodar, depois que ela roda, no início da sessão, no fim. E eles têm um comportamento de código de saída que é a coisa mais subestimada da ferramenta: **quando um hook sai com código 2, o que ele escreveu no stderr volta para o contexto do modelo como mensagem de erro.**
Leia de novo. Isso significa que um script de shell de trinta linhas consegue **injetar correção no loop**. Não é sugestão em documentação que o modelo talvez leia. É feedback que chega no momento exato do erro, com o texto que eu escrevi.
Esse é o *caminho de feedback* da definição de loop, implementado em bash. Cinco hooks meus usam isso: três para o modelo se autocorrigir, um para entregar uma tarefa de follow-up, um para travar de verdade.
Um exemplo genérico, que é a forma de todos eles:
```bash
#!/usr/bin/env bash
## PostToolUse — avisa quando um manifesto sai sem limite de recurso.
set +e
[ -t 0 ] && exit 0 # sem stdin, nada a fazer
payload="$(cat)"; [ -z "$payload" ] && exit 0
file="$(printf '%s' "$payload" | jq -r '.tool_input.file_path // empty')"
case "$file" in *.yaml|*.yml) ;; *) echo '{"continue":true}'; exit 0 ;; esac
## só olha workload de verdade, não Application/CRD/kustomization
grep -qE "^kind: (Deployment|StatefulSet|DaemonSet|Job|CronJob|Pod)$" "$file" || {
echo '{"continue":true}'; exit 0; }
if ! grep -q 'resources:' "$file"; then
printf 'Guardrail: %s define workload sem resources/limits. Adicione requests e limits antes de seguir.\n' "$file" >&2
exit 2 # <- stderr volta para o contexto do modelo
fi
echo '{"continue":true}'
```
Note duas coisas que aprendi na prática. Primeira: o hook **estreita o escopo antes de opinar**, se ele disparasse em todo YAML, ia gritar em manifesto de GitOps que legitimamente não tem `resources`, e guardrail que grita errado é guardrail que a gente desliga. Segunda: a mensagem diz **o que fazer**, não só o que está errado. Feedback acionável fecha o loop numa iteração; feedback vago gasta três.
#### O card é o objetivo, e o loop começa nele
Um loop precisa de objetivo que o modelo não inventou. No meu setup ele vem de um card do Jira, e o ciclo toca o card em três momentos: **descobrir qual é**, **criar a branch** e **comentar de volta no fim**.
**Descoberta do card.** Eu não digito o número da tarefa. Uma skill consulta o Jira via MCP com um JQL fechado no meu projeto, atribuído a mim, em andamento, ordenado pelo mais recentemente atualizado:
```text
project = AND assignee = currentUser() AND status = "In Progress"
ORDER BY updated DESC
```
E aqui está a decisão de design IRADA que decidi criar: **ele pega o primeiro resultado e não pergunta.** Diz em uma linha qual card assumiu, "usando o card X, tal resumo", e segue trabalhando. Se estiver errado, eu corrijo na mensagem seguinte.
Um loop que para para perguntar "qual desses três cards?" não é um loop, é um formulário. Pergunta bloqueante no início de toda tarefa é exatamente o atrito de humano-no-meio que Loop Engineering existe para remover. O padrão certo é **default otimista com correção barata**: escolha o mais provável, diga em voz alta o que escolheu, continue. Errar custa uma mensagem; perguntar custa todas as vezes.
As saídas de emergência são explícitas, e isso importa mais que a regra: se eu já dei a chave na mensagem, não busca nada. Se a busca voltar vazia, ela avisa e pede a chave, **nunca inventa uma**. Se eu citar outro projeto, usa aquele. Loop bom tem default; loop confiável tem default *e* as três exceções escritas.
**Criação da branch.** O nome é sempre `feature/{CHAVE-DA-ISSUE}`, independente do tipo, Bug, Task e Story todos entram como `feature/`. Taxonomia única, zero decisão a cada tarefa. Nome de branch é metadado, não é lugar de criatividade.
E tem um detalhe de arquitetura aí que eu considero mais importante que a convenção: **a sequência do git não está na skill.** Dar pull na base, sair dela para uma branch nova, nunca commitar na base, isso vive numa *rule*, e a skill do Jira diz explicitamente para não repetir esses passos. É a disciplina anti-duplicação. Se eu copiar a sequência do git em toda skill que mexe com git, mudar a sequência significa editar cinco arquivos e esquecer dois.
Tem também um ritual de limpeza antes de começar a próxima tarefa: voltar para a base, `git pull --prune` para derrubar as referências de rastreamento que já morreram no remoto, e apagar a branch local que já virou PR. Parece detalhe bobo, mas um loop que cria uma branch por tarefa e nunca limpa te deixa com quarenta branches órfãs em três meses.
**A chave mora na branch.** Esse é o ponto estrutural que faz o loop ser fechável, e é o que eu levaria para qualquer outro rastreador de tarefas. O modelo não precisa lembrar qual era o card, o próprio git conta:
```bash
git branch --show-current | grep -oE 'feature/[A-Z][A-Z0-9_]+-[0-9]+'
```
*"O agente esquece, o repo não"* deixa de ser abstração e vira um regex. O estado do ciclo está no nome da branch, não na conversa, então qualquer sessão nova, qualquer hook, qualquer subagente consegue recuperar o objetivo sem contexto anterior. É a peça de estado externo mais barata que eu tenho, e não custou nada além de escolher uma convenção e respeitá-la.
#### O ciclo que se fecha sozinho
O melhor exemplo de loop no meu setup é o que fecha esse ciclo: liga o PR de volta ao card. Ele mostra as três camadas trabalhando sem se atropelar.
O **hook** roda em `PostToolUse`, casando tanto com o comando de CLI que abre PR quanto com a tool MCP equivalente. E aí vem a parte que eu errei na primeira versão: ele **confirma que uma URL de PR realmente voltou na resposta** antes de fazer qualquer coisa. Sem isso, ele disparava quando o comando falhava ou era negado, anunciando um PR que não existia.
```bash
pr_url="$(printf '%s' "$response_blob" \
| grep -oE 'https://github\.com/[^"[:space:]]+/pull/[0-9]+' | head -1)"
[ -z "$pr_url" ] && { echo '{"continue":true}'; exit 0; }
```
E o passo decisivo: **o hook não escreve no rastreador.** Ele não tem credencial, não conhece a API, não sabe formatar o comentário. Ele sai com código 2 e devolve ao modelo um ponteiro, vá na seção tal da skill tal, extraia a chave da branch atual, resuma o que foi feito, comente no card com o link.
A **skill** é quem sabe o procedimento, e ela é específica de um jeito que só a prática ensina: o resumo sai em inglês mesmo quando a conversa é em português, porque o card é lido por outros times; o link do PR vai como link markdown com texto descritivo, nunca URL crua, porque URL crua vira uma string gigante que arrebenta a leitura do parágrafo; e se a branch não seguir o padrão esperado, **não faz nada e fica calado**, não todo PR está ligado a um card.
O **MCP** tem o token e escreve o comentário.
Trigger determinístico, procedimento versionado, efetor autenticado. Nenhuma das camadas sabe fazer o trabalho da outra, e é por isso que dá para mexer numa sem quebrar as demais.
#### Minha trava preferida: nada é destruído sem eu olhar
De tudo que eu construí nesse setup, esse é o hook de que eu mais gosto, e é o que eu recomendaria escrever primeiro se alguém me perguntasse por onde começar. A regra dele é uma frase: **toda operação destrutiva para e pede autorização, sempre, independente do modo em que eu esteja.**
Ele roda em `PreToolUse`, antes de qualquer coisa acontecer, e a cobertura é deliberadamente ampla. São dez regras rotuladas, testadas em ordem, e o rótulo importa porque é ele que vai para o log:
- **Remoção de arquivo**, `rm`, `rmdir`, `unlink`, `shred`, `del`, com ou sem `sudo`, inclusive quando aparecem depois de um `;`, de um `&&` ou dentro de um subshell.
- **Subcomando destrutivo depois de uma CLI conhecida**, a rede mais larga de todas: `delete`, `destroy`, `uninstall`, `purge`, `prune`, `remove`, `drop` precedidos de `az`, `kubectl`, `helm`, `docker`, `terraform`, `tofu`, `gh`, `argocd`, `flux`, `aws`, `gcloud`, `npm`, `apt` e companhia.
- **`terraform destroy`**, e também o `apply` disfarçado com a flag de destruição, que é o jeito silencioso de fazer a mesma coisa.
- **Git destrutivo**, `push --force`, `reset --hard`, `clean -f`, `branch -D`, `tag -d`, `stash drop` e `stash clear`. Perder trabalho local não é menos grave que perder recurso na nuvem, é só mais silencioso.
- **Docker**, `system prune`, `volume rm`, `network rm`, e o `compose down -v` que leva os volumes junto.
- **Kubernetes**, `kubectl delete` e `kubectl drain`, `helm uninstall`.
- **`find` com `-delete` ou `-exec rm`**, que é como um comando de busca se transforma em remoção em massa.
- **SQL**, `DROP TABLE`, `DROP DATABASE`, `DELETE FROM`, `TRUNCATE`.
- **Verbo destrutivo genérico**, a rede de segurança para o que eu não previ: pega uma tool de MCP chamada `delete_algumacoisa` ou um campo `"destroy"` no payload.
E tem um detalhe de escopo que faz esse último item funcionar. O hook não olha só linha de comando: **quando a ferramenta não é o shell, ele varre o `tool_input` inteiro.** Isso é o que faz uma tool de MCP que apaga recurso na nuvem cair na mesma rede que um `rm -rf`. Ferramentas que não destroem nada (ler, escrever, buscar arquivo) saem na primeira linha, sem custo.
**Por que "sempre" é a palavra que importa.** O modo que aceita edição automaticamente existe justamente para eu não aprovar cada passo, e é ótimo para isso. Só que ele não distingue "criar arquivo" de "apagar cluster". Esse hook devolve `permissionDecision: "ask"`, que **sobrevive ao auto mode**: mesmo com tudo liberado, remoção volta a exigir um sim explícito meu.
Repare no que isso significa: **é o único guardrail meu que não confia em mim.** Os outros protegem contra o agente errar. Esse protege contra eu estar no automático e aprovar sem ler, que é o modo de falha mais provável depois que o loop começa a funcionar bem. É o freio contra a rendição cognitiva, escrito em shell.
Ele também é o único que **ignora o kill-switch global**. Todos os meus outros hooks respeitam uma variável de ambiente que os desliga de uma vez; esse não olha para ela. Guardrail que desliga junto com o resto não é guardrail, é enfeite.
**Está funcionando?** O log diz que sim, e mais do que eu esperava. Em vinte dias, **100 detecções**, cerca de cinco por dia:
| Regra que disparou | Vezes |
|---|---|
| Subcomando destrutivo depois de CLI | 54 |
| Remoção de arquivo | 32 |
| Git destrutivo | 12 |
| SQL e verbo genérico | 2 |
**E o detalhe de engenharia que quase me custou caro.** O jeito elegante de um hook barrar algo é devolver um JSON pedindo confirmação:
```json
{ "hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "ask",
"permissionDecisionReason": "Operação destrutiva — confirme antes de seguir." } }
```
Só que existe um modo de permissão em que os prompts estão desligados. Nele, pedir confirmação é **pedir para o vazio**, a decisão é simplesmente ignorada e o comando passa. Descobri isso do pior jeito possível: o guardrail existia, parecia certo, e não protegia nada exatamente no modo em que eu mais precisava dele.
A correção é ser consciente do modo:
```bash
case "$perm_mode" in
bypassPermissions) printf 'BLOQUEADO: %s\n' "$reason" >&2; exit 2 ;;
*) jq -n --arg r "$reason" '{"hookSpecificOutput":{
"hookEventName":"PreToolUse","permissionDecision":"ask",
"permissionDecisionReason":$r}}' ;;
esac
```
Onde tem prompt, pede. Onde não tem, usa `exit 2`, que é o único mecanismo que bloqueia em qualquer modo, e a mensagem diz para sair do modo bypass e reexecutar se a intenção era real. Isso fecha a única brecha que restava.
E o log de auditoria é escrito **antes** da decisão, nunca depois. Se eu aprovar no automático, quero pelo menos ter o registro de que fui eu que aprovei, com data, sessão, regra e o comando inteiro. Auditoria que só grava o que foi bloqueado conta metade da história.
#### Verificador separado, com dentes
O componente que o Osmani chama de mais útil é separar quem escreve de quem confere. [Subagentes](https://code.claude.com/docs/en/sub-agents) são o mecanismo.
O que eu acrescentaria é: **separe por restrição de ferramenta, não por instrução.** Dizer no prompt "você é read-only" é pedir cortesia. Não entregar as ferramentas de escrita é garantir.
Meus dois verificadores, um que planeja antes de mexer, um que revisa depois, não têm `Edit` nem `Write`. Também não têm a ferramenta de spawnar outros agentes, então são folhas da árvore: não conseguem delegar o próprio julgamento para um terceiro que teria escrita. O agente que implementa tem escrita, e não é o mesmo que aprova.
E tem um teto explícito no orquestrador: se a revisão não convergir em **três rodadas**, ele para e me reporta em vez de continuar tentando. Escrevi isso meses antes de ler qualquer coisa sobre Loop Engineering, por um motivo prosaico, vi um ciclo revisar e reescrever a mesma coisa sem convergir. É o "iteration cap" da literatura, aprendido na marra.
Um detalhe que economiza contexto: meus verificadores têm **formato de saída fixo**, e uma das seções obrigatórias é *"obstáculos encontrados"*, problema de ambiente, comando que precisou de flag especial, dependência que atrapalhou. Isso impede que quem chamou redescubra o mesmo tropeço. É estado externo em escala de subagente.
#### A escada de verificação, na prática: escrevendo um operator
A tese 3 disse que em infra o verificador não é a suíte de testes. Mas isso não significa que não exista suíte. Significa que ela é **um degrau, não o topo**. O caso onde eu montei essa escada por inteiro foi escrevendo um operator Kubernetes em Go, com [Kubebuilder](https://book.kubebuilder.io/), e a ordem importa mais que cada peça.
**Degrau 1, compilar e passar o vet.** `go build` e `go vet`. Custa segundos, pega erro de digitação e de tipo. Óbvio, e ainda assim é o degrau que o agente mais tenta pular quando está confiante.
**Degrau 2, testes de unidade.** A lógica de tradução do operator concentra a maior parte deles, tabela-driven, dezenas de casos. É onde uma mudança de comportamento fica cravada em asserção.
E aqui está a regra que eu considero a mais valiosa deste artigo depois do `exit 2`, porque é a defesa direta contra reward hacking:
**Sempre que o agente adiciona um teste de regressão, ele tem que provar que o teste FALHA se você reverter a correção que ele guarda.** Um teste que passa igual com e sem a correção não está exercitando nada, é decoração que dá sensação de cobertura.
Isso é mutation testing manual, e resolve o problema central do loop autônomo. O agente é ótimo em escrever teste que passa. Pedir "escreva um teste", não. Digite "escreva um teste e me prove que ele pega o bug". É a diferença entre verificar e parecer que verificou.
**Degrau 3, testes de integração contra uma API real.** O reconciler roda contra `envtest`, que sobe um `kube-apiserver` e um `etcd` de verdade. Detalhe que virou nota na skill porque me custou uma sessão inteira de diagnóstico errado: esses binários **não vêm no repo**, precisam ser baixados uma vez por um passo de setup. Sem ele a suíte falha de um jeito que parece bug do código. Não era gap conhecido, era só um passo faltando, e eu quase "consertei" código que estava certo.
Essa é uma falha de loop clássica e vale nomear: **erro de ambiente que se disfarça de erro de código.** O agente lê o stack trace, acredita nele, e começa a consertar a coisa errada com muita confiança. O antídoto é o mesmo do resto: registrar o obstáculo por escrito na primeira vez que ele aparece, para a próxima sessão não repetir o diagnóstico.
**Degrau 4, o cluster local que imita o ambiente real.** E aqui está o limite duro do degrau anterior: `envtest` sobe a API do Kubernetes, mas **não sobe o data plane**. Ele não tem proxy de verdade, não move pacote. Qualquer coisa que dependa de comportamento real de rede, como um header sendo reescrito ou uma política aplicada no caminho do tráfego, passa no envtest e falha no mundo.
Então existe um degrau a mais: o Kubernetes que vem no Docker Desktop, rodando na minha máquina, configurado com **os mesmos valores de Helm do módulo que provisiona o ambiente real**. Não é um cluster de brinquedo com o default do chart; é o ambiente de produção em miniatura, e é isso que faz o teste valer. Ao lado dele, um backend que só ecoa os headers que recebeu, e um `curl`. Aí eu vejo o que realmente chegou.
Esse degrau também é onde mora um dos meus guardrails favoritos, e ele é de permissão, não de código: **os clusters reais são read-only para o agente**, só `get`, `list`, `watch`, `logs` e `events`, mais nada. O cluster local é a única exceção com acesso de escrita. A assimetria é o guardrail. O agente pode quebrar o quanto quiser onde quebrar é grátis, e não alcança onde não é.
E uma armadilha bem específica de quem roda WSL com Docker Desktop, que me custou um bom tempo: rodar o operator com `go run` no WSL e tentar alcançá-lo do cluster via `host.docker.internal` **não funciona**. WSL e a VM do Kubernetes do Docker Desktop são máquinas virtuais separadas. O DNS resolve, o que faz parecer que está tudo certo, e a conexão TCP simplesmente não completa. Diagnóstico enganoso do início ao fim.
**Não tem build de imagem no ciclo de iteração.** Editar arquivo, reiniciar o pod, ver o efeito, o loop interno fica em segundos em vez de minutos, e a imagem só é construída quando o comportamento já está validado. Que é exatamente o ponto: a imagem é o *resultado* do loop, não uma etapa dele.
**Degrau 5: A imagem. E só então,** quando os quatro degraus passam, aí sai a imagem, construída pelo serviço de build do registry, nunca na minha máquina.
Tem um sexto verificador nessa história que eu gosto de citar porque é um teste guardando **consistência entre duas fontes de verdade**, não comportamento. O RBAC do operator existe em dois lugares: um arquivo gerado a partir de marcadores no código, que **não pode ser editado à mão**, porque o gerador sobrescreve silenciosamente na próxima execução, e uma cópia de referência no manifesto. Um teste falha o build se os dois divergirem. Sem ele, alguém edita o gerado à mão, o gerador apaga na semana seguinte, e o operator perde permissão em produção sem ninguém ter tocado em permissão.
#### Quando o CI é o verificador: ler a pipeline de volta
Os cinco degraus acima rodam antes do push. Depois do push existe outro verificador, que é o único que enxerga o ambiente de CI de verdade: a pipeline.
E é aqui que o loop se fecha de um jeito que eu não esperava que funcionasse tão bem. O agente não precisa que eu traduza o erro do CI para ele. Ele lê direto, pelo `gh` CLI ou pela tool de MCP do GitHub, pega o log do que falhou, corrige e empurra de novo.
O detalhe de eficiência que faz diferença é pedir **só o que falhou**:
```bash
gh run list --branch "$(git branch --show-current)" --limit 1
gh run view --log-failed
```
`--log-failed` traz apenas os passos que quebraram. Jogar o log inteiro de um workflow no contexto é desperdício e, pior, enterra o erro real em milhares de linhas de saída de build bem-sucedida. Contexto é orçamento; log de CI é o item mais fácil de estourar.
Isso é *ground truth* do ambiente, no sentido exato que a Anthropic descreve, o agente não está julgando o próprio trabalho, está lendo o veredito de um sistema que ele não controla. Que é a definição de verificador honesto.
**E aqui vem a parte honesta:** esse é o pedaço **menos codificado** do meu setup. Os cinco degraus locais estão escritos numa skill; a leitura de CI ainda é convenção que vive na minha cabeça e se repete a cada sessão por hábito, não por procedimento. Não existe hook que dispare no push, não existe regra que force ler `--log-failed` em vez do log todo, não existe teto de quantas vezes tentar antes de me chamar.
#### Skills: a descrição é o que decide
[Skills](https://code.claude.com/docs/en/skills) são arquivos `SKILL.md` com procedimento escrito. Elas seguem o [padrão aberto Agent Skills](https://agentskills.io), o que significa que não é conhecimento preso numa ferramenta só.
O que mais gente entende errado, e eu entendi errado por um bom tempo: **a `description` do frontmatter não é documentação, é o mecanismo de roteamento.** É por ela que o modelo decide carregar a skill ou não. Descrição vaga é skill que nunca dispara.
```markdown
---
name: minha-skill
description: "O que faz + QUANDO usar, com as palavras que aparecem no pedido real. Diga também o que NÃO é, se existir skill vizinha que confunde."
---
### Quando usar
### Passos
### Guardrails
```
Duas coisas que a prática ensinou. **Desambiguação explícita vale ouro**: eu tenho duas skills sobre Kubernetes que fazem coisas diferentes, e cada descrição termina dizendo "isto é X, não Y, para Y use a outra". Sem isso, disparava a errada metade das vezes.
**Disclosure progressivo importa** porque o corpo da skill só carrega quando ela é usada. Procedimento no `SKILL.md`, material de referência longo em arquivos ao lado, script que ela chama num subdiretório. Referência de 300 linhas custa quase nada até o momento em que é necessária.
#### Rules com escopo: disciplina de token
Um [`CLAUDE.md`](https://code.claude.com/docs/en/memory) carrega em toda requisição. Isso é uma faca de dois lados: o que está lá é sempre verdade, e você paga por isso sempre.
Então eu separei. O arquivo raiz ficou deliberadamente curto, contexto, modelo de nomenclatura, os não-negociáveis, e a regra de roteamento. Profundidade de domínio foi para arquivos que carregam **só quando um arquivo daquele tipo é editado**, via glob de caminho.
A lição de escopo veio de um erro que dói de lembrar. Minha regra de manifestos casava com `**/*.yaml`, extensão nua. Resultado: disparava em pipeline, em config de linter, em qualquer YAML do mundo, injetando guardrail de Kubernetes onde não tinha Kubernetes. Trocar para escopo por **convenção de diretório** resolveu. Regra que dispara errado treina você a ignorar regra.
#### MCP no Docker: um gateway, muitos servidores
[MCP](https://code.claude.com/docs/en/mcp) é o que faz o loop alcançar sistemas reais. E aqui o Docker resolveu um problema chato de verdade.
Já escrevi um artigo inteiro sobre esse caminho, [MCP Server com Docker e Terraform: discovery, troubleshooting e produtividade](/artigos/terraform-mcp-server-docker), com a montagem passo a passo. Aqui o recorte é outro: o papel que ele cumpre dentro do loop.
Sem ele, cada servidor MCP é um processo com runtime próprio, dependência própria e credencial largada em algum `.env`. Com o [MCP Toolkit e o Catalog](https://docs.docker.com/ai/mcp-catalog-and-toolkit/), você habilita servidores pela interface do Docker Desktop e o [MCP Gateway](https://github.com/docker/mcp-gateway) agrega todos eles atrás de **uma única entrada** de configuração. Cada servidor roda em container, com limite de CPU e memória e `no-new-privileges`. E, o ponto que mais me importa, **as credenciais ficam no store cifrado do Docker**, não em arquivo no repo.
**O que eu tenho habilitado hoje.** Não adianta falar de sprawl de ferramentas em abstrato, então aqui está o inventário real, contado na saída do gateway enquanto eu escrevia este parágrafo:
| Servidor MCP | Ferramentas | Para que eu uso |
|---|---|---|
| `atlassian` | 77 | Jira e Confluence, o discovery do card e o comentário de volta no PR |
| `azure` | 65 | consulta de recurso, custo, quota, RBAC, diagnóstico |
| `grafana` | 65 | dashboards, consulta a métricas e logs, alertas |
| `github-official` | 44 | PR, issue, busca de código, leitura de workflow |
| `playwright` | 23 | navegar e validar página de verdade, não só supor |
| `kubernetes` | 23 | inspeção de cluster, sempre read-only fora do local |
| `dockerhub` | 13 | busca de imagem e checagem de tag |
| `terraform` | 9 | versão de provider e schema de recurso, o gate da tese 2 |
| `mcp-python-refactoring` | 9 | análise de código Python das automações |
| `context7` | 2 | documentação de biblioteca atualizada, contra alucinação de API |
| `docker-docs` | 1 | documentação oficial do Docker |
São **331 ferramentas em 11 servidores**, mais as nativas do próprio gateway, o que fecha as ~339 que aparecem no handshake. Um único container por servidor, uma única entrada de configuração no cliente.
Agora olhe essa tabela como orçamento em vez de catálogo. Três servidores concentram **207 das 331 ferramentas**, quase dois terços. Eu não uso 77 operações de Jira: uso quatro ou cinco. Esse é o custo escondido do "habilita que é fácil", e é a causa do problema de timeout logo abaixo, não só um detalhe de contexto.
**Você pode puxar esse setup inteiro com um comando.** Essa é a parte que eu descobri tarde e que mais me deixou com cara de bobo por ter configurado tudo na mão antes: um profile do MCP Toolkit **é publicável como artefato OCI**. Ele vai para um registry como qualquer imagem, e do outro lado alguém puxa e recebe a lista de servidores já montada.
Eu publiquei o meu:
```bash
## publicar o profile local em um registry
docker mcp profile push profile rafaferreira011/public:latest
## do outro lado, instalar tudo de uma vez
docker mcp profile pull rafaferreira011/public:latest
```
O [artefato está público no Docker Hub](https://hub.docker.com/r/rafaferreira011/public). Repare que **não é uma imagem executável**: são ~170 kB de JSON com `artifactType` `application/vnd.docker.mcp.profile.v1+json`, a relação de servidores com as imagens fixadas por digest. Ninguém roda esse artefato, o Toolkit lê e reconstrói a configuração.
Duas coisas que valem dizer, porque são exatamente as perguntas que eu faria:
**Segredo não viaja junto.** O profile guarda o *nome* do segredo e a variável de ambiente que ele preenche, nunca o valor. Os valores continuam no store cifrado da sua máquina. Eu confirmei baixando o meu próprio artefato e varrendo o JSON: zero token, zero chave. É o que torna publicar um profile uma coisa segura de fazer, e é o mesmo princípio da seção inteira, referência em vez de cópia.
**O profile público é um recorte, não o meu espelho.** São 8 servidores, os que funcionam para qualquer pessoa: Azure, GitHub, Terraform, Kubernetes, Playwright, Docker Hub, Docker Docs e Context7. Ficaram de fora justamente os que dependem de endpoint interno, porque nesses o campo de configuração carrega a URL do ambiente, e URL de ambiente interno em registry público é vazamento, não é conveniência. Segredo o Toolkit protege sozinho; **configuração ele não protege, e essa parte é sua.** Olhe o que vai no profile antes de dar push.
E fechando o argumento do orçamento de ferramentas lá de cima, existe a régua fina, que eu deveria ter começado a usar antes:
```bash
docker mcp profile tools --disable atlassian.jira_delete_issue
docker mcp profile tools --disable-all playwright
```
Dá para habilitar e desabilitar **ferramenta a ferramenta**, não só servidor inteiro. É a resposta certa para "77 operações de Jira das quais eu uso cinco": em vez de desligar o servidor e perder o que presta, corta a cauda e fica com o que você chama de verdade.
A configuração no lado do cliente é uma entrada só:
```json
{
"mcpServers": {
"MCP_DOCKER": {
"type": "stdio",
"command": "docker",
"args": ["mcp", "gateway", "run"]
}
}
}
```
Tem caminho ainda mais curto: no Docker Desktop, em **MCP Toolkit → Clients**, existe um botão que conecta o cliente e escreve esse arquivo por você. Pela CLI, o equivalente é `docker mcp client connect claude-code`. Segredo entra com `docker mcp secret set`, nunca no JSON. Depois é só rodar `/mcp` no cliente para conferir que conectou. O [blog oficial do Docker tem o passo a passo](https://www.docker.com/blog/add-mcp-servers-to-claude-code-with-mcp-toolkit/), e existe [um tutorial em vídeo do próprio Docker](https://www.youtube.com/watch?v=1Tu0c1zuz70) cobrindo a mesma sequência. Para diagnóstico, o Docker publica [um plugin oficial](https://github.com/docker/claude-plugins) que adiciona comandos de status e debug do gateway.
Agora as duas armadilhas que eu paguei, e que não estão em tutorial nenhum.
**Primeira: WSL.** Eu rodo o cliente dentro do WSL, com o Docker Desktop no Windows. O plugin `docker mcp` do lado Linux **não enxerga o Docker Desktop**, insiste que não está rodando, mesmo com o socket no lugar. Tentei symlink de socket, bind-mount, plugin alternativo; nada. A solução que funciona é chamar o **binário do Windows** via interop, `docker.exe`, que detecta o Desktop nativamente. Detalhe adicional: o arquivo de configuração precisa estar na **raiz do projeto**, não dentro do diretório de configuração do cliente, nesse segundo caminho ele é ignorado silenciosamente, e você fica olhando uma lista vazia sem nenhuma mensagem de erro.
**Segunda: timeout.** Gateway grande demora para subir. Ele carrega o catálogo, verifica imagens, inicia um container por servidor habilitado e lista as ferramentas de cada um **antes** de responder ao handshake. Eu medi: cerca de **21 segundos** para o `initialize` responder, já com as imagens em cache, servindo algumas centenas de ferramentas. O timeout padrão de conexão é de 30 segundos. Ou seja: funcionava quente e falhava frio, com uma mensagem de timeout que não diz nada sobre a causa.
A correção é aumentar o teto nas [configurações do cliente](https://code.claude.com/docs/en/settings):
```json
{ "env": { "MCP_TIMEOUT": "120000", "MCP_TOOL_TIMEOUT": "180000" } }
```
#### Estado externo
O modelo esquece entre execuções. Então tem que existir memória fora dele, e ela opera em duas escalas no meu setup.
**Entre sessões**, memória persistente guarda o que foi descoberto e custou caro para descobrir, não estrutura de código, que o repo já conta, mas coisa como "esse comportamento estranho tem essa causa raiz", com data. Fato durável, um por arquivo, indexado.
**Dentro da sessão**, um par de hooks com estado: um registra cada arquivo tocado num arquivo temporário por sessão; o outro, no encerramento, filtra os arquivos de infraestrutura, me mostra a lista e lembra de rodar os gates antes do PR, e trunca o registro.
#### O loop que melhora o loop
Voltando ao primeiro componente do Osmani: **automations são o que fazem um loop ser loop.** É a peça que eu demorei mais para colocar, e a que mais mudou as coisas.
Tenho uma rotina semanal agendada que lê os transcripts da própria semana e mede o que aconteceu: quais ferramentas foram mais chamadas, quais skills dispararam, quais subagentes foram acionados. Aí ela cruza isso com o que já existe no meu setup e propõe: aqui houve repetição que merece uma skill nova; aqui uma skill existente ficou vaga e precisa de descrição melhor.
A barra de aceitação é explícita, porque sem ela a rotina cria skill para tudo: precisa ser **repetível e não-óbvio**, ter aparecido em duas sessões com a mesma forma, *ou* ter custado iteração pesada uma vez, *ou* ser uma correção minha que ainda não estava escrita em lugar nenhum, do tipo "nesse repositório não crie nada", "sempre use tal comando".
E o detalhe que faz funcionar: ela registra o que foi **rejeitado**. Sem isso, a rodada seguinte propõe a mesma coisa de novo, e você passa a ignorar o relatório inteiro.
Tem uma segunda camada: uma skill de governança que define como escrever artefato nesse setup, quando é regra e quando é skill, limite de tamanho, e a obrigação de procurar sobreposição antes de criar coisa nova. Cada regra dela rastreia para uma falha concreta que eu vivi.
O loop tem meta-loop. E é aí que ele para de ser configuração e começa a ser sistema.
#### Como eu montei essa rotina
O objetivo era fácil de enunciar: **toda semana, ler as minhas próprias sessões de trabalho e transformar o que se repetiu em skill**, nova quando não existe nada cobrindo, melhoria na que já existe quando existe. Nada de inventar processo: a fonte é o que eu de fato fiz na semana, com o agente, no ambiente real.
A primeira decisão apareceu antes de qualquer código: **onde vive o insumo.** E a resposta elimina de saída a opção mais confortável. Os transcripts das minhas sessões só existem na minha máquina, então um agendador na nuvem, que rodaria com o computador desligado, sem eu precisar lembrar de nada, veria commit e PR, e é exatamente isso que não interessa. Commit conta o que ficou de pé; transcript conta o que eu pedi, quantas tentativas custou e qual suposição estava errada. **O valor está no atrito, e o atrito só fica registrado localmente.** Sobrou tarefa agendada no sistema operacional chamando o cliente em modo headless: menos elegante, e a única com acesso ao que importa.
A segunda decisão foi de divisão de trabalho, e é a mesma tese do resto do artigo: **o que é determinístico não vai para o agente.** Destilar a semana é trabalho de shell, varrer os transcripts, contar chamada de ferramenta, extrair os prompts reais separando-os do ruído de plumbing, cruzar com o histórico de commits, listar o inventário de skills que já existe. Dezenas de megabytes viram um digest de umas seiscentas linhas em menos de um minuto, sem gastar um token. O agente entra depois, com o digest pronto na mão, para fazer só a parte que exige julgamento: isso é rotina ou foi acidente? já existe skill que cobre? melhora a que existe ou cria nova?
Aí vieram as paredes. Três, e todas se parecem exatamente igual do lado de fora, **o agente diz que precisa de aprovação e para**, sem pista de qual delas é:
- **O agente não escreve na própria camada de configuração.** O diretório de customização é caminho sensível: em modo não-interativo a escrita é recusada, com ou sem regra de permissão liberando explicitamente aquele caminho. E é proteção correta, rotina que pode reescrever as próprias permissões não é rotina, é risco. A saída foi inverter o fluxo: o agente escreve a proposta num diretório de staging, e um script de shell promove só o que casa um padrão estreito, arquivo `.md` dentro de `skills//`, nunca configuração, nunca hook, nunca executável, guardando backup do que for sobrescrito. O que o script recusa, ele registra.
- **Liberar o caminho não libera criar arquivo.** Regra de permissão com escopo de caminho não limpa a aprovação de **criação** de arquivo novo, e a execução trava pedindo uma confirmação que, em headless, ninguém pode dar. Precisa combinar com o modo de permissão que aceita edição. Bônus: diretório oculto, começando com ponto, simplesmente não casa com o glob da regra, perdi um ciclo inteiro procurando bug antes de renomear o diretório e ver funcionar.
- **Comando composto não casa allow-list.** Eu havia liberado o script coletor por caminho; o agente rodou `mkdir -p ... && ./coletor` e a regra não casou. Isso virou princípio, e é o que consolidou a divisão acima: **passo determinístico roda no wrapper, não dentro do agente.**
O que a primeira execução real entregou: **uma skill nova**, um procedimento de virada de ingress que atravessa duas camadas de infraestrutura e que nenhuma skill existente cobria; **duas melhoradas**, uma delas ganhou a descoberta que mais me custou na semana, a de que o dry-run do cliente de linha de comando valida schema mas não avalia lógica de política de admissão, então "passou no dry-run" não significa nada ali; e **quatro rejeitadas**, cada uma com o motivo escrito, três delas por duplicarem skill existente.
Mas o item que me convenceu de que a coisa tinha valor foi outro: **ela corrigiu uma memória minha que estava errada.** Eu tinha um fato registrado dizendo que um certo repositório seguia meu fluxo padrão de branch e PR. Durante a semana eu havia dito o contrário, duas vezes, em sessões diferentes. A rotina leu isso nos transcripts, viu a contradição com o que estava escrito, e reescreveu o registro. O loop consertando o estado externo do próprio loop.
E uma honestidade sobre o alcance: **o passe agendado é rede de segurança, não o evento principal.** Rodando sem supervisão, o agente não pode me perguntar "isso vai repetir?", e essa resposta é justamente o critério que separa skill útil de entulho. Quando eu rodo o mesmo procedimento à mão, numa sessão normal, sai skill melhor. O agendamento existe porque o insumo é perecível e disciplina humana não é confiável; o refino continua sendo meu. Outer loop, de novo.
A verificação que me deixou tranquilo não foi ela ter criado skill, foi rodar duas vezes na mesma janela. Na segunda, reconheceu que a semana já tinha sido processada, reconferiu as rejeições anteriores e **não escreveu nada**. Zero arquivos promovidos. Automação que reescreve o que já existe a cada execução não é automação, é ruído com agenda.
#### A automação que eu não escrevi
Outra automação que pensei: uma rotina para **apagar as sessões antigas**, com mais de uma semana. A motivação é menos glamourosa que a da anterior e mais séria. Transcript é texto puro, e **tudo que passa por uma ferramenta é gravado nele**, conteúdo de arquivo, saída de comando, o que eu colei no prompt. Em ambiente de plataforma isso significa detalhe de infraestrutura acumulando em texto claro no meu diretório de usuário, protegido só por permissão de arquivo do sistema. E o bom que o próprio claude code ja tem um mecanismo de limpeza: **o client já varre por idade na inicialização**, e o período é uma chave no arquivo de configuração do usuário, `~/.claude/settings.json`:
```json
{ "cleanupPeriodDays": 8 }
```
O default são 30 dias, o mínimo é 1. Baixar para 8 foi uma escolha minha.
**A varredura não cobre tudo.** Ela apaga transcript, transcript de subagente, saída grande derramada em arquivo, snapshot pré-edição, cache de imagem e de colagem. Só que o **histórico de prompts**, o arquivo que guarda tudo que eu já digitei, com data e projeto, fica fora dela e persiste indefinidamente. Quem baixa a retenção por privacidade e para aí resolveu a maior parte do problema achando que resolveu o problema inteiro.
**Retenção e janela de análise se amarram.** Se o transcript expira em oito dias e a rotina de skills olha oito dias para trás, os dois números batem no caso normal, mas uma semana perdida por férias ou máquina desligada fica irrecuperável, porque o insumo foi varrido antes da execução seguinte. Semana que não roda é semana que não existe. Duas configurações feitas em minutos, uma dependência entre elas que não estava escrita em lugar nenhum: é assim que loop vira sistema, e é por isso que a dependência precisa ir para o estado externo, se ela só existe na minha cabeça, ela não existe.
#### Um inventário inteiro, do zero até virar sistema
O exemplo mais completo de tudo isso trabalhando junto não veio da rotina agendada, veio de um pedido pontual: mapear todas as tecnologias em uso num ambiente de plataforma com dezenas de repositórios. Sem inventário prévio. Era descobrir do zero, e o resultado ia decidir o que precisava virar skill.
A primeira rodada foi fan-out puro: um agente por área, infraestrutura como código, pipelines, orquestração de containers, linguagens, todos em paralelo, cada um devolvendo o que achou. Saiu organizado, sem furo visível. Foi exatamente essa perfeição que me fez desconfiar: levantamento bom demais de um ambiente que eu sei que é bagunçado é sinal de cobertura rasa, não de sorte. Pedi mais uma passada, recortando por um repositório específico que eu sabia ser denso, e a lista de tecnologias daquele recorte sozinho quase dobrou o total. O primeiro fan-out tinha visitado cada área uma vez e chamado isso de completo.
Fechei a segunda rodada com o mesmo princípio de sempre: quem escreve não confere. Nova leva de agentes, mas com a instrução invertida, não confirme o que já está escrito, **tente refutar**. Cada um recebeu um pedaço do levantamento e a ordem explícita de achar erro, não validar acerto. Valeu a rodada: achou um item que não existia (um agente anterior tinha inventado um detalhe plausível que não batia com o ambiente real), achou outro atribuído ao lugar errado, e um terceiro marcado como "desativado" quando na verdade estava ativo em produção. Nenhum dos três ia aparecer se eu tivesse pedido para o mesmo agente reler o próprio trabalho, ele ia confirmar o que já acreditava.
Com o levantamento fechado, o passo seguinte foi virar aquilo em conhecimento operacional, não documento pra ler uma vez, skill que o sistema carrega quando alguém pedir ajuda com uma daquelas tecnologias. E aqui entrou a decisão que o resto do artigo já defende, aplicada em escala: **nem tudo virou skill.** Duas coisas viraram **hook**, porque a regra era "isso tem que acontecer sempre, sem depender do modelo lembrar", um aviso de dependência de terceiro que tinha acabado de ser descontinuada e um checador de configuração que falha calado em vez de dar erro. **Nada virou agente novo**, porque agente é persona isolada com escopo de ferramenta próprio, e cada tecnologia daquelas era conhecimento de referência, não um papel a interpretar. Artefato errado custa tanto quanto artefato nenhum, essa parte do julgamento não terceirizo.
Pra não terminar com dezenas de skills competindo pela mesma descrição, agrupei por domínio operacional, um `SKILL.md` raiz por área, arquivo de referência por tecnologia dentro dele, carregado só quando aquela tecnologia específica entra na conversa. Antes de escrever a primeira linha, consultei a documentação oficial do próprio formato de skill via MCP: a intuição de "menor é melhor" tem limite, e o padrão oficial recomenda exatamente esse agrupamento com disclosure progressivo, pra não competir por trigger nem custar contexto à toa quando ninguém precisa daquele arquivo.
O último passo foi replicar tudo numa segunda camada de customização, que outra ferramenta usa nesse mesmo ambiente. A motivação não foi capricho de organização: é redundância de verdade. Se o Claude Code sair do ar, tiver uma degradação, ou eu simplesmente precisar trocar de ferramenta num dia ruim, o conhecimento não desaparece junto, ele já existe traduzido, pronto para outro agente carregar. Skill, hook e regra viraram ativo do time, não vendor lock-in de configuração. Eu esperava find-and-replace de caminho. Não foi. A documentação oficial da outra ferramenta, puxada via MCP na hora, corrigiu duas suposições de uma vez: a numeração das regras "inegociáveis" era diferente entre as duas camadas, citar por número mantendo só o nome do arquivo teria virado referência errada, e o formato de skill que eu vinha usando já era, na prática, um padrão aberto que a outra ferramenta também suporta nativamente, pasta de recurso e tudo. MCP não é só pra puxar doc de infraestrutura. É pra puxar doc de qualquer coisa que eu não deveria assumir de memória, incluindo o próprio formato que eu uso pra ensinar o agente.
### Conclusão
O que eu levaria daqui, na ordem em que eu faria de novo:
- **Comece pelo verificador, não pelo agente.** Sem gate honesto, aumentar autonomia só aumenta a velocidade com que você acumula problema. Um loop com verificador ruim é pior que nenhum loop, porque parece estar funcionando.
- **Escreva o freio antes do acelerador.** Teto de iteração, regra de parada, guardrail que dispara antes da geração. Quatro dos cinco itens da anatomia de um loop são freios; essa proporção não é acidente.
- **Separe quem escreve de quem confere, por ferramenta, não por instrução.** Read-only de verdade é não ter a ferramenta de escrita.
- **Um hook que sai com código 2 é feedback de loop de verdade.** É a peça mais barata e mais eficaz do meu setup, e não tem nada de IA nela.
- **Escreva primeiro a trava de remoção, e faça ela desconfiar de você.** Toda operação destrutiva para e pede autorização, inclusive no modo que liberou o resto, inclusive quando o pedido veio de uma ferramenta e não do shell. É o único guardrail que protege contra o operador no automático, e não contra o agente. Falso positivo nessa checagem é preço, não defeito.
- **Exija que o teste de regressão prove que pega o bug.** Se ele passa igual com e sem a correção, não testa nada. Não pedir "escreva um teste". Use "reverta a correção e me mostre o teste falhando" é a defesa mais barata que existe contra reward hacking.
- **Ordene os gates por custo e nunca deixe pular degrau.** Compilar, unidade, integração com API real, cluster local espelhando o ambiente de verdade, e só então a imagem. A imagem é o resultado do loop, não uma etapa dele.
- **Deixe o agente ler o CI sozinho, mas só a parte que falhou.** Ele não precisa que você traduza o erro. Precisa de acesso ao veredito e de disciplina para não arrastar o log inteiro para o contexto.
- **Default otimista, correção barata.** Onde o loop precisaria perguntar, faça ele escolher o mais provável, declarar em voz alta o que escolheu e continuar. Pergunta bloqueante no começo de toda tarefa transforma o loop em formulário. Só não esqueça de escrever as exceções: se a busca voltar vazia, pede, nunca inventa.
- **Guarde o estado do ciclo onde qualquer sessão acha.** A chave da tarefa no nome da branch faz o objetivo sobreviver a compactação, a sessão nova e a subagente. Estado externo não precisa de banco; às vezes precisa só de uma convenção de nome respeitada.
- **Deixe a descrição fazer o roteamento.** Skill boa com descrição ruim não dispara. Escope regra por convenção de diretório, nunca por extensão nua.
- **Automation é o que separa configuração de sistema.** Sem rotina agendada, você tem um setup bonito. Com ela, você tem um loop.
- **Discorde do padrão quando o seu domínio pedir.** Eu tirei worktree porque em infra o isolamento que importa é de estado, não de arquivo.
E o mais importante: **o outer loop continua sendo seu.** Delegar o ciclo interno é alavancagem; delegar o julgamento é abdicação. A frase com que o Osmani fecha o artigo dele é a melhor síntese que eu achei disso, e serve de régua: *"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."*
---
# Vibe Coding com DevSecOps: a IA gerou o site, mas a segurança do deploy foi MINHA - TDC Florianópolis 2026
URL: https://www.orafaelferreira.com/artigos/tdc-floripa-2026-devsecops
Publicado: 2026-07-23
Categoria: Palestras
Tempo de leitura: 8 min de leitura
> Na Trilha Software Security do TDC Florianópolis 2026, mostrei como a IA gerou meu site e como DevSecOps, Terraform e GitHub Actions garantiram o deploy seguro.
## TDC Florianópolis 2026 — Trilha Software Security
No dia **23 de julho de 2026**, junto com [**Jéssica Mello**](https://www.linkedin.com/in/jessica-tmello/) (LowOps Consultoria), palestrei na [**Trilha Software Security do TDC Florianópolis**](https://thedevconf.com/tdc/2026/florianopolis/trilha-software-security), um dos maiores eventos de tecnologia do Brasil, realizado no **CentroSul, em Florianópolis - SC**.
A trilha abordou um tema central: **"Construindo software seguro do design à produção em tempos de IA"** — explorando como a IA generativa acelera o desenvolvimento, mas também expande riscos e responsabilidades.
### Agenda
**Sessão:** Vibe Coding com DevSecOps: a IA gerou o site, mas a segurança do deploy foi MINHA
**Palestrantes:**
- Rafael Ferreira (Senior Azure Platform Engineer, Stefanini North America, Microsoft MVP)
- Jéssica Mello (LowOps Consultoria)
Um estudo de caso sobre os limites e riscos do "vibe coding" quando confrontado com exigências reais de produção — e como DevSecOps resolve isso.
### Programação da Trilha Software Security
O dia foi repleto de conteúdo técnico de altíssimo nível:
- **10:30–11:05** | *Mobile 2026: O custo da compatibilidade e a nova era de exploits com IA* — Michel Anderson Lütz Teixeira (AI/R Company)
- **11:15–11:50** | *SecOps Autônomo: Automatizando Bumps de Dependência e Resolução de CVEs com IA em Pipelines Zero Trust* — Felipe Faria (Mindera)
- **11:55–12:30** | *Desenvolvimento seguro com IA: planejamento, revisão e Cross-Agent na prática* — Marcelo Martins (Unicred)
- **14:10–14:45** | *Vibe Coding com DevSecOps: a IA gerou o site, mas a segurança do deploy foi MINHA* — Rafael Ferreira & Jéssica Mello
- **14:50–15:25** | *Prompt Injection: um problema de segurança em LLMs* — Guilherme Luiz Maia Pinto (Fortress OS)
- **15:30–16:30** | *Painel: Da AppSec à AgentSec: quem garante a segurança quando a IA escreve, corrige, opera e decide?* — Georgia Maria Ferro Benetti, Rodrigo Diehl, Kalita da Silva, Gabriel Ferreira Ramos da Conceição
- **17:10–17:45** | *Eficiência em AppSec: Utilizando a IA para escalar Segurança em Aplicações* — Thiago Lotufo (Globo)
- **17:50–18:25** | *IA em produção é risco: como governar decisões automatizadas com segurança* — Wesley Souza (AdviceHealth)
### A Jornada: IA Escreve, Você Responde
#### O Problema
Meu portfólio pessoal (`orafaelferreira.com`) estava obsoleto. Precisava modernizá-lo rápido, com estilo contemporâneo, mantendo foco em conteúdo (artigos, palestras, certificações). Tempo era um luxo que não tinha.
#### O Prompt & o Lovable
Estruturei um prompt detalhado — estilo visual, seções esperadas (blog, palestras, sobre), stack preferido (React), tom de voz — e usei o [**Lovable**](https://lovable.dev/) para gerar **100% via IA generativa** uma primeira versão.
O resultado foi perfeito para um protótipo: um site one-page bonito, responsivo, rodando em produção em horas.
Mas aí vem o problema.
#### A Crise do Vibe Coding em Produção
Quando saí do "protótipo legal" pra "arquitetura profissional", os clássicos apareceram:
- **Vendor lock-in:** o Lovable gerou código otimizado pra sua plataforma, não pra ser exportado e sustentado.
- **Custo insustentável:** hospedagem on-demand sendo cobrada por requisição.
- **Arquitetura monolítica:** one-page, tudo bundled junto, sem code-splitting, sem preocupação com assets.
- **Falta de padrão:** sem versionamento Git, sem pipeline, sem testes, sem "agora meu site quebrou em produção, e aí?".
Ficou claro: **a IA é excelente em acelerar, mas não entende responsabilidade.**
#### Retomando o Controle
Exportei o código do Lovable pro [**GitHub**](https://github.com/orafaelferreiraa/orafaelferreira-com), e daí começou o trabalho real.
Refatorei com **[GitHub Copilot](https://github.com/features/copilot)** (que também gera código, mas agora *meu*, meu repositório, minhas decisões), adotei **GitFlow** completo, versionamento semântico, e transformei o "site bonito" em "sistema profissional":
- Separei conteúdo (TypeScript data files, não CMS) de apresentação.
- Estruturei componentes reutilizáveis.
- Implementei i18n (português + inglês).
#### DevSecOps de Verdade
Agora veio a camada que diferencia um hobby de um sistema em produção:
**Infraestrutura 100% como código** via [**Terraform**](https://www.terraform.io/):
- [**Azure Static Web App**](https://learn.microsoft.com/en-us/azure/static-web-apps/) (distribuição global, HTTPS nativo, hosting seguro).
- DNS automatizado (apex + www) com validação de domínio.
- Tudo versionado, revisível, auditável.
**Pipeline de segurança** via [**GitHub Actions**](https://github.com/features/actions):
- **[tflint](https://github.com/terraform-linters/tflint)** — análise estática do Terraform.
- **[trivy](https://github.com/aquasecurity/trivy)** — scanning de vulnerabilidades em imagens e artefatos.
- **[checkov](https://www.checkov.io/)** — compliance & policy as code.
- Rodam tanto no `terraform plan` quanto no `apply` — sem passar, não deploya.
**Segredos sem hardcoding:**
- [**Service Principal**](https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals) do Azure com mínimos privilégios.
- Secrets armazenados no GitHub (criptografados, nunca em logs de build).
- Rotação automática de credenciais.
**Resultado:** posso quebrar meu site à vontade — qualquer merge pra main passa por um gauntlet de checks, testes e validações. Se algo errado subir, ele bate em policy e não sai do passe.
#### Stack Final & Qualidade
A evolução não parou em infraestrutura:
- **Frontend:** [**React 19**](https://react.dev/) + [**TypeScript**](https://www.typescriptlang.org/) + [**Vite**](https://vitejs.dev/) + [**TailwindCSS**](https://tailwindcss.com/) + [**shadcn/ui**](https://ui.shadcn.com/) (design system moderno, acessível).
- **Testes:** pirâmide completa — unit/integration com [**Vitest**](https://vitest.dev/) & [**React Testing Library**](https://testing-library.com/), E2E com [**Playwright**](https://playwright.dev/).
- **SEO tradicional + GEO:** structured data, meta tags, sitemaps, RSS — mas também otimizado pra "Generative Engine Optimization" (como LLMs descobrem conteúdo).
Tudo isso não seria possível se eu tivesse confiado 100% no "vibe coding" inicial.
### Os 4 C's do Cloud Native Security (Aplicados Aqui)
A estrutura clássica de segurança em cloud funciona em camadas:
1. **Cloud:** políticas de acesso, roles, networking (tudo Terraform, nada clicável em portal).
2. **Cluster/Infra:** Azure Static Web App é gerenciada, mas o Terraform valida config & compliance.
3. **Container:** Trivy verifica imagens; Checkov valida policies.
4. **Code:** GitHub Copilot ajuda, mas os testes garantem que o código faz o que deve.
Nenhuma camada é ignorada. Nenhuma depende só da IA.
### De "Prompt Engineer" a "Harness Engineer"
Quando você usa IA pra gerar código, a evolução natural é:
- **Fase 1:** Prompt Engineer — "escrever bons prompts" é o skill.
- **Fase 2:** Harness Engineer — "estruturar o loop IA + automação + feedback" é o skill.
Um harness engineer não só escreve prompts bons; ele:
- Define pipeline, testes, validações que a IA passa por.
- Entende quando a IA pode ir sozinha e quando não.
- Desenha feedback loops (errar, aprender, melhorar).
- Não confia na IA sozinha — a IA é aceleradora, não substituta.
Essa jornada do site foi aprender a ser um harness engineer, não só um prompt engineer.
### Checklist Prático: Do "Funcionando" ao "Seguro em Produção"
Aqui está o que você **não pode ignorar** depois que a IA gera algo funcional:
- **Segredos:** nunca hardcode. Use vaults, env vars, managed secrets.
- **Infraestrutura:** IaC (Terraform, CloudFormation, ARM) — nada de cliques em portal.
- **Testes:** unit, integration, E2E — a IA gera código, mas testes garantem que funciona *seu* caso de uso.
- **Scanning:** SAST (código), DAST (rodando), dependency checks, container scanning.
- **Logs & Monitoramento:** quem vai investigar incidente às 3 da manhã? Você. Logo, precisa de visibilidade.
- **Documentação:** a IA gera código rápido, mas documentação arquitetural é coisa de humano.
- **Código review:** até a IA merece code review.
- **Backup & Disaster Recovery:** quando der merda (e vai dar), você precisa de plano B.
### Lições da Jornada
1. **Um prompt bem estruturado bate tentativa e erro** — qualidade da entrada determina qualidade da saída.
2. **Unir IA + automação + cloud não é o futuro; é o presente** — mas exige T-shaped skills (rápido em amplitude, profundo em especialização).
3. **UX importa tanto quanto o produto** — design é decisão, não accident.
4. **A IA é o acelerador; você é o piloto** — profissional generalista (velocidade, vibe coding) precisa ser também especialista em T (DevOps, Terraform, Cloud, Security) pra sustentar o que a IA acelera.
E um thought final, polêmico: **se você não está gostando do seu trabalho, ou não está usando IA do jeito certo, ou está no emprego errado.**
### Slides da Apresentação
**Slides da Apresentação:** [Vibe Coding com DevSecOps: a IA gerou o site, mas a segurança do deploy foi MINHA](https://stoblobcertificados011.blob.core.windows.net/palestras/tdcfloripa26.pdf)
### Repositórios
- [Repositório do Site](https://github.com/orafaelferreiraa/orafaelferreira-com) — código-fonte, Terraform, pipeline completa.
Se você está mergulhando em vibe coding, generative AI, ou IA no deploy — as lições dessa jornada valem ouro.
---
# MCP Server com Docker e Terraform: discovery, troubleshooting e produtividade
URL: https://www.orafaelferreira.com/artigos/terraform-mcp-server-docker
Publicado: 2026-06-27
Categoria: Artigos
Tags: Terraform, Docker, DevOps, Platform Engineering, MCP, IA
Tempo de leitura: 15 min de leitura
> Um guia direto ao ponto para usar Terraform MCP Server com Docker no dia a dia: discovery, troubleshooting e produtividade
### Resumo rápido
- MCP cria um padrão para clientes de IA se conectarem a ferramentas e dados externos.
- Terraform MCP Server é uma forma prática de trazer contexto de providers, módulos, runs e plans para um workflow mais previsível.
- Agentes de codificação trabalham em um loop de execução (análise, ação e observação), e dá para guiar esse loop com engenharia.
- MCP e skills se completam: o MCP conecta o agente a dados atuais e as skills carregam as boas práticas para orientar cada passo.
O [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) cria um formato padrão para um cliente consultar ferramentas e dados sem ficar adivinhando formato ou fazendo scraping de texto.
O protocolo foi inicialmente desenvolvido pela [Anthropic](https://www.anthropic.com/) e hoje evolui como padrão aberto no ecossistema.
E o [Terraform MCP Server](https://developer.hashicorp.com/terraform/mcp-server) coloca isso no mundo Terraform.
### MCP é tipo um "USB da internet"
Uma analogia que ajuda muito: MCP funciona como um "USB-C" para apps de IA.
No mundo físico, você conecta mouse, teclado, webcam no mesmo padrão. No mundo de IA, você conecta servidores MCP de docs, cloud, banco, ticket, observabilidade e automação no mesmo protocolo.
Isso permite trocar informações sem reescrever tudo e diminui acoplamento entre cliente e integrações.
Exemplos simples:
- um agente conecta no MCP do Terraform para ler módulos e providers
- o mesmo agente conecta no MCP de observabilidade para investigar incidente
- depois conecta no MCP de wiki interna para buscar padrões do time
### Como o agente de IA realmente trabalha: o loop de execução
Antes de plugar qualquer MCP, vale entender como um agente de codificação (Claude Code, GitHub Copilot, Codex e afins) executa uma tarefa. Ele não resolve tudo de uma vez: trabalha em um **loop de execução**.
O ciclo se repete mais ou menos assim:
- **Análise** — o agente lê a tarefa (ou a especificação) e decide o próximo passo
- **Ação** — chama uma ferramenta: ler um arquivo, rodar um comando ou consultar um MCP
- **Observação** — lê o resultado daquela ação
- **Repetição** — volta para a análise e segue até concluir a tarefa
Quando você fica trocando prompt atrás de prompt no chat, corrigindo na tentativa e erro, o agente decide sozinho cada passo, sem trilho. É o famoso "vibe coding": até funciona, mas rende pouco e erra bastante.
A alternativa é aplicar engenharia a esse ciclo — guiar o loop em vez de só reagir a ele. Para isso existem dois controles complementares: **skills** (direção) e **MCPs** (ferramentas).
### Skills vs MCPs: dois controles que se completam
É fácil confundir os dois, mas cada um resolve um problema diferente:
- **MCP é o encanamento.** Dá ao agente *acesso* a ferramentas e dados externos — aqui, a documentação viva de providers e módulos do Terraform. Responde a "o que o agente consegue alcançar?".
- **Skill é o livro-texto.** Empacota *conhecimento e boas práticas* que o agente carrega sob demanda: workflows, convenções e guardrails. Responde a "como o agente deve trabalhar?".
A própria [HashiCorp resume bem](https://www.hashicorp.com/en/blog/introducing-hashicorp-agent-skills): o MCP é o "cano" que conecta dados à IA, enquanto as [Agent Skills](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) são os "livros-texto" de conhecimento — e o melhor resultado vem de usar os dois juntos.
Na prática, com Terraform:
- **só com MCP:** o agente consulta a versão atual do provider e evita gerar código preso a uma versão antiga do treinamento
- **só com skill:** o agente segue o style guide, escreve testes e revisa segurança, mas sem dados atualizados
- **com os dois:** dados atuais e boas práticas dentro do mesmo loop
Skills são um [formato aberto](https://agentskills.io/home) criado pela Anthropic: cada uma é uma pasta com um arquivo `SKILL.md` que descreve, em linguagem natural, quando e como o agente deve agir. Diferente de um prompt pontual, a skill é reutilizável e só entra em contexto quando é relevante.
### No dia a dia
Sem MCP, o fluxo costuma ser:
1. pesquisar manualmente provider/módulo
2. abrir várias abas para comparar versões
3. cruzar informação de workspace, run e plan na mão
4. responder o time com base em contexto parcial
Com MCP, um cliente compatível consegue consultar essas informações de forma estruturada.
Em vez de prompt genérico, você chama uma tool específica e recebe dados previsíveis. Isso reduz erros, acelera decisões e melhora rastreabilidade.
No dia a dia, os ganhos mais claros são:
- **discovery mais rápido:** buscar providers e módulos sem navegar em 10 páginas
- **menos erro de versão:** consultar versões recentes de forma objetiva
Exemplos de tools disponíveis:
- **search_providers** e **get_provider_details**
- **search_modules** e **get_module_details**
- **get_latest_provider_version** e **get_latest_module_version**
- **list_workspaces** e **get_workspace_details**
- **get_plan_json_output** e **get_run_details**
### Onde encontrar MCPs oficiais na internet
Se você quer fontes confiáveis para descobrir servidores MCP:
- [Site oficial do MCP](https://modelcontextprotocol.io/) (oficial: conceitos, spec e guias)
- [Organização oficial no GitHub](https://github.com/modelcontextprotocol) (oficial)
- [Lista de servidores do ecossistema MCP](https://github.com/modelcontextprotocol/servers) (comunidade/ecossistema)
- [Registry MCP da comunidade](https://github.com/modelcontextprotocol/registry) (comunidade)
Para ecossistemas grandes, vale acompanhar registries e catálogos de vendors:
- [Docker MCP Registry](https://hub.docker.com/mcp) (oficial Docker)
- [Microsoft MCP Registry](https://github.com/mcp?utm_source=vscode-website&utm_campaign=mcp-registry-server-launch-2025) (oficial Microsoft)
### Skills oficiais de Terraform da HashiCorp
Além do MCP Server, a HashiCorp publicou uma biblioteca aberta de skills: o [HashiCorp Agent Skills](https://www.hashicorp.com/en/blog/introducing-hashicorp-agent-skills), disponível no repositório [hashicorp/agent-skills](https://github.com/hashicorp/agent-skills).
As skills de Terraform ajudam o agente a:
- **gerar código no style guide** oficial da HashiCorp, em vez de convenções aleatórias encontradas na internet
- **escrever e rodar testes** com o framework nativo de testes do Terraform
- **orquestrar com Terraform Stacks** cenários multi-ambiente e multi-região
- **desenvolver e manter providers** seguindo o plugin framework (schema, ciclo de vida e breaking changes)
- **refatorar módulos**, quebrando configurações monolíticas em módulos reutilizáveis
Instalar é rápido. Para todas as skills, via npx:
```bash
npx skills add hashicorp/agent-skills
```
Ou uma skill específica:
```bash
npx skills add hashicorp/agent-skills/terraform/code-generation/skills/terraform-style-guide
```
No Claude Code, dá para instalar como plugin:
```bash
claude plugin marketplace add hashicorp/agent-skills
claude plugin install terraform-code-generation@hashicorp
```
O ganho reforça o tema deste artigo: a skill entrega as boas práticas e o MCP entrega os dados atuais. Juntos, reduzem alucinação e mantêm o código dentro do padrão.
### Onde o Docker entra de verdade
Reduzir variação de ambiente. Com [Docker](https://docs.docker.com/), você empacota o servidor MCP de forma reproduzível para:
- notebook local
- ambiente de desenvolvimento
- CI/CD
- máquina de quem entrou no time ontem
Isso corta o clássico "na minha máquina funciona" e ajuda a manter o mesmo comportamento entre ambientes.
### Setup mínimo para começar
Primeiro, confirme o Terraform no ambiente:
```bash
terraform version
```
Depois, rode o servidor MCP com Docker (exemplo; ajuste conforme a documentação oficial e versão mais recente):
```bash
docker run --rm -it --name terraform-mcp -e TF_IN_AUTOMATION=true -e TF_LOG=INFO -v "${PWD}:/workspace" -w /workspace hashicorp/terraform-mcp-server:1.0.0
```
### Primeira chamada real (hands-on)
Depois de subir o servidor MCP, o fluxo mínimo no cliente costuma ser:
1. listar as tools disponíveis
2. chamar uma tool de discovery (ex.: `search_providers`)
3. validar estrutura de resposta antes de automatizar
Exemplo de resposta esperada (resumida). Os campos exatos podem variar conforme a tool e o cliente MCP:
```json
{
"providers": [
{
"name": "azurerm",
"namespace": "hashicorp",
"latest_version": "x.y.z"
}
]
}
```
Com isso, você já valida conectividade, autenticação e formato dos dados.
### Como instalar e rodar MCP com Node.js (o mínimo necessário)
Se você quiser criar ou testar um MCP sem Docker, normalmente precisa de:
- Node.js LTS (18+ ou 20+)
- npm, pnpm ou yarn
- um cliente MCP (editor, agente, CLI, ou o Inspector)
Exemplo de bootstrap rapido com Node:
```bash
mkdir meu-mcp-node && cd meu-mcp-node
npm init -y
npm install @modelcontextprotocol/xxxx
```
Estrutura mínima comum:
- `package.json`
- `server.ts`
Exemplo mínimo de servidor (conceitual):
```ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
const server = new Server(
{ name: "meu-mcp", version: "0.1.0" },
{ capabilities: { tools: {} } }
);
// Registrar tools aqui (status, healthcheck, consultas etc.)
```
Execução típica em desenvolvimento:
```bash
npx tsx server.ts
```
No cliente MCP, configure esse servidor para rodar via stdio.
- criar um servidor MCP em TypeScript/JavaScript
- expor tools (ex.: consultar status, buscar docs, executar validações)
- rodar por stdio para o cliente consumir
Para testar localmente, muita gente usa o [MCP Inspector](https://github.com/modelcontextprotocol/inspector).
Se a equipe usa Docker em tudo, a abordagem mais estável é empacotar também o MCP Node em container para padronizar runtime.
### Troubleshooting rápido
Quando estou com erro, normalmente eu peço ajuda para o agent corrigir mesmo.
Exemplo de configuracao MCP (Terraform MCP Server via Docker/stdio):
```json
"io.github.hashicorp/terraform-mcp-server": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"TFE_ADDRESS",
"-e",
"TFE_TOKEN",
"-e",
"ENABLE_TF_OPERATIONS",
"hashicorp/terraform-mcp-server:1.0.0"
],
"env": {
"TFE_ADDRESS": "${input:TFE_ADDRESS}",
"TFE_TOKEN": "${input:TFE_TOKEN}",
"ENABLE_TF_OPERATIONS": "${input:ENABLE_TF_OPERATIONS}"
},
"gallery": "https://api.mcp.github.com",
"version": "1.0.0"
}
```
### Fluxo prático
1. subir o servidor MCP em container
2. conectar o cliente MCP (editor, agente ou automação)
3. validar uma consulta de discovery (provider/módulo)
4. validar uma consulta operacional (workspace/run/plan)
### Guardrails que você não deve ignorar
Se o servidor tiver acesso a ambientes reais, trate como componente crítico:
- use credenciais com privilégio mínimo
- evite segredo em variável solta no container
- defina limites claros para operações permitidas
- habilite logs suficientes para auditoria e troubleshooting
- separe bem o que é dev, homolog e prod
MCP acelera muito, mas sem guardrail ele também acelera o caos!
Se quiser aprofundar, estes dois cursos da Anthropic são ótimos pontos de partida:
- [Introduction to Model Context Protocol](https://anthropic.skilljar.com/introduction-to-model-context-protocol)
- [Model Context Protocol Advanced Topics](https://anthropic.skilljar.com/model-context-protocol-advanced-topics)
Resumo:
- **Terraform** continua sendo o motor declarativo
- **MCP** organiza como ferramentas e agentes consomem contexto atualizado
- **Skills** carregam as boas práticas que guiam o agente no loop de execução
- **Docker** entrega repetibilidade para rodar isso sem drama
Se a meta é reduzir erros operacionais e ganhar velocidade com controle, combinar Terraform MCP Server, skills e Docker é um passo bastante útil.
---
# Meu primeiro curso de Computação em Nuvem: práticas e governança com Azure
URL: https://www.orafaelferreira.com/artigos/alura-cloud-computing-fundamentos-iaas-paas-saas
Publicado: 2026-06-27
Categoria: Posts
Tags: Azure, Cloud, DevOps, Terraform, FinOps, IA
Tempo de leitura: 4 min de leitura
> Registro do curso que gravei para a Alura, com foco em fundamentos de cloud, governança, segurança, FinOps, IaC, automação e uso de IA com Azure.
## Computação em Nuvem: práticas e governança com Azure Na ALURA!
Salve, galera. Quero compartilhar com vocês que recentemente gravei o curso **Computação em Nuvem: práticas e governança com Azure** na Alura e ele já está no ar.
[**Link Oficial do Curso**](https://www.alura.com.br/curso-online-cloud-computing-fundamentos-de-iaas-paas-e-saas)
Caso não seja ainda aluno da Alura, você pode se inscrever com o link: [**Link amigo**](https://www.alura.com.br/promocao/awin_10EstudeAlurax)
### Por que esse curso existe
Há alguns anos, aprender cloud significava assistir horas de vídeo e, no final, criar uma máquina virtual. Hoje isso já não é suficiente.
Quem trabalha com Azure precisa entender arquitetura, segurança, governança, FinOps, Infrastructure as Code, automação e, agora, como utilizar IA para acelerar tudo isso.
A proposta não é criar mais um curso mostrando onde clicar no portal da Azure.
Quis construir um material que aproxima o estudante do que realmente acontece no mercado, com uma abordagem prática e conectada aos desafios de quem atua com infraestrutura e plataforma.
### O que o curso cobre
Ao longo de mais de 20 horas de conteúdo, passamos por temas como:
- Fundamentos de Cloud Computing
- Azure na prática
- Arquitetura de soluções em nuvem
- Segurança, identidade e governança
- FinOps e otimização de custos
- Redes e conectividade
- Infrastructure as Code com Terraform
- Como utilizar IA para acelerar o provisionamento de infraestrutura
- CI/CD, automação e boas práticas
- Well-Architected Framework e estratégias de migração
### Para quem o curso foi pensado
Esse conteúdo foi pensado para profissionais de infraestrutura, engenheiros de plataforma, arquitetos de soluções, profissionais de DevOps e estudantes de tecnologia que querem aprender práticas aplicáveis em Azure e conceitos multi-cloud para projetar, governar e operar ambientes em nuvem.
- entender modelos de serviço como IaaS, PaaS e SaaS
- projetar arquiteturas resilientes e escaláveis
- orquestrar e versionar infraestrutura com IaC
- gerenciar redes, conectividade e políticas
- aplicar governança, controle de acesso e otimização de custos
- automatizar pipelines e monitorar aplicações com foco em disponibilidade
### O que tem de prática
- laboratórios de rede, compute e storage
- App Services, Functions e bancos gerenciados
- governança e permissão com usuários, grupos, políticas e identidade
- IA para engenharia de cloud
- zonas de disponibilidade
- Well-Architected Framework
- estratégias de migração
Foi um projeto enorme, com muito planejamento e muito cuidado para transformar experiência de mercado em aprendizado aplicável.
Se você já é aluno, depois me conta o que achou. Seu feedback ajuda bastante e me dá ainda mais direção para os próximos conteúdos.
Se você quer aprender cloud indo além do básico, tenho certeza que esse curso vai te ajudar BASTANTE.
---
# GitHub Copilot in VSCode: Agents That Debug, Profile, and Test
URL: https://www.orafaelferreira.com/artigos/github-copilot-vscode-agents-debug-profile-test
Publicado: 2026-06-20
Categoria: Palestras
Tags: IA, DevOps, GitHub Copilot, VSCode
Tempo de leitura: 4 min de leitura
> No Microsoft Build //localhost: Florianópolis, mostrei como agentes do GitHub Copilot podem acelerar debugging, profiling e testes dentro do Visual Studio Code.
No dia **20 de junho de 2026**, realizamos o [**Microsoft Build //localhost: Florianópolis**](https://developer.microsoft.com/pt-br/reactor/events/27206/) em **Florianópolis** e apresentei uma talk que conectou uma ideia simples com impacto direto no dia a dia: agentes de IA não servem só para escrever código, eles também podem ajudar a investigar, medir e validar software com mais contexto.
O evento reuniu pessoas interessadas em IA, cloud, DevOps e desenvolvimento moderno. A proposta da palestra foi mostrar, na prática, como o **GitHub Copilot no VSCode** pode atuar como um parceiro de trabalho quando o fluxo exige análise, repetição e rapidez.
Evento organizado por mim e **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)**, representando a comunidade [**Azure User Groups Brasil**](https://azureusergroupsbrasil.com.br/), com o objetivo de aproximar a comunidade de cenários reais de uso do **GitHub Copilot** no dia a dia de quem constrói software.
Agentes bem configurados encurtam esse ciclo sem substituir a habilidade crítica do desenvolvedor. Eles ajudam a chegar mais rápido no ponto certo da investigação.
Na prática, o maior ganho aparece quando o agente ajuda a organizar o problema.
Em vez de abrir dezenas de arquivos sem direção, a conversa pode começar com contexto, hipóteses e sinais observáveis. Isso ajuda a:
- identificar a parte mais provável do bug
- sugerir arquivos e símbolos relacionados
- resumir o comportamento esperado versus o comportamento real
O resultado é menos tempo procurando e mais tempo corrigindo.
### Harness com agentes
Um agente pode ajudar a interpretar sinais de uso de CPU, latência, alocação e dependências, principalmente quando o problema está espalhado por mais de uma camada do sistema.
O ponto não é automatizar o diagnóstico inteiro. O ponto é chegar mais rápido nas perguntas certas:
- onde a aplicação passa mais tempo?
- qual etapa está repetindo trabalho desnecessário?
- qual caminho vale instrumentar primeiro?
### Testing com agentes
Testes são um dos melhores usos para esse tipo de fluxo. Agentes ajudam a transformar um cenário solto em um conjunto de casos reproduzíveis, o que facilita validar correções e evitar regressões. Isso vale especialmente quando o comportamento envolve dependências, interfaces ou estados difíceis de reproduzir manualmente.
A mensagem principal foi que agentes funcionam melhor quando entram no fluxo certo:
- com contexto
- com objetivo claro
- com validação humana no final
Quando isso acontece, o desenvolvedor ganha velocidade sem perder controle técnico.
Confira os conteúdos que tivemos no evento:
### From CLI to PR: Automating the Path to Merged Code
🔹 [Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)
Nesta demonstracao pratica, mostramos como utilizar GitHub Copilot CLI e agentes para automatizar desde o planejamento ate a revisao de Pull Requests, explorando gerenciamento de contexto, automacao e fluxos modernos de desenvolvimento.
### GitHub Copilot no Visual Studio: Agents That Debug, Profile and Test
🔹 [Rafael Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)
Nesta sessão, exploramos como os agentes do GitHub Copilot podem ajudar a investigar problemas, identificar gargalos de performance, analisar infraestrutura como codigo, entender comportamentos complexos de aplicacoes e acelerar troubleshooting em ambientes reais.
Menos tempo procurando a causa do problema.
Mais tempo resolvendo o problema.
### From Zero to Deployed on Azure with AI Agents
🔹 [Claudio Raposo](https://www.linkedin.com/in/claudioraposo/)
Um laboratorio pratico para quem quer colocar a mao na massa. Partindo de um terminal vazio, os participantes construiram e publicaram uma aplicacao no Azure utilizando GitHub Copilot CLI e agentes de IA para provisionamento de recursos, desenvolvimento, debugging e deployment.
### Slides
- [Build 2026 - GitHub Copilot in VSCode](https://stoblobcertificados011.blob.core.windows.net/palestras/build26.pdf)
- [LinkedIn Post Divulgação evento](https://www.linkedin.com/posts/orafaelferreiraa_microsoftbuild-githubcopilot-azure-activity-7473336231129522176-33Lc?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAiBr9cBknrEzJyFEqCS03tes6G6R1yclRw)
### Conecte-se com a comunidade
Se você quiser acompanhar os próximos encontros e participar da comunidade:
- [Site oficial](https://azureusergroupsbrasil.com.br/)
- [Linktree](https://linktr.ee/azureusergroupsbrasil)
- [Grupo no WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)
- [YouTube](https://www.youtube.com/@azureusergroupsbrasil?sub_confirmation=1)
- [LinkedIn](https://www.linkedin.com/company/azureusergroupsbrasil)
- [Meetup](https://www.meetup.com/azureusergroupsbrasil)
---
# Microsoft Build //localhost: Florianópolis
URL: https://www.orafaelferreira.com/artigos/microsoft-build-localhost-florianopolis
Publicado: 2026-06-20
Categoria: Organização de Eventos
Tags: Organização de Eventos, IA, GitHub Copilot, Microsoft Foundry
Tempo de leitura: 3 min de leitura
> Um registro do evento que organizei com o Vinicius Deschamps em Florianópolis, com foco em IA aplicada ao desenvolvimento, cloud e prática real.
No dia **20 de junho de 2026**, realizamos o [**Microsoft Build //localhost: Florianópolis**](https://developer.microsoft.com/pt-br/reactor/events/27206/) em **Florianópolis**, uma edição local pensada para colocar IA, desenvolvimento moderno e prática de engenharia no centro da conversa.
Evento organizado por mim e **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)**, representando a comunidade [**Azure User Groups Brasil**](https://azureusergroupsbrasil.com.br/), com o objetivo de aproximar a comunidade de cenários reais de uso do **GitHub Copilot** no dia a dia de quem constrói software.
A proposta foi reunir desenvolvedores, engenheiros de cloud e pessoas de comunidade para discutir o que muda quando agentes de IA entram no fluxo de trabalho.
Mais do que falar de tendência, queríamos mostrar:
- como agentes ajudam a acelerar investigação, validação e entrega
- como manter critério técnico mesmo usando IA
- como conectar criação, troubleshooting e automação em um fluxo prático
### O evento em Florianópolis
O encontro aconteceu em Florianópolis e fez parte da série **[Microsoft Build](https://news.microsoft.com/build-2026/) //localhost**, com uma pegada local e muito próxima da realidade de quem está construindo software em produção.
**Evento:** Microsoft Build //localhost: Florianópolis
**Data:** 20 de junho de 2026
**Cidade:** Florianópolis
- [Página oficial do evento](https://developer.microsoft.com/pt-br/reactor/events/27206/)
- [LinkedIn Post Divulgação evento](https://www.linkedin.com/posts/orafaelferreiraa_microsoftbuild-githubcopilot-azure-activity-7473336231129522176-33Lc?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAiBr9cBknrEzJyFEqCS03tes6G6R1yclRw)
A programação foi desenhada para conectar IA e prática de engenharia.
Os temas giraram em torno de:
- GitHub Copilot no fluxo de desenvolvimento
- uso de agentes para debugging, profiling e testes
- automação com foco em entrega e governança
Confira os conteúdos que tivemos no evento:
### From CLI to PR: Automating the Path to Merged Code
🔹 [Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)
Nesta demonstracao pratica, mostramos como utilizar GitHub Copilot CLI e agentes para automatizar desde o planejamento ate a revisao de Pull Requests, explorando gerenciamento de contexto, automacao e fluxos modernos de desenvolvimento.
### GitHub Copilot no Visual Studio: Agents That Debug, Profile and Test
🔹 [Rafael Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)
Nesta sessão, exploramos como os agentes do GitHub Copilot podem ajudar a investigar problemas, identificar gargalos de performance, analisar infraestrutura como codigo, entender comportamentos complexos de aplicacoes e acelerar troubleshooting em ambientes reais.
Menos tempo procurando a causa do problema.
Mais tempo resolvendo o problema.
### From Zero to Deployed on Azure with AI Agents
🔹 [Claudio Raposo](https://www.linkedin.com/in/claudioraposo/)
Um laboratorio pratico para quem quer colocar a mao na massa. Partindo de um terminal vazio, os participantes construiram e publicaram uma aplicacao no Azure utilizando GitHub Copilot CLI e agentes de IA para provisionamento de recursos, desenvolvimento, debugging e deployment.
Esse tipo de evento só acontece porque existe comunidade por trás.
Se você participou, obrigado pela presença. Se não conseguiu ir, este post fica como registro da organização e do propósito da edição.
### Conecte-se com a comunidade
Se você quiser acompanhar os próximos encontros e participar da comunidade:
- [Site oficial](https://azureusergroupsbrasil.com.br/)
- [Linktree](https://linktr.ee/azureusergroupsbrasil)
- [Grupo no WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)
- [YouTube](https://www.youtube.com/@azureusergroupsbrasil?sub_confirmation=1)
- [LinkedIn](https://www.linkedin.com/company/azureusergroupsbrasil)
- [Meetup](https://www.meetup.com/azureusergroupsbrasil)
---
# Atualização sobre a evolução do site: Temos mais Terraform, DNS-as-Code e multi-subscription
URL: https://www.orafaelferreira.com/artigos/artigo-terraform-infra-evolutiva
Publicado: 2026-06-14
Categoria: Artigos
Tempo de leitura: 6 min de leitura
> A infraestrutura do blog saiu da migração inicial para um desenho mais maduro: subscriptions separadas, DNS como código, azapi e preservação de registros TXT.
## Visão Geral
No [artigo anterior](https://www.orafaelferreira.com/artigos/artigo-terraform-infra-cicd), eu mostrei a base da construção do blog com Terraform, Azure Static Web Apps e GitHub Actions. Esse texto é o passo seguinte: o que eu evoluí depois que a primeira versão já estava no ar. A ideia aqui não é repetir o conteúdo anterior, é mostrar como a infraestrutura evoluiu depois dessa decisão.
A maior mudança dessa fase foi trazer o meu domínio **orafaelferreira.com** para dentro do Azure. Ele estava registrado e com o DNS na **GoDaddy**, e eu migrei a zona para o **Azure DNS**, assim me possibilitando gerenciar o domínio como código, junto com o resto da infraestrutura.
Com o domínio dentro do Azure, eu passo a:
- Centralização dos recursos no provider Azure
- controlar a zona DNS via Terraform, no mesmo fluxo de IaC do site
- reaproveitar o mesmo domínio em outros projetos e subdomínios
- versionar e auditar cada mudança de registro como faço com qualquer outro recurso
Algumas features:
- Terraform como infraestrutura como código (IaC)
- domínio orafaelferreira.com migrado da GoDaddy para o Azure DNS
- subscriptions separadas para site e DNS
- DNS-as-Code com CNAME, A e TXT gerenciados no próprio Terraform
- azapi para cobrir o que o provider não resolve e manter tudo em IaC
### 1. Tirando o domínio da GoDaddy
Antes, o orafaelferreira.com vivia inteiro na GoDaddy: registro e DNS no mesmo lugar, tudo editado na mão pelo painel. Funcionava, mas me prendia a cliques e deixava o DNS fora do meu fluxo de IaC.
A migração foi direta: criei a zona no Azure DNS, recriei os registros que já existiam e apontei os name servers do domínio na GoDaddy para os name servers do Azure. A partir daí, a autoridade do DNS passou a ser o Azure.
Isso me abre espaço para reusar o orafaelferreira.com em outros laboratórios e projetos sem repetir configuração manual.
### 2. Duas subscriptions
Aqui vou mostrar como trabalhar com duas subscriptions usando aliases de provider no Terraform. Em vez de depender de um único contexto, eu passo a indicar explicitamente onde cada recurso vive. Coisas que acontecem no dia a dia real, com ambientes de produção, que decidi espelhar e colocar em prática aqui.
```terraform
provider "azurerm" {
features {}
}
provider "azurerm" {
alias = "site"
features {}
subscription_id = var.site_subscription_id != "" ? var.site_subscription_id : null
}
provider "azurerm" {
alias = "dns"
features {}
subscription_id = var.dns_subscription_id != "" ? var.dns_subscription_id : null
}
provider "azapi" {
alias = "dns"
subscription_id = var.dns_subscription_id != "" ? var.dns_subscription_id : null
}
```
Visualmente, a arquitetura ficou assim:
### 3. DNS com IAC
Essa foi a parte que mais evoluiu em relação ao artigo anterior. Antes, a ideia era basicamente “subir o SWA e validar o domínio”. Agora o DNS também virou parte do código declarativo.
```terraform
data "azurerm_dns_zone" "this" {
provider = azurerm.dns
name = "orafaelferreira.com"
resource_group_name = data.azurerm_resource_group.dns_rg.name
}
resource "azurerm_dns_cname_record" "www" {
provider = azurerm.dns
name = "www"
zone_name = data.azurerm_dns_zone.this.name
resource_group_name = data.azurerm_dns_zone.this.resource_group_name
ttl = 3600
record = azurerm_static_web_app.this.default_host_name
}
resource "azurerm_static_web_app_custom_domain" "www" {
provider = azurerm.site
static_web_app_id = azurerm_static_web_app.this.id
domain_name = "www.orafaelferreira.com"
validation_type = "cname-delegation"
}
```
- o www aponta diretamente para o host do SWA
- a validação passa a refletir o estado real do DNS
#### O que é Apex?
O **apex** (ou naked domain) é o domínio raiz, sem nenhum prefixo. No caso do meu site, "orafaelferreira.com" é o apex, enquanto "www.orafaelferreira.com" é um subdomínio. O apex é importante porque é a forma "limpa" e mais comum de acessar um site: quando alguém digita só "orafaelferreira.com", está acessando o apex.
O apex também ganhou tratamento próprio. Em vez de esconder isso atrás de configuração manual, eu explicitei o caminho do registro A e a validação por TXT.
```terraform
locals {
apex_txt_values = distinct(concat(
var.apex_base_txt_records,
[azurerm_static_web_app_custom_domain.apex.validation_token]
))
}
resource "azurerm_dns_a_record" "apex" {
provider = azurerm.dns
name = "@"
zone_name = data.azurerm_dns_zone.this.name
resource_group_name = data.azurerm_dns_zone.this.resource_group_name
ttl = 3600
target_resource_id = azurerm_static_web_app.this.id
}
```
O detalhe importante está no distinct(concat(...)). Ele preserva os TXT base do domínio, como SPF, e adiciona o token de validação do Azure sem sobrescrever o que já existe.
Esse tipo de cuidado evita uma classe de erro chata: mudar o domínio para validar o SWA e quebrar outros usos do TXT sem perceber.
### 4. Por que usei azapi
Nem tudo o que eu precisava encaixou bem no provider padrão do AzureRM. No caso do TXT do apex, eu usei azapi para garantir o controle do record set.
```terraform
resource "azapi_resource" "apex_validation_txt" {
provider = azapi.dns
type = "Microsoft.Network/dnsZones/TXT@2018-05-01"
name = "@"
parent_id = data.azurerm_dns_zone.this.id
body = {
properties = {
TTL = 3600
TXTRecords = [for value in local.apex_txt_values : {
value = [value]
}]
}
}
}
```
Esse é um bom exemplo de onde o Terraform brilha: você não precisa forçar a solução para caber numa única ferramenta. Usa a melhor peça disponível para cada responsabilidade.
### 5. O site continua simples, mas a operação ficou melhor
Mesmo com essa evolução, eu não quis transformar o blog numa plataforma altamente complexa.
O SWA continua sendo a base do hosting, e isso me ajuda porque ele entrega o suficiente sem exigir engenharia excessiva para um site pessoal.
### 6. Quando esse nível de estrutura faz sentido
Nem todo projeto precisa começar assim. Se você está montando um site simples e isolado, talvez uma subscription só e um conjunto mínimo de recursos já resolvam. Mas quando o projeto vira laboratório vivo, quando você quer experimentar, evoluir e manter tudo auditável, esse tipo de arquitetura começa a fazer sentido.
No meu caso, o blog é também um espaço para testar ideias que depois podem virar conteúdo, palestra ou prática de trabalho. Então vale a pena investir tempo e esforço nessa base.
### Conclusão
Tirar o orafaelferreira.com da GoDaddy e trazer o domínio para o Azure foi o que destravou tudo: o DNS deixou de ser um painel manual e isolado e passou a fazer parte do mesmo código que descreve o site para criar os registros DNS. Com isso, a infraestrutura saiu de uma migração funcional para um desenho em que o site e o domínio ficam melhor organizados. De quebra, o domínio fica pronto para ser reaproveitado em outros projetos, sempre via IaC. Isso me ajuda no meu vibe coding, compartilhando o troubleshooting com a IA.
---
# Microsoft Build 2026: os destaques de Azure que mais me chamaram atenção
URL: https://www.orafaelferreira.com/artigos/microsoft-build-2026-destaques-azure
Publicado: 2026-06-07
Categoria: Artigos
Tags: IA
Tempo de leitura: 9 min de leitura
> Os anúncios do Microsoft Build 2026 que mais importam para quem trabalha com Azure: Cobalt 200, Azure Linux 4.0, Azure Container Linux, HorizonDB e Functions.
O **Microsoft Build 2026** veio recheado de anúncios, e a maior parte deles gira em torno de uma palavra: **agentes**. A plataforma está sendo recortada para suportar workloads agentic AI que raciocinam, tomam decisões em sequência e rodam continuamente em escala.
### Visão geral do Build 2026
O **Microsoft Build** é a conferência anual da Microsoft voltada para desenvolvedores, onde a empresa apresenta os principais lançamentos e atualizações da sua plataforma, de Azure e ferramentas de desenvolvimento a IA, dados e segurança.
[Fonte oficial](https://news.microsoft.com/build-2026/)
### Azure Cobalt 200
O **early access preview do Azure Cobalt 200** traz a segunda geração de VMs Arm-based da Microsoft, desenhada do zero para workloads cloud-native, escaláveis e baseadas em Linux, com foco explícito em agentic AI.
- até **50% mais performance de CPU** por geração sobre o Cobalt 100
- **até 128 vCPUs por VM**, com **3 MB de cache L2 por core** e **192 MB de cache L3** no nível de sistema
- **criptografia de memória habilitada por padrão**, com impacto de performance desprezível
- ganhos reais expressivos: até 135% em banco de dados, 80% em caching e 45% em criptografia de comunicação
[Fonte oficial](https://azure.microsoft.com/en-us/blog/new-azure-cobalt-200-vms-deliver-50-performance-improvement-fully-optimized-for-modern-agentic-ai-workloads/)
### Segurança para código, agentes e modelos
Com agentes assumindo decisões antes feitas por código determinístico, a segurança muda de figura. A Microsoft trouxe anúncios focados em proteger código, agentes e modelos ao longo de todo o ciclo de desenvolvimento.
- **auditabilidade** das atividades dos agentes e **RBAC** para controlar acesso
- **circuit breakers** e guardrails independentes do próprio agente
- detecção de comportamento anômalo com possibilidade de intervenção humana a qualquer momento
[Fonte oficial](https://www.microsoft.com/en-us/security/blog/2026/06/02/microsoft-build-2026-securing-code-agents-and-models-across-the-development-lifecycle/)
### Microsoft Marketplace para apps e agentes
O Microsoft Marketplace ganhou destaque como canal para construir, escalar e monetizar aplicações e agentes.
- caminho unificado para publicar e distribuir apps e agentes
- foco em ajudar desenvolvedores e ISVs a alcançar clientes e gerar receita
[Fonte oficial](https://devblogs.microsoft.com/all-things-azure/build-scale-and-monetize-apps-and-agents-with-microsoft-marketplace/)
### Azure HorizonDB
O **Azure HorizonDB (preview)** é um serviço de banco totalmente gerenciado, cloud-native e construído sobre PostgreSQL, pensado para workloads tier-1 e aplicações de IA.
- arquitetura de **compute e storage desacoplados** com design de **database-as-a-log** para performance previsível e alta disponibilidade
- **compatibilidade total com PostgreSQL**, drivers, ORMs e SQL existentes migram com pouca ou nenhuma mudança de código
- **dois endpoints**: um de leitura/escrita (primário) e um reader que faz load-balance entre réplicas HA (hoje até 4, com plano de chegar a 8)
- **pronto para IA**: vector search, embeddings, hybrid search, reranking semântico e pipelines de IA, servindo como camada de memória e recuperação de conhecimento para agentes
[Fonte oficial](https://aka.ms/HorizonDB-Build-blog)
### Azure Linux 4.0
O **Azure Linux 4.0 (public preview)** é a distribuição Linux open-source mantida pela própria Microsoft, construída para Azure, com footprint pequeno e postura de segurança endurecida.
- base no ecossistema **Fedora**, com a familiaridade dos pacotes **RPM**
- **kernel 6.18 LTS** otimizado para Azure, com drivers Hyper-V e tuning específico
- segurança forte: kernel lockdown, **dm-verity** para boot verificado, **SELinux** e **FIPS 140-3**
- pipeline de CVE com scan **duas vezes por dia** contra a NVD; ainda **não indicado para produção**
[Fonte oficial](https://techcommunity.microsoft.com/blog/linuxandopensourceblog/announcing-azure-linux-4-0-purpose-built-for-azure-now-in-public-preview/4524267)
### Azure Container Linux (ACL)
O **Azure Container Linux (ACL)** é um sistema operacional imutável e container-optimized para node pools do AKS, derivado do projeto **Flatcar Container Linux** e já em **GA a partir do AKS 1.34**.
- diretório `/usr` read-only protegido por **dm-verity**, validando hash assinado em boot e runtime
- superfície de ataque mínima e **atualizações automáticas semanais** baseadas em imagem
- **SELinux em enforcing** por padrão e **Trusted Launch com Secure Boot e vTPM** obrigatórios
- criação direta com `az aks create --os-sku AzureContainerLinux`; atenção às limitações (sem Pod Sandboxing, Artifact Streaming e Confidential VMs)
[Fonte oficial](https://techcommunity.microsoft.com/blog/linuxandopensourceblog/introducing-azure-container-linux-acl/4523411)
### Novidades do AKS
O AKS recebeu um conjunto de anúncios no Build 2026 que ampliam o controle em toda a stack — da operação do cluster até treino e inferência de IA rodando em cima dele.
- **Managed system node pools no AKS Automatic (GA)**: o Azure passa a cuidar do ciclo de vida dos nós de sistema (capacidade, patching, escala), evitando que os componentes do cluster disputem recursos com suas cargas — importante sobretudo em nós com GPU
- **AKS on bare metal (preview)**: roda o AKS em máquinas dedicadas **sem hypervisor**, com acesso direto a NVLink, RDMA e rede de alta performance — ideal para treino grande, inferência sensível a latência e pipelines de alto throughput
- **Fleet Manager para clusters Arc-enabled (GA)**: aplica updates, políticas e posicionamento de cargas em clusters dentro e fora do Azure a partir de um único control plane, com rollout progressivo e RBAC consistente
- **Anyscale on Azure (preview)**: traz o **Ray gerenciado** ao AKS para coordenar execução distribuída (GPUs e CPUs juntas, alocação fracionada de GPU), rodando dentro da sua subscription com Entra ID
- **AI Runway + KAITO** para servir modelos de forma Kubernetes-native: você escolhe o modelo, valida o ajuste à memória de GPU disponível e faz o deploy; o KAITO provisiona nós e sobe runtimes otimizados como **vLLM**
[Fonte oficial](https://techcommunity.microsoft.com/blog/appsonazureblog/whats-new-in-azure-kubernetes-service-at-microsoft-build-2026/4524862)
### Gestão de file shares mais simples e escalável (GA)
O Azure Files ganhou um novo modelo de gerenciamento para **file shares premium SSD (NFS)**, agora em disponibilidade geral, em que cada share é criado, protegido, escalado e cobrado de forma independente, **sem ficar amarrado à storage account**.
- **Cada share é um recurso próprio**, com performance, segurança e billing isolados (modelo provisioned v2), alinhando os limites aos limites reais da aplicação ou do tenant
- **Escala maior e provisionamento mais rápido**: até **10.000 file shares por subscription por região** e **time-to-first-share 2,5x mais rápido** que os shares clássicos
- **Isolamento por share**: restrições de rede, RBAC, política, snapshots e criptografia em trânsito definidos individualmente, ideal para cenários multi-tenant de SaaS
- **Infraestrutura como código e visibilidade de custo**: define naming, capacidade, IOPS, rede e tags em Bicep/ARM, com meters de billing por share para chargeback preciso
[Fonte oficial](https://techcommunity.microsoft.com/blog/AzureStorageBlog/simpler-scalable-file-share-management-in-azure---now-generally-available/4523035)
### Outros destaques
#### Project Solara
- **Plataforma chip-to-cloud** (codinome) criada do zero para experiências **agent-first** e para uma nova geração de dispositivos moldados ao redor de agentes, não de apps
- Aposta em **just-in-time UI**: a interface do agente se adapta a diferentes telas e modalidades (voz, visão, toque) sem o desenvolvedor redesenhar para cada formato
- Nasce **enterprise-ready**, com identidade (Entra ID), gestão (Intune), segurança e privacidade como fundação — além de ser **extensível** para você trazer seus próprios agentes
- Primeiros conceitos de hardware incluem um **dispositivo de crachá** (portátil) e um **dispositivo de mesa**, com silício de MediaTek e Qualcomm
[Fonte oficial](https://commandline.microsoft.com/project-solara-build-2026/)
#### Microsoft Scout
- **Agente pessoal always-on**, pensado para acompanhar o usuário de forma contínua
- Conecta-se ao Microsoft 365 para agir sobre contexto real de trabalho, não só responder perguntas isoladas
[Fonte oficial](https://www.microsoft.com/en-us/microsoft-365/blog/2026/06/02/introducing-microsoft-scout-your-always-on-personal-agent/)
#### Modernização agentic
- **GitHub Copilot modernization agent** chega à **disponibilidade geral**: operado pela CLI, atua como orquestrador que avalia prontidão de várias aplicações ao mesmo tempo, planeja jornadas específicas e automatiza upgrades de **Java e .NET**
- Integra-se ao fluxo nativo do GitHub criando **issues, pull requests e relatórios de avaliação** por aplicação, com coordenação assíncrona via coding agent e trilha de auditoria no **Agent HQ**
- Faz par com o **Azure Copilot migration agent (preview)**, que cobre o planejamento em escala de estate — descoberta, mapeamento de dependências, análise de ROI e wave planning — reduzindo meses de análise a minutos
- **Custom skills (GA)**: o time codifica padrões, bibliotecas e boas práticas em arquivos `skill.md` (formato aberto) e reaproveita em todo o portfólio
- Resultado relatado pela Microsoft: modernização até **4x mais rápida** em centenas de milhares de apps legados .NET e Java
[Fonte oficial](https://techcommunity.microsoft.com/blog/AppsonAzureBlog/closing-the-ai-readiness-gap-with-agentic-modernization/4524011)
#### Microsoft Web IQ
- **Inteligência de busca para a web**, trazendo dados e contexto atualizados para aplicações e agentes
- Pensado para alimentar experiências de IA com informação fresca da web em vez de conhecimento estático
[Fonte oficial](https://blogs.bing.com/search/June-2026/Announcing-Microsoft-Web-IQ)
### Azure Functions no Build 2026
No serverless, a mensagem reforça uma direção clara: o **Flex Consumption é onde as novidades chegam primeiro**.
- **cold starts menores** com instâncias always-ready e **integração com rede virtual**
- **per-function scaling** e **scale-out de até 1.000 instâncias** (contra 200 do Consumption)
- **mounts de Azure Files** para binários grandes e modelos de ML sem empacotar no deploy
[Fonte oficial](https://techcommunity.microsoft.com/blog/appsonazureblog/azure-functions-at-build-2026-update/4524075)
### Demos do Build 2026
Para ver na prática, seguem demos selecionadas do canal **Microsoft Developer**, todas gravadas no Build 2026. Cada uma é curta e vai direto ao ponto:
#### OpenClaw + Windows
- Mostra o **OpenClaw rodando em conjunto com o Windows**, no contexto da plataforma de desenvolvimento
- Boa amostra de como ferramentas de agente se integram ao ambiente nativo do sistema
- Teve a **participação especial do fundador da Open Cloud**, comentando um pouco de como ele está animado com o que está por vir
[](https://www.youtube.com/watch?v=J7ol1VDkg7w)
[Assistir no YouTube](https://www.youtube.com/watch?v=J7ol1VDkg7w)
#### Developer Experience on Windows
- Um tour pela **experiência de desenvolvimento no Windows**, alinhada aos anúncios de ferramentas para devs (Coreutils, WSL, configurações otimizadas)
- Útil para quem quer entender o caminho que a Microsoft está traçando para o fluxo de trabalho no Windows
[](https://www.youtube.com/watch?v=xVWHZkuhgys)
[Assistir no YouTube](https://www.youtube.com/watch?v=xVWHZkuhgys)
#### GitHub App + Rayfin
- Integração de um **GitHub App com o Rayfin**, ilustrando fluxos de automação e produtividade
- Mostra na prática como conectar repositórios a automações de ponta a ponta
[](https://www.youtube.com/watch?v=gJX6MOyef8Q)
[Assistir no YouTube](https://www.youtube.com/watch?v=gJX6MOyef8Q)
#### Microsoft Discovery
- Demonstração do **Microsoft Discovery** aplicado a cenários de pesquisa e descoberta acelerada por IA
- Dá uma ideia de como a IA encurta o tempo entre uma pergunta e uma resposta acionável
[](https://www.youtube.com/watch?v=uHtva5r9itY)
[Assistir no YouTube](https://www.youtube.com/watch?v=uHtva5r9itY)
#### MDASH
- **MDASH** é o codinome do **sistema de varredura de segurança agêntica multimodelo** da Microsoft Security, criado pela equipe de Segurança de Código Autônomo
- Diferente de abordagens de modelo único, **orquestra mais de 100 agentes de IA especializados** (modelos de fronteira e destilados) para descobrir, debater e comprovar bugs exploráveis de ponta a ponta
- Na prática, ajudou a encontrar **16 novas vulnerabilidades** na pilha de redes e autenticação do Windows, incluindo 4 falhas críticas de execução remota de código
[](https://www.youtube.com/watch?v=8QBDaRbur70)
[Assistir no YouTube](https://www.youtube.com/watch?v=8QBDaRbur70)
### Resumo brabo do que vem por ai: tudo aponta para agentes
---
# Azure Container Registry Artifact Cache: arquitetura, segurança e promoção entre ambientes
URL: https://www.orafaelferreira.com/artigos/azure-container-registry-artifact-cache
Publicado: 2026-05-31
Categoria: Artigos
Tempo de leitura: 6 min de leitura
> Guia prático de Artifact Cache no Azure Container Registry: arquitetura, segurança, pull-through cache e promoção de imagens entre ambientes.
Este artigo faz parte da série sobre Docker e containers, agora com foco em **Azure Container Registry (ACR) Artifact Cache**.
Se você trabalha com AKS, App Service, Functions, Container Apps ou pipelines de CI/CD, provavelmente já enfrentou pelo menos um destes problemas:
- limite de pull em registries públicos
- latência e instabilidade para baixar imagens em horário de pico
- dependência direta de registry externo em ambiente de produção
- excesso de credenciais espalhadas para autenticação entre registries
O Artifact Cache do ACR resolve esse conjunto com uma abordagem de **pull-through cache**: você continua puxando imagem com o nome do seu ACR, e a plataforma busca e armazena o conteúdo do upstream no primeiro pull.
### Onde a Docker entra diretamente neste desenho
Mesmo sendo um recurso do ACR, a operação do dia a dia passa por componentes do ecossistema Docker:
- **Docker Engine** no host de build ou no workstation
- **Docker CLI** para validar e executar comandos como pull, tags e comportamento do cache
- **Docker Hub** como upstream comum para imagens base e imagens de runtime
- **Formato OCI de imagens** — o mais comum no ecossistema Docker e runtimes cloud-native, mas não o único.
Na prática, boa parte do valor aparece quando você tira dependência direta de pull no Docker Hub em momentos de pico e passa a concentrar distribuição via ACR com cache local.
### O que é Artifact Cache, na prática
Pense no Artifact Cache como uma camada de distribuição local para imagens:
1. Seu runtime (AKS, por exemplo) faz pull em `meuacr.azurecr.io/time/api:1.0.0`.
2. Se a imagem ainda não estiver no cache, o ACR busca no upstream definido na regra.
3. O cliente recebe a imagem e, em paralelo, o ACR persiste o conteúdo de forma assíncrona.
4. Nos próximos pulls, a entrega sai do próprio ACR.
Esse comportamento reduz dependência de internet no caminho crítico, melhora previsibilidade de pull e permite aplicar controle de rede/segurança dentro do seu perímetro Azure.
### Quando esse recurso brilha
#### 1. Escala em cluster
Quando muitos nós sobem ao mesmo tempo (rolling update, autoscale, node replacement), o cache reduz pressão no upstream e no egress externo.
#### 2. Promoção de imagens entre ambientes
Você pode manter repositórios separados por ambiente (dev, staging e prod) e usar o cache para padronizar o consumo de imagens no destino.
#### 3. Ambientes restritos por rede
Com Private Link bem configurado, você evita expor pipeline e runtime diretamente ao registry externo.
### Upstreams suportados (resumo)
#### O que é um upstream?
No contexto do Artifact Cache, **upstream** é o registry de origem de onde o ACR vai buscar a imagem quando ela não estiver em cache. É o registry "de fora" — pode ser Docker Hub, GHCR, Quay ou até outro ACR.
Quando você configura uma cache rule, você define:
- **source-repo**: o caminho no upstream (ex.: `docker.io/library/nginx`)
- **target-repo**: o caminho dentro do seu ACR onde o conteúdo ficará espelhado (ex.: `mirror/library/nginx`)
Na prática, o upstream só é acessado no primeiro pull de uma tag. Depois, o ACR serve o conteúdo localmente. Se o upstream ficar indisponível, imagens já em cache continuam acessíveis — esse é o ganho de resiliência do padrão.
De acordo com a documentação oficial, o Artifact Cache suporta vários registries upstream, com diferenças de autenticação por fonte. Alguns exemplos:
- Docker Hub (somente autenticado)
- Azure Container Registry (somente autenticado)
- GHCR (autenticado e não autenticado)
- Quay (autenticado e não autenticado)
- registry.k8s.io (CLI)
- Microsoft Artifact Registry (não autenticado)
#### Exemplo com Docker Hub como upstream
Um padrão comum é cachear imagens oficiais usadas como base de aplicações:
```bash
az acr cache create \
--registry "acrpocprod" \
--name "dockerhub-nginx" \
--source-repo "docker.io/library/nginx" \
--target-repo "mirror/library/nginx" \
--cred-set "DockerHubCredSet"
```
Depois, em vez de puxar direto do Docker Hub, seu ambiente passa a consumir:
```bash
docker pull acrpocprod.azurecr.io/mirror/library/nginx:stable
```
### Limites e comportamento que você precisa saber
Esses pontos costumam gerar dúvida em troubleshooting:
1. O cache **não é prefetch automático de novas tags**. A tag só entra quando alguém puxa.
2. Limite de **até 1.000 cache rules** por registry.
3. Regras **não podem sobrepor** namespace/caminho.
4. O primeiro pull pode sofrer latência maior; os seguintes tendem a ser mais estáveis.
5. Em cenários com upstream privado, o upstream exige autenticação.
### Matriz de decisão rápida
| Cenário | Recomendação |
|---|---|
| Docker Hub público com limite de pull | Artifact Cache + credential set |
| Promoção entre ambientes com registries distintos | Artifact Cache + regra por repositório |
| Necessidade de menor blast radius de secret | Preferir credenciais com escopo mínimo e rotação |
| Upstream em rede restrita | Validar Trusted Services e ACLs no source |
| Cross-tenant | Planejar autenticação explícita por credencial |
### Troubleshooting objetivo
#### Erro de autorização no cache rule
- Confirme se a identidade foi anexada ao ACR downstream.
- Confirme o role assignment no upstream com escopo correto.
- Verifique se a autenticação configurada na cache rule está correta.
#### Primeiro pull funciona, mas desempenho não melhora
- Lembre que a cópia é assíncrona.
- Aguarde alguns instantes e repita pull para validar efeito de cache.
- Confira eventos/logs e permissão de leitura no upstream.
#### Regra não cria por conflito
- Regras de cache não podem se sobrepor.
- Revise namespace de `target-repo` e caminhos de `source-repo`.
#### Ambientes com rede restrita
- Verifique regras de firewall/private endpoint do upstream.
- Quando aplicável, habilite Trusted Services no source.
### Boas práticas para ambiente real
1. Padronize naming de cache rule por domínio/time/produto.
2. Separe namespace de cache por ambiente (ex.: `promoted/`, `quarantine/`).
3. Use tags imutáveis para promoção crítica (ou controle rigoroso de retag).
4. Evite escopo amplo de permissão quando ABAC estiver habilitado.
5. Adicione validação em pipeline para garantir que a regra de cache existe antes do deploy.
6. Monitore latência de pull e falhas de autenticação como indicadores de saúde.
### Exemplo de fluxo de promoção com governança
1. Build publica imagem em `devregistry.azurecr.io/team-a/api:1.4.0`.
2. Pipeline de qualidade executa scan e testes.
3. Aprovado, o pipeline dispara pull no destino:
```bash
docker pull prodregistry.azurecr.io/promoted/team-a/api:1.4.0
```
4. Esse pull alimenta o cache no prod.
5. Clusters de produção consomem do ACR de produção.
Esse padrão simplifica governança e reduz scripts customizados de import, sem abrir mão de rastreabilidade.
### Boas práticas
1. Mantenha imagens base oficiais e versionadas (evite depender sempre de `latest`).
2. Use tags imutáveis para promover release entre ambientes.
3. Reduza pulls diretos em registry público durante janela crítica de deploy.
4. Centralize auditoria de consumo de imagem no registry corporativo.
### Conclusão
O Azure Container Registry Artifact Cache não é apenas um recurso de conveniência. Em plataformas com muitos deploys e múltiplos ambientes, ele vira uma camada de resiliência operacional.
Combinando:
- pull-through cache
- identidade gerenciada
- RBAC/ABAC bem definido
- segmentação de namespace por ambiente
Você constrói uma estratégia mais segura, previsível e escalável para distribuição de imagens.
Para quem já está nessa pegada de Docker + Kubernetes + Azure, o Artifact Cache é um passo natural para maturidade de supply chain de containers.
### Referências
- [Microsoft Learn: Optimize image pulls with artifact cache in Azure Container Registry](https://learn.microsoft.com/azure/container-registry/artifact-cache-overview)
- [Azure CLI: az acr cache](https://learn.microsoft.com/cli/azure/acr/cache)
- [Docker Docs: Docker Hub usage and limits](https://docs.docker.com/docker-hub/usage/)
- [Docker Docs: docker pull reference](https://docs.docker.com/reference/cli/docker/image/pull/)
---
# O Dia em que Derrubei Produção em Plena Sexta-Feira e o log tava com meu nome – Code Island Ctrl Z 2026
URL: https://www.orafaelferreira.com/artigos/code-island-ctrlz-2026
Publicado: 2026-05-20
Categoria: Palestras
Tempo de leitura: 5-7 min de leitura
> No Code Island Ctrl Z 2026 contei como derrubei produção numa sexta-feira, o que aprendi com o incidente e por que a cultura blameless importa.
No dia **16 de maio de 2026**, rolou o [**Code Island Ctrl Z**](https://codeisland.com.br/ctrlz) na UniCesusc, em Florianópolis/SC – um evento presencial focado em cases reais, erros honestos e aprendizados práticos de quem já "derrubou produção" e sobreviveu para contar a história.
### Sobre o evento
O Ctrl Z nasceu para mostrar que todo mundo erra – até quem está no palco. Foram **14 palestrantes**, 150 vagas, 8 horas de conteúdo e muita troca sobre DEV, DATA, DEVOPS e CLOUD.
**Local:** UniCesusc – SC-401, 9301 – Santo Antonio de Lisboa, Florianópolis/SC
### Meu case: O Dia em que Derrubei Produção em Plena Sexta-Feira e o log tava com meu nome
> Sim, eu derrubei a produção. E sim, meu nome estava no log.
O ambiente era crítico, o impacto foi imediato e o culpado tinha nome e sobrenome gravados no log do sistema. Mas o mais importante não foi o erro técnico – foi o que veio depois:
- Como manter a calma quando o negócio está perdendo dinheiro?
- Como comunicar o problema sem perder a confiança do time?
- O que fazer para o erro não se repetir?
### Aprendizados que compartilhei
- Todo mundo vai errar – o que diferencia é como você reage
- Transparência e comunicação são mais importantes que buscar culpados
- Ter processo de rollback e monitoramento salva seu emprego
- Cultura de blameless postmortem: aprender, não punir
### Local e estrutura
O UniCesusc fica na SC-401, fácil acesso de carro, Uber, ônibus. Estacionamento disponível, acessibilidade garantida, e toda a estrutura para receber a galera tech de Floripa e região.
### Links e materiais
- [Slides da Apresentação](https://stoblobcertificados011.blob.core.windows.net/palestras/ctrlz.pdf)
- [Post divulgação do evento](https://www.linkedin.com/posts/orafaelferreiraa_codeisland-ctrlz-devops-share-7453042662477062144-nXTz?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAiBr9cBknrEzJyFEqCS03tes6G6R1yclRw)
### Quer participar dos próximos?
Fique ligado nas redes da [Code Island](https://codeisland.com.br) e acompanhe os próximos eventos!
---
# Global Azure Floripa 2026 (Evento Presencial)
URL: https://www.orafaelferreira.com/artigos/global-azure-floripa-2026
Publicado: 2026-05-17
Categoria: Organização de Eventos
Tempo de leitura: 4 min de leitura
> Mais uma edição do Global Azure em Florianópolis, organizada pelo Azure User Groups Brasil com trilhas práticas de cloud, IA e DevOps.
## Global Azure Floripa 2026
No dia **18 de abril de 2026**, aconteceu o [**Global Azure User Group Floripa 2026**](https://www.meetup.com/azureusergroupsbrasil/events/313851322/) no **Colégio Alpha**, em São José/SC, com temas sobre Azure, carreira internacional, segurança, arquitetura cloud native e DevOps.
O evento reuniu profissionais, estudantes e entusiastas para discutir tendências e casos práticos sobre **Microsoft Azure**, **IA** e **DevOps**.
Se você perdeu essa edição, este post reúne o panorama oficial do evento, com agenda, palestras e registros dos palestrantes.
### Organizadores
- **[Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)**
- **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)**
### Sobre o evento
- **Nome:** Global Azure Floripa 2026
- **Cidade:** São José
- **Local:** Colégio Alpha
- **Endereço:** Rua Vereador Walter Borges, 424, São José - SC
### Sobre o Global Azure
O [Global Azure](https://globalazure.net/) é uma iniciativa mundial em que comunidades locais realizam eventos para compartilhar conhecimento sobre Microsoft Azure e acelerar a evolução técnica de quem está na linha de frente.
### Agenda oficial
#### Manhã
- **09:00 - 10:00**
Arquitetura Celular na Era Cloud Native: Estratégias Modernas com Microsoft Azure
Palestrante: [Claudio Raposo](https://www.linkedin.com/in/cfraposo/)
- **10:00 - 11:00**
Azure Virtual Desktop: como acelerar seu negócio em minutos
Palestrante: [Leonardo Souza](https://www.linkedin.com/in/leomozzer/)
- **11:00 - 12:00**
Carreira internacional: como ganhar XP e se dar bem nas fases do jogo
Palestrante: [Lore Locks Coelho](https://www.linkedin.com/in/lorenalocks/?locale=en)
#### Almoço
- **12:00 - 13:30**
Almoço
#### Tarde
- **13:30 - 14:30**
Reactive DDD na prática: Modelagem event-first e integração reativa em alta escala
Palestrante: [Antonio Falcao Jr](https://www.linkedin.com/in/antoniofalcaojr/)
- **14:30 - 15:30**
Segurança sem gambiarra: usando HSM para proteger o que realmente importa
Palestrante: [Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)
- **15:30 - 16:30**
Vibe Coding com DevOps: usei IA pra criar meu site no Azure, mas quem fez o deploy fui EU
Palestrante: [Rafael Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)
#### Comunidade presente
### Links oficiais
- [Agenda e detalhes no Sessionize](https://global-azure-floripa-2026.sessionize.com/)
### Apoio local
Esta edição contou com apoio da **[Alpha Educação](https://www.alphaeducacao.com.br)**.
### Conecte-se com a comunidade
Se você quiser acompanhar os próximos encontros e participar da comunidade:
- [Site oficial](https://azureusergroupsbrasil.com.br/)
- [Linktree](https://linktr.ee/azureusergroupsbrasil)
- [Grupo no WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)
- [YouTube](https://www.youtube.com/@azureusergroupsbrasil?sub_confirmation=1)
- [LinkedIn](https://www.linkedin.com/company/azureusergroupsbrasil)
- [Meetup](https://www.meetup.com/azureusergroupsbrasil)
Obrigado a todos que participaram presencialmente e ajudaram a fortalecer o ecossistema cloud em Santa Catarina e no Brasil.
---
# Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU - Global Azure User Group Floripa 2026
URL: https://www.orafaelferreira.com/artigos/global-azure-user-group-floripa-2026
Publicado: 2026-05-02
Categoria: Palestras
Tags: Palestras
Tempo de leitura: 5-7 min de leitura
> Relato do Global Azure User Group Floripa 2026 no Colégio Alpha, em São José/SC: palestra Vibe Coding com DevOps, agenda completa e comunidade Azure em SC.
No dia **18 de abril de 2026**, aconteceu o [**Global Azure User Group Floripa 2026**](https://www.meetup.com/azureusergroupsbrasil/events/313851322/) no **Colégio Alpha**, em São José/SC, com temas sobre Azure, carreira internacional, segurança, arquitetura cloud native e DevOps.
Evento organizado por mim e **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)**, representando a comunidade [**Azure User Groups Brasil**](https://azureusergroupsbrasil.com.br/).
### Sobre o Global Azure
O [Global Azure](https://globalazure.net/) é uma iniciativa mundial em que comunidades locais realizam eventos para compartilhar conhecimento sobre Microsoft Azure e acelerar a evolução técnica de quem está na linha de frente.
### Agenda oficial
#### Manhã
| Horário | Palestrante | Sessão |
|--------|-------------|--------|
| 09:00 - 10:00 | Claudio Raposo | Arquitetura Celular na Era Cloud Native: Estratégias Modernas com Microsoft Azure |
| 10:00 - 11:00 | Leonardo Souza | Azure Virtual Desktop: como acelerar seu negócio em minutos |
| 11:00 - 12:00 | Lore Locks Coelho | Carreira internacional: como ganhar XP e se dar bem nas fases do jogo |
#### Almoço
| Horário | Sessão |
|--------|--------|
| 12:00 - 13:30 | Almoço |
#### Tarde
| Horário | Palestrante | Sessão |
|--------|-------------|--------|
| 13:30 - 14:30 | Antonio Falcao Jr | Reactive DDD na prática: Modelagem event-first e integração reativa em alta escala |
| 14:30 - 15:30 | Vinicius Deschamps | Segurança sem gambiarra: usando HSM para proteger o que realmente importa |
| 15:30 - 16:30 | Rafael Ferreira | Vibe Coding com DevOps: usei IA pra criar meu site no Azure, mas quem fez o deploy fui EU |
### Minha palestra
Nessa edição, apresentei a sessão sozinho, trazendo um case prático sobre como usar IA para acelerar desenvolvimento sem abrir mão de engenharia.
Tema da sessão:
**Vibe Coding com DevOps: usei IA pra criar meu site no Azure, mas quem fez o deploy fui EU**
Abordei principalmente:
- como usar IA para aumentar produtividade sem terceirizar pensamento técnico
- limites de código gerado sem processo de qualidade
- papel de CI/CD, validações e ownership técnico no deploy
- porque "entregar" não é só subir código, e garantir confiabilidade
### Comunidade Azure User Groups Brasil
Se você quiser participar da comunidade:
- [**WhatsApp**](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)
- [**YouTube**](https://www.youtube.com/@azureusergroupsbrasil)
- [**LinkedIn**](https://www.linkedin.com/company/azureusergroupsbrasil)
[LinkedIn Post Divulgação evento](https://www.linkedin.com/posts/orafaelferreiraa_palestra-confirmada-do-azure-user-groups-activity-7446882073878929409-aeCr?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAiBr9cBknrEzJyFEqCS03tes6G6R1yclRw)
### Conteúdos da sessão
Os slides da minha sessão estão disponíveis:
- [**Slides da Apresentação**](https://stoblobcertificados011.blob.core.windows.net/palestras/GlobalAzure26.pdf)
- [**Repositório do Site**](https://github.com/orafaelferreiraa/orafaelferreira-com)
---
# Imagens de contêiners Python no Kubernetes: comparação técnica e estratégia com Distroless
URL: https://www.orafaelferreira.com/artigos/docker-python-distroless-kubernetes
Publicado: 2026-04-28
Categoria: Artigos
Tempo de leitura: 10-12 min de leitura
> Comparação prática entre imagens de contêiners Python (slim, alpine e distroless) e como aplicar técnicas com foco em segurança e workloads no Kubernetes.
Vamos explorar estratégias multi-stage build com imagens de contêiner distroless para workloads Python no Kubernetes, criando soluções da vida real.
### O que é distroless
Imagens distroless contêm **apenas** o runtime da linguagem e suas dependências mínimas. Não incluem:
- **Shell** (bash, sh): não é possível abrir um terminal no container para debug
- **Package managers** (apt, yum, pip)
- **Utilitários do sistema** (curl, wget, vi, ls, cat)
- **Usuário root** (na variante `-nonroot`, roda como UID 65534). ALTO RISCO DE SEGURANÇA.
Exemplo de família de imagens distroless (valores anonimizados para referência arquitetural):
```dockerfile
mcr.microsoft.com/azurelinux/distroless/python:3.12 # root
mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot # non-root (recomendado)
mcr.microsoft.com/azurelinux/distroless/debug/python:3.12 # com shell (debug only)
```
**Nota:** a variante `debug` inclui um shell busybox e serve para troubleshooting temporário. NÃO deve ser usada em produção.
Criei uma solução e botei para rodar no Kubernetes, um script básico em Python para consumir uma API REST e disparar notificações, rodando menos de 5 segundos, uma vez por dia.
Durante a jornada, fiz um benchmark de imagens base para comparar seus tamanho, segurança e operação. A implementação final do workload foi feita com `mcr.microsoft.com/azurelinux/base/python:3.12` no estágio de build e `mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot` no runtime.
### Comparação das imagens consultadas
| Imagem | Tamanho | CVEs | Shell | Package Manager | Non-root |
|--------|---------|------|-------|------------------|----------|
| `python:3.12-slim` (Debian) | ~150MB | Médio-alto (Debian libs) | Sim | apt | Não (root) |
| `python:3.12-alpine` | ~50MB | Baixo | Sim | apk | Não (root) |
| `registry.example.com/containeres/python-build:3.12` | ~100MB | Baixo | Sim | tdnf | Não (root) |
| `registry.example.com/containeres/python-runtime-distroless:3.12-nonroot` | ~30MB | Mínimo | Não | Não | Sim |
**OBS:** a quantidade/severidade de CVEs varia conforme data do scan, base de vulnerabilidades e versão exata da imagem.
### O "problema"
Mesmo imagens otimizadas para runtime geral ainda podem incluir componentes que não são necessários para workloads curtos, por exemplo Jobs/CronJobs:
- Shell (`bash`, `sh`)
- Package manager (`apt`, `dpkg`)
- Utilitários como `curl`, `wget` e `find`
- Usuário root por padrão
Obviamente quando estamos criando, precisamos de certas ferramentas para desenvolvimento e depuração. Finalizado o desenvolvimento e testes, podemos e devemos enxugar a imagem. Para um container que executa um script e termina, nada disso é necessário. Cada binário extra também amplia a superfície de possíveis ataques.
### A engenharia entrando em ação: multi-stage build + distroless
A estratégia de separar **build** e **runtime** em dois estágios:
```dockerfile
## Stage 1: Build - instala dependências
FROM mcr.microsoft.com/azurelinux/base/python:3.12 AS build
WORKDIR /aplicativos
COPY requirements-ex.txt .
RUN pip install --no-cache-dir --target=/aplicativos/deps -r requirements-ex.txt
## Stage 2: Runtime - distroless (sem shell, sem package manager, non-root)
FROM mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot
WORKDIR /aplicativos
COPY --from=build /aplicativos/deps /aplicativos/deps
COPY worker_alertas.py .
ENV PYTHONPATH=/aplicativos/deps
ENTRYPOINT ["python3", "exemplo.py"]
```
**Resultado:** runtime rodando no mínimo com distroless non-root, menor superfície de ataque e operação mais previsível para Jobs/CronJobs.
| Estágio | O que tem | O que NÃO tem |
|---------|-----------|----------------|
| **Build** (`python-build:3.12`) | pip, compiladores, headers; tudo para instalar pacotes | Não vai para a imagem final |
| **Runtime** (`python-runtime-distroless:3.12-nonroot`) | Python runtime, glibc, CA certs | Sem shell, sem pip, sem apt, sem binários extras |
O `--target=/aplicativos/deps` instala dependências em um diretório isolado, que é copiado para o segundo estágio. O `PYTHONPATH` aponta para esse diretório.
### Pontos de atenção na hora de desenvolver uma solução distroless do zero!
#### 1. Logs
Falando de código e testes, sem `stream=sys.stdout` no `logging.basicConfig()`, os logs iam para `stderr` e, em alguns cenários de CronJob, não apareciam no `kubectl logs`:
```python
## Logs podem não aparecer
logging.basicConfig(level=logging.INFO)
## Garante stdout
logging.basicConfig(
level=logging.INFO,
format="%(asctime)s %(levelname)s %(message)s",
stream=sys.stdout,
)
```
#### 2. Erros em variáveis de ambiente
Sem shell e sem processo de init, se uma variável estivesse faltando, o container podia falhar rápido demais e dificultar a observabilidade:
```python
REQUIRED_ENV_VARS = ["API_URL", "API_KEY", "RECIPIENTS"]
def load_config() -> dict:
missing = [v for v in REQUIRED_ENV_VARS if v not in os.environ]
if missing:
logger.error("Missing env vars: %s", ", ".join(missing))
sys.exit(1)
# ...
```
#### 3. Debug sem shell
Com distroless, `kubectl exec -it -- /bin/sh` não funciona. Para troubleshooting, a estratégia é trocar temporariamente para a imagem de debug:
```dockerfile
## Temporário: apenas para troubleshooting
FROM mcr.microsoft.com/azurelinux/distroless/debug/python:3.12
```
Isso adiciona ~15-20MB, mas habilita shell busybox. Depois do diagnóstico, o ideal é voltar para a variante `-nonroot`.
#### 4. ENTRYPOINT, não CMD
Em imagens distroless **sem shell**, o formato exec é obrigatório:
```dockerfile
## Shell form: exige /bin/sh (que não existe)
## CMD python3 exemplo.py
## Exec form: obrigatório para distroless
ENTRYPOINT ["python3", "exemplo.py"]
```
### Na implementação final deste workload:
- **Build stage:** `mcr.microsoft.com/azurelinux/base/python:3.12`
- **Runtime stage:** `mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot`
Essa combinação manteve o workload simples para instalação de dependências no build e conseguimos entregar um runtime enxuto, sem shell e sem package manager em produção.
### Benefícios de segurança
1. **Sem shell**: reduz execução arbitrária de comandos
2. **Sem package manager**: impede instalação de ferramentas de exploração em runtime
3. **Non-root**: UID 65534, reduzindo risco de escalonamento trivial
4. **Superfície mínima**: tende a reduzir CVEs reportadas por scanners (como Trivy)
5. **Imutabilidade operacional**: menos formas de alterar o container em execução
### Quando usar (e quando não usar)
#### Use distroless quando
- Scripts/workers que rodam e terminam (CronJobs, Functions)
- Microsserviços que não exigem debug interativo frequente
- Workloads de produção onde segurança é prioridade
#### Evite distroless quando
- O ciclo de desenvolvimento depende fortemente de debug interativo
- A aplicação depende de binários de sistema (ffmpeg, imagemagick etc.)
- O time ainda não está pronto para um workflow de troubleshooting sem shell
### Template para CronJobs Python
```dockerfile
## Stage 1: Build
FROM mcr.microsoft.com/azurelinux/base/python:3.12 AS build
WORKDIR /aplicativos
COPY requirements-ex.txt .
RUN pip install --no-cache-dir --target=/aplicativos/deps -r requirements-ex.txt
## Stage 2: Runtime (distroless)
## Para debug temporário, troque por:
## FROM mcr.microsoft.com/azurelinux/distroless/debug/python:3.12
FROM mcr.microsoft.com/azurelinux/distroless/python:3.12-nonroot
WORKDIR /aplicativos
COPY --from=build /aplicativos/deps /aplicativos/deps
COPY exemplo.py .
ENV PYTHONPATH=/aplicativos/deps
ENTRYPOINT ["python3", "exemplo.py"]
```
E no Python, comece com:
```python
import logging
import sys
logging.basicConfig(
level=logging.INFO,
format="%(asctime)s %(levelname)s %(message)s",
stream=sys.stdout,
)
```
A adoção de distroless non-root removeu shell, package manager e root do runtime. Os principais desafios encontrados foram logs em stdout, validação de variáveis e troubleshooting sem shell, que são contornáveis com práticas simples.
**Nota de compliance (NDA):** nomes de imagens, caminhos e artefatos foram anonimizados para fins de publicação; exemplos, métricas e cenários estão apresentados sem identificação de cliente, tenant ou ambiente específico.
Para workloads Python executados como Jobs no Kubernetes, distroless é uma escolha sólida.
---
# Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU - SQL Saturday Joinville 2026
URL: https://www.orafaelferreira.com/artigos/sql-saturday-joinville-2026
Publicado: 2026-04-20
Categoria: Palestras
Tempo de leitura: 6-8 min de leitura
> Relato da palestra Vibe Coding com DevOps no SQL Saturday Joinville 2026: como usei IA para criar meu site sem abrir mão de pipeline, governança e ownership.
No dia **11 de abril de 2026**, participei como palestrante no **[SQL Saturday Joinville 2026](https://sqlsaturday.com/2026-04-11-sqlsaturday1139/)**, realizado na **Univille**, em Joinville/SC, organizado pela comunidade **[Comunidado](https://comunidado.com.br/)**
O SQL Saturday é um dos eventos mais tradicionais da comunidade de dados, reunindo profissionais de SQL Server, Azure, analytics e Inteligência Artificial para compartilhar experiências reais de mercado.
### Cronograma do evento
#### Centro de Convenções
| Horário | Palestrante | Sessão |
|--------|-------------|--------|
| 08:30 - 09:00 | - | Keynote - Palestra Inicial |
| 09:00 - 09:50 | Fabiano Amorim | Hackeando MSSQL na nuvem. Todas elas. Como me tornei sysadmin no Azure, AWS, GCP e Alibaba. |
| 09:50 - 10:40 | Rodrigo Ribeiro | Microsoft SQL and AMD in the era of AI (IA no SQL Server: Embeddings). |
| 10:40 - 11:10 | - | Coffee break |
| 11:10 - 12:00 | Gerson Viergutz | MCP no Power BI. |
| 12:00 - 13:30 | - | Almoço |
#### Auditório da Reitoria
| Horário | Palestrante | Sessão |
|--------|-------------|--------|
| 13:30 - 14:20 | Sidney Cirqueira | Microsoft Fabric - What's new and What's next. |
| 14:20 - 15:10 | Alison Pezzott | Arquitetura de Dados Moderna com CI/CD no Microsoft Fabric e Power BI: separando responsabilidades entre Engenharia e Analytics. |
| 15:10 - 15:40 | - | Coffee break |
| 15:40 - 16:20 | Walter Silvestre Coan | Desenvolvendo agentes de IA com o Microsoft Agent Framework. |
| 16:20 - 17:10 | Nilton Ueda | A convergência entre Inteligência Artificial e Business Intelligence está transformando a maneira como as organizações criam, consomem e agem com base em insights de dados. |
| 17:10 - 17:30 | - | Encerramento |
#### Anfiteatro I
| Horário | Palestrante | Sessão |
|--------|-------------|--------|
| 13:30 - 14:20 | Paulo dos Santos | Azure AI Foundry - Do protótipo à produção: IA com governança, segurança e escala. |
| 14:20 - 15:10 | William Lino Oliveira | Agentes de IA para bancos de dados: descobrir, recomendar e otimizar. |
| 15:10 - 15:40 | - | Coffee break |
| 15:40 - 16:20 | Lerina Mesquita | Arquitetura moderna sem governança: como evitar que seu Lakehouse vire um Data Swamp. |
| 16:20 - 17:10 | Arthur Ferreira Reis | Qualidade de dados no Databricks: Great Expectations, DQX e testes isolados. |
| 17:10 - 17:30 | - | Encerramento |
#### Anfiteatro II
| Horário | Palestrante | Sessão |
|--------|-------------|--------|
| 13:30 - 14:20 | Rafael Ferreira & Jessica Mello | Vibe Coding com DevOps: usei IA para criar meu site, mas quem fez o deploy fui eu. |
| 14:20 - 15:10 | Laurindo Dunba | Demonstração prática (hands-on) sobre a plataforma Databricks e GitHub. |
| 15:10 - 15:40 | - | Coffee break |
| 15:40 - 16:20 | Rodrigo Gonçalves | Do ' OR 1=1 ao Shell: técnicas avançadas de SQLi e evasão para profissionais de dados. |
| 16:20 - 17:10 | - | Sessão em aberto |
| 17:10 - 17:30 | - | Encerramento |
### Minha palestra
Apresentei novamente com a [**Jéssica Mello**](https://www.linkedin.com/in/jessica-tmello/) a sessão:
**Vibe Coding com DevOps: usei IA para criar meu site, mas quem fez o deploy fui eu**.
A ideia foi mostrar como acelerar construção com IA sem abrir mão de fundamentos de engenharia, pipeline, governança e ownership técnico no deploy.
Falamos sobre:
- produtividade com IA aplicada ao desenvolvimento
- limites e riscos de gerar código sem processo
- importância de CI/CD e validações automáticas
- responsabilidade técnica no momento de publicar em produção
Participar do SQL Saturday Joinville 2026 como palestrante foi uma experiência excelente. O evento apenas reforça a força da comunidade técnica em Santa Catarina e como dados + IA + cloud estão cada vez mais conectados na prática.
Se você trabalha com dados, engenharia, analytics ou arquitetura em nuvem, esse é o tipo de evento que acelera aprendizado e eleva a qualidade das decisões no trabalho real.
[LinkedIn Post Divulgação evento](https://www.linkedin.com/posts/orafaelferreiraa_tem-muita-gente-falando-de-ia-criando-c%C3%B3digo-activity-7441808604246073344-ukc7?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAiBr9cBknrEzJyFEqCS03tes6G6R1yclRw)
### Slides
Os slides estão disponíveis aqui:
- **Slides da Apresentação:**
[Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU](https://stoblobcertificados011.blob.core.windows.net/palestras/SemServidorPlatform_Engineering.pdf)
### Repositórios da apresentação
- **Repositório do Site:**
[](https://github.com/orafaelferreiraa/orafaelferreira-com)
---
# Sem Servidor Conf 2026 (Edição Floripa): Platform Engineering - Construindo uma Plataforma Serverless Self-Service
URL: https://www.orafaelferreira.com/artigos/sem-servidor-conf-florianopolis-2026
Publicado: 2026-04-18
Categoria: Palestras
Tempo de leitura: 4 min de leitura
> Relato do Sem Servidor Conf 2026 em Florianópolis, onde palestrei sobre Platform Engineering e a construção de uma plataforma serverless self-service.
No dia **08 de abril de 2026**, participei como palestrante no **[Sem Servidor Conf 2026 - Edição Floripa](https://semservidor.com.br/sem-servidor-2026-edicao-floripa/)**, realizado no **Faial Prime Suites**, em Florianópolis.
Foi um evento presencial com foco total em **cloud, serverless-first e arquitetura moderna**, trazendo discussões práticas para o dia a dia de quem toma decisões técnicas.
### Grade de palestras
13:00 Credenciamento
14:00 - Abertura - Evandro Pires @ Sem Servidor
14:15 - Durable Functions vs Step functions... quem leva? - [Giovana Armani](https://www.linkedin.com/in/giovana-armani/) @ AWS
14:55 - O mistério dos pacotes perdidos, MTU quebrando sua Lambda - [Jorge Kohn](https://www.linkedin.com/in/jorgekg/) @ Senior Sistemas
15:35 - Integrações com APIs terceiras e serviços AWS - Um jeito simples usando Appsync - [Marcelo Andrade](https://www.linkedin.com/in/meandrade/) @ sls.guru
16:15 - Netbuilding + Coffee - -
17:00 - Serverless além do Tech (Case Buzios Divers) - [Filipe Barretto](https://www.linkedin.com/in/filipebarretto/) @ Buzios Divers / AWS Hero
17:40 - Platform Engineering: Construindo uma Plataforma Serverless Self-Service - Rafael Ferreira @ Stefanini North América
18:20 - Removendo a tecnologia das suas decisões de tecnologia - [Fernando Sapata](https://www.linkedin.com/in/fernandosapata/) @ Select / tnkr
19:00 - Encerramento - Evandro Pires @ Sem Servidor
Apresentei a talk **Platform Engineering: Construindo uma Plataforma Serverless Self-Service**.
A proposta foi mostrar como aplicar conceitos de platform engineering para acelerar entregas padronizadas, com automação e autonomia para os times, sem abrir mão da governança.
Falei sobre desafios de escalar, padronização de ambientes e como transformar boas práticas em produtos internos reutilizáveis.
### Um evento com conteúdo aplicável
Rolou palestras técnicas sobre AWS, integrações, arquitetura e tomadas de decisão em tecnologia. O mais legal foi como as palestras se conectaram em torno de um mesmo objetivo: **ajudar times a fazer escolhas melhores em cloud**.
E o diferencial como sempre, foi o networking durante os intervalos. Reunindo profissionais de diferentes contextos e empresas para trocar experiência de forma direta e sem filtro.
### Comunidade
Eventos como o Sem Servidor reforçam como a comunidade técnica no Brasil está madura e cada vez mais orientada a conteúdo prático.
Se você trabalha com cloud e arquitetura moderna, esse tipo de encontro acelera muito o aprendizado e melhora a qualidade das decisões no trabalho real.
[LinkedIn Post Divulgação evento](https://www.linkedin.com/posts/orafaelferreiraa_dia-08-de-abril-vou-estar-palestrando-no-activity-7439634283931004930-SxKr?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAiBr9cBknrEzJyFEqCS03tes6G6R1yclRw)
### Slides
Os slides estão disponíveis aqui:
- **Slides da Apresentação:**
[Platform Engineering - Construindo uma Plataforma Serverless Self-Service](https://stoblobcertificados011.blob.core.windows.net/palestras/SemServidorPlatform_Engineering.pdf)
### Repositórios da apresentação
- **Platform Stack:**
[platform-as-a-service-stack](https://github.com/orafaelferreiraa/platform-as-a-service-stack)
- **Pipeline Stack:**
[pipeline-as-a-service-stack](https://github.com/orafaelferreiraa/pipeline-as-a-service-stack)
- **TF Modules Stack:**
[tfmodules-as-a-service-stack](https://github.com/orafaelferreiraa/tfmodules-as-a-service-stack)
---
# Platform Engineering e Policy-as-Code que aceleram times
URL: https://www.orafaelferreira.com/artigos/platform-engineering-policy-as-code
Publicado: 2026-04-15
Categoria: Artigos
Tempo de leitura: 18–22 min de leitura
> Uma visão agnóstica de cloud sobre como Platform Engineering e Policy-as-Code reduzem carga cognitiva, aumentam segurança e aceleram entregas.
## Introdução
O [Platform Engineering](https://platformengineering.org/) surge como resposta à crescente complexidade das aplicações em nuvem. Criamos plataformas internas que automatizam infraestrutura e governança. A plataforma é tratada como um produto: o desenvolvedor é o cliente interno e deve encontrar o “caminho dourado” (golden path). Uma boa definição de Platform Engineering resume seu propósito: “melhorar a segurança, conformidade, custos e tempo de entrega de valor dos times de desenvolvimento por meio de experiências de desenvolvedor aprimoradas e self-service num ambiente seguro e governado”. Ao padronizar processos e oferecer automações prontas, as plataformas eliminam etapas repetitivas e reduzem drasticamente a carga cognitiva dos desenvolvedores.
Sem essa governança integrada, temos riscos de custos excessivos, falhas de segurança e não-conformidades. Equipes podem criar recursos em regiões caras ou não vigiadas, esquecer tags obrigatórias, expor APIs inadvertidamente etc. O Platform Engineering garante o complience disso criando guardrails automatizados: cada “guardrail” adiciona automaticamente práticas recomendadas. Isso reforça a segurança e compliance de modo invisível e natural ao desenvolvedor, acelerando entregas em vez de bloqueá-las.
### O que é Policy-as-Code (PaC)
[Policy-as-Code](https://platformengineering.org/blog/policy-as-code) é o paradigma de codificar regras de negócio, segurança e compliance em código executável, versionado e testável em pipelines. Em vez de revisar manuais, é validado automaticamente a mudança. Na prática, regras como “só usar VMs criptografadas” ou “não criar recursos fora de regiões aprovadas” viram definições de política em JSON (ou Rego, YAML etc.), armazenadas em repositório Git. Isso garante feedback rápido e contínuo: violações são detectadas tão cedo quanto possível, evitando que recursos errados cheguem à produção.
Quando implementamos PaC, mudamos do modelo "fazer e auditar depois" para "validar antes de implantar". Como destaca a comunidade de engenharia de plataforma, chamada "CAPOC" (Compliance At Point Of Change) – comprimir o ciclo de feedback de dias para segundos. Por exemplo, se um desenvolvedor tentar subir um container vulnerável, um engine de política ([OPA](#opa) ou [Kyverno](#kyverno)) a rejeita imediatamente, retornando erros legíveis. Assim, equipes de segurança se mantem centralizada, mas sem serem gargalo, cada time segue com autonomia porque políticas automatizadas garantem que só configurações aprovadas irão ver a luz do dia. Além disso, todo evento acaba criando trilhas de auditoria nativas que facilitam evidências de compliance.
### Ecossistema de ferramentas de políticas
O universo de PaC é amplo e, em geral, independente da nuvem. Várias ferramentas permitem implementar políticas em diferentes camadas:
#### OPA (Open Policy Agent)
[Open Policy Agent](https://www.openpolicyagent.org/docs/latest/) é uma enginee de políticas open-source graduado pela CNCF. Usa a linguagem Rego para definir regras gerais e pode ser integrado em aplicações, gateways de API, pipelines CI/CD e clusters Kubernetes. É ideal para cenários multi-cloud e autorização genérica, oferecendo boa performance e trilhas de auditoria detalhadas. Com OPA, é declarada regras em Rego e avalidas as decisões no ponto de mudança (CAPOC), garantindo feedback rápido e consistente.
#### Kyverno
[Kyverno](https://kyverno.io/) é uma ferramenta declarativa Kubernetes-native de PaC. Políticas em YAML validam, geram e podem até mutar recursos (por exemplo, adicionar labels faltantes automaticamente). Por ser nativo de Kubernetes, costuma ter curva de aprendizado mais suave para engenheiros de plataforma e acompanha features modernas do ecossistema.
#### Conftest
[Conftest](https://www.conftest.dev/) é baseada em [OPA](#opa) e valida arquivos de infraestrutura como código antes do apply (Terraform, Kubernetes YAML, Helm, CloudFormation etc.). Escrevemos policies em Rego e executamos testes no CI/CD ou localmente (ex.: `conftest test ./infra`). Isso captura violações cedo (tipos de VMs não permitidos, ausência de tags obrigatórias), evitando deploys inválidos e reduzindo retrabalho.
#### Azure Policy
[Azure Policy](https://learn.microsoft.com/en-us/azure/governance/policy/overview) é a solução nativa do Azure com painel de compliance, built-ins e integração com pipelines e CI. Escrevi um artigo detalhado sobre [Azure Policy na prática](https://www.orafaelferreira.com/artigos/az-policy). Em outros provedores, há equivalentes: no AWS, Service Control Policies (SCPs) e AWS Config Rules; no GCP, Organization Policies. Essas políticas nativas são ideais para aplicação universal das regras específicas de cada nuvem.
Hoje minha especialidade é cloud Azure, onde me sinto mais confortável. Recentemente criamos um projeto interno de Policy-as-Code com Terraform: colocamos as policies (arquivos .json) em uma pasta no repositório e o Terraform aplica essas definições automaticamente para toda a organização. Esse fluxo garante consistência, versionamento e a possibilidade de aplicar politicas de forma centralizada e garante governança em escala sem depender de processos manuais.
##### Um exemplo de Azure Policy
Um exemplo prático de Azure Policy que implementei em ambientes de produção foi: "Azure Backup should be enabled for Virtual Machines" (ID: 013e242c-8828-4970-87b3-ab247555486d) para auditar VMs sem item de backup associado a um Recovery Services Vault. Para passo a passo e opções de remediação (Portal, Azure Policy), veja: [Azure Backup para Máquinas Virtuais](https://www.orafaelferreira.com/artigos/azure-backup-virtual-machines).
### Fluxo DevEx com governança integrada
Para não atrapalhar a experiência do desenvolvedor (DevEx), as verificações de política devem ocorrer em todas as etapas do fluxo:
- **IDE/Local**: extensões (VSCode, IntelliJ) validam IaC e alertam sobre violações antes do commit (ex.: região proibida, tag ausente).
- **CI/CD (pré-merge)**: um job dedicado (policy-test) roda Conftest/OPA/Azure CLI Policy e barra PRs não conformes com mensagens claras.
- **Admission Controllers (Kubernetes)**: Gatekeeper ou [Kyverno](#kyverno) negam deploys inválidos (imagem não autorizada, portas indevidas) e podem mutar recursos para corrigir padrões.
- **Runtime Cloud**: [Azure Policy](https://learn.microsoft.com/en-us/azure/governance/policy/overview), AWS Config, etc., auditam continuamente; painéis de compliance mostram o status e facilitam remediação rápida.
### Boas práticas FinOps
De acordo com a [FinOps Foundation](https://www.finops.org/), as boas práticas incluem (confira também meu artigo sobre [fundação sólida em FinOps](https://www.orafaelferreira.com/artigos/finops-foundation-cloud)):
- **Tags obrigatórias**: owner, costCenter, environment — base para alocação de custos e responsabilização.
- **Controle de SKUs/limites por ambiente**: restrinja tipos de VMs e SKUs (evita surpresas em dev/staging).
- **Desligamento automático**: pare recursos de dev/sandbox fora do horário (Azure Automation/Runbooks/Stop schedules).
- **Orçamentos e alertas**: defina budgets (ex.: 80% do previsto) e acople alertas ao pipeline; falhe deploys quando limites forem excedidos.
- **Visibilidade e análises**: exporte custos para Analytics/Power BI; use Azure Cost Management/AWS Cost Explorer para dashboards de FinOps.
Exemplo: uma [Azure Landing Zone](https://www.orafaelferreira.com/artigos/foundation-lz) já vem com tagging obrigatório e orçamentos como parte da fundação.
### Estratégia de implantação de políticas
Ao adotar PaC e políticas de governança, faça um rollout gradual e iterativo:
**Audit → Aviso → Bloqueio → Remediação**: inicie monitorando (modo Audit) para entender impactos sem interromper processos. Depois passe a emitir warning (alertas visíveis) e só então a ações de Deny ou Modify. A comunicação ativa entre TI e times de DevOps é crucial a cada fase.
**Quick wins**: comece por políticas simples e de alto impacto, como região de implantação e tags obrigatórias. São fáceis de entender e gerarão resultados rápidos. Conforme a confiança cresce, evolua para regras mais críticas.
**Mensagens claras**: políticas devem ter descrições óbvias. Erros genéricos tipo "Policy Failed" não são úteis – prefira feedback específico ("Região inválida: use East US ou West Europe").
**Planos de 30/60/90 dias**: muitos times definem cronogramas de maturidade. Por exemplo, em 30 dias inventariar políticas desejadas e habilitar audit mode, em 60 dias integrar testes no CI e usar admission controllers em staging, e em 90 dias ativar bloqueios em produção para regras críticas e automatizar remediações. Assim, a governança vira um facilitador continuo, não um obstáculo emergencial.
### Conclusão
Integrar Policy-as-Code à engenharia de plataforma transforma a governança numa aliada, não num gargalo. Quando as políticas de segurança, compliance e custo são incorporadas no dia a dia de forma automatizada, elas se tornam invisíveis ao usuário – o time só vê as “regras do jogo” funcionando nos bastidores. Como resultado, equipes entregam mais rápido e com menor risco: não há mais um “time do não” bloqueando solicitações, mas sim orientações automáticas que guiam o desenvolvimento.
### Referências
- [Platform Engineering](https://platformengineering.org/)
- [Policy-as-Code](https://platformengineering.org/blog/policy-as-code)
- [Martin Fowler – Platform Engineering](https://martinfowler.com/articles/platform-teams-stuff-done.html)
- [Open Policy Agent](https://www.openpolicyagent.org/docs/latest/)
- [Kyverno](https://kyverno.io/)
- [Conftest](https://www.conftest.dev/)
- [Azure Policy Overview](https://learn.microsoft.com/en-us/azure/governance/policy/overview)
- [Azure Cloud Adoption Framework - Landing Zones](https://learn.microsoft.com/en-us/cloud-adoption-framework/landing-zones/)
- [FinOps Foundation](https://www.finops.org/)
- [Azure Policy na prática](https://www.orafaelferreira.com/artigos/az-policy)
- [Fundação sólida em FinOps](https://www.orafaelferreira.com/artigos/finops-foundation-cloud)
- [Azure Backup para Máquinas Virtuais](https://www.orafaelferreira.com/artigos/azure-backup-virtual-machines)
---
# Arquitetura Baseline do Zero: App Service com Application Gateway, Private Link e Azure DNS
URL: https://www.orafaelferreira.com/artigos/app-gateway-baseline-private-endpoint
Publicado: 2026-03-08
Categoria: Artigos
Tempo de leitura: 22 min de leitura
> Guia passo a passo da baseline architecture no Azure: Azure DNS, Application Gateway WAF, Private Endpoints, Key Vault, SQL, Storage, TLS e testes finais.
## Arquitetura baseline do zero (sem retrabalho)
Muita gente me pergunta: "como eu pratico?", "como eu estudo pra certificação?", "como eu monto um laboratório de verdade?". A resposta é simples: implementando. Não adianta só assistir vídeo ou ler documentação se você nunca subiu a arquitetura com as próprias mãos.
A arquitetura que vamos implementar é baseada nas referências oficiais do [Centro de Arquitetura do Azure](https://learn.microsoft.com/pt-br/azure/architecture/), onde a Microsoft publica padrões, práticas recomendadas e arquiteturas de referência para cargas de trabalho reais.
Arquitetura final:
**Usuário -> Azure DNS (público) -> Application Gateway WAF -> Private Endpoint -> App Service**
Com serviços de apoio privados:
- Key Vault
- Storage Account
- Azure SQL
[Referência oficial da Microsoft](https://learn.microsoft.com/pt-br/azure/architecture/web-apps/app-service/architectures/baseline-zone-redundant)
### O que vamos criar
- Resource Group único para o laboratório
- Domínio público delegado para Azure DNS
- VNet segmentada com subnets dedicadas
- Private DNS Zones para resolução interna de Private Link
- App Service com acesso público desabilitado
- Application Gateway WAF v2 com IP público
- Certificado TLS no Key Vault com Managed Identity
- Validações finais de ponta a ponta
Troque os nomes abaixo para o seu ambiente, mantendo o padrão:
- Resource Group: `rg-app-baseline-lab`
- Região: `Brazil South`
- Domínio: `seudominio.com.br`
- App público: `app.seudominio.com.br`
- VNet: `vnet-app-baseline`
## ETAPA 1 - Criar Resource Group
Crie o grupo de recursos:
- Nome: `rg-app-baseline-lab`
- Região: `Brazil South` (ou outra com suporte a zonas)
Tudo do laboratório fica aqui dentro. O RG serve como uma pasta, onde você organizar seus arquivos. E na Azure, é onde fica o seus recursos, você deletando o RG você deleta tudo que tem dentro.
## ETAPA 2 - Utilizar domínio
Compre ou utilize o domínio público (exemplo: `seudominio.com.br`) no registrador da sua preferência.
## ETAPA 3 - Criar zona DNS pública no Azure
No Azure, crie uma **DNS Zone pública**:
- Nome: `seudominio.com.br`
- Tipo: Público
Depois de criada:
- Copie os 4 name servers da zona
- No registrador, substitua os DNS atuais pelos name servers do Azure
Quando a delegação propagar, o Azure DNS vira autoridade oficial do domínio e assim poderemos seguir com as alterações tudo dentro de um portal.
## ETAPA 4 - Criar VNet e subnets
Crie a VNet:
- Nome: `vnet-app-baseline`
- Address space: `10.0.0.0/16`
- Região: mesma do Resource Group
Crie as subnets:
```
snet-appGateway 10.0.1.0/24
snet-appService 10.0.0.0/24
snet-privateEndpoints 10.0.2.0/27
```
Configuração obrigatória:
- Em `snet-appService`, habilite delegation para `Microsoft.Web/serverFarms`
- A subnet do Application Gateway deve ser dedicada (não compartilhe com PE, VM ou NIC)
Nota prática importante: `GatewaySubnet` é reservada para `VPN Gateway` e `ExpressRoute`. Para `Application Gateway`, crie uma subnet dedicada com outro nome, por exemplo `SubnetAppGateway`, `agw-subnet` ou `snet-appgw`. O nome não é obrigatório, mas a exclusividade da subnet é obrigatória.
### NSG (Network Security Group) obrigatório na subnet do Application Gateway
Conforme a documentação da Microsoft, a subnet do Application Gateway v2 exige NSG com regras específicas. Sem essas regras, o gateway não funciona.
Crie um NSG e associe a `snet-appGateway` com as seguintes regras:
**Inbound:**
| Prioridade | Nome | Source | Destination | Porta | Protocolo | Ação |
|---|---|---|---|---|---|---|
| 100 | Allow-HTTP | Any | Subnet prefix | 80 | TCP | Allow |
| 110 | Allow-HTTPS | Any | Subnet prefix | 443 | TCP | Allow |
| 120 | Allow-GatewayManager | GatewayManager | Any | 65200-65535 | TCP | Allow |
| 130 | Allow-AzureLoadBalancer | AzureLoadBalancer | Any | Any | Any | Allow |
**Outbound:**
| Prioridade | Nome | Source | Destination | Porta | Protocolo | Ação |
|---|---|---|---|---|---|---|
| 100 | Allow-Internet | Any | Internet | Any | Any | Allow |
A regra `GatewayManager` nas portas `65200-65535` é obrigatória para o control plane do Application Gateway v2. Sem ela, o backend health não funciona.
### DDoS Protection
A Microsoft recomenda habilitar DDoS Protection na VNet que contém a subnet do Application Gateway com IP público. No portal:
- VNet -> DDoS Protection -> Enable
## ETAPA 5 - Criar Private DNS Zones
Crie estas zonas privadas:
- `privatelink.azurewebsites.net`
- `privatelink.database.windows.net`
- `privatelink.vaultcore.azure.net`
- `privatelink.blob.core.windows.net`
Depois, crie o **Virtual Network Link** de cada zona para `vnet-app-baseline`.
Sem esse passo, Private Endpoint costuma quebrar por falha de resolução DNS.
## ETAPA 6 - Criar Key Vault (privado)
Crie o Key Vault:
- Nome: `kv-app-baseline`
- Public network access: **Disabled**
- Authorization model: **Azure RBAC**
Depois crie o Private Endpoint do Key Vault:
- Subnet: `snet-privateEndpoints`
- Private DNS Zone: `privatelink.vaultcore.azure.net`
## ETAPA 7 - Criar Storage Account (privado)
Crie a Storage Account:
- Nome único (exemplo): `stappbaseline123`
- Redundância: `ZRS`
- Public network access: **Disabled**
Crie o Private Endpoint para Blob:
- Subresource: `blob`
- Subnet: `snet-privateEndpoints`
- Private DNS Zone: `privatelink.blob.core.windows.net`
## ETAPA 8 - Criar Azure SQL (privado)
Ordem recomendada no portal para evitar retrabalho:
1. Criar o SQL Server
2. Criar o SQL Database
3. Criar o Private Endpoint para o SQL
Crie o SQL Server:
- Public network access: **Disabled**
Crie o banco de dados no servidor criado:
- Camada: `General Purpose`
- Zone redundancy: habilitado
Depois crie o Private Endpoint do SQL:
- Subnet: `snet-privateEndpoints`
- Private DNS Zone: `privatelink.database.windows.net`
## ETAPA 9 - Criar App Service Plan
Configuração recomendada para baseline:
- Tier: `Premium v3/v4`
- Zone redundancy: habilitado
- Instance count inicial: `3`
A Microsoft recomenda no mínimo 3 instâncias para o App Service Plan com zone redundancy. Se uma zona falhar, as outras 2 mantêm a disponibilidade sem esperar o startup de novas instâncias.
## ETAPA 10 - Criar Web App
Crie o Web App (Node, .NET ou container) usando o plano da etapa anterior.
Depois configure:
- Networking -> VNet Integration -> `snet-appService`
- Public Network Access -> **Disabled**
- Health Check -> `/` (ou endpoint de health da sua app)
O Health Check permite que o App Service detecte instâncias com problema e redirecione tráfego automaticamente para instâncias saudáveis. Requer no mínimo 2 instâncias no plano.
## ETAPA 11 - Criar Private Endpoint do Web App
No Web App:
- Networking -> Private Endpoint -> Add
- Subnet: `snet-privateEndpoints`
- Subresource: `sites`
- Private DNS Zone: `privatelink.azurewebsites.net`
Resultado esperado: o App Service fica acessível apenas internamente.
## ETAPA 12 - Criar Application Gateway + WAF
Primeiro, crie um Public IP:
- SKU: `Standard`
- Zone-redundant
Depois crie o Application Gateway:
- SKU: `WAF_v2`
- Autoscaling: habilitado
- Min instances: `3` (Microsoft recomenda no mínimo 3 para evitar downtime de 6-7 min no startup de nova instância)
- Subnet: `snet-appGateway` (ou a subnet dedicada definida para o gateway)
Depois de criar o Application Gateway, crie uma **WAF Policy**:
- Pesquise `Web Application Firewall policies` -> Create
- Mode: **Prevention**
- Ruleset: `Microsoft Default Rule Set (DRS) 2.1` ou mais recente
- Associe ao Application Gateway criado
Sem a WAF Policy em Prevention, o WAF não bloqueia ataques como SQL injection e XSS.
Configuração inicial (HTTP temporário para validar fluxo):
1. Listener HTTP:
- Protocolo: `HTTP`
- Porta: `80`
2. Backend Pool:
- Target: FQDN
- Valor: `nomedoapp.azurewebsites.net`
3. HTTP Settings:
- Protocolo: `HTTPS`
- Porta: `443`
- Override host name: `nomedoapp.azurewebsites.net`
- SNI: habilitado
4. Health Probe customizada:
- Host: `nomedoapp.azurewebsites.net`
- Path: `/` (ou endpoint de health da sua app)
5. Rule:
- Associe Listener -> Backend Pool -> HTTP Settings
Se backend ficar `Unhealthy`, o problema costuma ser DNS privado não vinculado corretamente ou host/probe incorretos.
## ETAPA 13 - Criar registro DNS público
Na zona DNS pública `seudominio.com.br`, crie:
- Tipo: `A`
- Nome: `app`
- IP: IP público do Application Gateway
Resultado:
`app.seudominio.com.br` -> Application Gateway
## ETAPA 14 - Configurar HTTPS real com certificado
Emita certificado para:
`app.seudominio.com.br`
Pode ser Let's Encrypt, ZeroSSL ou certificado comercial.
### Tutorial rápido - certificado gratuito com ZeroSSL
Para este lab, use o fluxo por validação DNS no ZeroSSL.
1. Acesse o ZeroSSL e inicie emissão para `app.seudominio.com.br`.
2. Escolha validação por `CNAME`.
3. O ZeroSSL vai fornecer um registro parecido com este:
```
Name
_xxxx.app.seudominio.com.br
Target
xxxx.comodoca.com
```
4. Na zona `seudominio.com.br` no Azure DNS, crie o `CNAME` com os valores informados.
5. Aguarde propagação e valide:
```bash
nslookup -type=CNAME _xxxx.app.seudominio.com.br
```
6. Conclua a validação no portal do ZeroSSL e baixe os arquivos:
```
certificate.crt
ca_bundle.crt
private.key
```
7. Converta para `PFX`:
```bash
openssl pkcs12 -export \
-out app-seudominio.pfx \
-inkey private.key \
-in certificate.crt \
-certfile ca_bundle.crt
```
Importe o certificado no Key Vault.
### Passo obrigatório - criar User Assigned Managed Identity
[Referência oficial da Microsoft](https://learn.microsoft.com/azure/application-gateway/key-vault-certs)
Conforme a documentação, a integração Application Gateway + Key Vault exige 3 passos:
1. Criar uma User Assigned Managed Identity
2. Delegar acesso dessa identidade ao Key Vault
3. Associar a identidade e o certificado no Application Gateway via CLI ou PowerShell
Importante: com Azure RBAC no Key Vault (como configuramos na ETAPA 6), o vínculo da identidade e do certificado no Application Gateway não é suportado pelo portal. Use PowerShell ou CLI.
#### Passo 1 - Criar a identidade
No portal:
- Pesquise `Managed Identities` -> Create
- Nome: `mi-agw-kv-reader`
- Resource Group: `rg-app-baseline-lab`
- Região: mesma do lab
#### Passo 2 - Conceder permissão no Key Vault
No Key Vault -> IAM:
- Role: `Key Vault Secrets User`
- Principal: `mi-agw-kv-reader`
Nota: como o Key Vault tem Private Endpoint habilitado (ETAPA 6), o Application Gateway já consegue acessar via IP privado desde que a zona `privatelink.vaultcore.azure.net` esteja linkada a VNet (ETAPA 5).
#### Passo 3 - Associar identidade e certificado no Application Gateway (PowerShell)
```powershell
## Obter o Application Gateway
$appgw = Get-AzApplicationGateway -Name agw-app-baseline -ResourceGroupName rg-app-baseline-lab
## Associar a User Assigned Managed Identity
Set-AzApplicationGatewayIdentity -ApplicationGateway $appgw \
-UserAssignedIdentityId "/subscriptions//resourceGroups/rg-app-baseline-lab/providers/Microsoft.ManagedIdentity/userAssignedIdentities/mi-agw-kv-reader"
## Obter o secret ID do certificado no Key Vault (sem versão para auto-rotação)
$secret = Get-AzKeyVaultSecret -VaultName "kv-app-baseline" -Name ""
$secretId = $secret.Id.Replace($secret.Version, "")
## Adicionar o certificado SSL ao Application Gateway
Add-AzApplicationGatewaySslCertificate -KeyVaultSecretId $secretId -ApplicationGateway $appgw -Name $secret.Name
## Aplicar as alterações
Set-AzApplicationGateway -ApplicationGateway $appgw
```
#### Passo 4 - Criar Listener HTTPS no portal
Agora sim, no portal:
- Application Gateway -> Listeners -> Add Listener
- Protocol: HTTPS
- Porta: 443
- Host name: `app.seudominio.com.br`
- Certificate: selecione o certificado adicionado no passo anterior
- Save
#### Passo 5 - Redirect HTTP para HTTPS
No Application Gateway, crie uma regra de redirecionamento:
- Application Gateway -> Rules -> selecione a regra do Listener HTTP (porta 80)
- Backend targets: troque para **Redirection**
- Target type: `Listener`
- Target listener: o listener HTTPS criado no passo anterior
- Redirect type: `Permanent (301)`
Isso garante que todo acesso HTTP seja redirecionado automaticamente para HTTPS.
## ETAPA 15 - Testes finais (checklist de aceite)
Teste 1:
```
https://app.seudominio.com.br
```
Esperado: carregar normalmente via Application Gateway.
Teste 2:
```
https://nomedoapp.azurewebsites.net
```
Esperado: falhar (acesso público do App Service desabilitado).
Teste 3:
```
nslookup app.seudominio.com.br
```
Esperado: retornar o IP público do Application Gateway.
Se os 3 testes passarem, sua baseline esta pronta com:
- DNS público no Azure
- WAF na borda
- Private Link no backend
- Isolamento de rede
- TLS ponta a ponta
## Troubleshooting rápido
### Backend `Unhealthy` no Application Gateway
- Verifique se as Private DNS Zones estão linkadas a VNet
- Confirme host da probe e path de health
- Valide se o Web App responde 200 no endpoint usado na probe
### Erro de certificado no listener HTTPS
- Confirme Managed Identity ativa no Application Gateway
- Confirme role `Key Vault Secrets User` no Key Vault
- Aguarde propagação de permissões RBAC (pode levar alguns minutos)
### Erro de host header
- Confirme que o domínio público foi adicionado no App Service (Custom Domains), quando exigido pelo seu fluxo
## Exportar como Infrastructure as Code (IaC)
Para quem não conhece, o Azure permite exportar todos os recursos de um Resource Group como código. Você pode gerar templates em ARM (JSON), Bicep ou Terraform direto pelo portal ou CLI.
No portal: Resource Group -> Export template.
Isso é útil para versionar a infraestrutura, replicar o ambiente em outra subscription ou usar como base para automação em pipelines de CI/CD.
Neste laboratório, exportei o Resource Group inteiro no formato Terraform. O arquivo ficou com mais de 2 mil linhas, então não incluí aqui no artigo. Publiquei no meu repositório do GitHub como referência:
[**Github**](https://github.com/orafaelferreiraa/tf-app-gateway-baseline-private-endpoint)
Importante: esse export não foi testado como implementação real com `terraform apply`. O Azure gera o código a partir do estado atual dos recursos, mas nem sempre o resultado é aplicável sem ajustes. Use como ponto de partida e referência, não como código pronto para produção.
## Visualização da arquitetura no portal
O Azure oferece uma funcionalidade de visualização gráfica direto pelo Resource Group. No portal, acesse Resource Group -> Resource visualizer. Lá você consegue ver todos os recursos e suas conexões em um diagrama interativo, e exportar a imagem.
Este é o resultado final do nosso laboratório:
## Conclusão
Esse roteiro evita o ciclo comum de "cria recurso, testa, quebra DNS, volta tudo".
Seguindo essa ordem, você implementa a arquitetura baseline completa de forma previsível: primeiro identidade e rede, depois Private Link, em seguida borda WAF e por fim DNS/TLS público com validação final.
---
# Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU - Meetup Codecon #15
URL: https://www.orafaelferreira.com/artigos/codecon-15-florianopolis
Publicado: 2026-02-27
Categoria: Palestras
Tempo de leitura: 4 min de leitura
> Relato da palestra Vibe Coding com DevOps no Meetup Codecon #15 em Florianópolis: um site que nasceu de um prompt com IA e chegou à produção com DevOps.
No dia **25 de fevereiro de 2026**, rolou o [**Codecon Meetup #15**](https://eventos.codecon.dev/eventos/floripa-meetup-codecon-15) em Florianópolis. O encontro aconteceu no **Impact Hub Bewiki**, no centro da cidade, um espaço de coworking focado em inovação e conexões entre profissionais de tecnologia.
Foram cerca de 3 horas de troca técnica, networking e conversas sobre como a IA e o ensino estão mudando a forma de construir software.
Abri a noite junto com a [**Jéssica Mello**](https://www.linkedin.com/in/jessica-tmello/) com a talk:
**Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU**
A proposta foi mostrar um case real: a construção do meu site pessoal usando **IA generativa + engenharia de software + DevOps**.
A história começou com um prompt simples, pedindo um site profissional, moderno e responsivo. A primeira versão saiu toda com IA e virou um one-page rápido de colocar no ar, mas aquilo era só o começo.
### Do prompt ao código
Depois da primeira versão gerada por IA, o próximo passo foi assumir o controle do projeto. O site saiu da ferramenta de geração e foi para um repositório com versionamento profissional, refatoração e organização de código.
Foi ali que o projeto deixou de ser só um experimento de IA e virou um produto de verdade: separação em múltiplas páginas, melhorias de UX, ajustes de SEO e evolução contínua.
A IA ajudou muito a acelerar, mas engenharia ainda manda no resultado final.
### Colocando em produção
Toda a infraestrutura foi provisionada usando **Infrastructure as Code (Terraform)**, garantindo imutabilidade e consistência. O deploy ficou totalmente automatizado com pipeline CI/CD.
Push no repositório, testes rodando, deploy automático. No ClickOps.
Também falamos sobre o lado que pouca gente comenta quando o assunto é IA. Dependência de plataforma, custos e vendor lock-in são alguns riscos. IA acelera muito, mas em produção exige controle. Essa foi uma das mensagens centrais da talk.
Mas uma coisa continua igual: deploy ainda é responsabilidade do engenheiro.
E ainda bem.
### Tecnologia como ponte
Na sequência, a **[Maiza Louise](https://www.linkedin.com/in/maizalouise/)** trouxe a talk: **Tecnologia como ponte para educação de qualidade**
Uma visão bem diferente e complementar, mostrando como tecnologia pode gerar impacto real fora do mundo corporativo. Esse tipo de assunto deixa o meetup muito mais rico.
### Fechamento
Eu e a Maisa estavamos representando a Alura, que estava presente apoiando o evento. Tivemos um sorteio de um ano de licença da plataforma.
E essa é a foto com o ganhador:
### Slides
Os slides estão disponíveis aqui:
- **Slides da Apresentação:**
[Vibe Coding com DevOps – Codecon #15](https://stoblobcertificados011.blob.core.windows.net/palestras/codecon15.pdf)
---
# Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU - no 92º Python Floripa
URL: https://www.orafaelferreira.com/artigos/python-floripa-92-hostgator
Publicado: 2026-02-01
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> Relato do 92º Python Floripa na HostGator: talk Vibe Coding com DevOps ao lado de Jéssica Mello, IA sem romantização, DevOps no mundo real e networking.
No dia **31 de janeiro de 2026**, rolou o [**92º Python Floripa**](https://www.meetup.com/pt-br/floripa-python-meetup/events/312978297/?eventOrigin=group_past_events), dessa vez dentro do QG da **HostGator**, em Florianópolis. E olha… competimos com a praia num sábado de sol em pleno verão e ganhamos. Isso diz muita coisa sobre a força da comunidade.
Casa cheia, energia lá em cima e um clima muito claro: sem hype, mais prática. Menos buzzword, mais ideia de como construir software hoje.
### Uma tarde FOD@
As talks se conectaram, nada fora do contexto. Como desenvolver software com mais consciência, estratégia e visão de longo prazo.
Abri a tarde junto com a [**Jéssica Mello**](https://www.linkedin.com/in/jessica-tmello/), puxando uma conversa bem direta sobre **Vibe Coding com DevOps**. IA ajuda, acelera, mas não substitui humano, processo e muito menos o engenheiro/a. E sim, **DevOps continua sendo peça-chave** quando o assunto é colocar aplicação no ar com segurança, controle e previsibilidade.
A ideia não foi vender futuro mágico, foi apresentar um case real, mesmo que o meu site (vulgo esse que você está lendo agora).
### IA no dia a dia de quem constrói
Na sequência, a **Evelyn Cid** aprofundou exatamente esse ponto: como a IA já está impactando a rotina do desenvolvedor agora, do código à tomada de decisão. Menos palco, mais bastidor. Menos promessa, mais uso consciente por quem está no teclado todos os dias.
Fechando o evento, a **Ana Paula Mendes** trouxe um tema que deveria ser obrigatório em qualquer carreira tech: **brag document**.
### Comunidade sendo comunidade
As **lightning talks** deram aquele tempero clássico do Python Floripa: projetos pessoais, ideias em construção, dicas práticas e muita troca honesta. Gente aprendendo, gente ensinando e todo mundo no mesmo nível.
E claro, o coffee break fez jus à fama. Muita conversa e networking
### Agradecimento
Fica aqui um agradecimento gigante à Comunidade **Python Floripa**, que fortalecem demais a cena tech em Floripa.
As talks estão disponíveis no [YouTube](https://www.youtube.com/watch?v=XQPHdujjrAY) pra quem quiser assistir ou reassistir. E se a quiser participar do próximo, já se organiza e acompanha as novidades no nosso [calendário](https://tech.floripa.br/).
- **Slides da Apresentação:** [Vibe Coding com DevOps: usei IA pra criar meu site, mas quem fez o deploy fui EU](https://stoblobcertificados011.blob.core.windows.net/palestras/98python-floripa.pdf)
---
# A Stack por trás do meu Blog: Pipelines CI/CD, Testes e Estratégias GitHub Actions
URL: https://www.orafaelferreira.com/artigos/artigo-github-actions-deep-dive
Publicado: 2026-01-22
Categoria: Artigos
Tempo de leitura: 15 min de leitura
> Deep dive nas estratégias de GitHub Actions do meu blog: arquitetura de workflows, cache, pirâmide de testes, segurança e observabilidade em casos reais.
## Introdução
No [artigo anterior](https://www.orafaelferreira.com/artigo-terraform-infra-cicd), mostrei como estruturei a infraestrutura do blog com Terraform e GitHub Actions. Agora vamos seguir em frente e fazer um deep dive no GitHub Actions (Pipelines CI/CD).
Vou compartilhar estratégias de deploy, pull requests, conceitos de engenharia de platforma aplicadas na prática, otimizações de performance e práticas de segurança que apliquei.
### O que vamos ver:
- **Arquitetura de Workflows**: Overview das 3 pipelines (infra-plan, infra-deploy, deploy-app)
- **Estratégias de Branching**: trunk-based development aplicado na prática
- **Pirâmide de Testes**: unitários, componentes e E2E
- **Otimização de Performance**: caching de dependências e providers Terraform
- **Segurança em Pipelines**: tflint, tfsec, Checkov e gestão de secrets Azure
- **Job Summaries**: informações dos outputs após as execuções
### 1. Arquitetura de Workflows
#### 1.1 Organização e Nomenclatura
Uma das primeiras decisões que tomei foi: **como organizar as workflows**. Em projetos menores, tudo pode ficar em um único arquivo. Em projetos maiores, com a separação fica mais a manutenção e sua usabilidade.
**Estrutura atual do projeto:**
```
.github/
workflows/
infra-plan.yml # PR → Terraform plan + validações
infra-apply.yml # main → Terraform apply + docs
deploy-app.yml # main → build + testes + deploy
```
#### 1.2 Path Filters: Execute Apenas o Necessário
Uma otimização simples mas poderosa: **não rode workflows quando não há mudanças relevantes**.
**infra-plan.yml** (executa apenas em mudanças na infra):
```yaml
on:
pull_request:
branches: [ main ]
paths:
- 'infra/**'
- '.github/workflows/infra-plan.yml'
```
**deploy-app.yml** (executa em mudanças no código da aplicação):
```yaml
on:
push:
branches: [ main ]
paths:
- 'src/**'
- 'e2e/**'
- 'public/**'
- 'index.html'
- 'package.json'
- 'package-lock.json'
- 'bun.lockb'
- 'tsconfig*.json'
- 'vite.config.ts'
- 'tailwind.config.ts'
- 'postcss.config.js'
- 'eslint.config.js'
- '.github/workflows/deploy-app.yml'
```
Se você só mexer no README, nenhum workflow roda.
#### 1.3 Workflow Chaining: Infra → App
O **deploy-app.yml** tem um trigger com uma condition: aguarda a workflow **infra-apply** terminar com sucesso:
```yaml
on:
workflow_run:
workflows: ["infra-apply"]
types:
- completed
branches: [ main ]
jobs:
build_and_deploy:
if: github.event.workflow_run.conclusion == 'success'
```
Se eu alterar algo na infraestrutura (Terraform) e o código do site ao mesmo tempo, a infra deve ser provisionada antes do deploy da app.
### 2. Estratégias de Branching e CI/CD
A estratégia de branching influencia diretamente **como seus workflows se comportam**.
#### 2.1 Trunk-Based Development na Prática
**Abordagem implementada:**
```
main (produção)
↑
feature branches ou commits diretos
```
**Workflow por evento:**
**Pull Request → main** (infra-plan.yml):
```yaml
on:
pull_request:
branches: [ main ]
paths:
- 'infra/**'
- '.github/workflows/infra-plan.yml'
workflow_dispatch:
jobs:
terraform-plan:
# Executa plan, validações, scans
# Adiciona comentário do plan no PR
```
**Push → main** (infra-apply.yml e deploy-app.yml):
```yaml
on:
push:
branches: [ main ]
paths:
- 'infra/**'
- '.github/workflows/infra-apply.yml'
workflow_dispatch:
jobs:
terraform: # infra-apply
build_and_deploy: # deploy-app
```
**Proteção adicional**: o bot github-actions é bloqueado para evitar loops infinitos:
```yaml
if: github.actor != 'github-actions[bot]'
```
#### 2.2 Concurrency Control
**Problema**: múltiplos pushes podem criar race conditions no deploy.
**Solução**: controle de concorrência
```yaml
concurrency:
group: deploy-${{ github.ref }}
cancel-in-progress: true # Cancela deploys anteriores
```
Para infraestrutura (Terraform):
```yaml
concurrency:
group: infra-${{ github.head_ref || github.ref }}
cancel-in-progress: true # Cancela runs anteriores
```
### 3. Pirâmide de Testes
```
/\
/ \
/ E2E\ ← Poucos, críticos
/------\
/ API \ ← Médios, contratos
/----------\
/ Unit Tests \ ← Base sólida
/--------------\
```
#### 3.1 Testes Unitários (Base)
**No projeto do blog:**
```yaml
- name: Unit tests
run: npm run test:ci
```
```json
// package.json
{
"scripts": {
"test": "vitest",
"test:ci": "vitest run --coverage --reporter=verbose"
}
}
```
**Configuração Vitest:**
```typescript
// vitest.config.ts
export default defineConfig({
test: {
globals: true,
environment: 'jsdom',
setupFiles: './src/setupTests.ts',
coverage: {
provider: 'v8',
reporter: ['text', 'lcov', 'html'],
exclude: [
'node_modules/',
'src/setupTests.ts',
'**/*.d.ts',
'**/*.config.*',
'**/mockData',
],
thresholds: {
lines: 80,
functions: 75,
branches: 70,
statements: 80,
},
},
},
});
```
**Output no CI:**
- Output no job summary
- Falha se abaixo dos thresholds
#### 3.2 Testes de Componente
**Objetivo**: validar UI isoladamente.
```yaml
- name: Component tests
run: npm run test:components:ci
```
**React Testing Library + Vitest:**
```typescript
// src/components/ui/button.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { Button } from './button';
describe('Button', () => {
it('executa onClick quando clicado', async () => {
const handleClick = vi.fn();
render();
await userEvent.click(screen.getByRole('button'));
expect(handleClick).toHaveBeenCalledTimes(1);
});
it('renderiza variantes corretamente', () => {
const { container } = render();
expect(container.firstChild).toHaveClass('bg-destructive');
});
});
```
**Configuração específica:**
```typescript
// vitest.config.components.ts
export default defineConfig({
test: {
include: ['src/components/**/*.test.tsx'],
environment: 'jsdom',
setupFiles: './src/setupTests.ts',
},
});
```
#### 3.3 Testes E2E
**Objetivo**: validar fluxos críticos de ponta a ponta.
```yaml
- name: Get Playwright version
id: playwright-version
run: echo "version=$(npm list @playwright/test --depth=0 --json 2>/dev/null | jq -r '.dependencies["@playwright/test"].version // empty')" >> $GITHUB_OUTPUT
- name: Cache Playwright browsers
uses: actions/cache@v4
with:
path: ~/.cache/ms-playwright
key: playwright-${{ runner.os }}-${{ steps.playwright-version.outputs.version }}
- name: Install Playwright browsers
if: steps.playwright-cache.outputs.cache-hit != 'true'
run: npx playwright install --with-deps
- name: E2E smoke tests
run: npm run test:e2e:ci
```
**Testes smoke (cenários críticos):**
```typescript
// e2e/smoke.spec.ts
import { test, expect } from '@playwright/test';
test.describe('Smoke Tests', () => {
test('deve carregar a página inicial', async ({ page }) => {
await page.goto('/');
await expect(page).toHaveTitle(/Rafael Ferreira/);
await expect(page.locator('h1')).toBeVisible();
});
test('deve navegar para artigo e renderizar conteúdo', async ({ page }) => {
await page.goto('/');
await page.click('text=Blog');
await page.click('a:has-text("Terraform")').first();
await expect(page).toHaveURL(/artigo-terraform/);
await expect(page.locator('article')).toBeVisible();
});
test('deve alternar idioma', async ({ page }) => {
await page.goto('/');
const initialLang = await page.locator('html').getAttribute('lang');
await page.click('[data-testid="language-toggle"]');
const newLang = await page.locator('html').getAttribute('lang');
expect(newLang).not.toBe(initialLang);
});
});
```
**Configuração Playwright:**
```typescript
// playwright.config.ts
export default defineConfig({
testDir: './e2e',
fullyParallel: true,
forbidOnly: !!process.env.CI,
retries: process.env.CI ? 2 : 0,
workers: process.env.CI ? 1 : undefined,
reporter: process.env.CI ? 'github' : 'html',
use: {
baseURL: 'http://localhost:5173',
trace: 'on-first-retry',
screenshot: 'only-on-failure',
},
webServer: {
command: 'npm run preview',
port: 5173,
reuseExistingServer: !process.env.CI,
},
});
```
#### 3.4 Paralelização de Testes
**Estratégia de matriz:**
```yaml
test:
runs-on: ubuntu-latest
strategy:
matrix:
shard: [1, 2, 3, 4]
steps:
- name: Run tests
run: npm run test:ci -- --shard=${{ matrix.shard }}/4
```
**Para Playwright:**
```yaml
e2e:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shardIndex: [1, 2, 3, 4]
shardTotal: [4]
steps:
- name: Run E2E
run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
```
**Resultado**: redução de ~75% no tempo de execução.
### 4. Otimização de Performance
#### 4.1 Estratégias de Cache Avançadas
**Cache em camadas:**
```yaml
- name: Cache dependencies
uses: actions/cache@v4
with:
path: |
~/.npm
node_modules
~/.cache/ms-playwright
key: ${{ runner.os }}-deps-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/playwright.config.ts') }}
restore-keys: |
${{ runner.os }}-deps-${{ hashFiles('**/package-lock.json') }}-
${{ runner.os }}-deps-
```
**Cache de build:**
```yaml
- name: Cache build output
uses: actions/cache@v4
with:
path: |
.next/cache
dist/
.vite/
key: build-${{ runner.os }}-${{ github.sha }}
restore-keys: |
build-${{ runner.os }}-
```
**Cache de Terraform providers:**
```yaml
- name: Cache Terraform
uses: actions/cache@v4
with:
path: |
infra/.terraform
~/.terraform.d/plugin-cache
key: terraform-${{ runner.os }}-${{ hashFiles('infra/.terraform.lock.hcl') }}
```
#### 4.2 Artifacts Estratégicos
**Quando usar artifacts vs cache:**
| Cache | Artifacts |
|-------|-----------|
| Dependências | Build outputs |
| Providers/plugins | Test reports |
| Ferramentas CLI | Deploy packages |
| Reutilização entre jobs | Transferência entre workflows |
**Exemplo otimizado:**
```yaml
build:
steps:
- name: Build
run: npm run build
- name: Upload build
uses: actions/upload-artifact@v4
with:
name: dist-${{ github.sha }}
path: dist/
retention-days: 7
if-no-files-found: error
deploy:
needs: build
steps:
- name: Download build
uses: actions/download-artifact@v4
with:
name: dist-${{ github.sha }}
path: dist/
```
#### 4.3 Job Conditionals Inteligentes
**Evite jobs desnecessários:**
```yaml
deploy-docs:
if: |
github.event_name == 'push' &&
github.ref == 'refs/heads/main' &&
contains(github.event.head_commit.message, '[docs]')
```
**Path filters:**
```yaml
on:
push:
paths:
- 'src/**'
- 'package.json'
- '!**/*.md'
```
**Combinação com GitHub CLI:**
```yaml
- name: Check for relevant changes
id: changes
run: |
FILES=$(gh pr view ${{ github.event.pull_request.number }} \
--json files --jq '.files[].path')
if echo "$FILES" | grep -E '^src/'; then
echo "has-src-changes=true" >> $GITHUB_OUTPUT
fi
- name: Run tests
if: steps.changes.outputs.has-src-changes == 'true'
run: npm test
```
### 5. Segurança nas Pipelines
#### 5.1 A Pirâmide de Segurança em IaC
Assim como aplicações (unit → component → E2E), infraestrutura também precisa de validações em camadas:
| Camada | Ferramenta | Foco |
|--------|-----------|------|
| **Compliance** | Checkov | Policies CIS, PCI-DSS, HIPAA |
| **Segurança** | tfsec | Vulnerabilidades e misconfigurations |
| **Estilo** | TFLint | Boas práticas e sintaxe |
**Sincero?** Para um blog talvez não fosse necessário. Mas esse projeto é meu **lab vivo** - é aqui onde testo estratégias e aprendo antes de levar pra produção. Vale a pena pelos ~30s adicionados no deploy.
#### 5.2 Implementação
**TFLint:**
```yaml
- name: Setup TFLint
uses: terraform-linters/setup-tflint@v4
- name: Cache TFLint plugins
uses: actions/cache@v4
with:
path: ~/.tflint.d/plugins
key: ${{ runner.os }}-tflint-${{ hashFiles('infra/.tflint.hcl') }}
- name: Run TFLint
run: tflint --init && tflint -f compact
```
**tfsec:**
```yaml
- name: tfsec scan
uses: aquasecurity/tfsec-action@v1.0.3
with:
working_directory: infra
soft_fail: false
```
**Checkov:**
```yaml
- name: Checkov scan
uses: bridgecrewio/checkov-action@v12
with:
directory: infra
soft_fail: false
```
#### 5.3 Gestão de Secrets
```yaml
jobs:
terraform:
env:
ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
ARM_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
deploy:
steps:
- name: Deploy to Azure Static Web Apps
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
```
### 6. Job Summaries: Visibilidade Pós-Execução
#### 6.1 Job Summary no deploy-app.yml
```yaml
- name: Job summary
if: always()
run: |
{
echo "## 🚀 App Deploy Summary"
echo ""
echo "| Item | Value |"
echo "|------|-------|"
echo "| Event | \`${{ github.event_name }}\` |"
echo "| Branch | \`${{ github.ref_name }}\` |"
echo "| Actor | \`${{ github.actor }}\` |"
echo "| Commit | \`$(git rev-parse --short HEAD)\` |"
echo ""
echo "### 📦 Build Info"
echo ""
echo "| Metric | Value |"
echo "|--------|-------|"
echo "| Output | \`dist/\` |"
echo "| Files | $(find dist -type f | wc -l) |"
echo "| Size | $(du -sh dist | cut -f1) |"
echo ""
echo "### ✅ Deploy Status"
echo ""
echo "Application deployed to **Azure Static Web Apps**"
echo ""
echo "🌐 [View Application](https://www.orafaelferreira.com)"
} >> "$GITHUB_STEP_SUMMARY"
```
**Por que `if: always()`?**
- Roda mesmo se steps anteriores falharem
- Sempre tenho visibilidade do que aconteceu
#### 6.2 Job Summary no infra-apply.yml
```yaml
- name: Job summary
if: always()
run: |
{
echo "## Terraform Apply Summary";
echo "";
echo "| Item | Value |";
echo "|------|-------|";
echo "| Branch | \`${{ github.ref_name }}\` |";
echo "| Actor | \`${{ github.actor }}\` |";
echo "| Backend | \`stostateorafael/statetf/infra.terraform.tfstate\` |";
echo "| Status | ✅ Applied |";
} >> "$GITHUB_STEP_SUMMARY"
```
**Benefício**: em vez de vasculhar logs, você vê um resumo direto na UI do Actions.
### 7. Deploy: Azure Static Web Apps
#### 7.1 Deploy Direto para Produção
O deploy-app.yml faz um **deploy simples e direto** para o Azure Static Web Apps:
```yaml
- name: Deploy to Azure Static Web Apps
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
action: 'upload'
app_location: 'dist'
skip_app_build: true # Já fizemos build antes
```
**Por que skip_app_build: true?**
- O build já foi executado antes (`npm run build`)
- Testes já rodaram (unitários e componentes)
- Apenas fazemos upload do `dist/` pronto
#### 7.2 Fluxo Completo do Deploy
```
1. Install deps (npm install)
↓
2. Unit tests (Vitest)
↓
3. Component tests (React Testing Library)
↓
4. Type check (tsc)
↓
5. Build (Vite)
↓
6. Deploy to Azure SWA
↓
7. Job Summary (métricas)
```
**Tempo total**: ~3-5 minutos dependendo do cache
### 8. Custos
#### 8.1 Custo Zero para Repositórios Públicos
**GitHub Actions pricing:**
- **Public repos**: minutos ilimitados ✅
- Private repos: 2000 min/mês (free), depois $0.008/min
Como o blog é **público**, os custos são **zero**. Mas ainda assim está otimizado.
#### 8.2 Timeouts: Proteção Contra Runs Travados
Todas as pipelines têm **timeout configurado**:
```yaml
## infra-plan.yml
timeout-minutes: 25
## infra-apply.yml
timeout-minutes: 30
## deploy-app.yml
timeout-minutes: 20
```
**Por quê?**
- Evita workflows travados consumindo hardware
- Falha rápida em caso de problemas em loop infinito
### 9. Workflow Dispatch: Triggers Manuais
#### 9.1 Trigger Manual nas 3 Pipelines
Todas as 3 workflows suportam **trigger manual** via `workflow_dispatch`, permitindo execução sob demanda sem precisar fazer commits:
```yaml
on:
workflow_dispatch:
```
**Como usar:**
1. Vá para GitHub Actions
2. Selecione o workflow desejado
3. Clique em "Run workflow"
4. Confirme a execução
Caso queira dar uma olhada em detalhes: [Workflows](https://github.com/orafaelferreiraa/orafaelferreira-com/tree/main/.github/workflows)
### Conclusão
- **Arquitetura**: 3 workflows com responsabilidades segregadas
- **Path filters**: executa apenas quando necessário
- **Concurrency control**: evita race conditions
- **Testes**: pirâmide com unitários + componentes
- **Cache**: dependências npm, providers Terraform e plugins TFLint
- **Segurança**: TFLint + tfsec + Checkov validam código Terraform
- **Documentação**: terraform-docs auto-gera docs no README
- **Deploy**: direto para Azure SWA após validações
- **Job summaries**: métricas claras em cada execução
- **Workflow dispatch**: todas as 3 pipelines podem ser executadas manualmente
Não comecei com tudo isso, fui evoluindo conforme fui aprendendo coisas novas e implementando em um case real.
Faça o mesmo, crie algum projeto pequeno pessoal, quebre, teste, aprenda, evolua!
---
# AKS Spot & Terraform: Economia de Custos e o Guia Crítico de Taints
URL: https://www.orafaelferreira.com/artigos/aks-spot-terraform-economia-custos-taints
Publicado: 2025-12-30
Categoria: Artigos
Tempo de leitura: 8 min de leitura
> Como economizar até 90% no AKS com Spot Node Pools via Terraform: taints, tolerations e configurações críticas para evitar interrupções inesperadas.
## AKS Spot & Terraform: Economia de Custos e o Guia Crítico de Taints
No ecossistema de nuvem, a eficiência financeira é tão importante quanto a eficiência técnica. [O uso de Azure Spot Node Pools no AKS permite economizar até 90% em comparação com instâncias regulares](https://azure.microsoft.com/pt-br/products/virtual-machines/spot/). Contudo, essa economia exige uma configuração rigorosa de Taints para evitar que sua aplicação sofra interrupções inesperadas.
### 1. O que são Spot Node Pools?
[Instâncias Spot](https://learn.microsoft.com/azure/virtual-machines/spot-vms) utilizam a capacidade ociosa do Azure. Quando o Azure precisa dessa capacidade de volta, ele interrompe as instâncias com um aviso prévio de apenas 30 segundos.
#### Características Principais
- **Efemeridade**: Os nós podem ser removidos a qualquer momento.
- **Custo**: Drasticamente reduzido.
- **Casos de Uso**: Processamento em lote, ambientes de teste, CI/CD, cargas de trabalho stateless resilientes, ambientes de desenvolvimento.
- **Limitação**: Não podem ser o pool de sistema (System Node Pool) padrão do cluster.
> **Documentação Oficial**: Para mais detalhes sobre a implementação de [Spot Node Pools no AKS](https://learn.microsoft.com/pt-br/azure/aks/spot-node-pool), consulte a documentação completa da Microsoft.
### 2. O Conceito Vital: Taints e Tolerations
Um **[Taint](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)** é um atributo aplicado a um nó que "repele" pods. Para que um pod seja agendado em um nó com Taint, ele deve possuir uma **Toleration** (tolerância) correspondente.
No contexto de instâncias Spot, o Taint é a sua principal ferramenta de segurança para garantir que apenas pods preparados para interrupções sejam alocados nesses nós.
#### Efeitos de Taint no AKS
| Efeito | Descrição |
|--------|-----------|
| **NoSchedule** | O Kubernetes não agendará novos pods no nó se eles não tiverem a tolerância. |
| **NoExecute** | Além de não agendar novos, remove pods existentes que não toleram o nó. |
| **PreferNoSchedule** | O sistema tenta evitar o agendamento, mas pode colocar o pod lá se não houver alternativa. |
### 3. Implementação com Terraform
Para criar um pool de nós Spot com as proteções adequadas, utilizamos o recurso [azurerm_kubernetes_cluster_node_pool](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster_node_pool). O exemplo abaixo demonstra a configuração ideal:
```terraform
resource "azurerm_kubernetes_cluster_node_pool" "spot" {
name = "spotpool01"
kubernetes_cluster_id = azurerm_kubernetes_cluster.main.id
vm_size = "Standard_DS2_v2"
# Ativação do modo Spot
priority = "Spot"
eviction_policy = "Delete" # Deleta a VM após o despejo
spot_max_price = -1 # Paga até o preço de uma instância regular
# Configuração do Taint (Crítico!)
node_taints = [
"kubernetes.azure.com/scalesetpriority=spot:NoSchedule"
]
# Labels para seleção de nós via Affinity
node_labels = {
"kubernetes.azure.com/scalesetpriority" = "spot"
"node-type" = "preemptible"
}
# Autoscaling é altamente recomendado para Spot
enable_auto_scaling = true
min_count = 1
max_count = 5
}
```
**⚠️ Atenção no Taint**: O AKS aplica por padrão o label `kubernetes.azure.com/scalesetpriority=spot`. Ao definir `node_taints` manualmente no Terraform, certifique-se de que ele reflete a estratégia de isolamento da sua carga de trabalho.
**Referência Terraform**: Para configurações adicionais do cluster AKS, consulte a documentação do recurso [azurerm_kubernetes_cluster](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster).
### 4. Taints de Inicialização (Node Initialization Taints)
Uma funcionalidade avançada mencionada na [documentação oficial do AKS](https://learn.microsoft.com/azure/aks/use-node-taints) é o **Node Initialization Taint**. Eles são usados para marcar nós no momento da inicialização, garantindo que o tráfego só chegue ao nó após a execução de scripts de configuração ou instalação de agentes de segurança (como o Prisma Cloud ou Cilium).
- **Uso**: Temporário, durante o boot do nó.
- **Terraform**: Pode ser configurado para garantir que o nó esteja "pronto" antes de receber qualquer carga.
### 5. Agendando Pods no Pool Spot
Para que sua aplicação utilize os nós criados, você deve configurar o manifesto do Kubernetes com a Toleration correta. Caso contrário, o scheduler ignorará o pool Spot e sua aplicação não rodará (ou rodará no pool regular mais caro).
#### Exemplo de Manifesto (YAML)
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-batch-process
spec:
template:
spec:
containers:
- name: worker
image: my-repo/worker:latest
# 1. Permite entrar no nó Spot
tolerations:
- key: "kubernetes.azure.com/scalesetpriority"
operator: "Equal"
value: "spot"
effect: "NoSchedule"
# 2. Força a preferência pelo nó Spot
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "kubernetes.azure.com/scalesetpriority"
operator: In
values:
- "spot"
```
### 6. Checklist de Atenção
Ao utilizar Terraform para gerenciar AKS Spot, observe estes pontos críticos:
- **Eviction Policy**: Use `Delete` para evitar custos de disco orfãos e problemas de cota de vCPU no Azure.
- **[Cluster Autoscaler](https://learn.microsoft.com/azure/aks/cluster-autoscaler)**: Sem ele, se todos os nós Spot forem removidos, o pool pode ficar com 0 nós permanentemente até uma intervenção manual.
- **Upgrade**: Pools Spot não suportam surge upgrade da mesma forma que pools regulares. O nó é simplesmente substituído.
- **SLA**: Lembre-se que instâncias Spot não possuem SLA de disponibilidade.
### 7. FinOps: A Importância da Gestão Financeira em Nuvem
Quando falamos de otimização de custos no Azure, especialmente em ambientes enterprise e de larga escala, **FinOps** (Financial Operations) se torna algo vital. Em infraestruturas complexas, os custos podem escalar rapidamente, tornando essencial uma abordagem estruturada para monitoramento, análise e otimização contínua de gastos.
FinOps não é apenas sobre reduzir custos, mas sim sobre maximizar o valor do investimento em nuvem. Isso envolve:
- **Visibilidade de Custos**: Entender onde e como os recursos estão sendo consumidos
- **Otimização Contínua**: Identificar oportunidades de economia, como o uso de Spot Instances
- **Cultura de Responsabilidade**: Engajar equipes de engenharia, operações e finanças na gestão de custos
- **Decisões Baseadas em Dados**: Usar métricas para tomar decisões informadas sobre arquitetura e recursos
A utilização de Spot Node Pools, como demonstrado neste artigo, é um exemplo prático de como FinOps pode gerar economias significativas (até 90%) sem comprometer a qualidade das aplicações resilientes.
**Aprofunde-se em FinOps**: Para entender melhor como construir uma base sólida em Cloud Native, incluindo práticas de FinOps, DevOps e Sustentabilidade, confira o artigo completo: [Antes do Cloud Native: Construindo uma Fundação Sólida para a Nuvem](https://www.orafaelferreira.com/artigos/antes-cloud-native-fundacao-solida)
### Conclusão
O uso de AKS Spot via Terraform é uma estratégia brilhante para reduzir a fatura do Azure, mas exige um entendimento profundo do agendador do Kubernetes. Os Taints são sua barreira de proteção: eles garantem que sua aplicação crítica não seja agendada por engano em um nó que pode desaparecer em 30 segundos.
---
# DevOpsDays Florianópolis 2025
URL: https://www.orafaelferreira.com/artigos/devopsdays-florianopolis-2025
Publicado: 2025-12-28
Categoria: Organização de Eventos
Tempo de leitura: 3 min de leitura
> DevOpsDays Floripa 2025: um dia que já ficou marcado por talks, café quentinho, salgadinhos disputados e muita gente boa conectada pela cultura DevOps.
Em **6 de dezembro de 2025**, o auditório do **Centro Universitário Cesusc (UNICESUSC)** virou ponto de encontro da comunidade DevOps para um dia inteiro de talks, open-spaces e reencontros.
📍 **Local**: SC-401, 9301 - Santo Antonio de Lisboa, Florianópolis - SC, 88050-001
🌐 **Site oficial**: [DevOpsDays Florianópolis 2025](https://devopsdays.org/events/2025-florianopolis/welcome/)
📲 **Linktree**: [Redes e novidades](https://linktr.ee/devopsdaysfln)
### O dia em ordem cronológica
- 08:00 - 09:00 — Credenciamento
- 09:00 - 09:30 — Abertura oficial.
- 09:30 - 10:05 — Eduardo Munari Crossplane: Habilitando Engenharia de Plataforma na sua Infraestrutura.
- 10:05 - 10:45 — Coffee break. Sim, eu estava lá disputando os salgadinhos. 😋 
- 10:45 - 11:20 — Alison Duarte — Construindo uma Plataforma Self-Service: Criação de Projetos utilizando um Catálogo de Serviços.
- 11:20 - 11:55 — Jonatas (jojo) Baldin — Escrevendo seu Primeiro Operador de Kubernetes.
- 11:55 - 12:30 — Ruan Oliveira — Banalizamos a migração entre clouds com Kubernetes.
- 12:30 - 13:40 — Almoço para recarregar as energias.
- 13:40 - 13:55 — Retorno
- 13:55 - 14:30 — Rafael Mateus — Backstage na Prática: É Hora de Subir uma Plataforma de DEx na sua Firma.
- 14:30 - 15:05 — Camila Maia — Keynote — O Hack das Oportunidades.
- 15:05 - 15:40 — Lightning Talks
- 15:40 - 16:15 — Coffee break parte 2
- 16:15 - 16:50 — Luis Pontes — Lambda Pinball: Simplificando a Orquestração Serverless.
- 16:50 - 17:25 — Dri Cardoso, João Brito — Cérebro e Código: saúde mental e performance cognitiva na tecnologia.
- 17:25 - 18:00 — Sorteios 
### Patrocinadores
- **Platinum**: grafana, Elastic
- **Gold**: Software.com.br
- **Community**: UNICESUSC
### Organização local
Lanusse Morais • Rafael Ferreira • Patrick Machado • Gislaine Luciane • Julio Fontes • Stefani Dal Puppo • Leandro Venâncio • Henrique Pereira Zimermann
### Código de conduta
Nosso evento segue o [Código de Conduta do DevOpsDays](https://devopsdays.org/events/2025-florianopolis/conduct/). Ajude a manter um ambiente seguro e acolhedor para todos.
Nos vemos na próxima edição do **DevOpsDays Floripa**! 🚀
---
# Como foi minha jornada para a certificação CKA
URL: https://www.orafaelferreira.com/artigos/jornada-certificacao-cka
Publicado: 2025-12-27
Categoria: Artigos
Tempo de leitura: 9 min de leitura
> Três meses de estudo focado, labs diários na KodeKloud, simulados e checklists que usei para conquistar a certificação CKA.
## Como foi minha jornada para a certificação CKA
Há 3 meses decidi tirar a certificação **[CKA (Certified Kubernetes Administrator)](https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/)**. Para acelerar os estudos, segui a trilha da **KodeKloud**, que é referência absoluta no mercado.
Minha base já contava com o conhecimento dos cursos do **[DevOpsPro](https://curso.devopspro.com.br/devops-pro/)** e da **[LinuxTips](https://linuxtips.io/)**, além da experiência prática que tenho no trabalho. No entanto, para a prova, eu precisava de velocidade e precisão.
Utilizei exaustivamente o curso **[Ultimate Certified Kubernetes Administrator (CKA) Mock Exam Series](https://learn.kodekloud.com/user/courses/ultimate-certified-kubernetes-administrator-cka-mock-exam-series)**. Os exercícios reproduzem a pressão do exame real e me ajudaram a automatizar a resolução de problemas complexos em cenários de cluster real. Documentei abaixo o que funcionou para chegar pronto no dia da prova.
#### Certificados dos Cursos de Preparação
**[Curso Certified Kubernetes Administrator (KodeKloud)](https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/?couponCode=PMNVD2025)**
**[Udemy Labs - Certified Kubernetes Administrator with Practice Tests](https://learn.kodekloud.com/user/courses/udemy-labs-certified-kubernetes-administrator-with-practice-tests)**
**[Curso Ultimate CKA Mock Exam Series (KodeKloud)](https://learn.kodekloud.com/user/courses/ultimate-certified-kubernetes-administrator-cka-mock-exam-series)**
#### 🏆 Resultado da Prova CKA
> **Exam Results**
> - **Status:** Pass ✅
> - **Your Score:** 75%
> - **Score Needed:** 66%
#### 🎖️ Certificação Oficial
**Certified Kubernetes Administrator (Linux Foundation)**
## Topicos Abordados na Prova CKA 2025
### 1. Arquitetura do Cluster e Conceitos Core
A base de tudo é entender a separação entre o **Control Plane** e os **Worker Nodes**.
* **ETCD:** O banco de dados chave-valor que armazena todo o estado do cluster. Backup e restauração aqui são críticos.
* **Kube-API Server:** O único componente que fala com o ETCD. Tudo passa por ele.
* **Kube-Scheduler:** Decide em qual nó o seu Pod vai morar, baseando-se em recursos disponíveis.
* **Kubelet:** O agente que roda nos nós e garante que os containers estejam rodando conforme o esperado.
* **Kube-Proxy:** Gerencia as regras de rede (IPtables/IPVS) para permitir a comunicação.
### 2. Gerenciamento do Ciclo de Vida da Aplicação
Administrar aplicações envolve estratégias de atualização e resiliência:
* **Deployments:** Permitem atualizações automáticas (*Rolling Updates*) e reversões (*Rollbacks*).
* **ConfigMaps e Secrets:** Separam a configuração e dados sensíveis do código da imagem.
* **Escalonamento:** O uso de **HPA (Horizontal Pod Autoscaler)** e **VPA (Vertical Pod Autoscaler)** para ajustar a infraestrutura à demanda.
### 3. Agendamento e Escalabilidade Avançada
Não basta rodar o Pod; é preciso saber *onde* ele deve rodar:
* **Taints and Tolerations:** Impedem que Pods sejam colocados em nós específicos, a menos que tenham uma permissão explícita.
* **Node Affinity:** Atrai Pods para nós específicos.
* **Resource Quotas & Limits:** Essenciais para evitar que um único Pod utilize todos os recursos do nó.
### 4. Rede e Conectividade
A parte MAIS desafiadora do exame.
* **Serviços:** ClusterIP (interno), NodePort (exposição básica) e LoadBalancer (integração com nuvem).
* **Ingress vs. Gateway API:** Enquanto o Ingress é o padrão clássico, a **Gateway API** (foco nas atualizações de 2025) oferece um modelo mais expressivo.
* **Network Policies:** O firewall interno do K8s, fundamental para segurança *Zero Trust*.
### 5. Armazenamento (Storage)
A persistência de dados em um ambiente efêmero:
* **PV (Persistent Volume):** O recurso de armazenamento real no cluster.
* **PVC (Persistent Volume Claim):** O "ticket" ou pedido de um usuário por armazenamento.
* **Storage Classes:** Permitem o provisionamento automático e dinâmico de discos.
### 6. Segurança e Manutenção
Garantir a integridade e a atualização do cluster:
* **RBAC (Role-Based Access Control):** Definir **QUEM** pode fazer **O QUÊ** e em **QUAL** Namespace.
* **TLS Certificates:** O Kubernetes usa certificados para todas as comunicações. Saber expirar, renovar e aprovar CSRs é vital.
* **Upgrade do Cluster:** O processo de usar o `kubeadm` para atualizar o Control Plane e os Nodes de forma segura.
### 7. Resolução de Problemas (Troubleshooting)
No exame CKA, você passará a maior parte do tempo consertando coisas quebradas.
* **Logs e Describe:** `kubectl logs` e `kubectl describe` são seus melhores amigos.
* **Componentes de Sistema:** Se o cluster cair, verifique o status do serviço no SO com `journalctl -u kubelet`.
#### Dica de ouro
Pratique exaustivamente os **Imperative Commands** (`kubectl run`, `kubectl create`) para ganhar tempo e evitar erros de sintaxe em arquivos YAML.
### Considerações sobre a Prova
A prova CKA 2025 é 100% prática e exige velocidade e precisão. Você terá **2 horas** para resolver entre **15 e 20 questões** em ambientes reais de cluster Kubernetes. Não existe múltipla escolha, apenas você, o terminal e a documentação oficial.
#### Questões que Caíram
Durante a prova, encontrei questões que abordavam os seguintes tópicos:
**1. Instalação e Configuração de CNI**
- Instalar o **Calico v3.28.2** via tigera-operator
- Configurar CRDs e verificar NetworkPolicies funcionais
**2. Gestão de Armazenamento**
- Criar **PersistentVolumeClaims** e recuperar dados de volumes existentes
- Configurar **StorageClass** com `volumeBindingMode: WaitForFirstConsumer`
- Definir StorageClass padrão do cluster
**3. Troubleshooting de Cluster**
- Corrigir configurações de **kube-apiserver** após migração (etcd endpoints incorretos)
- Identificar componentes quebrados e reiniciar serviços
- Ajustar certificados e paths de arquivos após mudança de máquina
**4. Configuração de Recursos**
- Calcular e aplicar **resource requests** para Pods (dividindo recursos do nó igualmente)
- Configurar sidecard e containers com os mesmos valores de request
**5. Helm e Gerenciamento de Aplicações**
- Instalar **Argo CD** via Helm (versão 7.7.3) sem reinstalar CRDs
- Gerar templates Helm e salvar manifestos
- Usar `--set crds.install=false` para evitar conflitos
**6. Ingress e Gateway API**
- Criar recursos Ingress com TLS
- Migrar de Ingress para **Gateway API** (novidade 2025)
- Configurar HTTPRoute e Gateway com hostname específico
**7. Horizontal Pod Autoscaler (HPA)**
- Criar HPA com target de 50% CPU
- Configurar `downscaleStabilizationWindow` para 30 segundos
- Instalar e configurar metrics-server quando necessário
**8. Sidecar Containers**
- Adicionar container sidecar para streaming de logs
- Usar volumes compartilhados (`emptyDir`)
- Comando: `tail -n+1 -f /var/log/app.log`
**9. Services e Exposição**
- Reconfigurar Deployment para expor porta 80/tcp
- Criar Service tipo **NodePort** usando comandos imperativos
- Entender a diferença entre containerPort e Service port
**10. PriorityClass e Preemption**
- Criar PriorityClass com valor específico
- Fazer patch em Deployment existente para usar a nova priority
- Observar eviction de Pods de menor prioridade
**11. ConfigMaps e TLS**
- Atualizar ConfigMap para permitir **TLSv1.2** e **TLSv1.3** em NGINX
- Recriar Pods para aplicar mudanças de configuração
- Testar com `curl --tls-max 1.2` (deve falhar)
**12. Custom Resource Definitions (CRDs)**
- Listar CRDs do cert-manager
- Extrair documentação com `kubectl explain` (ex: `certificate.spec.subject`)
- Salvar outputs em arquivos específicos
**13. Preparação de Sistema (Container Runtime)**
- Instalar e configurar **cri-dockerd** via dpkg
- Configurar parâmetros sysctl para Kubernetes
- Habilitar e startar serviços do systemd
**14. Services com Cálculos de Recursos**
- Expor Deployment via NodePort
- Considerar overhead de 10% e limites adequados
#### Distribuição de Pontos
As questões não valem o mesmo. Questões de troubleshooting e setup completo tendem a valer mais (8-12% cada), enquanto tarefas simples como criar um Service valem menos (2-4%). Por isso, é estratégico focar primeiro nas questões que você domina completamente.
### Recursos Recomendados para Preparação
Além do curso da KodeKloud, aqui estão alguns recursos que podem acelerar significativamente sua preparação:
#### Repositórios no GitHub
- **[CKA-PREP-2025-v2](https://github.com/vj2201/CKA-PREP-2025-v2)**
- **[CKA2025](https://github.com/gkeskar/CKA2025)**
Esses repositórios contêm questões similares às que caem na prova e são excelentes para praticar cenários hands-on.
#### Playlists no YouTube
- **[Playlist 1 — Kubernetes CKA Full Course](https://www.youtube.com/watch?v=kDZEiXHpEks&list=PLSsEvm2nF_8nGkhMyD1sq-DqjwQq8fAii)**
- **[Playlist 2 — CKA Crash Course](https://www.youtube.com/watch?v=-6QTAhprvTo&list=PLkDZsCgo3Isr4NB5cmyqG7OZwYEx5XOjM)**
- **[Playlist 3 — Kubernetes Administrator Series](https://www.youtube.com/watch?v=WFTVTi8JhKc&list=PLvZb3tGyqC1TOasSaN36haM5xlCxHQBlA)**
Assista às playlists enquanto pratica os labs. A combinação de teoria + prática é fundamental para fixar os conceitos.
### Conclusão
A combinação de prática diária, simulados fez toda a diferença. Se você está começando agora, foque em repetir os labs até que os comandos se tornem automáticos.
---
# A Stack por trás do meu Blog: IaC com Terraform, Static Web Apps e Github Actions
URL: https://www.orafaelferreira.com/artigos/artigo-terraform-infra-cicd
Publicado: 2025-12-13
Categoria: Artigos
Tempo de leitura: 13 min de leitura
> Como migrei meu blog para Terraform e GitHub Actions: state remoto em Azure Storage, Static Web Apps, domínio customizado e um pipeline confiável até produção.
## Visão Geral
Algumas semanas atrás eu decidi migrar meu blog para uma versão mais moderna, simples de operar e fácil de evoluir. O plano:
Terraform para declarar infraestrutura, GitHub Actions para orquestrar e Azure Static Web Apps para hospedar. Neste artigo, irei contar um pouco dessa jornada:
Vamos passar por tudo o que sustenta o blog hoje:
- Organização dos arquivos Terraform (providers, backend, variáveis e recursos)
- Estratégia de state remoto em Azure Storage
- Provisionamento do SWA e domínio customizado
- Padrões de execução local com Service Principal
- Pipelines CI/CD no GitHub Actions para "plan" (PRs) e "apply" (push em main)
- Segurança, lint e scans: TFLint, tfsec, Checkov (era preciso tudo isso? claro que não! meu site se tornou meu projeto pessoal de estudos)
- Automatização de documentação com terraform-docs
- Integração com o deploy do app (build + upload da pasta "dist")
Ao final, você terá uma visão ponta a ponta do que acontece desde um "git push" até o site atualizado em produção.
### Estrutura Terraform
Dentro da pasta `infra/` temos os principais arquivos que definem a infraestrutura:
- `providers.tf`: versão do Terraform, provider `azurerm` e suas capabilities.
- `backend.tf`: configuração do backend remoto do state no Azure Storage.
- `variables.tf`: variáveis para vincular o repositório ao SWA (URL, branch e token).
- `main.tf`: recursos da solução (Static Web App + domínio customizado) e o resource group consumido como data source.
#### providers.tf
O arquivo fixa as versões para garantir reprodutibilidade e compatibilidade:
```terraform
terraform {
required_version = "1.13.4"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "4.50.0"
}
}
}
provider "azurerm" {
features {}
}
```
- **Terraform**: versão 1.13.4, versão mais atual de quando fiz o projeto
- **Provider azurerm**: versão 4.50.0, versão mais atual de quando fiz o projeto
#### backend.tf
Quando migrei, uma das primeiras decisões foi nunca manter state local.
```terraform
terraform {
backend "azurerm" {
resource_group_name = "rg-site"
storage_account_name = "stostateorafael"
container_name = "statetf"
key = "infra.terraform.tfstate"
use_azuread_auth = true
}
}
```
- **RG/Storage/Container**: isolam o state em um bucket dedicado.
#### variables.tf
Variáveis me ajudaram a controlar comportamentos por ambiente: no apply em main, os valores reais chegam via secrets. Isso mantém o fluxo seguro com segurança.
```terraform
variable "repository_url" {
description = "GitHub repository URL para SWA (vazio em PR)"
type = string
default = ""
}
variable "repository_branch" {
description = "Branch do repositório para SWA (vazio em PR)"
type = string
default = ""
}
variable "repository_token" {
description = "GitHub PAT para linkage CI (omitido em PR)"
type = string
sensitive = true
default = ""
}
```
- Em apply, os valores reais chegam via secrets do GitHub Actions.
#### main.tf
Aqui fica a cereja do bolo: o Azure Static Web Apps na camada gratuita com domínio customizado. Eu queria um hosting estável, com HTTPS automático e integração perfeita com GitHub. O SWA entrega isso sem dor de cabeça.
```terraform
## Recurso de RG existente (fora do TF)
data "azurerm_resource_group" "rg" {
name = "rg-site"
}
## Static Web Apps (SWA)
resource "azurerm_static_web_app" "this" {
name = "swa-site-orafael"
resource_group_name = data.azurerm_resource_group.rg.name
location = "eastus2"
sku_tier = "Free"
sku_size = "Free"
repository_url = var.repository_url
repository_branch = var.repository_branch
repository_token = var.repository_token
}
## Domínio customizado (validação DNS via TXT)
resource "azurerm_static_web_app_custom_domain" "txt-value" {
static_web_app_id = azurerm_static_web_app.this.id
domain_name = "www.orafaelferreira.com"
validation_type = "dns-txt-token"
}
```
- O RG é um **data source** (mantido fora do Terraform), já que é onde fica o storage account para manter o state remoto.
- O SWA tem linkage com este repositório, então o deploy do blog é natural ao meu fluxo de commits.
- O domínio **www.orafaelferreira.com** usa validação por DNS TXT; depois da propagação, o Azure cuida dos certificados.
### Service Principal
Para validação das pipelines podem fazer o deploy na cloud, estou utilizando Service Principal (SP).
Exemplo de export das credenciais (Linux) e execução:
```bash
export ARM_CLIENT_ID=
export ARM_CLIENT_SECRET=
export ARM_TENANT_ID=
export ARM_SUBSCRIPTION_ID=
export SWA_REPOSITORY_TOKEN=
cd infra
terraform init
terraform plan
terraform apply -auto-approve -var "repository_url=https://github.com//" -var "repository_branch=main" -var "repository_token=${SWA_REPOSITORY_TOKEN}"
cd -
```
> Em ambientes Windows PowerShell, adapte com `$Env:VAR=valor`.
### Pipelines CI/CD no GitHub Actions
Se a infraestrutura é o esqueleto, os pipelines que bota pra rodar. Cada commit tem revisão, aplicação e publicação.
A automação está dividida em três workflows principais.
#### 1) `infra-plan.yml` (PRs)
Dispara em pull requests que alteram `infra/**` ou o próprio workflow. Objetivo: validações e geração do **plan**.
Passos:
- `actions/checkout@v4`
- `hashicorp/setup-terraform@v3` (Terraform 1.13.4)
- Cache dos providers Terraform e plugins do TFLint
- `terraform init`
- `terraform fmt -check -recursive` (não quebra o build em PR)
- `terraform validate`
- `tflint --init && tflint -f compact`
- `tfsec` e `Checkov` com `soft_fail: false` (quebram em achados críticos)
- `terraform plan -out=tfplan` com variáveis placeholder
- Upload do artifact `tfplan`
- Comentário no PR com o **plan** já expandido (sem tabela de status). Eu quis reduzir cliques e atrito: abrir o PR e já ver o que muda.
#### 2) `infra-apply.yml` (push em main)
Dispara em push que altera `infra/**` ou o próprio workflow, e também pode ser manual via `workflow_dispatch`.
Passos de segurança e qualidade:
- `terraform init`, `fmt`, `validate`, `tflint`, `tfsec`, `Checkov` (mesma base do plan)
- `terraform apply -auto-approve` com `repository_url`, `repository_branch`, `repository_token` vindos de secrets
- **terraform-docs**: injeta documentação do módulo no `README.md` e commita automaticamente (quando houver alteração)
- **Job Summary**: resumo simples (branch/actor/backend/status), sem seção de outputs para evitar ruído quando não definidos. Na migração eu removi a seção de outputs do summary para evitar alertas desnecessários.
#### 3) `deploy-app.yml` (build + upload da SPA)
Dispara em push de arquivos do app, manual (`workflow_dispatch`) e após conclusão bem-sucedida do `infra-apply` via `workflow_run`.
Pipeline do app:
- Node 20 + cache npm
- `npm install`
- Testes: unitário (Vitest), componentes (RTL) e E2E smoke (Playwright)
- `npm run typecheck` e `npm run build`
- Cache de browsers do Playwright (otimiza tempo e custo)
- Deploy com `Azure/static-web-apps-deploy@v1` usando `action: upload` e `skip_app_build: true` (fazemos o build antes). Essa foi uma escolha de performance e previsibilidade no build.
Proteção contra loops:
- Condição no job: `(github.event_name == 'push' && github.actor != 'github-actions[bot]')`…
- Isso evita que commits automatizados (ex.: terraform-docs) disparem deploys do app desnecessariamente — um ajuste que nasceu de um incidente: o bot fazia commit e o app queria redeploy sem mudanças reais.
### Segurança e Qualidade
- **TFLint**: enforce de boas práticas e estilo nos `.tf`.
- **tfsec**: análise de segurança estática específica para Terraform (Azure incluído).
- **Checkov**: políticas de segurança e conformidade (CSPM) adicionais.
- **actions/cache@v4**: acelera builds mantendo providers e plugins.
- **Sem outputs no summary**: evita confusão quando não há `output` definido no módulo.
> Observação: caso sejam necessários outputs (ex.: hostname, IDs), basta adicionar blocos `output` em `infra/` e consumir no resumo/pipelines. Por ora, optei por manter o módulo minimalista.
### Documentação Automatizada
Durante a migração, quis que a documentação acompanhasse o código sem esforço humano. O `infra-apply.yml` roda **terraform-docs** e injeta a referência do módulo no `README.md`. Se não houver mudanças, nenhum commit é feito — é documentação viva, sem burocracia.
### Fluxo de Trabalho: do PR ao Deploy
1. **PR em `infra/**`** → roda `infra-plan.yml`: valida, escaneia segurança e gera o `plan`.
2. **Merge em `main`** → roda `infra-apply.yml`: aplica mudanças, atualiza docs.
3. **Push do app** (ou workflow_run de infra) → roda `deploy-app.yml`: builda e publica a pasta `dist/` no SWA. Esse foi o momento mais satisfatório da migração: ver o blog ir ao ar segundos depois do merge.
Tudo isso com proteção contra loops de commits do bot e com caches para acelerar o ciclo.
Caso queira dar uma olhada em detalhes: [Workflows](https://github.com/orafaelferreiraa/orafaelferreira-com/tree/main/.github/workflows)
### Conclusão
A combinação de Terraform + GitHub Actions entrega uma infraestrutura escalável, auditável e automatizada.
Com state remoto seguro, validações de segurança e documentação contínua, o resultado é um pipeline confiável que leva alterações de infraestrutura e aplicação ao Azure de forma robusta.
---
# Segurança em Camadas e Open Source no DevOpsDays POA 2025
URL: https://www.orafaelferreira.com/artigos/devopsdays-poa-2025
Publicado: 2025-12-02
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> Como foi palestrar no DevOpsDays Porto Alegre 2025 sobre Defesa em Profundidade e ferramentas Open Source para proteger ambientes Cloud Native.
## DevOpsDays Porto Alegre 2025
No dia **29 de novembro de 2025**, estive presente no [**DevOpsDays Porto Alegre**](https://devopsdays.org/events/2025-porto-alegre/welcome/), O DevOpsDays é conhecido mundialmente para quem ama infraestrutura ágil, e a edição de POA manteve a tradição: conteúdo de altíssimo nível.
### Minha palestra
#### Como aplicar Segurança em Camadas na sua arquitetura Cloud Native com Open Source
Fui aceito para apresentar a palestra **"Como aplicar Segurança em Camadas na sua arquitetura Cloud Native com Open Source"**.
Durante a sessão, explorei a estratégia de **Defesa em Profundidade (Defense in Depth)**, saindo da teoria para a prática com ferramentas do ecossistema CNCF. A defesa deve ser contínua e integrada em cada camada.
### Destaques do Evento
A programação técnica foi excelente, especialmente a parte da tarde! Após minha apresentação, tive a oportunidade de acompanhar grandes colegas da comunidade que trouxeram temas extremamente relevantes para o nosso dia a dia:
- **João Brito** com a palestra *As quatro dimensões de segurança em Kubernetes*, um excelente complemento ao meu tema.
- **Daniel Rodrigues** falando sobre *Chaos Mesh: Engenharia do caos para Kubernetes*, explorando como injetar falhas de forma controlada.
- **Vinicius Campitelli** sobre *Criando esteiras de CI/CD performáticas e seguras*, um tema vital para a cultura DevOps.
- **Cristiano Diedrich** abordando o *DevFinOps - Além das tags*, mostrando a evolução da mentalidade de custos e eficiência.
- O tradicional **Coffee Break**, um momento perfeito para recarregar as energias e fazer um networking de qualidade.
É massa demais ver tanta gente nova interessada em aprender e tantos profissionais experientes dispostos a compartilhar.
> **Segurança TEM que começar na fundação.**
> Não existe "bala de prata", existe defesa em camadas.
- **Slides da Apresentação:** [Defesa em Camadas com Open Source](https://stoblobcertificados011.blob.core.windows.net/palestras/DefesaemCamadasOS.pdf)
---
# Trabalhar para o Exterior – Realidade, Desafios e Oportunidades no IFSC
URL: https://www.orafaelferreira.com/artigos/trabalhar-para-o-exterior-ifsc-2025
Publicado: 2025-11-18
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> Na Semana Acadêmica de ADS do IFSC, eu e Vinícius Deschamps falamos sobre a realidade de trabalhar para o exterior: desafios, oportunidades e histórias reais.
## Trabalhar para o Exterior: Realidade, Desafios e Oportunidades
Durante a ([**1ª Semana Acadêmica de ADS do IFSC**](https://saads.framer.website/)), eu e o meu parceiro [Vinícius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/) tivemos a honra de fechar a noite do dia 06/11 com uma conversa que muita gente sempre quis ouvir, mas poucos realmente contam: **como é trabalhar para o exterior na vida real**.
Nada de glamour de LinkedIn, nada de “ficar rico em 3 passos”, nada de frase de efeito.
Foi papo reto, experiência de campo e aquelas histórias que normalmente ficam só no café da firma.
O evento aconteceu no **IFSC São José**, reunindo estudantes, profissionais e curiosos querendo entender como funciona a vida tech além das fronteiras brasileiras. E, sinceramente, foi incrível ver tanta gente interessada em construir uma carreira internacional com planejamento e consciência.
### Sobre a Palestra
**Tema:** Trabalhar para o Exterior – Realidade, Desafios e Oportunidades
**Palestrantes:** [Rafael Ferreira](https://www.linkedin.com/in/orafaelferreiraa/) & [Vinícius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)
**Data:** 06/11 às 21h10
**Evento:** 1ª Semana Acadêmica de ADS – IFSC
**Local:** São José – SC
### O que a gente trouxe pra galera
A gente sabe que o assunto “trabalhar pra fora” virou moda, mas também virou uma terra de muita promessa vazia. Então fizemos o oposto.
Falamos sobre:
- O que realmente muda quando você trabalha com times internacionais
- Como lidar com cultura, comunicação e expectativas totalmente diferentes
- Realidades do fuso, das reuniões e do inglês de verdade (não aquele decorado em curso)
- O impacto na vida pessoal — rotina, saúde, relacionamentos e até grana
- Estratégias que realmente funcionam pra conquistar oportunidades lá fora
- E claro… os perrengues. Porque sempre tem perrengue.
A ideia não foi mostrar um “mundo perfeito”.
A ideia foi preparar a galera para o que é **de fato**.
### Por que esse assunto importa??
Porque a comunidade técnica precisa falar sobre carreira e escolhas reais.
Trabalhar para o exterior pode abrir portas absurdas, mas também exige maturidade, adaptação e clareza sobre o que você quer da sua vida.
Achar que trabalhar pra fora é só “ganhar em dólar e ser feliz” é receita pra frustração.
Mas entender como se preparar, como se posicionar e como navegar esses ambientes… aí sim muda o jogo.
E se a nossa conversa ajudou pelo menos uma pessoa a tomar uma decisão mais consciente, já valeu o rolê.
### Alguns momentos da noite
Aqui você pode inserir as fotos do evento:
### 🧾 Links de Indicação Úteis pra Quem Quer Trabalhar pra Fora
Se você está **começando sua jornada internacional**, aqui vão dois serviços que **uso pessoalmente** e recomendo:
#### 💼 Abrir ou manter seu CNPJ com a **Contabilizei**
Simplifique sua vida como PJ, sem dor de cabeça com impostos e obrigações contábeis:
👉 [Abra sua conta na Contabilizei com meu link de indicação](https://www.contabilizei.com.br/programa-de-indicacao?ref=daf792a9759933c6a3f54a8832357168&nome=RAFAEL&email=rafael_low@hotmail.com&utm_source=plataforma&utm_campaign=MGM&utm_source=plataforma)
#### 💸 Receber em dólar com ótimas taxas usando a **TechFX**
Pra quem recebe moeda de fora (dólar, euro, libra...) direto na conta PJ, TechFX ajuda a economizar nas taxas e ganhar agilidade:
👉 [Crie sua conta TechFX com meu link e comece a receber melhor](https://www.techfx.com.br/rafa-ferreira/)
### Gratidão pelo convite
Fica meu agradecimento ao IFSC, ao pessoal da organização da Semana Acadêmica e a todo mundo que ficou até o final da noite com a gente.
A troca foi forte e verdadeira.
E que venham mais conversas que vão além do código.
- **Slides da Apresentação:** [GreenOps e Cloud Sustentável no MVP Conf 2025](https://stoblobcertificados011.blob.core.windows.net/palestras/CarreiraGlobal%20emDevOps.pdf)
---
# GreenOps e Cloud Sustentável no MVP Conf 2025
URL: https://www.orafaelferreira.com/artigos/mvp-conf-sp
Publicado: 2025-11-10
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> Relato da palestra GreenOps e Cloud Sustentável no MVP Conf Brasil 2025: estratégias para uma nuvem eficiente, econômica e sustentável, e fotos do evento.
## MVP Conf Brasil 2025
Nos dias **24 e 25 de outubro de 2025**, estive presente no [**MVP Conf Brasil**](https://mvpconf.com.br/), realizado na **UNIP Campus Paraíso/Vergueiro, em São Paulo - SP**.
O evento reuniu **mais de 500 especialistas Microsoft** de todo o país — dois dias intensos de **aprendizado, networking e compartilhamento de conhecimento técnico de alto nível**.
### Minha palestra
#### GreenOps e Cloud Sustentável: o equilíbrio entre performance, custo e meio ambiente
Fui convidado para compartilhar a palestra **"GreenOps e Cloud Sustentável"**, onde explorei **estratégias práticas para adotar uma operação de nuvem mais eficiente, econômica e ambientalmente responsável**.
Durante a sessão, mergulhamos em tópicos como:
- O papel do **GreenOps** dentro da governança de nuvem corporativa
- Como medir e reduzir o **carbon footprint** em ambientes Azure
- A união entre **FinOps, Cloud Efficiency e automação**
- Arquiteturas **verdes, resilientes e escaláveis**
- Casos reais de **sustentabilidade digital aplicada ao dia a dia corporativo**
A ideia foi mostrar que dá pra fazer **mais com menos impacto**, sem comprometer a performance — e ainda **gerando economia real**.
Porque, convenhamos, eficiência e sustentabilidade podem (e devem) andar juntas.
### Um evento com propósito
O **MVP Conf** vai muito além de tecnologia.
Todo o valor arrecadado com os ingressos é **100% destinado a instituições sociais**, como a **Casa do Zezinho**, **Associação Prato Cheio** e **Associação Fênix**.
É inspirador ver uma comunidade tão técnica e diversa unida por um propósito tão nobre: **usar o conhecimento pra gerar impacto real**.
### Um encontro de gigantes
Foi uma honra dividir o palco com tanta gente incrível e poder representar a comunidade de **arquitetura cloud e sustentabilidade** dentro desse ecossistema.
### Networking e reencontros
O MVP Conf é aquele tipo de evento que **você chega pra assistir uma palestra e sai com dez novas conexões no LinkedIn**.
O ambiente colaborativo e cheio de energia positiva.
Reencontrei amigos de comunidade, troquei ideias com profissionais de diferentes regiões e claro, **renderam boas conversas sobre café, cloud e caos controlado**.
Participar do **MVP Conf Brasil 2025** foi uma experiência única.
Um evento **feito por especialistas para a comunidade**, com **propósito social, conteúdo técnico de peso e um clima de colaboração genuína**.
> **Sustentabilidade não é tendência, é responsabilidade.**
> E quando unimos tecnologia e propósito, o impacto é exponencial.
- **Slides da Apresentação:** [GreenOps e Cloud Sustentável no MVP Conf 2025](https://stoblobcertificados011.blob.core.windows.net/palestras/mvp-conf25.pdf)
---
# Antes de Estudar Ferramentas, Entenda a Cultura DevOps - whiteStone_dev 8ª Edição
URL: https://www.orafaelferreira.com/artigos/wsd-devops
Publicado: 2025-10-19
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> No dia 02 de outubro de 2025, participei como palestrante na 8ª edição da whiteStone_dev, realizada no INAITEC – Pedra Branca, em Palhoça (SC).
## whiteStone_dev – 8ª Edição | Cultura DevOps
No dia **02 de outubro de 2025**, participei como palestrante na [**8ª edição da whiteStone_dev**](https://whitestonedev.com.br/#/eventos/8edicao), realizada no **INAITEC – Pedra Branca**, em **Palhoça (SC)**.
Uma noite dedicada à **Cultura DevOps**, onde a comunidade se reuniu para discutir o que realmente faz essa mentalidade transformar times e organizações.
### O evento
A **whiteStone_dev** chegou à sua 8ª edição com uma proposta diferente:
falar menos sobre *ferramentas* e mais sobre **pessoas, princípios e práticas** que tornam o DevOps algo vivo dentro das empresas.
O evento contou com **apoio do INAITEC** (que sediou o encontro) e **patrocínio educacional da FIAP**, reunindo profissionais, estudantes e entusiastas de tecnologia da região metropolitana de Florianópolis.
📍 **Local:** INAITEC – Pedra Branca, Palhoça – SC
📅 **Data:** 02 de outubro de 2025
🕖 **Horário:** A partir das 19h
### Minha palestra
#### Antes de Estudar Ferramentas, Entenda a Cultura DevOps
Na minha sessão, falei sobre o que vem **antes das ferramentas** — a **mentalidade e os valores que sustentam o verdadeiro DevOps**.
Abordei temas como colaboração, aprendizado contínuo e o impacto cultural que transforma a forma como entregamos software no dia a dia.
Toquei em pontos como:
- O que realmente significa *Cultura DevOps*
- Por que a transformação começa nas pessoas, não nas ferramentas
- Exemplos reais de times que aplicam princípios DevOps com propósito
- Como a empatia e a colaboração se traduzem em entregas melhores
- Práticas para criar times autônomos e de alta performance
### Programação da Noite
A 8ª edição da whiteStone_dev foi marcada por talks inspiradoras e uma energia de comunidade contagiante:
- **19:00** — Abertura e Check-in
- **19:10** — Rafael Ferreira — *Antes de Estudar Ferramentas, Entenda a Cultura DevOps*
- **20:00** — Julio Santos — *Da Entropia ao Equilíbrio: Lições de Arquitetura de Software Sustentável*
- **21:00** — Eduardo P. Gutkoski - AppSync Event API – *AWS User Group Floripa*
- **21:50** — Networking & Encerramento
### Galeria de Fotos
### Encontro com a Comunidade
Além das palestras, o evento foi uma grande oportunidade pra reencontrar amigos, conhecer novas pessoas e fortalecer os laços entre comunidades — especialmente com a presença do **AWS User Group Floripa** e parceiros locais.
### Conclusão
Participar do **whiteStone_dev 8ª Edição | Cultura DevOps** foi uma experiência incrível.
Ver a comunidade reunida para discutir cultura, arquitetura e colaboração é o que mantém viva a essência do movimento DevOps.
Agradecimento especial à **organização do whiteStone_dev**, aos **palestrante Julio Santos e equipe do AWS User Group Floripa**, e a todos que participaram dessa noite memorável.
> **DevOps não é sobre ferramentas — é sobre pessoas, cultura e propósito.**
- **Slides da Apresentação:** [Antes de Estudar Ferramentas, Entenda a Cultura DevOps](https://stoblobcertificados011.blob.core.windows.net/palestras/dod-wsd.pdf)
---
# DevOps Além da Hype: Pessoas, Cultura e Prática - Esquenta MVPConf 2025 Curitiba
URL: https://www.orafaelferreira.com/artigos/mvp-crtb
Publicado: 2025-10-12
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> Relato da palestra DevOps Além da Hype no Esquenta MVPConf 2025, na UTFPR em Curitiba: cultura DevOps, programação completa do evento e fotos da experiência.
No dia **27 de setembro de 2025**, participei como palestrante no [**Esquenta do MVPConf 2025**](https://www.hubingressos.com.br/evento/mvpconfcuritiba), realizado no **auditório da UTFPR**, em Curitiba – PR.
Um evento incrível que serviu como prévia do maior encontro de especialistas Microsoft do Brasil: o **MVPConf**.
### O evento
Curitiba foi o palco da **última edição do Esquenta MVPConf**, reunindo profissionais, estudantes e entusiastas de tecnologia para um dia inteiro de **palestras técnicas de altíssimo nível**.
A cidade — reconhecida como uma das mais inteligentes e inovadoras do Brasil — recebeu especialistas premiados com o título de **Microsoft MVP (Most Valuable Professional)**, compartilhando conhecimento e experiências reais do dia a dia.
📍 **Local:** Auditório Principal da UTFPR
📅 **Data:** 27 de setembro de 2025
🕘 **Horário:** 09h00 às 18h00
### Minha palestra
#### DevOps Além da Hype: Pessoas, Cultura e Prática
Durante a minha sessão, falei sobre o que realmente sustenta o DevOps além das ferramentas — as **pessoas, a cultura e as práticas reais**.
Abordei como o movimento nasceu, como evoluiu, e por que as empresas que prosperam em DevOps entendem que **colaboração e empatia** vêm antes do código.
Toquei em pontos como:
- O nascimento do movimento DevOps e o *Agile Infrastructure*
- Os **Three Ways**, do *The Phoenix Project*
- As 4 métricas do livro *Accelerate*
- O framework **CALMS** e como aplicá-lo na prática
- Como criar um ambiente onde a **cultura** habilita a **entrega contínua**
### Programação do evento
O dia foi repleto de palestras inspiradoras e muito conteúdo técnico:
- **09:00 - 09:10** — Abertura do evento
- **09:10 - 09:50** — Keynote - Task TI
- **10:00 - 10:50** — Felipe Augusto — *Testes de unidade e integração em .NET com xUnit, Bogus, ReportGenerator e TestContainers*
- **11:00 - 11:50** — Rafael Ferreira — *DevOps além da hype: Pessoas, cultura e prática*
- **12:00 - 14:00** — Almoço e Networking
- **14:00 - 14:50** — Bruno Brito — *Do 1º usuário ao 1 milhão: Como escalar sua aplicação*
- **15:00 - 15:50** — Carlos dos Santos — *Criando e publicando uma aplicação com Containers e Azure*
- **16:00 - 16:50** — Walter Coan — *Monitoramento de equipamentos industriais com Azure IoT Operations e OPC UA*
- **17:00 - 17:50** — Johnson — *Proteção na era da IA com o Microsoft Security Copilot*
### Estrutura e Experiência
O evento contou com uma **estrutura impecável**, com estandes, recepção organizada e um público engajado.
Além das palestras, rolou aquele networking maroto nos intervalos, com troca de ideias e reencontros com amigos da comunidade.
Poder compartilhar com a comunidade aprendizados sobre **Cultura DevOps** em um evento com tantos profissionais talentosos reforça o propósito de continuar disseminando conhecimento.
Agradeço à **organização**, aos **palestrantes**, aos **patrocinadores** e a todos que fizeram parte desse dia memorável.
**DevOps é sobre pessoas — tecnologia é apenas a ponte.**
- **Slides da Apresentação:** [DevOps Além da Hype: Pessoas, Cultura e Prática](https://stoblobcertificados011.blob.core.windows.net/palestras/mvpcrtb25.pdf)
---
# Projetar e Implementar Soluções de Rede no Azure - AZ-700
URL: https://www.orafaelferreira.com/artigos/az-700
Publicado: 2025-10-06
Categoria: Artigos
Tempo de leitura: 4 min de leitura
> Guia de estudos para a AZ-700: endereçamento IP, DNS, hub-and-spoke, NAT Gateway, VPN, ExpressRoute, balanceadores, Private Endpoint e segurança de rede.
### Introdução
Se você está querendo se aventurar no mundo das redes em nuvem, a **certificação AZ-700** é o passaporte para provar que domina como projetar e implementar soluções de rede dentro do Microsoft Azure.
Depois de concluir o curso [*AZ-700 - Projetar e Implementar Soluções de Rede do Azure* do Higor Barbosa](https://www.udemy.com/course/az-700-vnet/), compilei aqui os principais aprendizados e boas práticas que realmente fazem diferença, tanto para quem administra ambientes corporativos quanto para quem busca aprofundar o domínio técnico em Azure Networking.
### 1. Planejamento de Endereçamento IP
Tudo começa com as redes.
Planeje suas **VNets e subnets** com cuidado: o Azure reserva sempre cinco endereços por subnet (do primeiro ao quarto e o último).
### 2. Resolução de Nomes (DNS Público e Privado)
- **Azure DNS:** gerencia domínios públicos com redundância global e desempenho via anycast.
- **Azure Private DNS:** resolve nomes internamente entre VNets privadas, integrando automaticamente registros das VMs.
- **Private DNS Resolver:** resolve consultas entre ambientes *on-premises* e Azure sem precisar expor tráfego para a internet.
### 3. Conectividade e Roteamento de VNets
1. **VNet Peering** – comunicação direta, rápida e segura.
2. **VPN Gateway** – conecta VNets entre regiões ou com ambiente local.
3. **UDR (User Defined Routes)** – define rotas personalizadas entre sub-redes.
**Topologia Hub-and-Spoke**
Organize o ambiente para que o *hub* concentre segurança e conectividade. As *spokes* hospedam workloads isolados, conectados via peering ou WAN Virtual.
### 4. NAT Gateway
Quando suas VMs precisam de saída de internet com IP fixo, use o **Azure NAT Gateway**.
Ele evita exaustão de portas SNAT e garante previsibilidade em cenários de egress controlado.
### 5. Monitoramento e Diagnóstico
**Network Watcher** oferece:
- *Connection Monitor*
- *IP Flow Verify*
- *Packet Capture*
- *NSG Flow Logs*
Combine com **Azure Monitor** e **Log Analytics** para construir uma visão completa da rede, detectar gargalos e ativar alertas automáticos.
### 6. VPN Site-to-Site e Ponto-a-Site
**Site-to-Site (S2S):**
- Conecta datacenters e VNets.
- Use gateways **route-based** e é possível, configuração ativa-ativa com BGP.
**Ponto-a-Site (P2S):**
- Conexões individuais de dispositivos.
- Suporte a SSTP, IKEv2 e OpenVPN.
- Pode autenticar via certificados, RADIUS ou Entra ID (AAD).
Essas opções permitem criar conectividade híbrida estável e segura entre diferentes ambientes.
### 7. ExpressRoute e WAN Virtual
Quando o assunto é conectividade privada e de alta performance:
- **ExpressRoute** conecta seu ambiente local diretamente ao backbone do Azure.
- **Azure Virtual WAN** centraliza e automatiza o roteamento global, integrando S2S, P2S, ER e VNets.
### 8. Balanceadores de Carga e Entrega de Aplicações
Camada 4 → **Azure Load Balancer**
Camada 7 → **Application Gateway (AppGW)**
Gerenciamento Global → **Traffic Manager** e **Azure Front Door**
Cada serviço tem seu lugar:
- **LB**: ideal para backend interno.
- **AppGW**: faz roteamento baseado em URL e HTTPS com WAF embutido.
- **Front Door**: CDN global + balanceamento inteligente entre regiões.
- **Traffic Manager**: DNS-based routing (latência, prioridade, geográfico).
### 9. Acesso Privado a Serviços PaaS
Duas opções dominam:
1. **Service Endpoints:** protegem o acesso a serviços PaaS via backbone, mas mantêm o recurso com IP público.
2. **Private Endpoints:** criam uma interface privada na sua VNet, isolando o tráfego totalmente.
Hoje, o padrão corporativo é sempre **Private Endpoint**, mais seguro, mais fácil de auditar e compatível com políticas de compliance.
### 10. Segurança de Rede no Azure
Os blocos de segurança que mais fazem diferença no dia a dia:
| Serviço | Função |
|----------|--------|
| **NSG (Network Security Group)** | Controle de tráfego em sub-redes e NICs |
| **ASG (Application Security Group)** | Agrupamento lógico de VMs por aplicação |
| **Azure Firewall** | Inspeção e regras centralizadas |
| **Firewall Manager** | Políticas e governança em larga escala |
| **WAF (Web Application Firewall)** | Proteção camada 7 contra ataques Web |
| **DDoS Protection** | Mitigação automática de ataques volumétricos |
### 11. Conclusão
Entender **endereçamento, conectividade, segurança e entrega de aplicações** te coloca em outro nível, não só tecnicamente, mas na forma de pensar na infraestrutura com sua resiliência e escalabilidade de rede.
---
#### Referências oficiais
- [Microsoft Learn — AZ-700: Design and Implement Azure Network Solutions](https://learn.microsoft.com/certifications/exams/az-700/)
- [Microsoft Docs — Virtual Network Overview](https://learn.microsoft.com/azure/virtual-network/virtual-networks-overview)
- [Azure Architecture Center — Hub-and-Spoke Network Topology](https://learn.microsoft.com/azure/architecture/reference-architectures/hybrid-networking/hub-spoke)
*Baseado no curso de Higor Barbosa na Udemy (2025).*
- [2025-06 - AZ-700 - Projetar e Implementar Soluções de Rede do Azure](https://www.udemy.com/certificate/UC-49bfc006-aeb5-476d-8083-229aac73cd8f/)
---
# GreenOps na Cloud: Arquitetando um Futuro Sustentável - TDC São Paulo 2025
URL: https://www.orafaelferreira.com/artigos/tdc-greenops
Publicado: 2025-10-04
Categoria: Palestras
Tempo de leitura: 3 min de leitura
> Relato da minha palestra GreenOps na Cloud na Trilha de Arquitetura Cloud do TDC São Paulo 2025, com práticas sustentáveis, networking e certificado.
## TDC São Paulo 2025
No dia **17 de setembro de 2025**, participei como palestrante da [**Trilha de Arquitetura Cloud** no **TDC São Paulo**](https://thedevconf.com/tdc/2025/sao-paulo/trilha-arquitetura-cloud), um dos maiores eventos de tecnologia do Brasil, realizado no **ProMagno, em São Paulo - SP**.
Foram **8 horas de muito conteúdo, inovação, networking e tecnologia** reunindo profissionais, comunidades e empresas de todo o país.
### Minha palestra
#### GreenOps na Cloud: Arquitetando um Futuro Sustentável
Na minha sessão, falei sobre como **adotar práticas sustentáveis na nuvem** pode gerar impacto positivo tanto para o planeta quanto para o negócio.
Exploramos estratégias que combinam **FinOps, automação e arquitetura verde**, mostrando que é possível reduzir custos e emissões sem comprometer performance.
Toquei em temas como:
- O papel do **GreenOps** na governança de nuvem corporativa
- Como usar **métricas ambientais (carbon footprint)** dentro do Azure
- Boas práticas de **FinOps + Cloud Efficiency**
- A importância de **arquiteturas sustentáveis e automatizadas**
- Casos reais e aprendizados práticos em ambientes globais
### Programação da Trilha Arquitetura Cloud
O dia foi intenso e repleto de conteúdo técnico de altíssimo nível, participi de algumas palestras:
- **Thiago Silva (Bosch)** — Construindo o futuro na nuvem: Benefícios da Redundância e paz de espírito com Recuperação de Desastres
- **Renan Oliveira (CTO - Hypetech)** e **André Bassi (Platform Engineer - Hypetech)** — Arquitetura Multi-cloud na Prática: Escalabilidade Sem Fronteiras
- **Marcello Ozzetti (Accenture)** e **Victor Muniz (Accenture)** — DevOps como Serviço: Templates Padronizados para Multi-Frameworks e Multi-Cloud
- **Camila Macedo (Red Hat)** — Descomplicando o Operator Pattern: estenda a API do Kubernetes
### Encontro com os Alura Stars
Durante o evento, também rolou um momento especial com o **grupo dos Alura Stars** que estavam presentes no TDC.
Foi ótimo encontrar tanta gente que compartilha a mesma paixão por tecnologia, aprendizado e comunidade.
### Espaço de Fotos e Networking
O **hall de entrada do ProMagno** estava com uma estrutura incrível, e o evento ainda contou com um **espaço dedicado para fotos profissionais**.
Com um fotógrafo no local, os participantes puderam **atualizar a foto do perfil do LinkedIn** e registrar o momento com qualidade.
### Galeria de Fotos
### Certificado de Participação
Participar do **TDC São Paulo** foi uma experiência incrível, energia contagiante, público engajado e discussões profundas sobre o futuro da **arquitetura em nuvem e sustentabilidade digital**.
> **Pense grande, pense verde.**
- **Slides da Apresentação:** [GreenOps na Cloud: Arquitetando um Futuro Sustentável](https://stoblobcertificados011.blob.core.windows.net/palestras/tdc-greenops-25.pdf)
---
# Explorando a cultura DevOps: Por que tanto se fala de cultura por trás da entrega contínua? - Encontro das comunidades AWS User Group Floripa + DevOps Floripa 2025
URL: https://www.orafaelferreira.com/artigos/dod-meetupaws
Publicado: 2025-09-30
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> Palestrei sobre cultura DevOps no encontro das comunidades AWS User Group Floripa e DevOps Floripa, realizado no auditório da ACATE em setembro de 2025.
## Encontro das comunidades AWS User Group Floripa + DevOps Floripa
No dia **03 de setembro de 2025**, participei como palestrante no [**Encontro das comunidades AWS User Group Floripa + DevOps Floripa**](https://www.meetup.com/aws-user-group-floripa/events/310698392/?eventOrigin=group_events_list), realizado no **Auditório da ACATE - Passeio Primavera (SC-401)**.
Um evento colaborativo que uniu duas comunidades vibrantes para discutir **computação em nuvem, cultura DevOps, inovação e muito networking**.
### Minha palestra
#### Explorando a Cultura DevOps: Por que tanto se fala de cultura por trás da entrega contínua?
Na minha sessão, trouxe reflexões sobre como a **cultura** é o principal motor por trás das práticas DevOps.
Mais do que ferramentas, DevOps é sobre **mentalidade, colaboração e propósito**.
Toquei em pontos como:
- Por que falar de **cultura** importa tanto quanto falar de tecnologia
- O impacto da **empatia e colaboração** em times distribuídos
- Como **práticas reais** transformam entregas contínuas em valor para o negócio
- Casos práticos de pipelines e times que adotaram a mudança cultural antes da técnica
### Programação do evento'
O encontro teve uma programação muito rica e diversa:
- **18h45 - 19h20** — Recepção + Introdução às comunidades
- **19h20 - 19h30** — Apresentação da empresa **Zallpy** (patrocinadora do evento)
- **19h30 - 20h** — *Do Qubit à Aritmética: Como calcular a + b usando computadores quânticos?* — *Ruan Luiz (Grupo de Computação Quântica da UFSC)*
- **20h - 20h30** — Coffee + Networking ☕
- **20h45 - 21h15** — *Explorando a Cultura DevOps* — *Rafael Ferreira (Senior Platform Engineer)*
- **21h15 - 21h45** — *Logs não são o suficiente* — *Marcelo Scheidt (Principal Engineer, e-Hub da Zallpy)*
- **21h45** — Encerramento
### Destaques da minha sessão
- Cultura DevOps é sobre **pessoas e interações**
- Ferramentas só têm valor quando aplicadas com **propósito claro**
- A **entrega contínua** depende de confiança e alinhamento cultural
- **Exemplos práticos** de mudanças que deram certo (e outras que ensinaram muito)
### Galeria de Fotos
### Conclusão
O encontro foi uma irado cheio de aprendizado e conexão com as comunidade **AWS User Group Floripa**, **DevOps Floripa** aos patrocinadores e todos que participaram dessa noite.
> **DevOps é sobre cultura, não sobre ferramentas.**
- **Slides da Apresentação:** [Explorando a cultura DevOps: Por que tanto se fala de cultura por trás da entrega contínua?](https://stoblobcertificados011.blob.core.windows.net/palestras/dod-meetup25.pdf)
---
# DevOps Além da Hype: Pessoas, Cultura e Prática - DevOpsDays Curitiba 2025
URL: https://www.orafaelferreira.com/artigos/dod-crtb25
Publicado: 2025-09-01
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> Relato da palestra DevOps Além da Hype no DevOpsDays Curitiba 2025, na UFPR: cultura, pessoas, framework CALMS, programação do evento e galeria de fotos.
## DevOpsDays Curitiba 2025
No dia **30 de agosto de 2025**, tive o prazer de participar do **DevOpsDays Curitiba**, um dos principais eventos da comunidade DevOps no Brasil. O evento aconteceu no **Centro Politécnico da UFPR**, reunindo profissionais apaixonados por tecnologia, inovação e cultura DevOps.
### Minha palestra
#### DevOps Além da Hype: Pessoas, Cultura e Prática
Falar sobre DevOps vai muito além de falar sobre ferramentas. Na minha sessão, foquei na **transformação cultural**, no papel das **pessoas** e em **práticas reais** que impactam a entrega de software de forma mais rápida, contínua e confiável.
Toquei em pontos como:
- O nascimento do movimento DevOps, desde o *Agile Infrastructure* em 2008
- Os **Three Ways**, do *The Phoenix Project*
- As 4 métricas do livro *Accelerate*
- A importância das **topologias de times** (Team Topologies)
- O framework **CALMS** e os pilares para sustentar o DevOps na prática
### Programação do evento
O evento contou com nomes de peso e temas de altíssimo nível, como:
- **Vinicius Moraes** — Usando Infraestrutura como Código para Criar um Sistema de Detecção de Intrusões
- **Ederson do Nascimento** — SRE na Prática
- **Bruno Lopes** — Otimizando Clusters Kubernetes com Karpenter
- **João Brito** — 15 Dicas em 30 Minutos
- **Lucas Ribeiro da Mata** — MLOps na prática
- **Gabriel Bazzotti** — Policy as Code e Segurança em Clusters!
- **Igor Estevan Jasinski** — Machine Learning e Séries Temporais com Prometheus
### Destaques da minha sessão
- 🧠 Cultura DevOps ≠ Ferramentas
- 🛠️ Integração de ferramentas com propósito (CI/CD, IAC, observabilidade)
- 🚀 Transformação real de pipelines com Kubernetes
- 📊 Métricas de sucesso para times de alta performance
- 👥 Colaboração e empatia como base de qualquer transformação
### Galeria de Fotos
### Conclusão
Agradeço à organização, aos palestrantes, e a toda galera que colou na minha sessão.
> **DevOps não é um destino. É uma jornada contínua.**
- **Slides da Apresentação:** [DevOps Além da Hype: Pessoas, Cultura e Prática](https://stoblobcertificados011.blob.core.windows.net/palestras/DevOps-CRTB.pdf)
---
# Cloud Moderna ANTI Ataque: blindagem DevOps que você PRECISA conhecer - Hacking na Web Day Florianópolis 2025
URL: https://www.orafaelferreira.com/artigos/hack
Publicado: 2025-08-20
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> Relato da palestra Cloud Moderna ANTI Ataque no Hacking na Web Day Florianópolis 2025: defesa em camadas, os 4Cs da Cloud Native Security e blindagem DevOps.
## Cloud Moderna ANTI Ataque: minha experiência no HNWD Floripa 2025
No último dia **16 de agosto de 2025**, rolou em Florianópolis o [**HNWD (Hacking na Web Day)**](https://www.sympla.com.br/evento/hnwd-florianopolis-2025/2960275?referrer=orafaelferreira.com&referrer=orafaelferreira.com), um dos eventos mais autênticos e relevantes da cena de hacking e segurança cibernética no Brasil. Essa edição aconteceu no Castelmar Hotel, reunindo especialistas, entusiastas e comunidades apaixonadas por segurança da informação.
O HNWD nasceu como um encontro feito *da comunidade para a comunidade*, e já virou referência nacional. Em 2025, a tour passou por **seis cidades brasileiras**, trazendo conteúdo de altíssimo nível, com palestras práticas, CTFs presenciais, além de muito networking e trocas intensas de experiência.
### Minha palestra: blindagem DevOps em ambientes cloud
Tive a honra de palestrar no **Auditório 2**, ao meio-dia, com o tema:
**"Cloud Moderna ANTI Ataque: blindagem DevOps que você PRECISA conhecer"**.
## Resumo da Talk
Na palestra **Cloud Moderna ANTI Ataque: Blindagem DevOps Essencial**, apresentei duas frentes principais de segurança:
### Parte 1 — Defesa em Camadas
Mostrei como proteger ambientes cloud com uma **arquitetura em múltiplas camadas**, utilizando os principais recursos nativos das clouds:
- **Identidade & Acesso**: IAM, RBAC, Zero Trust, MFA.
- **Perímetro**: WAF, CDN, VPN, Bastion, proteção DDoS.
- **Rede & Segmentação**: VNet/SG/NACL, isolamento de workloads.
- **Compute & Containers**: Defender, Inspector, OS Config, AKS/EKS/GKE.
- **Aplicações**: API Management, App Services, Gateways, Key Vault/Secrets.
- **Dados**: Criptografia, KMS, controle de chaves.
- **Monitoramento & Resposta**: SIEM (Sentinel, Security Hub, Chronicle), logs centralizados, automação de incidentes.
### Parte 2 — Os 4Cs da Cloud Native Security
Conectando com o modelo da CNCF, mostrei como aplicar defesa de forma **Cloud Native**:
- **Cloud** → Governança, Policy, Defender for Cloud, Config, SCC.
- **Cluster** → Segurança em Kubernetes (RBAC, hardening, runtime visibility).
- **Container** → Scan de imagens, assinatura, execução não-root, OPA/Kyverno.
- **Código** → Shift Left, SAST/DAST, SCA, secret scanning, IaC seguro.
O evento foi cheio de aprendizado. Tivemos palestras sobre **IA adversarial, XSS avançado, Kubernetes hacking, deepfakes, AWS hardening** e muito mais. Além disso, o espaço de comunidades e patrocinadores trouxe aquela vibe que só a cena de segurança brasileira tem: **colaboração acima da competição**.
Quero agradecer a todos que participaram da minha palestra e trocaram ideias comigo durante o evento. Foi uma experiência incrível poder compartilhar práticas de blindagem em nuvem com tanta gente interessada em levar segurança a sério no dia a dia.
E claro: parabéns à organização do HNWD e a todos os apoiadores que tornam esse evento possível. É nítido que o hacking no Brasil está cada vez mais **forte, maduro e conectado**.
Nos vemos na próxima!
- **Slides da Apresentação:** [Cloud Moderna ANTI Ataque: blindagem DevOps que você PRECISA conhecer](https://stoblobcertificados011.blob.core.windows.net/palestras/CloudModernaANTIAtaque.pdf)
---
# Certificação HashiCorp Terraform Associate 003: Dicas, Experiências e Preparação
URL: https://www.orafaelferreira.com/artigos/terraform-associate-artigo
Publicado: 2025-08-03
Categoria: Artigos
Tempo de leitura: 5 min de leitura
> Como foi passar no exame HashiCorp Certified Terraform Associate 003: estrutura da prova, experiência pessoal e dicas de estudo para a preparação.
##
### Introdução
Fala galera! Tudo bom? Recentemente passei no exame **HashiCorp Certified: Terraform Associate (003)** e quero compartilhar com vocês um pouco sobre como foi a experiência, desde a estrutura da prova até as minhas dicas de estudo. Se você é um profissional de DevOps querendo se certificar em Terraform, este artigo é pra você!
Para quem não conhece, essa certificação Terraform Associate basicamente valida seus conhecimentos fundamentais sobre o Terraform e conceitos de Infraestrutura como Código (IaC).
### Sobre o Exame Terraform Associate
O Terraform Associate (versão 003) é uma certificação de nível "fundamental" da HashiCorp voltada para Terraform. É recomendada para engenheiros de infraestrutura/DevOps que atuam em operações, TI ou desenvolvimento e já conhecem os conceitos básicos do Terraform.
**Formato da prova:**
- Online, com supervisão (proctored)
- 57 questões de múltipla escolha
- Tempo: 1 hora (60 minutos)
- Idioma: Inglês
- Custo: cerca de US$70
- Validade: 2 anos
### Tópicos Principais do Exame
- **Infraestrutura como Código (IaC):** Saber o que é IaC e por que é vantajosa, destacando a consistência, automação e versionamento de infraestrutura.
- Exercício prático: [1-UnderstandInfrastructureasCode(IaC)concepts-BuildingVM](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/1-UnderstandInfrastructureasCode(IaC)concepts-BuildingVM)
- **Propósito do Terraform em relação a outras ferramentas:** Entender os benefícios de ser multi-cloud e agnóstico ao provedor e o papel do arquivo de estado.
- Exercício prático: [2-UnderstandTerraformbasics](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/2-UnderstandTerraformbasics)
- **Fundamentos do Terraform:** Dominar sintaxe HCL, blocos de recursos e dados, providers, variáveis e outputs.
- **Uso do Terraform além do fluxo básico:** Conhecer comandos como `terraform import` para importar recursos, `terraform state` para inspecionar o estado e como habilitar logs de depuração.
- **Módulos:** Saber encontrar módulos no registro público, usar módulos locais e remotos, versionar e entender o escopo de variáveis.
- Exercício prático: [5-InteractwithTerraformmodules1](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/5-InteractwithTerraformmodules1)
- Exercício prático: [5-InteractwithTerraformmodules2](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/5-InteractwithTerraformmodules2)
- **Fluxo de trabalho:** Gravar a sequência `write → plan → apply` (CAI NA PROVA) e também `validate`, `fmt` e `destroy`.
- **Estado:** Entender backends locais e remotos, locking de estado, drifts e comandos como `terraform state mv`, bem como segredos no `tfstate`.
- **Ler e modificar configurações:** Utilizar variáveis e outputs corretamente, proteger segredos, trabalhar com tipos complexos e funções HCL.
- Exercício prático: [8-Read,generate,ModifyConfiguration-Collections](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/8-Read%2Cgenerate%2CModifyConfiguration-Collections)
- Exercício prático: [8-Read,generate,ModifyConfiguration-Functions](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/8-Read%2Cgenerate%2CModifyConfiguration-Functions)
- Exercício prático: [8-Read,generate,ModifyConfiguration-Secrets](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate/8-Read%2Cgenerate%2CModifyConfiguration-Secrets)
- **Conhecer o Terraform Cloud/Enterprise:** Ter noções das funcionalidades da oferta SaaS (state remoto, integração com VCS, políticas e colaboração).
- **Workspaces:** Embora não apareça explicitamente no blueprint, várias questões NA PROVA abordam Workspaces. Saiba criar, listar, selecionar e remover workspaces e as diferenças em relação a usar backends distintos.
### Minha Preparação e Materiais de Estudo
- **Curso TFTEC:** 100% prático, com labs e simulado final. [Acesse aqui](https://tftec.curseduca.pro/m/c/terrafom-associate-1694628491755)
- **Labs próprios:** Pratiquei com cloud Azure.
- **GitHub pessoal:** Criei um [repositório](https://github.com/orafaelferreiraa/Terraform-Training-Projects/tree/main/Treinamento%20TFTEC%20Terrafom%20Associate) com todos os projetos que fiz nos labs.
- **Curso Udemy – Terraform Associate Practice Exam (em inglês):** Excelente para testar conhecimentos com simulado realista. [Acesse aqui](https://www.udemy.com/course/terraform-associate-practice-exam/)
### Dicas para o Exame
- **Domine IaC na teoria:** O exame cobra definições e vantagens da IaC. Saiba explicar por que versionar infraestrutura como código aumenta a confiabilidade e como se diferencia de ferramentas de gerenciamento de configuração.
- **Pratique todos os comandos:** Não fique só no trio `init/plan/apply`. Experimente `fmt`, `import`, `state list/show/mv`, `workspace`, `login/logout` e assim por diante.
- **Estude o arquivo de estado:** Saiba que o `tfstate` é salvo localmente por padrão e pode ser movido para backends remotos. Entenda como funciona o locking, como lidar com drifts e quando usar `terraform state rm`.
- **Módulos são fundamentais:** Crie e utilize módulos para entender entradas e saídas, escopo de variáveis, versionamento e fontes (local, registro ou repositório Git).
- **Aprenda sobre Workspaces:** Domine os comandos `workspace new/list/select/show` e compreenda que cada workspace tem seu próprio arquivo de estado.
- **Conheça o Terraform Cloud:** Mesmo que nunca tenha usado a versão SaaS, leia sobre suas vantagens: state remoto com bloqueio automático, integrações com Git, execução em equipe e políticas de governança.
- **Gerencie o tempo na prova:** Sessenta minutos para 57 perguntas dá cerca de um minuto por questão. Marque a melhor opção e volte depois se necessário.
- **Mantenha a calma:** Revise as opções com atenção, pois muitas vezes a diferença está em uma palavra (e em inglês). Antes de submeter, revise tudo.
- **Transfira o aprendizado para o trabalho:** Refatore códigos reais com boas práticas. Aplicar o conteúdo no dia a dia reforça o aprendizado.
### Conclusão
Fazer a certificação Terraform Associate foi uma experiência valiosa. Além de receber o badge, consolidei conceitos essenciais de IaC e do Terraform que aplico diariamente. A prova reflete demandas do mundo real: ao estudar para ela, você aprimora seu domínio da ferramenta e se prepara melhor para projetos de nuvem e automação.
Recomendo a certificação para quem já utiliza Terraform. Ela formaliza o conhecimento e pode abrir portas — muitas vagas pedem familiaridade com Terraform, e ter a certificação ajuda a comprovar essa habilidade. Para quem pretende avançar, a HashiCorp oferece também o nível Professional, então a Associate pode ser só o começo.
**Referências**:
- [HashiCorp Terraform Associate](https://developer.hashicorp.com/terraform/tutorials/certification-003/associate-review-003)
---
# Organizador – Azure User Groups Brasil
URL: https://www.orafaelferreira.com/artigos/azure-user-groups-brasil
Publicado: 2025-06-21
Categoria: Organizador Grupo de Comunidade
Tempo de leitura: 2 min de leitura
> Atuação nacional no Azure User Groups Brasil e local no Azure User Group Florianópolis, fortalecendo comunidades, eventos e conteúdo sobre Microsoft Azure.
### Introdução
O **Azure User Groups Brasil** nasceu para conectar comunidades regionais, incentivar novas branches e ampliar o acesso a conteúdo de qualidade sobre **Microsoft Azure** e tecnologias cloud em todo o país.
Além de fortalecer a troca entre organizadores, palestrantes e participantes, a iniciativa cria um ponto de encontro nacional para quem quer aprender, compartilhar experiências reais e evoluir na carreira.
Se você curte comunidade, cloud e colaboração, esse grupo é para você.
## Azure User Groups Brasil
* 🌐 [Site oficial](https://azureusergroupsbrasil.com.br/)
* 🔗 [Linktree oficial](https://linktr.ee/azureusergroupsbrasil)
* 🗂️ [Branches](https://azureusergroupsbrasil.com.br/branches)
* 📅 [Eventos](https://azureusergroupsbrasil.com.br/events)
* 🧭 [Nova Branch](https://azureusergroupsbrasil.com.br/nova-branch)
* 👥 [Grupo WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)
* ▶️ [YouTube](https://www.youtube.com/@azureusergroupsbrasil?sub_confirmation=1)
* 💼 [LinkedIn](https://www.linkedin.com/company/azureusergroupsbrasil)
* 🤝 [Meetup](https://www.meetup.com/azureusergroupsbrasil)
* 📸 [Instagram](https://www.instagram.com/azureusergroupsbrasil/)
* 🔗 [Acessar o Linktree do Azure User Groups Brasil](https://linktr.ee/azureusergroupsbrasil)
### Nossas Branches
Comunidades regionais ativas em todo o Brasil, organizando meetups, workshops e eventos técnicos sobre Azure.
| Branch | Local | Resumo | Organizadores |
|--------|-------|--------|---------------|
| [**Azure User Group Florianópolis**](https://azureusergroupsbrasil.com.br/branches/florianopolis) | Florianópolis, SC | Comunidade Azure de Floripa conectando desenvolvedores, arquitetos e profissionais de TI com meetups, workshops e eventos na Ilha da Magia. | 2 |
| [**Azure User Group Curitiba**](https://azureusergroupsbrasil.com.br/branches/curitiba) | Curitiba, PR | Comunidade focada em Microsoft Azure na região de Curitiba, reunindo profissionais, estudantes e entusiastas para compartilhar experiências e boas práticas. | 3 |
### Expansão da comunidade
Quer levar o **Azure User Groups Brasil** para a sua cidade? A comunidade mantém uma página dedicada para abertura de novas branches, reunindo pessoas que queiram organizar encontros locais e expandir o alcance da iniciativa.
* 🚀 [Quero abrir uma branch](https://azureusergroupsbrasil.com.br/nova-branch)
* ℹ️ [Saiba mais sobre a comunidade](https://azureusergroupsbrasil.com.br/about)
### Atuação local: Azure User Group Florianópolis
Além da frente nacional, também faço parte do **Azure User Group Florianópolis**, branch local da comunidade em Santa Catarina.
O grupo conecta desenvolvedores, arquitetos e profissionais de TI interessados em tecnologias Microsoft Azure, promovendo meetups, workshops e eventos para fortalecer o ecossistema tech da Ilha da Magia.
* 📍 [Página da branch Florianópolis](https://azureusergroupsbrasil.com.br/branches/florianopolis)
### Como participar
Se você quer acompanhar eventos, conhecer a branch mais próxima ou entrar em contato com a organização nacional, estes são os principais canais:
* 👥 [Entrar no grupo do WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)
O **Azure User Groups Brasil** consolida um movimento nacional de comunidades locais sobre Azure. No meu caso, essa atuação acontece em duas frentes complementares: no nível nacional, apoiando a expansão da comunidade, e no nível local, ajudando a fortalecer o **Azure User Group Florianópolis**.
Se fizer sentido para você, participe da branch mais próxima ou ajude a abrir a próxima.
---
# Os 6Rs que Você Precisa Conhecer para Migrar para a Cloud; O sétimo R é de Rivotril?! - Esquenta MVP Conf Blumenau 2025
URL: https://www.orafaelferreira.com/artigos/mvp-conf-blu
Publicado: 2025-05-23
Categoria: Palestras
Tags: Azure
Tempo de leitura: 2 min de leitura
> Palestrei sobre os 6Rs de migração para a cloud no Esquenta MVP Conf Blumenau 2025, evento que antecipou o clima da próxima edição do MVP Conf em São Paulo.
## Esquenta MVP Conf Blumenau
No último dia **26 de abril de 2025**, Blumenau foi palco de um grande evento tech do sul do Brasil: o **Esquenta MVP Conf**, uma amostra da energia e do conteúdo de alto nível que teremos na próxima edição do [MVP Conf em São Paulo](https://www.mvpconf.com.br). A FURB (Fundação Universidade Regional de Blumenau) recebeu MVPs da Microsoft e rolou muita troca de ideia.
### Minha palestra
#### Os 6Rs que Você Precisa Conhecer para Migrar para a Cloud
**O sétimo R é de Rivotril?!**
Falar sobre migração pode parecer batido, mas muita gente ainda se perde na hora de escolher a estratégia certa. Na minha sessão eu trouxe o **framework dos 6Rs** (Rehost, Replatform, Rearchitect, Rebuild, Replace e Retire), mostrei quando usar cada um e acrescentei algumas piadas para manter a sanidade da galera.
### Palestrantes e temas
- **Henrique Mauri** — Desenvolvendo aplicações modernas com .NET e Azure
- **Vinicius Deschamps** — “Olha mãe, sem usar senhas”: como utilizar Managed Identity no Azure
- **Rodrigo Dornel** — Análise de Dados com Power BI & Copilot
- **Walter Coan** — Evolução da plataforma Azure IoT: do IoT Hub até o IoT Operations
- **Claudio Rapôso** — Revolucione Suas Aplicações: o segredo contra falhas em FaaS com JavaScript que ninguém te contou!
- **Felipe Augusto** — Event-Driven no Azure: como utilizar o Azure Service Bus para escalabilidade e resiliência
- **Rafael Ferreira** — Os 6Rs que Você Precisa Conhecer para Migrar para a Cloud; o sétimo R é de Rivotril?!
- **Johnson de Souza** — Preparar a segurança e a conformidade para dar suporte ao Microsoft 365 Copilot
- **Bruno Leires** — O futuro da administração do 365 com Copilot: o que esperar?
### Destaques da Palestra
- 🚀 **Cloud Foundation**: por que não adianta colocar o telhado antes da base
- 🧱 **Landing Zones**: seu ponto de partida estruturado
- 🛠️ Ferramentas como **Azure Migrate** e **Database Migration Service**
- 💰 **FinOps** e **GreenOps**: migrar sem estourar o orçamento
### Galeria de Fotos
---
# Trabalhando para o Exterior – Global Azure Floripa 2025
URL: https://www.orafaelferreira.com/artigos/carreira-internacional
Publicado: 2025-05-18
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> Abertura do Global Azure Floripa 2025 com Vinicius Deschamps: realidade, desafios e oportunidades de trabalhar para o exterior na área de tecnologia.
## Trabalhar para o Exterior: Realidade, Desafios e Oportunidades 🌍💼
Durante o [**Global Azure 2025 – Edição Azure Floripa**](https://www.meetup.com/azure-user-groups/events/306207034/?eventOrigin=group_past_events), tive o prazer de abrir o evento ao lado do grande amigo e profissional **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)** com uma palestra que foge um pouco do tradicional técnico — mas que é um divisor de águas **"Trabalhando para o Exterior: Realidade, Desafios e Oportunidades"**.
Falamos sobre como é atuar em uma empresa internacional, os bastidores que, os impactos na vida pessoal e profissional, e claro, compartilhamos nossas experiências reais no mercado global.
### 🎙️ Sobre a Palestra
**Tema:** Trabalhando para o Exterior
**Palestrantes:** [Rafael Ferreira](https://www.linkedin.com/in/orafaelferreiraa/) & [Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)
**Evento:** Global Azure 2025 – Azure Floripa
**Data:** 10 de maio de 2025
**Local:** Neoway, Florianópolis - SC
### 💬 O que abordamos?
- Diferenças culturais e adaptação no trabalho remoto com times globais
- Estratégias para se destacar em entrevistas internacionais
- Dicas montar um perfil atrativo para o mercado global
- Dicas práticas de quem vive isso no dia a dia
- E o mais importante: falamos a real!
### 📸 Momentos que Valem o Registro
Confira algumas fotos da nossa palestra:
### 🧾 Links de Indicação Úteis pra Quem Quer Trabalhar pra Fora
Se você está **começando sua jornada internacional**, aqui vão dois serviços que **uso pessoalmente** e recomendo:
#### 💼 Abrir ou manter seu CNPJ com a **Contabilizei**
Simplifique sua vida como PJ, sem dor de cabeça com impostos e obrigações contábeis:
👉 [Abra sua conta na Contabilizei com meu link de indicação](https://www.contabilizei.com.br/programa-de-indicacao?ref=daf792a9759933c6a3f54a8832357168&nome=RAFAEL&email=rafael_low@hotmail.com&utm_source=plataforma&utm_campaign=MGM&utm_source=plataforma)
#### 💸 Receber em dólar com ótimas taxas usando a **TechFX**
Pra quem recebe moeda de fora (dólar, euro, libra...) direto na conta PJ, TechFX ajuda a economizar nas taxas e ganhar agilidade:
👉 [Crie sua conta TechFX com meu link e comece a receber melhor](https://www.techfx.com.br/rafa-ferreira/)
### 💙 Por que falamos disso?
Porque a comunidade técnica precisa falar sobre carreira, escolhas conscientes e qualidade de vida, não só sobre código. E se pudermos ajudar alguém a conquistar uma oportunidade internacional com mais preparo e menos ilusões, já valeu a pena!
#GlobalAzure #AzureFloripa #TrabalhoInternacional #CarreiraTI #ComunidadeTech #Azure
---
# Global Azure feat Azure Floripa 2025 (Evento Remoto)
URL: https://www.orafaelferreira.com/artigos/global-azure25
Publicado: 2025-05-18
Categoria: Organização de Eventos
Tempo de leitura: 2 min de leitura
> Relato da edição remota do Global Azure 2025 com o Azure Floripa: dois dias intensos de conteúdo técnico de qualidade e aprendizado com a comunidade brasileira.
## Global Azure 2025 feat. Azure Floripa: Tecnologia, Café e Muito Compartilhamento!
Mais um ano, mais uma edição do [**Global Azure 2025 – Edição Azure Floripa**](https://www.meetup.com/azure-user-groups/events/306207034/?eventOrigin=group_past_events)! E sim, o **Azure Floripa** colou junto mais uma vez pra fazer história com a comunidade técnica brasileira. Foram 2 dias intensos, com conteúdo de qualidade, e muito aprendizado!
Se você perdeu, relaxa — a gente fez esse post cheio de links pra você maratonar as talks.
### Organizadores
- **[Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)**
- **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)**
### Palestras e Sessões em Destaque
#### Fazendo Backup de VMs no Azure Utilizando o Azure Backup
[](https://www.youtube.com/watch?v=fWaowwBWUwU)
#### Migrando sua infraestrutura para Nuvem - Projeto Real
[](https://www.youtube.com/watch?v=gP4tWge98to)
#### BCDR - Business Continuity and Disaster Recovery
[](https://www.youtube.com/watch?v=uHe08MPkJG4)
#### Desenvolvendo Agentes Inteligentes com Semantic Kernel e LLM
[](https://www.youtube.com/watch?v=1F6sn6Q4vEc)
#### Azure App Service e Docker: Trabalhando com Aplicações Contêinerizadas
[](https://www.youtube.com/watch?v=g5dusKDV3Ig)
#### Azure IoT Operations
[](https://www.youtube.com/watch?v=4FqXwTd-hNg)
#### Arquitetando Agentics e Aplicações Multiagentes
[](https://www.youtube.com/watch?v=6-PuO2A9NmA)
#### Your Gateway to the World of Artificial Intelligence
[](https://www.youtube.com/watch?v=Gx8viB0t6wU)
#### Do Código à Nuvem: IaC e Conteinerização no Ecossistema Azure
[](https://www.youtube.com/watch?v=8aG6Q-4DKjI)
#### Facilite sua vida com Azure Blobs
[](https://www.youtube.com/watch?v=3PygDrlNdEM)
#### Impulsione seus estudos com a Cloud: Explorando o poder do Azure para aprender na prática!
[](https://www.youtube.com/watch?v=9sH15kycARo)
### Bora se conectar?
Se você quer participar, contribuir ou só ficar por dentro dos próximos eventos da comunidade **Azure Floripa**, se liga aqui:
- **[WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)**
- **[YouTube](https://lnkd.in/dtX9uKEk)**
- **[Visite nosso site](https://lnkd.in/d8vBRFpm)**
Saiba mais: [Global Azure](https://globalazure.net/)
---
# Global Azure 2025 – Azure Floripa (Evento Presencial)
URL: https://www.orafaelferreira.com/artigos/global-azure25pres
Publicado: 2025-05-18
Categoria: Organização de Eventos
Tempo de leitura: 3 min de leitura
> No dia 10 de maio de 2025, rolou a edição presencial do Global Azure 2025 – Edição Azure Floripa em Florianópolis, e que evento, meus amigos!
## Global Azure 2025 – Azure Floripa
No dia **10 de maio de 2025**, rolou a edição **presencial** do [**Global Azure 2025 – Edição Azure Floripa**](https://www.meetup.com/azure-user-groups/events/306207034/?eventOrigin=group_past_events) em **Florianópolis**, e que evento, meus amigos! Recebemos a comunidade na sede da **Neoway**, com uma programação intensa, conteúdo técnico de qualidade e aquele clima de parceria e aprendizado que só quem vive comunidade entende.
Com palestras inspiradoras, demos na prática e muito networking com profissionais incríveis, essa edição mostrou a força da **comunidade Azure em Santa Catarina**.
### 📍 Onde foi?
**Local:** Neoway – R. Patrício Farias, 131 – Itacorubi, Florianópolis - SC
**Data:** Sábado, 10 de maio de 2025
**Formato:** Presencial e gratuito!
### 🗓️ Programação Completa
| Horário | Duração | Atividade |
|-----------------|---------|---------------------------------------------------------------------------|
| 09:00 - 09:15 | 15 min | Abertura do Evento – Vinicius Deschamps / Rafael Ferreira |
| 09:15 - 09:55 | 40 min | Keynote: Trabalhando para o exterior – Vinicius Deschamps / Rafael Ferreira |
| 09:55 - 10:35 | 40 min | Migração de Backups (GRS para LRS) – Thiago Henrique Mattos |
| 10:35 - 10:55 | 20 min | ☕ Pausa da Manhã |
| 10:55 - 11:35 | 40 min | Acesso Seguro Global – Denis Alonso |
| 11:35 - 12:15 | 40 min | Diga adeus à infraestrutura cara! Descubra o poder do OCR serverless na Azure! – Cláudio Filipe Lima Rapôso |
| 12:15 - 13:30 | 1h15 | 🍽 Almoço |
| 13:30 - 14:10 | 40 min | Desenvolvendo uma Aplicação de Chat com RAG usando o Azure AI Foundry – Marcelo Pacífico |
| 14:10 - 14:50 | 40 min | Message Broker com Azure Service Bus – Felipe Pimentel Augusto |
| 14:50 - 15:30 | 40 min | Integração do GitHub Actions com o Azure – Kauã Pozzi |
| 15:30 - 15:55 | 25 min | ☕ Pausa da Tarde |
| 15:55 - 16:45 | 40 min | Protegendo sua arquitetura multi-cloud com o Microsoft Defender for Cloud – Pedro Ignácio | |
| 16:45 - 17:00 | 15 min | Encerramento e Agradecimentos |
### 📸 Quer ver como foi?
Se liga nas fotos e reveja os melhores momentos:
### 👏 Agradecimentos
Um evento como esse não acontece sozinho. Nosso **muito obrigado aos palestrantes, patrocinadores, parceiros**.
Em especial, agradecemos à **[Neoway](https://www.neoway.com.br/)**, que gentilmente cedeu o espaço para o evento, e à **[Softensity](https://www.softensity.com/)**, que apoiou com um coffee break.
E claro, nosso reconhecimento à **comunidade**, que marcou presença em peso e mostrou, mais uma vez, que conhecimento se constrói **junto**.
### 💙 Participe da Comunidade Azure Floripa!
Não deixe a energia acabar aqui. Cola com a gente nas redes, participe dos meetups e fique por dentro dos próximos eventos!
- **[WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)**
- **[YouTube](https://lnkd.in/dtX9uKEk)**
- **[Visite nosso site](https://lnkd.in/d8vBRFpm)**
---
#GlobalAzure #AzureFloripa #MicrosoftAzure #EventoPresencial #ComunidadeTech #AzureBrasil
---
# Pipelines com Azure DevOps: Automatizando o Provisionamento Seguro da sua infraestrutura na nuvem - SQL Saturday 2025 by Comunidado
URL: https://www.orafaelferreira.com/artigos/sqlsat25
Publicado: 2025-04-06
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> Relato da palestra sobre Pipelines com Azure DevOps no SQL Saturday Joinville 2025, com provisionamento seguro de infraestrutura via Terraform e Bicep.
No último sábado, 5 de abril de 2025, tive o imenso prazer de participar como palestrante no [**SQL Saturday Joinville 2025**](https://sqlsaturday.com/2025-04-05-sqlsaturday1104/), realizado na UNIVILLE – Campus Universitário, localizado em Joinville, SC. Este evento presencial, que reuniu cerca de 500 participantes, foi uma excelente oportunidade para mergulhar fundo em temas como tecnologia, dados, inteligência artificial e inovação.
O SQL Saturday é conhecido mundialmente por ser um evento referência para a comunidade de dados, e esta edição em Joinville não deixou nada a desejar. Contou com uma programação rica, oferecendo palestras simultâneas com conteúdos altamente relevantes e ministradas por grandes nomes do mercado brasileiro de tecnologia.
### Sobre Minha Palestra
Na minha palestra intitulada **"Pipelines com Azure DevOps: Automatizando o Provisionamento Seguro da sua Infraestrutura na Nuvem"**, abordei pontos essenciais para implementar pipelines eficientes utilizando Azure DevOps, garantindo agilidade, segurança e qualidade na entrega da infraestrutura.
Conversamos bastante sobre como DevOps deixou de ser uma simples tendência e se tornou uma cultura fundamental nas empresas modernas. Também mostrei na prática o funcionamento das pipelines de Integração Contínua e Entrega Contínua (CI/CD) e como essa automação facilita significativamente o processo de deploy em ambientes cloud, utilizando ferramentas como Terraform para provisionamento de infraestrutura.
Alguns tópicos detalhados que abordei durante a palestra foram:
- **Fundamentos e Cultura DevOps**: Expliquei como o DevOps está transformando as empresas, melhorando significativamente a comunicação, colaboração e produtividade dos times de desenvolvimento e operações.
- **Azure DevOps Overview**: Discuti brevemente sobre a história e as funcionalidades principais do Azure DevOps, destacando as diferenças e vantagens entre Azure DevOps Services (SaaS) e Azure DevOps Server (IaaS).
- **Estruturando Pipelines CI/CD**: Apresentei passo a passo a criação e execução de pipelines usando Azure DevOps, mostrando como é possível automatizar testes, builds e deploys, garantindo entregas rápidas e seguras.
- **Casos Práticos**: Compartilhei exemplos reais e cenários práticos em que utilizei o Azure DevOps com Terraform e Bicep, evidenciando a importância da automação para lidar com infraestruturas complexas.
### Networking e Troca de Experiências
Um grande diferencial de eventos é o networking, e SQL Saturday Joinville não foi diferente.
Quero deixar aqui um agradecimento especial ao Comunidado e a toda equipe organizadora que tornou esse evento possível, proporcionando uma experiência incrível para todos os envolvidos.
Até o próximo evento!
---
---
# Minhas Contribuições para a Tradução do Kubernetes
URL: https://www.orafaelferreira.com/artigos/translatek8s
Publicado: 2025-03-23
Categoria: Artigos
Tempo de leitura: 3 min de leitura
> Como contribuí com a tradução da documentação do Kubernetes para o português brasileiro e por que isso torna a tecnologia mais acessível à comunidade.
## Minhas Contribuições para a Tradução do Kubernetes
Como parte do meu aprendizado e desejo de retribuir à comunidade, decidi participar do projeto de tradução da documentação do Kubernetes para o português brasileiro. Este esforço é importante para tornar a tecnologia mais acessível ao público da língua portuguesa.
### Contribuições Recentes
#### 1. Windows no Kubernetes
- **Issue**:
- **Pull Request**:
- **Página traduzida**:
**Descrição**: Tradução da página de visão geral "Windows no Kubernetes" para o português brasileiro. Esta página oferece uma introdução abrangente sobre o suporte a nós Windows no Kubernetes, incluindo tópicos como rede, armazenamento, gerenciamento de recursos e segurança para nós Windows.
#### 2. Guia para executar contêineres do Windows no Kubernetes
- **Issue**:
- **Pull Request**:
- **Página traduzida**:
**Descrição**: Tradução da página de conceito "Guia para executar contêineres do Windows no Kubernetes" para o português brasileiro. Esta página fornece instruções detalhadas sobre como utilizar contêineres Windows no ambiente Kubernetes, tornando o conteúdo acessível para a comunidade lusófona.
#### 3. Containers Windows no Kubernetes
- **Issue**:
- **Pull Request**:
- **Página traduzida**:
**Descrição**: Tradução da página de conceito "Containers Windows no Kubernetes" para o português brasileiro. Esta página introduz o conceito de contêineres Windows no ecossistema Kubernetes, explicando sua importância e funcionamento básico.
### Importância da Tradução
A tradução da documentação do Kubernetes para o português brasileiro é fundamental por várias razões:
1. **Acessibilidade**: Permite que desenvolvedores e profissionais de TI brasileiros acessem informações cruciais em sua língua nativa.
2. **Adoção**: Facilita a adoção do Kubernetes por empresas e organizações no Brasil.
3. **Comunidade**: Fortalece a comunidade brasileira de Kubernetes, incentivando mais pessoas a contribuírem e participarem.
4. **Educação**: Auxilia no aprendizado e na formação de novos profissionais especializados em Kubernetes.
### Como Contribuir
Se você também deseja contribuir para a tradução do Kubernetes, aqui estão algumas etapas para começar:
1. Familiarize-se com o [processo de contribuição do Kubernetes](https://kubernetes.io/pt-br/docs/contribute/).
2. Junte-se ao canal Slack `#kubernetes-docs-pt` da comunidade Kubernetes.
3. Verifique as [páginas pendentes de tradução](https://kubernetes.io/pt-br/docs/contribute/localization_pt-br/).
4. Escolha uma página para traduzir e crie uma issue no [repositório kubernetes/website](https://github.com/kubernetes/website).
5. Faça um fork do repositório, crie uma branch e realize a tradução.
6. Submeta um Pull Request com sua tradução para revisão.
Contribuir para a tradução do Kubernetes é uma excelente maneira de aprender mais sobre a tecnologia enquanto ajuda a comunidade. Junte-se a nós neste esforço importante!
---
# O que é Azure Policy? Uma Visão Completa
URL: https://www.orafaelferreira.com/artigos/az-policy
Publicado: 2025-01-09
Categoria: Artigos
Tempo de leitura: 9 min de leitura
> O Azure Policy é um recurso da Microsoft Azure que ajuda organizações a implementar governança e compliance de forma automatizada e em larga escala.
O [**Azure Policy**](https://learn.microsoft.com/pt-br/azure/governance/policy/) é um recurso da Microsoft Azure que ajuda organizações a implementar governança e compliance de forma automatizada e em larga escala. Ele garante que os recursos na nuvem estejam em conformidade com as diretrizes corporativas, padrões de segurança e requisitos regulatórios.
Imagine que, toda vez que você vê uma placa — seja no shopping ou no trânsito — ela funciona como uma policy (política). A placa tem a função de te alertar sobre regras e comportamentos esperados. Caso você não siga essas orientações e um segurança perceba a irregularidade, ele pode te abordar, corrigir sua ação ou até mesmo te impedir de continuar no local.
### O que o Azure Policy Faz?
O Azure Policy avalia continuamente os recursos e as ações no Azure com base em **definições de política**. Essas definições, escritas em formato JSON, descrevem regras que determinam se os recursos estão ou não em conformidade com os padrões estabelecidos.
#### Principais Benefícios e Casos de Uso:
- **Conformidade em Larga Escala:** Avalia recursos e toma ações automáticas para garantir conformidade.
- **Automação e Consistência:** Implementa políticas de maneira consistente em todas as suas assinaturas e grupos de recursos.
- **Segurança e Gerenciamento:** Reforça políticas de segurança, como restringir SKUs de VMs, impor criptografia e definir regiões específicas para implantação de recursos.
- **Conformidade Regulatória:** Auxilia no cumprimento de normas como GDPR, ISO 27001 e SOC 2.
### Como o Azure Policy Funciona?
O **Azure Policy** funciona criando e aplicando **definições de política** e **iniciativas** para controlar como os recursos são implantados e gerenciados. Esses componentes incluem:
#### Definições de Política
Uma **definição de política** é uma regra individual que descreve um critério para conformidade, como:
- Permitir a criação de recursos apenas em uma região específica.
- Garantir que todas as VMs utilizem discos criptografados.
Exemplo de definição de política em JSON:
```json
{
"mode": "All",
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "deny"
}
}
}
```
#### Iniciativas
Uma **iniciativa** é uma coleção de múltiplas definições de políticas agrupadas com um propósito comum, como:
- Garantir conformidade regulatória (por exemplo: GDPR, ISO 27001).
- Padronizar a segurança de uma aplicação.
#### Atribuições
Uma **atribuição de política** aplica uma definição ou iniciativa a um escopo específico, como:
- Assinatura Azure.
- Grupo de Recursos.
- Recurso Individual.
#### Efeitos das Políticas
As políticas podem ter diferentes efeitos, como:
- **Deny:** Impede a criação ou modificação de recursos não conformes.
- **Audit:** Apenas registra a não conformidade sem bloquear a ação.
- **Modify:** Faz modificações automáticas nos recursos para garantir conformidade.
- **DeployIfNotExists:** Implanta recursos adicionais para garantir conformidade.
### Imagine a Situação: Ser Bloqueado por uma Política do Azure
Imagine que você está tentando implantar uma nova máquina virtual no Azure para testar uma aplicação. Você escolhe uma região aleatória, digamos **South India**, porque parece conveniente no momento. No entanto, ao tentar concluir a criação da VM, você recebe um erro:
**"A criação de recursos nesta região não está permitida pela política da empresa."**
O que aconteceu? Você foi impedido por uma **Azure Policy** aplicada em sua organização! Essa política foi configurada pelo time de governança de TI para garantir que todos os recursos sejam criados apenas em regiões específicas, como **East US** e **West Europe**, por razões de conformidade e segurança.
#### Frustração? Sim. Mas por uma Boa Razão.
Parece frustrante ser bloqueado quando você só queria testar uma VM, certo? No entanto, o propósito dessa **regra** não é atrapalhar seu trabalho, mas sim proteger o ambiente da empresa e manter padrões consistentes. Veja o porquê:
- ✅ **Conformidade Legal:** Algumas empresas precisam armazenar dados apenas em regiões específicas por leis como a LGPD (Lei Geral de Proteção de Dados).
- ✅ **Otimização de Custos:** Restringir o uso de regiões mais caras pode reduzir significativamente os gastos.
#### Como Resolver?
Se você precisar de uma exceção para essa política, você pode:
1. **Solicitar uma Isenção (Exemption):** Um administrador pode criar uma isenção temporária para um recurso específico.
2. **Testar em um Sandbox:** Se for um teste, você pode pedir acesso a um ambiente separado sem restrições.
3. **Propor uma Revisão da Política:** Se a necessidade for frequente, pode ser o caso de revisar a política e flexibilizar as regiões permitidas.
Essa experiência mostra como o **Azure Policy** ajuda a manter o controle e a segurança, mesmo quando parece um bloqueio.
### Azure Policy vs Azure RBAC (Controle de Acesso Baseado em Função)
Embora ambos estejam relacionados à governança e controle no Azure, eles têm propósitos diferentes:
| Aspecto | Azure Policy | Azure RBAC |
|-----------------------------|-------------------------------------|---------------------------------|
| **Objetivo Principal** | Garantir conformidade de recursos | Controlar permissões de acesso |
| **Escopo de Aplicação** | Regras de conformidade e segurança | Controle de ações de usuários |
| **Exemplo de Uso** | Negar criação de VMs não criptografadas | Restringir quem pode criar VMs |
### Melhores Práticas ao Utilizar Azure Policy
- **Inicie com o Efeito Audit:** Antes de bloquear recursos, use `Audit` para monitorar o impacto das políticas.
- **Use Iniciativas:** Agrupe políticas relacionadas para facilitar a gestão.
- **Automatize com IAC:** Implemente Azure Policy como infraestrutura como código (IAC) para aplicar políticas de forma automatizada em pipelines CI/CD.
- **Exclua Recursos Sensíveis:** Utilize `notScopes` para excluir recursos ou grupos de recursos específicos de políticas rígidas.
### Conclusão
O **Azure Policy** é uma ferramenta essencial para garantir governança e conformidade no Azure. Ele proporciona controle robusto para organizações que buscam proteger seus ambientes de nuvem e manter padrões de segurança e conformidade regulatória.
Implementando boas práticas e monitoramento contínuo, sua organização pode manter um ambiente seguro e alinhado às políticas corporativas.
Ao estudar **Azure Policy** você estará se preparando para as certificações:
- [**Microsoft Certified: Azure Administrator Associate (AZ-104)**](https://learn.microsoft.com/pt-br/credentials/certifications/azure-administrator/?practice-assessment-type=certification)
- [**Microsoft Certified: Azure Security Engineer Associate (AZ-500)**](https://learn.microsoft.com/pt-br/credentials/certifications/azure-security-engineer/?practice-assessment-type=certification)
Nos próximos artigos, irei demonstrar de forma prática projetos que implementei em organizações de nível enterprise.
---
---
# Pipelines com Azure DevOps: Automatizando o (im)possível - Code Island Cloud 2024
URL: https://www.orafaelferreira.com/artigos/code-island24
Publicado: 2024-11-24
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> Palestrei sobre pipelines com Azure DevOps na segunda edição do Code Island Cloud, realizada na Unisul Centro Florianópolis em novembro de 2024.
No último sábado, 23 de novembro de 2024, tive o prazer de participar como palestrante da segunda edição do **Code Island Cloud**, realizado na Unisul – Centro Florianópolis. O evento foi 100% presencial e trouxe à comunidade as últimas novidades em **Cloud**, abrangendo temas de **Dev, Data e DevOps**. Além disso, foi uma grande oportunidade para **networking** com profissionais apaixonados por tecnologia!
O evento contou com uma programação irada, com grandes nomes do cenário tech e proporcionando momentos de aprendizado e troca de experiências. Com minha palestra, **"Pipelines com Azure DevOps: Automatizando o (Im)possível"**, compartilhei insights e práticas para otimizar a automação de fluxos de trabalho em projetos modernos relacionados a Infraestrutura.
### Sobre Minha Palestra
Na minha apresentação, mostrei como utilizar o Azure DevOps para criar pipelines robustas e automatizar processos de deploy de infra. Alguns dos tópicos que discuti incluem:
- **Estruturando Pipelines**: Teorioa de pipelines CI/CD.
- **Automação Inteligente**: Boas práticas de integração de testes, builds e deploys automatizados.
- **Casos Reais**: Exemplos práticos de projetos onde a automação simplificou processos complexos.
### O Evento Como Um Todo
Além da minha palestra, rolou talks sobre **Blockchain**, **Resiliência na AWS**, **Segurança em Nuvem**, **Inteligência Artificial Generativa**, e muito mais.
Destaque também para o networking proporcionado pelo evento. Foi uma grande oportunidade para trocar ideias com os amigos de comunidade e profissionais de tecnoligia, compartilhar experiências valiosas sobre o dia a dia na área.
---
---
# Estratégias de Cloud Foundation em Larga Escala: Garantindo que Você Não Retorne para On-Premise - Tech Connection Floripa 2 Edição 2024
URL: https://www.orafaelferreira.com/artigos/tc-floripa24
Publicado: 2024-11-10
Categoria: Palestras
Tags: Azure
Tempo de leitura: 2 min de leitura
> No dia 9 de novembro de 2024, tive o prazer de palestrar na segunda edição do Tech Connection Florianópolis.
No dia **9 de novembro de 2024**, tive o prazer de palestrar na segunda edição do **[Tech Connection Florianópolis](https://talkfloripa.com.br/)**. Minha palestra, intitulada **“Estratégias de Cloud Foundation em Larga Escala: Garantindo que Você Não Retorne para On-Premise”**, foi uma oportunidade de compartilhar minha experiência e conhecimento com um público engajado e apaixonado por tecnologia.
### O Contexto da Palestra
Migrar para a nuvem é um dos grandes movimentos tecnológicos da atualidade, mas garantir que essa jornada seja sustentável e escalável é um desafio ainda maior. Muitos projetos de adoção de nuvem enfrentam dificuldades ao longo do caminho, seja por falta de planejamento, arquitetura inadequada ou governança insuficiente.
O foco da minha palestra foi exatamente este: como construir uma **Cloud Foundation** robusta, que suporte o crescimento da organização e evite o temido retorno ao ambiente **on-premise** – um movimento custoso e frequentemente sinal de insucesso na jornada para a nuvem.
### Os Pilares de uma Cloud Foundation de Sucesso
Durante a apresentação, abordei alguns pilares para construir uma **Cloud Foundation** sólida, incluindo:
1. **Governança e Políticas de Segurança**
Expliquei como estabelecer políticas claras para gerenciamento de identidades, controle de acessos e compliance, garantindo que a adoção da nuvem atenda aos padrões corporativos e regulatórios.
2. **Automação com Infraestrutura como Código (IaC)**
Destaquei o papel de ferrramentas como **Terraform** como ferramentas indispensáveis para automatizar a criação e manutenção de recursos na nuvem, promovendo consistência e reduzindo erros manuais.
3. **Observabilidade e Monitoramento**
Enfatizei a importância de integrar ferramentas para garantir visibilidade total sobre o ambiente, facilitando a identificação de gargalos e problemas antes que eles impactem o negócio.
4. **Custos e FinOps**
Um ponto essencial foi como implementar boas práticas de **FinOps** para gerenciar e otimizar custos, evitando desperdícios e garantindo o retorno do investimento na nuvem.
5. **Resiliência e Escalabilidade**
Por fim, mostrei como arquitetar soluções que sejam resilientes a falhas e capazes de escalar conforme a demanda.
### O Engajamento do Público
A resposta do público foi extremamente positiva. Desde o início da apresentação, percebi olhares atentos e perguntas surgindo – um reflexo de como o tema ressoou com os desafios enfrentados por muitos profissionais.
Além da palestra, o evento foi uma oportunidade única para criar novas conexões e aprender com outros profissionais incríveis.
Que essa seja apenas mais uma etapa na nossa jornada de aprendizado e evolução tecnológica. Obrigado a todos que participaram. **Até a próxima!** 🚀
---
---
# TFTEC Ao Vivo 2024: Conexão, Conhecimento e Imersão em Cloud
URL: https://www.orafaelferreira.com/artigos/tftec2024
Publicado: 2024-11-04
Categoria: Registro Eventos Presenciais
Tempo de leitura: 7 min de leitura
> Nos dias 26 e 27 de outubro, São Paulo foi palco do evento TFTEC Ao Vivo, uma imersão totalmente única no universo do Azure.
Nos dias 26 e 27 de outubro, São Paulo foi palco do evento [**TFTEC Ao Vivo**](https://www.tftec.com.br/tftecaovivo-2024/), uma imersão totalmente única no universo do Azure. O evento reuniu profissionais e entusiastas de tecnologia de todo o Brasil para um aprendizado prático e aprofundado, com um dia cheio de "mão na massa" e interações em tempo real com especialistas. Foram mais de 16 horas de conteúdo intensivo, distribuídas em dois dias, proporcionando uma experiência completa e exclusiva aos participantes.
Além do aprendizado técnico, o evento ofereceu diversas oportunidades de **networking**, permitindo conhecer a comunidade técnica além das fotinhas do Youtube e Linkedin HAHA. Houve também um happy hour para os participantes onde trocamos experiências e demos várias risadas.
#### Benefícios oferecidos aos participantes:
- Acesso completo aos dois dias de evento.
- Brindes exclusivos.
- Coffee breaks e almoço.
- Acesso às gravações por 2 anos.
- Certificado de participação impresso.
Os alunos do [**TFTEC Prime**](https://www.tftec.com.br/) que participaram do evento receberam vantagens especiais, como renovação gratuita ou descontos para eventos futuros.
### Arquitetura da Solução Azure do TFTEC Cloud
Um dos grandes destaques do evento foi a apresentação de uma **arquitetura robusta e moderna** para aplicações no Azure, projetada para alta escalabilidade e segurança. Esse exemplo prático foi essencial para que os participantes compreendessem como construir soluções complexas na plataforma. Irei explorar os principais componentes dessa arquitetura.
#### Visão Geral da Arquitetura
A arquitetura integra diversos serviços do Azure, organizados para oferecer uma infraestrutura segura, escalável e fácil de manter para aplicações corporativas. Os principais elementos são:
- **Segurança e Autenticação**: Uso do Azure Active Directory (Entra ID) e Azure AD B2C, para autenticação e autorização para usuários internos e externos. O App Registration facilita o gerenciamento de permissões e registros de aplicações.
- **Application Gateway (App GW) e API Management (APIM)**: O App Gateway protege e gerencia o tráfego de entrada para as aplicações, enquanto o APIM centraliza a gestão de APIs, garantindo roteamento seguro e controle de acesso.
- **Monitoramento e Análise**: Com o Azure Application Insights e Log Analytics, a arquitetura oferece visibilidade dos logs e desempenho. Isso facilita o monitoramento em tempo real.
- **Serviços Backend e Banco de Dados**: No backend, as APIs centralizam a lógica de negócios, incluindo sistemas de CRM e outros serviços essenciais. Essas APIs se conectam ao Azure SQL Database para armazenamento com alta disponibilidade e integridade dos dados.
- **Serviços Integrados do Azure**: A arquitetura também utiliza serviços como Storage Account para armazenamento de arquivos, Key Vault para gerenciamento seguro de Secrets, Azure Functions para execução de tarefas sob demanda, Logic Apps para automação de fluxos de trabalho e DNS Zone.
- **Azure DevOps**: Com o Azure Repos para controle de versão do código, Azure Pipelines para automação CI/CD, e Terraform para definição de infraestrutura como código (IaC).
- **Azure Container Registry (ACR)**: Permite fácil integração com o Kubernetes e outros serviços, facilitando o deploy seguro e contínuo das aplicações.
### Terraform e Kubernetes
##### Provisionamento de Infraestrutura com Terraform:
- **Infraestrutura como Código (IaC)**: O Terraform é utilizado para gerenciar a infraestrutura como código, permitindo que toda a configuração seja descrita em arquivos, facilitando a reutilização e o versionamento.
- **Configuração e Versionamento**: Geralmente profissionais de DevOps configuram o código Terraform para a infraestrutura, que é versionado no Azure Repos e gerenciado por pipelines, garantindo consistência e segurança nos deploys.
##### Pipeline de Build e Deploy:
- **Construção e Armazenamento de Imagens**: Com o código da infraestrutura no Azure Repos, o pipeline é ativado para construir e enviar as imagens de contêiner para o Azure Container Registry (ACR).
- **Testes e Validações**: O pipeline automatizado executa testes e validações antes de enviar a imagem, garantindo que o build esteja em conformidade com as políticas de qualidade da equipe.
##### Gerenciamento de Estado com Backend Remoto:
- **Armazenamento Seguro de Estado**: O estado do Terraform, armazenado no arquivo `tfstate`, é mantido em um backend remoto, utilizando Azure Key Vault e Storage Account para garantir segurança e facilitar a colaboração.
##### Azure Kubernetes Service (AKS):
- **Orquestração de Contêineres**: O AKS gerencia os contêineres, consumindo as imagens armazenadas no ACR e distribuindo as cargas de trabalho conforme necessário, mantendo a disponibilidade e performance das aplicações.
##### Monitoramento e Análise:
- **Visibilidade e Monitoramento Contínuo**: Log Analytics e Application Insights oferecem uma visão em tempo real dos logs e dados de desempenho, facilitando a análise e resolução proativa de problemas.
### Descrição do Pipeline de CI/CD com Terraform
1. **Desenvolvimento**
- **Codificação**: O desenvolvedor escreve o código da infraestrutura usando Terraform.
- **Pull Request (PR)**: Após finalizar, cria um PR no Azure Repos, enviando as mudanças.
2. **Pipeline de Integração Contínua (CI)**
- **Validações Automatizadas**:
- `terraform init`: Inicializa o Terraform.
- `terraform fmt`: Formata o código conforme os padrões.
- `terraform validate`: Valida a sintaxe e a integridade do código.
- `checkov`: Verifica a segurança do código.
- `tflint`: Executa linting para identificar possíveis erros e padrões não recomendados.
- `terraform plan`: Gera um plano de execução mostrando as mudanças que serão aplicadas.
- **Infracost**: Calcula o custo estimado das alterações e adiciona um comentário no PR com a previsão de custos, auxiliando na avaliação do impacto financeiro.
3. **Verificação e Revisão**
- **Correção de Erros**: Se o pipeline CI falhar, o desenvolvedor revisa e corrige o código.
- **Revisão do PR**: Com o CI aprovado, o PR é revisado pela equipe.
- **Aprovação**: Se aprovado, o pipeline de CD é iniciado.
4. **Pipeline de Entrega Contínua (CD)**
- `terraform init`: Reexecuta a inicialização para o ambiente de produção.
- `terraform apply`: Aplica as mudanças no ambiente real, atualizando a infraestrutura conforme o plano.
5. **Validação Final**
- **Verificação do Ambiente**: A equipe valida se tudo está conforme o esperado no ambiente de produção.
Esse fluxo garante que as mudanças na infraestrutura sejam aplicadas de forma controlada e segura, com verificações de qualidade, segurança e custo antes de qualquer alteração no ambiente produtivo. O uso de ferramentas como Terraform e Infracost permite automação e transparência, contribuindo para um gerenciamento eficiente da infraestrutura em nuvem.
### Arquitetura de CI/CD com Azure DevOps para Deploy no Azure Kubernetes Service (AKS)
O diagrama a seguir ilustra um pipeline de CI/CD configurado no Azure DevOps, integrando o Azure Kubernetes Service (AKS) para orquestração de contêineres. Esse pipeline automatiza o processo de build, packaging, armazenamento e deploy de uma aplicação em contêiner no AKS.
1. **Código Fonte**
- **Desenvolvedor**: Cria e edita o código da aplicação.
- **Azure Repos**: O código é versionado e armazenado no Azure Repos.
- **Trigger de CI**: O pipeline de Integração Contínua inicia automaticamente após o push.
2. **Build**
- **Azure Pipelines Build**: Constrói a aplicação e prepara o contêiner.
- **Docker**: O código é empacotado em uma imagem Docker.
- **Helm**: Um chart Helm é gerado para definir e configurar o deploy no Kubernetes.
- **Azure Container Registry (ACR)**: A imagem Docker é armazenada no ACR.
- **Trigger de CD**: Um trigger de Entrega Contínua é acionado quando uma nova imagem é enviada ao ACR.
3. **Deploy**
- **Azure Pipelines Deploy**: Aplica o chart Helm e realiza o deploy da imagem no cluster AKS.
4. **Ambiente**
- **Azure Kubernetes Service (AKS)**: Ambiente final de execução da aplicação, onde o Kubernetes orquestra e gerencia os contêineres em um cluster escalável.
Esse fluxo automatizado facilita a integração e o deploy contínuos, assegurando que cada alteração no código seja construída, validada e implantada de maneira consistente. A integração com Docker e Helm permite uma configuração flexível e reproduzível para a implantação de contêineres no AKS.
### Conclusão
O **TFTEC Ao Vivo** foi um evento incrível, proporcionando uma oportunidade única de rever amigos, fortalecer o networking e aprender mais sobre o universo Azure. Durante dois dias imersivos, profissionais de todo o Brasil puderam se aprofundar em tecnologias de ponta, participar de sessões práticas e interagir diretamente com especialistas da área. Além do aprendizado técnico, o ambiente amigável e colaborativo criou um espaço valioso para trocas de experiências e conexões duradouras, reafirmando a importância da comunidade Azure no desenvolvimento de novas competências e na inovação contínua. Estamos ansiosos para o próximo encontro e para continuar crescendo juntos na jornada rumo à nuvem!
Caso queira visitar o repositório oficial do projeto, segue os links:
[tftecsp2024](https://github.com/raphasi/tftecsp2024?tab=readme-ov-file)
[-tftec-aovivo-iac](https://github.com/raphasi/-tftec-aovivo-iac/tree/main)
---
---
# Architecting a Secure Landing Zone for AI Workloads in the Cloud - MVP TALKS CI&T 2024
URL: https://www.orafaelferreira.com/artigos/mvp-day
Publicado: 2024-11-02
Categoria: Organização de Eventos
Tags: IA
Tempo de leitura: 3 min de leitura
> Relato do primeiro CI&T MVP Day em Campinas: palestra sobre landing zone segura para workloads de IA, sessões de outros MVPs e painel sobre ser Microsoft MVP.
No último dia 24 de outubro, organizamos o primeiro CI&T MVP Day — um evento interno, exclusivo para funcionários da CI&T, realizado na nossa sede global tech em Campinas. Este evento marcante reuniu palestras sobre segurança, nuvem e inteligência artificial, além de proporcionar momentos de troca e inspiração entre profissionais apaixonados por tecnologia. Com nomes de peso como **[Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)**, **[Márcio Rogério Nizzola](https://www.linkedin.com/in/nizzola/)** e **[Cláudio Raposo](https://www.linkedin.com/in/cfraposo/)**, exploramos temas que estão moldando o presente e o futuro da tecnologia.
> 💬 "Posso dizer! CI&T MVP Day foi o pipoco do trovão azul celestial!" — *Cláudio Raposo, Software Architect e MVP Microsoft*
### O que Rolou no CI&T MVP Day:
#### 🔹 Architecting a Secure Landing Zone for AI Workloads in the Cloud
**Palestrante:** Rafael Martin Alves Ferreira
Apresentei um guia prático para a criação de uma Landing Zone segura para workloads de IA na nuvem. Destaquei como as Landing Zones, fundamentadas nos frameworks **Cloud Adoption Framework (CAF)** e **Well-Architected Framework (WAF)**, são essenciais para escalar e proteger workloads de IA.
- **Slides da Apresentação:** [Architecting a Secure Landing Zone for AI Workloads in the Cloud](https://stoblobcertificados011.blob.core.windows.net/palestras/CIT.pdf)
#### 🔹 Desenvolvimento de Function Apps Seguros com Managed Identity e Service Connector
**Palestrante:** [Cláudio Raposo](https://www.linkedin.com/in/cfraposo/)
Cláudio abordou um dos grandes desafios do desenvolvimento serverless: segurança no gerenciamento de credenciais. Ele demonstrou como o uso de **Managed Identity** e **Service Connector** no Azure elimina a necessidade de armazenar senhas no código, reforçando a segurança de aplicações na nuvem. Essa sessão foi essencial para quem busca criar soluções na nuvem mais seguras e eficientes.
#### 🔹 Utilizando Azure OpenAI para Reconhecimento e Interpretação de Documentos
**Palestrante:** [Márcio Rogério Nizzola](https://www.linkedin.com/in/nizzola/)
Márcio compartilhou suas experiências com o **Azure OpenAI**, **Document Intelligence** e **Form Recognizer**. Ele demonstrou, com exemplos práticos, como essas ferramentas estão transformando o reconhecimento e a interpretação de documentos, abrindo novas oportunidades para a automação de processos e gestão de informações empresariais.
### Inspirando a Próxima Geração de MVPs
O evento foi encerrado com um painel inspirador: **"O que preciso para ser um Microsoft MVP?"**. Cada palestrante compartilhou suas trajetórias e experiências, ressaltando que o título de MVP vai além de um reconhecimento técnico — representa um compromisso com a tecnologia e com a comunidade.
### Conclusão: Um Dia para Guardar na Memória
O CI&T MVP Day foi uma oportunidade de aprendizado transformador e troca de conhecimentos. Agradeço a todos que participaram e contribuíram para tornar esse dia memorável. Se você não pôde estar presente, fique atento aos próximos eventos e conteúdos que estamos preparando!
Para todos que compartilham a paixão por tecnologia e inovação, reforçamos nosso compromisso com a comunidade. Vamos juntos em direção ao futuro, onde conhecimento, colaboração e segurança na nuvem serão mais importantes do que nunca.
---
---
# Deploy de um Futuro com Sustentabilidade: GreenOps na Cloud - #27 Cloud Native São Paulo - Sustainability Day na AWS 2024
URL: https://www.orafaelferreira.com/artigos/sustentability-day
Publicado: 2024-10-31
Categoria: Palestras
Tempo de leitura: 5 min de leitura
> Resumo do Sustainability Day 2024 no AWS Startup Loft em São Paulo: palestras sobre GreenOps na Cloud, Backstage, Karpenter e KEDA com o Cloud Native São Paulo.
No último dia 22 de outubro, o **[CNCF - Cloud Native São Paulo 🇧🇷](https://www.linkedin.com/company/cloud-native-sao-paulo/posts/?feedView=all)**, em parceria com a **[Amazon Web Services (AWS)](https://www.linkedin.com/company/amazon-web-services/)** e a **[Cloud Native Computing Foundation (CNCF)](https://www.linkedin.com/company/cloud-native-computing-foundation/posts/?feedView=all)**, organizou o aguardado evento "Sustainability Day" no AWS Startup Loft em São Paulo. Com um foco especial na sustentabilidade nas operações de TI, o meetup reuniu especialistas, desenvolvedores e entusiastas da tecnologia para discutir estratégias inovadoras que equilibram eficiência e responsabilidade ambiental na nuvem.
Se você não pôde comparecer, este post traz um resumo completo com os principais insights sobre práticas sustentáveis que prometem revolucionar a tecnologia e sua aplicação na nuvem. Confira como o **GreenOps** está impactando a infraestrutura e veja como você pode começar a implementar essas práticas para um futuro mais verde e eficiente.
#### 🌍 A Importância da Sustentabilidade na Nuvem
A tecnologia, com seu crescimento acelerado, trouxe uma nova demanda por infraestrutura na nuvem, aumentando o consumo de energia e os custos operacionais. Agora, o desafio é claro: como equilibrar eficiência e inovação sem comprometer o meio ambiente? Esse tema foi o ponto de partida do evento, abordando como ferramentas e práticas inovadoras podem otimizar o consumo de recursos e reduzir a pegada de carbono na nuvem.
#### 💡 Palestras e Insights Inspiradores
##### 1. Deploy de um Futuro com Sustentabilidade: GreenOps na Cloud
**Palestrante:** [Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)
**Resumo:** Compartilhei como o GreenOps pode ser incorporado ao dia a dia das operações na nuvem, permitindo que empresas façam deploys de forma mais sustentável. Discuti práticas e frameworks que empresas líderes têm utilizado para minimizar o impacto ambiental, enquanto aumentam a eficiência dos sistemas. Foram apresentados **cases reais** e **exemplos práticos** que mostram como a sustentabilidade e a inovação podem caminhar lado a lado.
- **Slides da Apresentação:** [Deploy de um Futuro com Sustentabilidade: GreenOps na Cloud](https://stoblobcertificados011.blob.core.windows.net/palestras/cncn-sp.pdf)
##### 2. Otimizando DevEx e Sustentabilidade: Como o Backstage Transforma Infraestruturas com GreenOps
**Palestrante:** [Cláudio Filipe Lima Rapôso](https://www.linkedin.com/in/cfraposo/)
**Resumo:** Cláudio explorou como o **Backstage**, plataforma de experiência do desenvolvedor (DevEx), pode facilitar a integração de GreenOps na infraestrutura de TI. Ele demonstrou como a experiência do desenvolvedor pode ser aprimorada ao automatizar pipelines sustentáveis e reduzir custos operacionais. **Casos de uso** mostraram a força do Backstage para uma infraestrutura sustentável e centrada no desenvolvedor.
##### 3. Escalonamento Eficiente e Sustentável no Kubernetes: Como Karpenter e KEDA Fazem a Diferença
**Palestrantes:** [Pedro Oliveira](https://www.linkedin.com/in/pedrohco1/) & [Tiago Reichert](https://www.linkedin.com/in/tiago-reichert/)
**Resumo:** Pedro e Tiago discutiram a importância do gerenciamento de recursos para a sustentabilidade e otimização de custos no Kubernetes. Utilizando **Karpenter para escalonamento automático** e **Amazon Graviton para economizar até 60% de energia**, eles mostraram como essas soluções são eficientes para atender à demanda e, ao mesmo tempo, reduzir o desperdício de recursos.
#### 🔥 Como Participar desse Movimento
Mesmo que você não tenha participado do meetup, ainda é possível adotar as práticas discutidas e fazer parte dessa revolução na nuvem:
- **Estude mais sobre GreenOps:** Entenda como aplicar práticas sustentáveis nas operações em nuvem e descubra as ferramentas que auxiliam no monitoramento e otimização do consumo energético. Para um entendimento aprofundado, confira o [artigo sobre Green Computing Foundation e sustentabilidade na nuvem](https://www.orafaelferreira.com/artigos/finops-foundation-cloud) no blog!
- **Experimente soluções como Backstage, Karpenter e KEDA:** Essas ferramentas já fazem a diferença em muitas empresas e podem ser incorporadas facilmente ao seu ambiente para criar uma infraestrutura mais sustentável.
- **Conecte-se com a comunidade Cloud Native:** Os organizadores e palestrantes do [CNCF Cloud Native São Paulo 🇧🇷](https://www.linkedin.com/company/cloud-native-sao-paulo/posts/?feedView=all) são grandes influenciadores neste campo. Acompanhe-os e aprenda como eles aplicam conceitos de sustentabilidade em projetos de alta escala.
- **Participe de futuros meetups:** O movimento está apenas começando! Esses encontros proporcionam aprendizado contínuo e networking com profissionais que estão liderando a transformação sustentável na tecnologia.
#### 🌱 Conclusão: Sua Jornada Rumo à Sustentabilidade Começa Agora!
A sustentabilidade já não é uma escolha opcional, é uma necessidade. Com as práticas e ferramentas apresentadas, você pode começar a fazer a diferença, implementando GreenOps em seu ambiente e otimizando o uso de recursos. **Pequenas mudanças podem gerar um grande impacto**, mostrando que sua empresa está comprometida com um futuro mais sustentável e eficiente.
Então, prepare-se! Fique atento aos próximos eventos do [CNCF Cloud Native São Paulo 🇧🇷](https://www.linkedin.com/company/cloud-native-sao-paulo/posts/?feedView=all) e venha descobrir como pequenas mudanças na infraestrutura podem trazer benefícios duradouros para o seu negócio e para o meio ambiente. Vamos juntos transformar a tecnologia em uma força para um futuro verde!
[](https://www.credly.com/badges/a6940f87-b34a-497e-8c1e-93545075c0ee/public_url "Speaker - Cloud Native Sustainability Week 2024")
#### Encerramento
Seguimos com um animado happy hour, proporcionando uma excelente oportunidade para networking e risadas. Um ambiente descontraído e divertido, permitindo uma troca de ideias mais informal e a formação de novas conexões profissionais. E para quem se perguntou da qualidade das fotos, sim, é isso, tivemos um fotógrafo profissional ([Erivaldo Lopes](https://www.linkedin.com/in/erivaldolopes/))!
Quer participar como palestrante em um próximo meetup?
https://lnkd.in/ddvBG7hM
Caso queira conferir todas as fotos, segue o [link](https://lightroom.adobe.com/shares/7f7588265265451f9f986f379c64bd13).
Se você não teve a oportunidade de comparecer a este evento, não se preocupe, você pode conferir a gravação no YouTube:
[](https://www.youtube.com/watch?v=mIgEJseOt0U&t)
---
# Automatizando Infraestrutura Moderna com Metodologias Ágeis
URL: https://www.orafaelferreira.com/artigos/agil
Publicado: 2024-10-29
Categoria: Artigos
Tempo de leitura: 3 min de leitura
> Como metodologias ágeis apoiam a automação de infraestrutura moderna em DevOps, com Scrum, ciclo de vida do projeto ágil e exemplos práticos.
No mundo altamente competitivo em todas as áreas (iremos focar na tecnologia), a agilidade tornou-se uma característica indispensável, especialmente para profissionais de DevOps (assim como eu). A implementação de metodologias ágeis, como o Scrum, transformou a maneira como projetos de infraestrutura são gerenciados e executados. Com o uso de ferramentas modernas como Terraform, Ansible, Puppet, ferramentas de Infraestrutura como Código (IaC), Azure DevOps, GitHub Actions e players de nuvem Azure e AWS, as equipes podem provisionar e migrar aplicativos de maneira eficiente e adaptável.
### Metodologias Ágeis em DevOps
As metodologias ágeis promovem uma abordagem iterativa e incremental, permitindo que as equipes respondam rapidamente às mudanças e entreguem valor continuamente. Em DevOps, isso se traduz em uma colaboração mais eficaz entre equipes de desenvolvimento e operações, facilitando a integração contínua e a entrega contínua (CI/CD).
**Componentes Chave do Scrum:**
- **Papéis:** Product Owner, ScrumMaster e Equipe de Desenvolvimento.
- **Ritos:** Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
- **Artefatos:** Product Backlog, Sprint Backlog e Incremento.
Essa estrutura ajuda a garantir que todos os membros da equipe estejam alinhados e trabalhando de forma coesa para alcançar os objetivos do projeto.
### Provisionamento Ágil de Infraestrutura
O provisionamento ágil de infraestrutura é essencial para suportar a migração de aplicativos de forma segura e veloz, garantindo que o provisionamento seja executado de maneira eficiente. Utilizando IaC, as equipes podem definir, provisionar e gerenciar.
**Benefícios do Terraform e IaC:**
- **Consistência:** Garantia de que a infraestrutura seja provisionada de maneira idêntica em diferentes ambientes.
- **Automação:** Redução de erros humanos e aumento da eficiência operacional.
- **Versão de Controle:** Capacidade de rastrear mudanças na infraestrutura ao longo do tempo.
### Ciclo de Vida do Projeto Ágil
1. **Planejamento Inicial:** No Sprint Planning, a equipe define as necessidades de infraestrutura e divide o trabalho em histórias claras e gerenciáveis.
2. **Desenvolvimento Iterativo:** Durante os Sprints, a equipe trabalha em ciclos curtos, entregando incrementos de infraestrutura provisionada, testada e validada.
3. **Feedback Contínuo:** O Sprint Review permite que o PO e outros stakeholders forneçam feedback imediato, garantindo que a infraestrutura atenda às expectativas.
4. **Adaptação e Melhoria Contínua:** A Sprint Retrospective ajuda a equipe a identificar áreas de melhoria, ajustando processos e práticas para futuros Sprints.
### Casos de Uso e Exemplos Práticos
Um exemplo prático da aplicação dessas metodologias pode ser visto em uma equipe DevOps responsável por migrar uma aplicação crítica para a nuvem Azure. Utilizando Scrum, Terraform e GitHub Actions, a equipe pode definir e automatizar a infraestrutura necessária, garantindo que cada parte do sistema esteja funcionando corretamente antes de avançar.
**Exemplo de Histórias de Usuário:**
- "Como administrador de sistema, quero provisionar servidores no Azure para garantir a migração contínua do aplicativo."
- "Como desenvolvedor, quero configurar pipelines CI/CD com GitHub Actions para automatizar testes e implementações."
### Conclusão
A integração de metodologias ágeis com ferramentas modernas como Terraform, GitHub Actions e Azure transforma a maneira como os profissionais de DevOps gerenciam projetos de provisionamento de infraestrutura. A abordagem ágil permite que as equipes naveguem pelas complexidades do provisionamento de infraestrutura com confiança, mantendo a flexibilidade necessária para adaptar-se às mudanças e garantindo a entrega contínua de valor. Em um ambiente de TI em constante evolução, a agilidade, juntamente com a automação e a colaboração, é a chave para o sucesso sustentado.
---
# Prepare-se para a Transição Obrigatória do TLS 1.2 no Azure
URL: https://www.orafaelferreira.com/artigos/tls
Publicado: 2024-10-08
Categoria: Artigos
Tempo de leitura: 9 min de leitura
> Em outubro de 2024 a Microsoft encerra o suporte ao TLS 1.0 e 1.1 em todos os serviços Azure: entenda o impacto e como preparar suas aplicações para o TLS 1.2.
Em outubro de 2024, a Microsoft encerrará o suporte para as versões mais antigas do TLS (Transport Layer Security), especificamente TLS 1.0 e 1.1, em todos os serviços Azure. A partir de 31 de outubro de 2024, todas as interações com serviços do Azure deverão ser feitas via TLS 1.2 ou superior. Essa mudança é parte de um esforço contínuo para garantir segurança e criptografia avançadas nos dados e interações envolvendo os serviços da plataforma.
Se você ainda utiliza versões anteriores do TLS em seus recursos, essa mudança poderá impactar diretamente sua operação, resultando em possíveis interrupções de serviço caso a transição não seja feita a tempo.
Caso queira saber mais do [anúncio](https://learn.microsoft.com/pt-br/lifecycle/announcements/transport-layer-security-1x-disablement)
### O que é TLS e por que é importante?
TLS (Transport Layer Security) é um protocolo de criptografia que visa proteger a comunicação entre dois sistemas, como navegadores e servidores ou servidores entre si, garantindo a privacidade e a integridade dos dados. Ele é o sucessor do SSL (Secure Sockets Layer) e tem sido amplamente adotado em diversas camadas de aplicação, especialmente em ambientes de nuvem e serviços web.
A importância de usar o TLS 1.2 ou superior se resume a três pontos principais:
1. **Segurança Aprimorada**: As versões mais antigas do TLS (1.0 e 1.1) não oferecem os mesmos níveis de proteção que o TLS 1.2 ou 1.3. Vulnerabilidades conhecidas nessas versões podem ser exploradas, tornando-as menos seguras para proteger dados sensíveis.
2. **Sigilo em Frente Perfeita (Perfect Forward Secrecy)**: Uma das melhorias trazidas pelas versões mais recentes do TLS é o conceito de "sigilo em frente perfeita". Isso significa que, mesmo que uma chave de sessão seja comprometida, as sessões passadas não podem ser descriptografadas, garantindo maior segurança a longo prazo.
3. **Conjuntos de Cifras Mais Fortes**: TLS 1.2 oferece suporte para conjuntos de cifras mais fortes, protegendo contra ataques criptográficos que podem ser eficazes contra cifras mais antigas usadas em TLS 1.0 e 1.1.
### Impacto da Mudança em Ambientes Azure
Em termos práticos, isso significa que qualquer recurso que interaja com os serviços do Azure—como appliances de rede, gateways de aplicação ou scripts automatizados que utilizam APIs do Azure—precisará estar preparado para utilizar TLS 1.2 ou superior até a data limite.
Uma área que pode não ser diretamente afetada por essa mudança são os recursos internos de clusters, como em clusters Kubernetes que usam comunicações internas que não envolvem APIs externas do Azure. Nesses casos, as mudanças no protocolo TLS podem não ser aplicáveis, pois o foco da atualização está nos serviços que fazem interface diretamente com as APIs do Azure.
### Ações Recomendadas
1. **Verifique a Compatibilidade de TLS 1.2**: Confirme que seus sistemas, servidores e recursos que interagem com o Azure estão configurados para usar TLS 1.2 ou superior. Isso inclui revisar gateways de aplicação (como o Azure Application Gateway), appliances de rede e quaisquer outros pontos que possam utilizar versões legadas do TLS.
2. **Atualize ou Migre**: Caso seus recursos ainda dependam de TLS 1.0 ou 1.1, é fundamental fazer a transição para o TLS 1.2 ou superior antes de 31 de outubro de 2024. Esse processo pode envolver atualizações de software ou reconfigurações em appliances de rede e servidores.
3. **Teste suas Aplicações e Infraestrutura**: Além de confirmar que os recursos suportam TLS 1.2, é importante testar suas aplicações e infraestrutura para garantir que elas continuarão funcionando corretamente após a migração.
### Como Verificar se Seus Recursos Estão Usando TLS Inferior a 1.2
Se você possui recursos no Azure que interagem com serviços da Microsoft, é fundamental verificar se eles estão configurados para usar TLS 1.2. Abaixo, segue um resumo de como identificar a versão de TLS em uso para alguns dos principais recursos do Azure.
[Referência](https://jamescook.dev/azure-tls-end-of-support-2024#heading-storage-accounts)
#### 1. Storage Accounts
Para verificar a versão mínima de TLS em Storage Accounts:
- Acesse a conta de armazenamento no portal do Azure.
- No menu lateral, selecione **Configurações**.
- Localize a seção **Versão mínima de TLS**.
#### 2. Web Apps
Para verificar em Web Apps:
- Selecione o recurso de Web App.
- Vá até **Configurações** e, em seguida, selecione **Configurações gerais**.
- Procure por **Versão mínima de TLS de entrada**.
#### 3. SQL Managed Instance
Para verificar em SQL Managed Instance:
- Selecione o recurso SQL Managed Instance.
- Acesse **Configurações** > **Rede**.
- Localize a **Versão mínima de TLS**.
#### 4. Azure Database for PostgreSQL
Para verificar em Azure Database for PostgreSQL:
- Selecione o recurso Azure Database for PostgreSQL.
- Acesse **Segurança de conexão** no menu lateral.
- Localize a **Versão mínima de TLS**.
#### 5. Azure Cosmos DB
Para verificar em Azure Cosmos DB:
- Acesse o recurso Azure Cosmos DB.
- No menu lateral, selecione **Rede** > **Conectividade**.
- Verifique o campo **Protocolo de Segurança de Camada de Transporte Mínimo**.
#### 6. Function Apps
Para verificar em Function Apps:
- Selecione o recurso Function App.
- Vá até **Configurações** e depois para **Configurações Gerais**.
- Localize **Versão mínima de TLS de entrada**.
### Considerações Importantes
Antes de migrar para TLS 1.2 ou superior, é importante considerar os seguintes pontos:
- **Conectividade**: Verifique a compatibilidade dos sistemas que utilizam o recurso. Alguns clientes ou sistemas legados podem não suportar TLS 1.2.
- **Testes em Ambientes Controlados**: Realize testes em ambientes de desenvolvimento ou teste para garantir que a migração para TLS 1.2 não causará impactos inesperados.
- **Compatibilidade com Software Antigo**: Alguns softwares ou sistemas legados podem não suportar TLS 1.2, exigindo atualizações ou reconfigurações adicionais.
- **Configurações Personalizadas de TLS**: Verifique se há configurações personalizadas de TLS nos seus recursos que possam precisar de ajustes.
### Como Verificar o ambiente no Azure em massa
Se você gerencia vários recursos no Azure, pode ser demorado verificar a versão de TLS manualmente em cada um deles. No entanto, utilizando ferramentas como o **Azure Resource Graph** e o **Log Analytics**, você pode executar consultas que facilitam esse processo.
#### O que é o Azure Resource Graph?
O [Azure Resource Graph](https://learn.microsoft.com/pt-br/azure/governance/resource-graph/overview) é uma ferramenta poderosa para realizar consultas sobre seus recursos no Azure, permitindo que você execute pesquisas eficientes e rápidas em todos os recursos distribuídos em diferentes assinaturas. Ele facilita a visualização de metadados, como o tipo de recurso, a localização e, neste caso, a versão mínima de TLS em uso.
Com o Azure Resource Graph, você pode fazer consultas que identificam rapidamente quais recursos ainda estão utilizando TLS 1.0 ou 1.1 e precisam ser atualizados. Isso pode ser aplicado em diversos serviços do Azure, como Application Gateways, App Services, Storage Accounts, SQL Servers, Key Vaults, entre outros.
#### Exemplo de Consultas
##### Verificar Todos os Recursos com Versões de TLS Abaixo de 1.2
Esta consulta identifica diferentes tipos de recursos e verifica se eles estão utilizando versões antigas de TLS:
```bash
resources
| where type in (
"microsoft.keyvault/vaults",
"microsoft.storage/storageaccounts",
"microsoft.web/sites",
"microsoft.sql/servers",
"microsoft.network/applicationgateways",
"microsoft.apimanagement/service",
"microsoft.containerregistry/registries",
"microsoft.cdn/profiles"
)
| extend minTlsVersion = case(
type == "microsoft.keyvault/vaults", properties.properties.minimumTlsVersion,
type == "microsoft.storage/storageaccounts", properties.minimumTlsVersion,
type == "microsoft.web/sites", properties.siteConfig.minTlsVersion,
type == "microsoft.sql/servers", properties.minimalTlsVersion,
type == "microsoft.network/applicationgateways", properties.sslPolicy.minProtocolVersion,
type == "microsoft.apimanagement/service", properties.customProperties["Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls10"],
type == "microsoft.containerregistry/registries", properties.policies.trust.minTlsVersion,
type == "microsoft.cdn/profiles", properties.deliveryPolicy.minTlsVersion,
"Unknown"
)
| where isnotempty(minTlsVersion) and minTlsVersion != "Unknown" and minTlsVersion !contains "1.2"
| project name, type, resourceGroup, subscriptionId, minTlsVersion
| sort by type, name
```
##### Verificação em Contas de Armazenamento
```bash
resources
| where type == "microsoft.storage/storageaccounts"
| extend minTlsVersion = properties.minimumTlsVersion
| where isnotempty(minTlsVersion) and minTlsVersion !contains "1.2"
| project name, resourceGroup, subscriptionId, minTlsVersion
```
##### Verificação em Web Apps
```bash
AppServiceResources
| where type =~ 'microsoft.web/sites/config'
| project id, name, minTlsVersion = properties.MinTlsVersion
| where isnotempty(minTlsVersion)
```
##### Verificação em Azure Cosmos DB
```bash
resources
| where type == "microsoft.documentdb/databaseAccounts"
| extend minTlsVersion = properties.minimalTlsVersion
| where isnotempty(minTlsVersion) and minTlsVersion !contains "1.2"
| project name, resourceGroup, subscriptionId, minTlsVersion
```
Essas consultas podem ser adaptadas para incluir outros tipos de recursos e ajudar a garantir que toda a sua infraestrutura do Azure esteja em conformidade com os novos requisitos de segurança.
### Utilizando o Azure Monitor para Monitorar Versões TLS
Além do Azure Resource Graph, o Azure Monitor pode ser utilizado para monitorar as versões de TLS em uso em tempo real.
#### Monitoramento de TLS com Azure Monitor
Para garantir que seus recursos estejam usando TLS 1.2 ou superior, você pode utilizar as consultas de logs e métricas disponíveis no Azure Monitor e no Log Analytics. O monitoramento da versão do TLS em uso é crucial, especialmente considerando a proximidade da descontinuação de versões mais antigas como o TLS 1.0 e 1.1.
[Referência](https://learn.microsoft.com/en-us/azure/key-vault/general/monitor-key-vault#sample-kusto-queries)
#### Identificar Clientes Usando TLS Inferior a 1.2
Essa consulta mostra requisições ao Key Vault feitas com uma versão de TLS inferior a 1.2 nos últimos 90 dias:
```bash
AzureDiagnostics
| where TimeGenerated > ago(90d)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where isnotempty(tlsVersion_s) and strcmp(tlsVersion_s, "TLS1_2") < 0
| project TimeGenerated, Resource, OperationName, requestUri_s, CallerIPAddress, OperationVersion, clientInfo_s, tlsVersion_s
| sort by TimeGenerated desc
```
### Verificando Recursos via PowerShell
Se preferir usar PowerShell para verificar a versão do TLS em seus recursos, você pode usar o seguinte comando:
[Referência](https://stackoverflow.com/questions/77559639/what-azure-resources-uses-tls)
```powershell
Install-Module -Name Az.ResourceGraph
Connect-AzAccount
Search-AzGraph -Query "Resources | where properties.minimumTlsVersion == 'TLS1_2' | project name, type, properties.minimumTlsVersion"
```
Esse comando retorna uma lista de recursos que já estão configurados para usar TLS 1.2.
### Conclusão
Embora a Microsoft tenha declarado que suas implementações de TLS 1.0 e 1.1 não apresentam vulnerabilidades conhecidas, a mudança para TLS 1.2 oferece uma série de vantagens, especialmente em termos de segurança. A transição para uma versão mais segura do TLS é essencial para evitar interrupções e garantir que seus dados estejam devidamente protegidos.
Portanto, não deixe para a última hora. Avalie suas dependências no TLS agora e inicie o processo de migração para evitar problemas com a mudança em outubro de 2024.
Se precisar de suporte técnico, a Microsoft oferece recursos como a comunidade Microsoft Q&A, além de opções de suporte formal para quem possui um plano de suporte ativo.
---
# Como Configurar um WSL de Respeito
URL: https://www.orafaelferreira.com/artigos/zsh
Publicado: 2024-09-12
Categoria: Artigos
Tempo de leitura: 3 min de leitura
> Aprenda a montar um WSL de respeito para DevOps e SRE: Zsh com tema e plugins, ferramentas essenciais de linha de comando e aliases poderosos para o dia a dia.
### Introdução
Neste artigo, você vai aprender a montar um WSL de respeito, ambiente que todo DevOps, SRE ou engenheiro de plataforma deveria ter na manga. Vamos configurar o WSL com Zsh, tema e plugins, instalar ferramentas essenciais como `kubectx` e `kubens`, e configurar atalhos poderosos como o alias `k` para `kubectl`.
Ideal para quem vive no terminal e quer performance, praticidade.
### Parte 1 – Shell Zsh com estilo e produtividade
#### Passo 1: Verificar se o Zsh já está instalado
```bash
zsh --version
```
#### Passo 2: Instalar o Zsh
```bash
sudo apt install zsh -y
```
#### Passo 3: Mudar o shell padrão para Zsh
```bash
chsh -s /bin/zsh
```
#### Passo 3: Reiniciar o terminal
Feche e reabra seu terminal.
#### Passo 4: Instalar Oh My Zsh
```bash
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
```
#### Passo 5: Clonar o tema Dracula para Zsh
```bash
git clone https://github.com/dracula/zsh.git
```
#### Passo 6: Criar um link simbólico para o tema
Após clonar o repositório, crie um link simbólico para o tema na pasta de temas do Oh My Zsh:
```bash
ln -s $PWD/zsh/dracula.zsh-theme ~/.oh-my-zsh/themes/dracula.zsh-theme
```
#### Passo 7: Configurar o tema no Zsh
Edite o arquivo de configuração do Zsh:
```bash
vim ~/.zshrc
```
Altere a linha que começa com ZSH_THEME= para:
```bash
ZSH_THEME="dracula"
```
#### Passo 8: Instalar Plugins
Instale os plugins úteis com os seguintes comandos:
a) zsh-autosuggestions
```bash
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
```
b) zsh-syntax-highlighting
```bash
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
```
#### Passo 9: Adicionar os plugins ao Zsh
Abra o arquivo ~/.zshrc novamente:
```bash
vim ~/.zshrc
```
Adicione os plugins que você instalou na linha plugins=(...):
```bash
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)
```
#### Passo 10: Aplicar as mudanças
Após fazer as alterações, salve e feche o editor. Aplique as mudanças com:
```bash
source ~/.zshrc
```
#### Passo 11: Verificar se tudo está funcionando
Reinicie o terminal e verifique se o tema Dracula e os plugins estão funcionando corretamente.
### Parte 2 – Kubernetes com classe: kubectx, kubens e alias `k`
#### Instalar `kubectx` e `kubens`
```bash
mkdir -p ~/.local/bin
git clone https://github.com/ahmetb/kubectx.git ~/.local/bin/kubectx
sudo ln -sf ~/.local/bin/kubectx/kubectx /usr/local/bin/kubectx
sudo ln -sf ~/.local/bin/kubectx/kubens /usr/local/bin/kubens
```
Autocomplete para kubectx e kubens no Zsh
```bash
mkdir -p ~/.oh-my-zsh/completions
cp ~/.local/bin/kubectx/completion/_kubectx.zsh ~/.oh-my-zsh/completions/_kubectx
cp ~/.local/bin/kubectx/completion/_kubens.zsh ~/.oh-my-zsh/completions/_kubens
```
Edite e adicione no final do arquivo ~/.zshrc:
```bash
fpath+=("$HOME/.oh-my-zsh/completions")
autoload -Uz compinit
compinit
```
Recarregar o Zsh
```bash
exec zsh
```
Criar o alias k para kubectl com autocomplete
Adicione no ~/.zshrc:
```bash
alias k="kubectl"
```
E recarregue:
```bash
source ~/.zshrc
```
Pronto! Com autocomplete e velocidade. O terminal nunca mais será o mesmo.
---
# Minha Experiência na Codecon Summit: Um Evento Para Devs e Por Devs
URL: https://www.orafaelferreira.com/artigos/codecon
Publicado: 2024-09-11
Categoria: Registro Eventos Presenciais
Tempo de leitura: 3 min de leitura
> No último dia 07/09/2024, tive a oportunidade de participar da Codecon Summit, um dos maiores eventos de tecnologia voltados para desenvolvedores.
No último dia 07/09/2024, tive a oportunidade de participar da [Codecon Summit](https://codecon.dev/summit/programacao), um dos maiores eventos de tecnologia voltados para desenvolvedores. Se você já esteve em um evento organizado por devs e para devs, sabe que a experiência é sempre enriquecedora, com uma abundância de conteúdo técnico de alto nível.
A Codecon se destaca não apenas como um espaço de aprendizado, mas também como um ambiente de conexão, troca de experiências e um verdadeiro festival de ideias. O formato descontraído do evento nos faz sentir como se estivéssemos em um grande festival, mas com uma imersão total em tecnologia.
#### O Que Aconteceu no Evento?
##### Manhã: Explorando os Stands e Conectando com a Comunidade
Começamos o dia explorando os diversos stands do evento. Você sentia no ar uma vibe contagiante, e cada stand trazia uma temática única, onde empresas e comunidades de tecnologia ofereceram atividades interativas e muita informação sobre suas soluções e ferramentas.
Além de conhecer novas tecnologias, houve várias oportunidades de diversão, brindes e desafios — incluindo a famosa "caça ao pato", uma das atividades mais comentadas do evento. 🦆 Os participantes que conseguissem coletar o pato, podiam levar ele embora, tornando o evento único. Foi uma excelente maneira de quebrar o gelo e iniciar conexões com outros participantes.
O networking aconteceu de forma natural, com os participantes entusiasmados e dispostos a compartilhar suas experiências. Para mim, essa foi uma das partes mais gratificantes do evento — conhecer pessoas que compartilham a mesma paixão pela tecnologia e descobrir soluções inovadoras através das conversas informais.
##### Tarde: Palestras e Painéis Inspiradores
Após uma manhã repleta de interações nos stands, a tarde foi dedicada a conteúdo técnico de altíssima qualidade. Abaixo, destaco as principais palestras e painéis que pude acompanhar:
- **Painel: Skip Level – De Júnior para Pleno e de Pleno para Sênior** (14:30 - 15:30)
- **Painel: Tendências em IA e o Impacto no Desenvolvimento de Software** (15:30 - 16:30)
- **Construindo Soluções Flexíveis e Escaláveis com Arquitetura Orientada a Eventos** (16:30 - 17:30)
- **Como Vídeos Funcionam: Pipeline de Streaming com FFMpeg e Serverless** (17:30 - 18:30)
Esses momentos foram essenciais para aprofundar conhecimentos em áreas cruciais para o desenvolvimento de software moderno, com ênfase em escalabilidade, inteligência artificial e arquitetura de sistemas.
#### Reflexões Finais
A Codecon Summit vai além do aprendizado técnico — é também sobre construir conexões e fazer parte da comunidade de tecnologia comprometidos com a inovação. As interações matinais nos stands e o conteúdo técnico das palestras me reforçaram a importância de estar conectado à comunidade e de manter o aprendizado contínuo.
Se você está em busca de uma oportunidade para se atualizar sobre as últimas tendências no desenvolvimento de software e conhecer pessoas incríveis da área, não pode perder a próxima edição da Codecon. E se você também esteve presente nesta edição, que tal continuarmos essa conversa? O que achou do evento?
- [**Post Linkedin**](hhttps://www.linkedin.com/posts/rafaelmaferreira_codecon-desenvolvimento-microservices-activity-7238878836468133888-Ypt6?utm_source=share&utm_medium=member_desktop)
---
---
# Curso DP-900 Fundamentos de Dados do Azure 2024
URL: https://www.orafaelferreira.com/artigos/curso-dp-900
Publicado: 2024-09-02
Categoria: Organização de Eventos
Tags: Certificações
Tempo de leitura: 3 min de leitura
> Relato do curso DP-900 Fundamentos de Dados do Azure ministrado para a comunidade Azure Floripa em agosto de 2024: conteúdo, dinâmica do dia e agradecimentos.
No último sábado, 31 de agosto de 2024, a comunidade técnica Azure Floripa se reuniu na Igreja Batista de Forquilhinhas para um dia de aprendizado e colaboração com o curso **DP-900: Fundamentos de Dados do Azure**. Parabenizamos todos os participantes pelo incrível engajamento e dedicação ao longo do evento!
- **Saiba mais:** [Curso DP-900 Em São José/SC](https://www.eventbrite.com.br/e/curso-dp-900-em-sao-josesc-tickets-947904667377)
- [**Post Linkedin**](https://www.linkedin.com/posts/rafaelmaferreira_curso-dp-900-em-s%C3%A3o-jos%C3%A9sc-activity-7221484277182402560-mdRO?utm_source=share&utm_medium=member_desktop)
- **Slides da Apresentação:** Utilizado Material Oficial da Microsoft fornecido para MCT's.
### Explorando os Fundamentos de Dados na Nuvem com a Azure Floripa
O curso **DP-900**, também conhecido como "Microsoft Azure Data Fundamentals", proporcionou uma imersão prática e teórica no universo dos dados na nuvem. Com o objetivo de atender tanto profissionais de TI quanto iniciantes na gestão de dados, o curso ofereceu uma base sólida sobre os principais conceitos de dados no Azure, preparando os alunos para o exame de certificação DP-900.
### Aprendizado com Especialistas Reconhecidos
O evento contou com a presença de dois renomados especialistas, ambos membros ativos da comunidade Azure Floripa:
👨🏫 [Cláudio Raposo](https://www.linkedin.com/in/cfraposo/) - Microsoft MVP e Microsoft Certified Trainer, trouxe mais de uma década de experiência em desenvolvimento de software, compartilhando insights valiosos sobre análise de sistemas e melhores práticas de desenvolvimento.
👨🏫 [Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/) (eu) - Microsoft MVP e Microsoft Certified Trainer, com vasta experiência em arquiteturas de nuvem Azure, ofereceu uma visão aprofundada sobre a transformação digital e soluções inovadoras em nuvem.
### Engajamento e Colaboração da Comunidade Azure Floripa
Durante o curso, os participantes exploraram tópicos como dados relacionais e não relacionais, big data, análise de dados, e os principais serviços de dados no Azure, como **Azure SQL Database**, **Azure Cosmos DB**, **Azure Data Lake Storage** e **Azure Synapse Analytics**. As sessões foram dinâmicas e interativas, com discussões e trocas de ideias que enriqueceram o aprendizado.
O entusiasmo e a dedicação de todos foram notáveis, reafirmando o compromisso da comunidade Azure Floripa com o crescimento profissional e o compartilhamento de conhecimentos.
### Próximos Passos e Agradecimentos
Agradecemos a todos os participantes pelo engajamento. Vocês não apenas participaram, mas contribuíram significativamente para o sucesso do evento. Este curso foi apenas o início, e esperamos vê-los aplicando esses conhecimentos em seus projetos e avançando em suas carreiras.
Fiquem atentos aos próximos eventos e oportunidades de aprendizado promovidos pela Azure Floripa. Continuaremos a fortalecer nossa comunidade técnica por meio de encontros que visam a troca de conhecimento e o crescimento coletivo.
**Juntos, Construímos o Futuro da Tecnologia com a Azure Floripa**
Nosso sincero agradecimento aos instrutores, participantes e a todos que contribuíram para o sucesso deste evento. É por meio de encontros como este que fortalecemos nossos laços como comunidade e nos preparamos para os desafios do futuro.
Até o próximo evento!
---
# Estratégias de Modernização de Aplicações: Aplicando os 6Rs com o Cloud Adoption Framework
URL: https://www.orafaelferreira.com/artigos/6rs
Publicado: 2024-08-11
Categoria: Artigos
Tags: Azure
Tempo de leitura: 11 min de leitura
> A modernização de aplicações na nuvem é extremamente importante para que as organizações maximizem suas capacidades oferecidas pela computação em nuvem.
### Introdução
A modernização de aplicações na nuvem é extremamente importante para que as organizações maximizem suas capacidades oferecidas pela computação em nuvem. No contexto do Microsoft Azure, as estratégias de modernização podem ser categorizadas em quatro grandes abordagens: **Innovate**, **Migrate**, **Modernize** e **Retire**. Cada uma dessas abordagens oferece diferentes caminhos para otimizar, reestruturar ou descontinuar aplicações, de acordo com as necessidades específicas de negócios e tecnologia. Neste artigo, exploraremos essas estratégias detalhadamente, utilizando o framework dos 6Rs como base para a tomada de decisões.
#### 1. Innovate
**Inovar na nuvem** vai além da simples migração de aplicações existentes. Trata-se de reimaginar e reconstruir aplicações para explorar as capacidades e possibilidades únicas que a nuvem oferece. A inovação envolve transformações profundas, como a reestruturação da arquitetura ou até a reconstrução completa das aplicações. As abordagens dentro da categoria **Innovate** incluem:
##### Rearchitect (Rearquitetar):
Rearquitetar consiste em uma reestruturação significativa da arquitetura da aplicação, visando otimizar seu desempenho e funcionalidade no ambiente de nuvem. Esse processo pode envolver a adoção de abordagens modernas, como microsserviços, computação serverless e arquiteturas orientadas a eventos. Essas abordagens melhoram a escalabilidade granular e aumentam a resiliência da aplicação, permitindo que ela responda de forma eficiente a variações de demandas e falhas.
**Quando usar Rearquitetar:**
- **Alta Escalabilidade e Resiliência:** Use quando a aplicação precisa escalar e resistir a variações na demanda.
- **Limitações Estruturais:** Quando a arquitetura atual impede a adoção de novas tecnologias ou cenários modernos.
##### Rebuild (Reconstruir):
Reconstruir é a abordagem ideal quando a aplicação atual não pode ser adaptada para atender às necessidades futuras ou novas demandas de negócios. Ao reconstruir uma aplicação do zero utilizando, por exemplo, tecnologias cloud native, é possível introduzir novas funcionalidades, melhorar a escalabilidade e flexibilidade, e alinhar a aplicação com as melhores práticas de desenvolvimento moderno. Essa abordagem facilita a criação de soluções compatíveis com as capacidades avançadas da nuvem, como inteligência artificial (IA), machine learning e análises em tempo real.
**Quando usar Reconstruir:**
- Inadequação Tecnológica: Use quando a aplicação não acompanha as demandas tecnológicas atuais ou futuras.
- Aproveitamento Máximo da Nuvem: Quando o objetivo é explorar ao máximo capacidades como IA e machine learning.
##### Replace (Substituir):
A abordagem **Replace** consiste em substituir uma aplicação existente por uma solução de **Software as a Service (SaaS)** ou outra solução comercial pronta. Essa estratégia permite à empresa evitar os custos e o tempo envolvidos na modificação ou manutenção de uma aplicação legada, optando por uma solução que já atende de forma mais eficiente às necessidades do negócio. Ao adotar uma solução SaaS, a organização também se beneficia de atualizações contínuas, suporte especializado e a possibilidade de escalabilidade sem a complexidade de gerenciar a infraestrutura subjacente.
**Quando usar Replace:**
- SaaS como Solução Ideal: Quando uma solução SaaS moderna atende melhor às necessidades do negócio e pode ser implementada facilmente.
- Custo-Benefício: Quando os custos de manter ou modernizar a aplicação atual superam os benefícios, tornando a substituição por uma solução pronta mais econômica e estratégica.
##### Inovação Relacionada à Adoção da Nuvem
A inovação na nuvem é um diferencial competitivo, vai além da migração ou modernização, desbloqueando novas capacidades técnicas e expandindo as possibilidades de negócios. No **Cloud Adoption Framework**, o foco é entender profundamente as necessidades dos clientes e criar inovações que transformem a forma como eles interagem com os produtos da empresa.
Para saber mais sobre o CAF, [confira esse artigo](https://www.orafaelferreira.com/artigos/foundation-cloud) no meu blog.
**Implementação de Inovação com MVPs**
Uma abordagem eficaz é começar com um Produto Mínimo Viável (MVP), que é uma versão inicial de um novo recurso ou aplicação. O MVP oferece funcionalidade suficiente para coletar feedback dos usuários e validar a possibilidade da inovação. Esse processo de construir, medir e aprender permite ajustes rápidos para atender melhor às necessidades dos clientes.
#### 2. Migrate
A migração para a nuvem é a maneira mais rápida de levar aplicações ao Azure, permitindo que as organizações operem na nuvem da mesma forma que estava no onpremise. Essa abordagem é especialmente vantajosa para empresas que buscam agilidade na transição, aproveitando rapidamente os benefícios da escalabilidade, flexibilidade e redução de custos operacionais, o famoso OPEX . A principal estratégia dentro da categoria **Migrate** é o **Rehost**, também conhecido como "vai do jeito que dá", traduzido do lift-and-shift.
##### Rehost (Reospedagem):
O Rehost envolve mover aplicações para a nuvem sem modificar o código ou a arquitetura existente, um exemplo prático é mover uma virtual machine do jeito que ela se encontra no onpremise para a cloud. Essa abordagem é ideal para empresas que desejam desativar rapidamente datacenters locais ou que precisam migrar urgentemente, mas cujas aplicações já atendem aos requisitos de negócios e não necessitam de mudanças significativas no curto prazo.
**Quando Usar Migrate:**
- **Migração Urgente:** Move aplicações para a nuvem rapidamente, com mínima complexidade.
- **Preservação de Funcionalidade:** Mantém as aplicações inalteradas enquanto as transfere para a nuvem.
##### Visão Geral da Migração no Azure
O processo de migração para o Azure é estruturado para garantir uma transição suave e eficaz, minimizando riscos e maximizando os benefícios da nuvem. A migração segue a metodologia do **Cloud Adoption Framework (CAF)**, dividida em quatro estágios principais: **Preparação**, **Avaliação**, **Implantação** e **Liberação**.
1. **Preparação:** Garante que todos os pré-requisitos sejam atendidos e que as equipes estejam prontas para o projeto. Inclui o alinhamento organizacional, a seleção de regiões do Azure e a preparação da infraestrutura necessária.
2. **Avaliação:** Analisa as cargas de trabalho e o ambiente existente para identificar a melhor abordagem de migração, documentando a complexidade do cenário.
3. **Implantação:** Replicação e modernização das cargas de trabalho na nuvem, preparando-as para a gestão contínua.
4. **Liberação:** Testes, otimização e liberação das cargas de trabalho para as operações, com documentação completa do processo.
##### Ferramentas para Migração:
| **Ferramenta** | **Funcionalidade** | **Descrição** |
|-----------------------------------------------|---------------------------------------------|------------------------------------------------------------------------------------------------------|
| Migrações para Azure: Descoberta e Avaliação | Avaliar servidores locais (SQL, Web) | Avalia servidores VMware, Hyper-V e físicos para migração para o Azure. |
| Migração e Modernização | Migrar servidores | Migra VMs de VMware, Hyper-V, servidores físicos e VMs públicas para Azure. |
| Assistente de Migração de Dados | Avaliar bancos de dados SQL Server | Avalia e identifica bloqueadores e melhorias para migração de SQL Server. |
| Serviço de Migração de Banco de Dados do Azure| Migrar bancos de dados | Migra bancos de dados locais para SQL Server no Azure. |
| Migration Assistant de Aplicativo Web | Avaliar e migrar aplicativos Web | Avalia e migra aplicativos .NET e PHP para o Serviço de Aplicativo do Azure. |
| Azure Data Box | Migrar dados offline | Transfere grandes volumes de dados offline para o Azure. |
#### 3. Modernize
Modernizar aplicações é um algo fundamental para extrair o máximo valor dos recursos nativos da nuvem. Diferente de uma simples migração, a modernização envolve ajustes na arquitetura ou na plataforma da aplicação, sem necessidade de reestruturação completa. A principal abordagem dentro da categoria **Modernize** é o **Replatform**.
##### Replatform (Replataforma):
O Replatform envolve pequenas alterações na aplicação para que ela execute de maneira mais eficiente no ambiente de nuvem. Isso pode incluir a migração de um banco de dados para uma solução gerenciada ou a adaptação da infraestrutura para utilizar serviços de Plataforma como Serviço (PaaS). Essa abordagem melhora a eficiência operacional e reduz o custo total de propriedade (TCO), mantendo a integridade das funcionalidades principais.
**Quando Usar Modernize:**
- **Aproveitamento de Recursos Nativos da Nuvem:** Quando a aplicação pode se beneficiar significativamente dos recursos nativos da nuvem, como serviços gerenciados e automação, sem grandes mudanças estruturais.
- **Foco em Eficiência e Redução de Custos:** Quando o objetivo principal é melhorar a eficiência operacional e reduzir o TCO, aproveitando os serviços gerenciados da nuvem.
##### Modernização na Nuvem: Uma Abordagem Estruturada
A modernização é estruturada em duas fases principais:
1. **Alinhamento de Negócios:** Identifica as cargas de trabalho que mais irão se beneficiar da modernização e estabelece um roteiro detalhado para alcançar esses objetivos.
2. **Estratégias de Modernização:** Adota novas tecnologias e metodologias, como DevOps e PaaS, para aprimorar processos, aplicativos e bancos de dados.
**Benefícios da Modernização:**
- **Maximização da Produtividade:** Libera as equipes para focarem na inovação, reduzindo a sobrecarga de gerenciamento.
- **Redução de Custos:** Adotar soluções PaaS e modernizar processos operacionais, diminuindo os custos de manutenção de infraestrutura.
- **Aumento da Agilidade:** Agiliza a resposta às mudanças de mercado, permitindo lançamentos rápidos de novas funcionalidades.
##### Implementação de PaaS para Modernização
A modernização pode ser realizada através de várias soluções de PaaS, cada uma oferecendo um equilíbrio diferente entre controle e produtividade:
- **Container PaaS:** Como o Azure Kubernetes Service (AKS) e Azure Red Hat OpenShift, oferecem maior controle sobre cargas de trabalho, gerenciando todo o cluster, manutenção e implementação.
- **Application PaaS:** Recursos como Azure App Service, Azure Spring Cloud e Azure Functions proporcionam um facilidade entre controle e produtividade, onde a plataforma gerencia a disponibilidade e a implementação.
- **Low/No Code PaaS:** Ferramentas como Power Apps e Power Automate permitem a construção rápida de aplicações com pouca ou nenhuma codificação, maximizando a produtividade e o tempo de mercado.
Se ainda estiver em dúvida, confira a árvore de decisões abaixo para identificar qual serviço de computação na Azure melhor atende às suas necessidades
##### Modernização de Bancos de Dados na Nuvem
A modernização de bancos de dados pode melhorar significativamente a forma como você armazena, processa e utiliza dados. O objetivo é aumentar a confiabilidade, o desempenho e reduzir custos. Existem soluções de **PaaS** e **IaaS** disponíveis para modernizar qualquer tipo de banco de dados na nuvem.
**Categorias de Soluções de Banco de Dados:**
- **Azure SQL**: Soluções para SQL Server e outros bancos de dados SQL de código fechado.
- **Open-source e NoSQL**: Soluções para bancos de dados SQL de código aberto e NoSQL.
Cada categoria de banco de dados oferece três soluções: duas de **PaaS** e uma de **IaaS**. Essas opções permitem um equilíbrio entre controle e produtividade, suportando diferentes origens de bancos de dados.
**Azure SQL:**
- **SQL Server em máquinas virtuais (IaaS)**
- **Azure SQL Managed Instance (PaaS)**
- **Banco de Dados Azure SQL totalmente gerenciado (PaaS)**
**Open-source SQL & NoSQL:**
- **MySQL, MariaDB ou PostgreSQL em máquinas virtuais (IaaS)**
- **Azure Cosmos DB e Azure Managed Instance para Apache Cassandra (PaaS)**
- **Bancos de dados MySQL, MariaDB e PostgreSQL totalmente gerenciados (PaaS)**
#### 4. Retire (Desativar)
À medida que as organizações evoluem, nem todas as aplicações continuam a agregar valor. Em alguns casos, a estratégia mais eficiente é desativar ou aposentar uma aplicação. O processo de **Retire** envolve a desativação de aplicações que não são mais necessárias ou que foram substituídas por soluções mais modernas e eficientes. Essa abordagem simplifica a infraestrutura de TI e otimiza os recursos, redirecionando esforços e investimentos para áreas que realmente necessitam de suporte.
**Quando usar Retire:**
- **Substituição por Alternativas Modernas:** Quando a aplicação foi substituída por uma solução mais moderna que oferece maior eficiência e alinhamento com as metas de negócios.
- **Manutenção Injustificável:** Quando a aplicação exige um esforço de manutenção desproporcional aos benefícios que oferece.
- **Redução de Complexidade:** Quando a simplificação da infraestrutura é uma prioridade, aposentando sistemas legados para melhorar a agilidade da TI.
##### Processo de Retire: Passos para Desativação Eficiente
1. **Avaliação de Aplicações:** Análise da relevância e do custo de manutenção da aplicação para o negócio.
2. **Planejamento de Desativação:** Documentação completa e comunicação clara com stakeholders sobre o processo de desativação.
3. **Execução da Desativação:** Realização de backups, arquivamento de dados e desativação controlada da aplicação.
4. **Revisão Pós-Desativação:** Monitoramento do ambiente após a desativação e preparação de um relatório final.
**Benefícios de Retirar Aplicações:**
- **Simplificação da Infraestrutura:** Reduz a complexidade operacional e os custos associados.
- **Otimização Financeira (FinOps):** Otimiza a utilização e o custo dos recursos na nuvem.
- **Sustentabilidade (GreenOps):** Reduz o consumo de energia e promove práticas de TI mais verdes.
### Conclusão
A modernização de aplicações na nuvem é um processo que exige uma análise cuidadosa de cada aplicação em relação às necessidades do negócio e às capacidades da nuvem. As estratégias agrupadas em **Innovate**, **Migrate**, **Modernize** e **Retire** fornecem um framework flexível para orientar as decisões de modernização. Ao aplicar essas estratégias, as organizações não apenas migram para a nuvem, mas também garantem que suas aplicações estejam otimizadas para o futuro, oferecendo o máximo valor ao negócio.
Este artigo oferece uma visão clara das opções disponíveis para a modernização de aplicações, auxiliando você a tomar decisões importantes e a planejar uma transição bem-sucedida para a nuvem.
---
# Guia de Criação de Máquinas Virtuais no Microsoft Azure
URL: https://www.orafaelferreira.com/artigos/guia-criacao-vms-azure
Publicado: 2024-07-26
Categoria: Artigos
Tempo de leitura: 22 min de leitura
> Guia introdutório para criar máquinas virtuais Linux e Windows no Azure, cobrindo Resource Groups, Virtual Networks, NSGs e acesso via SSH e RDP.
### Introdução
Este artigo será uma base introdutória essencial para os próximos conteúdos que virão, onde exploraremos mais a fundo a criação e gerenciamento de máquinas virtuais no Microsoft Azure. Aqui, abordaremos os passos iniciais para criar máquinas virtuais tanto para Linux quanto para Windows, fornecendo um fundamento para as futuras discussões e tutoriais.
Criar máquinas virtuais no Microsoft Azure pode parecer uma tarefa complicada, mas com este guia passo a passo, você verá que é mais simples do que parece. Vamos explorar a criação de máquinas virtuais tanto para Linux quanto para Windows. Vamos começar!
### Passo 1: Criação do Resource Group
Antes de criar qualquer recurso no Azure, precisamos de um Resource Group, que funciona como um contêiner lógico para todos os recursos relacionados. Vamos criar um Resource Group chamado `rg-example`.
1. Acesse o portal do Azure.
2. Vá para "Resource Groups" e clique em "Create".
3. Nomeie seu Resource Group como `rg-example`.
4. Selecione a região desejada.
5. Clique em "Review + Create" e, em seguida, "Create".
### Passo 2: Criação da Virtual Network
A próxima etapa é criar uma Virtual Network (VNet), que permite a comunicação entre recursos do Azure.
1. Vá para "Virtual Networks" e clique em "Create".
2. Nomeie a VNet como `vnet-example`.
3. Selecione o Resource Group `rg-example`.
4. Configure o endereço IP e as sub-redes conforme necessário.
5. Clique em "Review + Create" e, em seguida, "Create".
### Passo 3: Criação da NSG (Network Security Group)
O Network Security Group (NSG) é responsável por controlar o tráfego de rede para as VMs. Vamos criar um NSG chamado `nsg-example`.
1. Vá para "Network Security Groups" e clique em "Create".
2. Nomeie o NSG como `nsg-example`.
3. Selecione o Resource Group `rg-example`.
4. Clique em "Review + Create" e, em seguida, "Create".
### Passo 4: Anexar o NSG à Subnet
Depois de criar o NSG, precisamos anexá-lo à Subnet `default` da nossa VNet `vnet-example`.
1. Acesse o NSG `nsg-example` e selecione a settings > Subnet.
2. Associate, selecione a subnet `default` e salve as alterações.
### Passo 5: Criação da Virtual Machine Linux
Vamos criar a VM com nome vm-example dentro do rg-example com o tipo de segurança: Standard.
1. Vá para "Virtual Machines" e clique em "Create".
2. Selecione o Resource Group `rg-example`.
3. Nomeie a VM como `vm-example`.
4. Altere o tipo de segurança para Standard.
5. Selecione "Ubuntu Server 20.04 LTS ARM64 Gen2" como a imagem.
6. Selecione "Arm64" como a arquitetura (para maior eficiência energética e de processamento).
7. Configure a VM com o tamanho `Standard_D2ps_v5`.
8. Escolha a autenticação por senha e defina uma senha.
9. Certifique-se de que a VM não tenha portas de entrada públicas configuradas.
**Saiba Mais:** [Máquinas Virtuais do Azure com processadores baseados em Arm do Ampere Altra](https://azure.microsoft.com/pt-br/updates/generally-available-new-azure-virtual-machines-with-ampere-altra-armbased-processors/)
10. Na seção "Networking", certifique-se de que a VM esteja na VNet `vnet-example` e na Subnet `default`.
11. Selecione "Review + Create" e, em seguida, "Create".
Após a criação, precisamos liberar a porta SSH 22 no NSG `nsg-example` para acessar a VM.
1. Acesse o NSG `nsg-example`.
2. Adicione uma regra de entrada para permitir o tráfego na porta 22.
#### Conectando-se à VM Linux
Após a VM estar em execução verifique qual IP público foi atribuído à VM , copie o IP público e conecte-se via SSH:
```bash
ssh usuario@IPX.XXX.XXX.XX
```
No meu caso:
```bash
ssh raafel@172.210.28.194
```
De preferência, atualize os pacotes do sistema:
```bash
sudo apt-get update
sudo apt-get upgrade -y
```
### Criação da Virtual Machine Windows 11
Vamos criar uma VM com Windows 11 dentro do nosso `rg-example`, com o nome `vm-example-win`, tipo de segurança `Standard` e imagem `Windows 11 Pro`.
1. Vá para "Virtual Machines" e clique em "Create".
2. Selecione o Resource Group `rg-example`.
3. Nomeie a VM como `vm-example-win`.
4. Altere o tipo de segurança para Standard.
5. Selecione "Windows 11 Pro" como a imagem.
6. Configure a VM com o tamanho `Standard_B4ms` para testes mais rápidos.
7. Escolha a autenticação por senha e defina uma senha de sua preferência (não se esqueça de anotar a senha).
8. Certifique-se de que a VM não tenha portas de entrada públicas configuradas. Confirme a licença.
9. Na seção "Networking", certifique-se de que a VM esteja na VNet `vnet-example` e na Subnet `default`, e que não seja atribuído um NSG à NIC.
10. Selecione "Review + Create" e, em seguida, "Create".
Após a criação, precisamos liberar a porta RDP no NSG `nsg-example` para acessar a VM.
1. Acesse o NSG `nsg-example`.
2. Adicione uma regra de entrada para permitir o tráfego na porta RDP.
#### Conectando-se à VM Windows
1. No seu computador com Windows, abra o aplicativo "Remote Desktop Connection" (procure por "Remote" no menu Iniciar).
2. Copie o IP público atribuído à VM `vm-example-win`, digite no Remote Desktop Connection, clique no botão conectar, escolha "Use another account", e digite o usuário e senha que foram criados anteriormente. Clique em "OK".
3. Confirme o certificado de segurança quando solicitado:
---
### Conclusão
Criar máquinas virtuais no Azure é um processo estruturado que envolve a criação de vários componentes, como Resource Groups, Virtual Networks e Network Security Groups. Seguindo este guia, você pode configurar rapidamente VMs Linux e Windows para atender às suas necessidades. Lembre-se de sempre garantir a segurança das suas VMs e otimizar suas configurações para o melhor desempenho.
A flexibilidade e o poder do Azure permitem que você adapte a infraestrutura de TI às demandas específicas do seu projeto, seja ele para desenvolvimento, teste ou produção. Utilize as práticas recomendadas para maximizar a eficiência e a segurança de suas VMs.
Se tiver dúvidas ou precisar de mais detalhes, não hesite em entrar em contato. Espero que este guia tenha sido útil para você!
---
# Explorando a Inteligência Artificial Generativa
URL: https://www.orafaelferreira.com/artigos/ia-gen
Publicado: 2024-07-25
Categoria: Artigos
Tempo de leitura: 9 min de leitura
> O que é IA generativa, suas aplicações e impacto econômico, efeitos na produtividade dos desenvolvedores, preocupações éticas e o caminho até a AGI.
### Introdução
A inteligência artificial (IA) tem transformado diversos setores e aspectos da vida cotidiana, e a chegada da IA generativa marca uma nova era de inovação e possibilidades. Desde o lançamento do ChatGPT pela OpenAI, em novembro de 2022, a IA generativa ganhou destaque global, impactando tanto o mercado quanto a sociedade. Este artigo explora o que é a IA generativa, suas aplicações e as implicações éticas e econômicas que acompanham essa tecnologia emergente.
### O Que é IA Generativa?
IA generativa refere-se a sistemas de inteligência artificial capazes de criar conteúdo de alta qualidade, como texto, imagens e áudio. Esses sistemas utilizam modelos avançados, conhecidos como grandes modelos de linguagem (LLMs), para prever e gerar conteúdo com base em grandes volumes de dados. O ChatGPT, por exemplo, pode gerar respostas detalhadas e contextualizadas para perguntas, criar textos criativos e até mesmo produzir recomendações personalizadas.
### Aplicações e Impacto Econômico
As aplicações de IA generativa são vastas e variadas. Empresas como Google e Microsoft possuem seus produtos, como o Gemini e o Copilot, respectivamente. Essas ferramentas permitem que os usuários gerem textos e imagens a partir de comandos simples, chamados de prompts. Além disso, a IA generativa está revolucionando o desenvolvimento de software, tornando a criação de aplicações de IA mais velozes e menos custosa.
Estudos indicam que a IA generativa pode adicionar entre 2,6 a 4,4 trilhões de dólares à economia global anualmente. [A Goldman Sachs estima que essa tecnologia pode aumentar o Produto Interno Bruto (PIB) global em 7% na próxima década](https://blog.mackenzie.br/vestibular/3-carreiras-para-trabalhar-com-inteligencia-artificial-ia/). Contudo, também há preocupações sobre o impacto na força de trabalho, [com estimativas de que cerca de 10% das tarefas realizadas por mais de 80% dos trabalhadores nos Estados Unidos poderiam ser afetadas pela IA generativa](https://pt.euronews.com/next/2023/03/24/estes-sao-os-postos-de-trabalho-que-poderao-ser-mais-afetados-pela-inteligencia-artificial).
### Como a IA Generativa Funciona?
O funcionamento da IA generativa é baseado em aprendizado supervisionado, onde modelos são treinados para prever a próxima palavra ou imagem em uma sequência com base em dados anteriores. Este processo envolve grandes volumes de dados textuais e de imagens que ajudam os modelos a aprender padrões e gerar conteúdo coerente e relevante.
Por exemplo, ao solicitar a criação de uma imagem de "uma maçã vermelha", o modelo usa técnicas de aprendizado profundo para gerar uma imagem que corresponde à descrição fornecida. Este processo pode ser refinado através de ajustes nos prompts e parâmetros do modelo, permitindo a geração de conteúdos altamente específicos e detalhados.
### Desafios e Limitações
Apesar do potencial, a IA generativa enfrenta desafios significativos. Um dos principais problemas é a questão das "alucinações", onde o modelo pode gerar informações incorretas ou fictícias de forma convincente. Além disso, a IA tem limitações de conhecimento, pois só pode acessar dados até o momento em que foi treinada, o que pode levar à desatualização de informações.
Outro aspecto crucial é a questão ética, especialmente no que diz respeito ao viés e ao uso responsável da tecnologia. Como os modelos são treinados com dados disponíveis na internet, eles podem refletir e perpetuar preconceitos existentes na sociedade. Portanto, é fundamental que desenvolvedores e usuários estejam cientes dessas questões e trabalhem para mitigá-las.
### Aplicando IA Generativa em Aplicações de Software
A construção de aplicações de software com IA generativa tem se tornado mais fácil e eficaz, graças aos avanços dessa tecnologia. Por exemplo, a criação de sistemas para leitura de avaliações de restaurantes para monitoramento de reputação antes exigia um grande esforço de engenharia de machine learning, incluindo a coleta de dados, o treinamento de modelos e a implantação em nuvem. Esse processo, que poderia levar meses, agora pode ser simplificado com a IA generativa.
Hoje, com o desenvolvimento baseado em prompts, a criação de um classificador de sentimentos pode ser reduzida a apenas algumas linhas de código. Um exemplo clássico é o uso de prompts para classificar uma avaliação de restaurante como positiva ou negativa. Anteriormente, esse processo envolvia rotular centenas ou milhares de exemplos para treinar um modelo. Agora, com uma simples chamada a um grande modelo de linguagem (LLM), é possível obter uma classificação de sentimento com precisão e eficiência.
### Impacto na Produtividade e Desenvolvimento
A redução da barreira para a construção de aplicações com IA generativa está permitindo uma alta demanda de novos aplicativos. Tarefas que antes levavam de 6 a 12 meses para serem desenvolvidas agora podem ser concluídas em dias ou semanas. Isso é especialmente benéfico para empresas que precisam de soluções rápidas e eficazes para problemas complexos.
### Desafios e Soluções
Apesar das vantagens, a IA generativa ainda enfrenta desafios, como a precisão em cálculos e a execução de ações críticas. Por exemplo, ao responder a uma pergunta sobre juros compostos, um LLM pode não fornecer uma resposta precisa sem o auxílio de ferramentas adicionais, como uma calculadora. Nesse contexto, a utilização de ferramentas auxiliares se torna essencial para aumentar a precisão e a funcionalidade das respostas.
Além disso, a verificação das ações sugeridas pela IA é crucial para evitar erros custosos. Em sistemas de atendimento ao cliente, por exemplo, é importante implementar mecanismos de confirmação antes de concluir transações, garantindo assim que as respostas geradas sejam precisas e seguras.
### Avanços Futuramente Possíveis
O futuro da IA generativa em software está repleto de possibilidades empolgantes. Pesquisadores estão explorando o uso de agentes baseados em LLMs que podem tomar decisões complexas e executar sequências de ações. Embora essa tecnologia ainda esteja em fase experimental, ela promete transformar a maneira como interagimos com sistemas de IA, possibilitando uma automação ainda mais avançada e personalizada.
### Objetivos de Aprendizagem
1. Analisar fluxos de trabalho e identificar novas oportunidades de negócios que surgem do potencial da IA generativa para melhorar a eficiência, produtividade e geração de valor.
2. Reconhecer que a IA automatiza principalmente tarefas dentro dos trabalhos, não funções inteiras, e avaliar tarefas para o potencial da IA generativa com base em dois critérios principais: viabilidade técnica e valor comercial.
3. Discutir as principais preocupações que surgem da adoção da IA generativa e dos grandes modelos de linguagem (LLMs), incluindo perda de empregos, amplificação dos piores impulsos da humanidade e extinção humana.
4. Listar os princípios da IA responsável, incluindo justiça, transparência, privacidade, segurança e uso ético, e aprender estratégias para garantir o desenvolvimento e a implantação de IA de forma ética e socialmente responsável.
### Uso Cotidiano de LLMs em Interfaces Web
Com o avanço da IA generativa, muitas profissões têm integrado essa tecnologia em suas atividades diárias, utilizando interfaces web para acessar LLMs. Profissionais de marketing, por exemplo, utilizam essas ferramentas para gerar ideias de campanhas de e-mail, enquanto recrutadores podem resumir avaliações de candidatos. Programadores também se beneficiam ao gerar rascunhos iniciais de códigos, embora muitas vezes seja necessário corrigir erros. A versatilidade dos LLMs permite sua aplicação em diversas funções, servindo como assistentes de escrita ou editores de texto, e até mesmo como parceiros de pensamento para explorar ideias e soluções.
### Análise de Tarefas de Trabalhos
Uma abordagem eficaz para implementar a IA generativa é identificar tarefas específicas dentro de funções de trabalho que podem ser automatizadas ou aprimoradas. Em vez de substituir empregos inteiros, a IA geralmente se concentra em automatizar tarefas. A viabilidade técnica e o valor comercial dessas tarefas são critérios fundamentais para avaliar o potencial da IA generativa. Por exemplo, a automatização de respostas de chat pode ser viável e valiosa, enquanto a realização de conversas telefônicas complexas ainda pode ser desafiadora.
### Exemplos de Análise de Tarefas em Diferentes Funções
Ao analisar diferentes funções de trabalho, pode-se descobrir que as melhores oportunidades para a IA generativa não são necessariamente as mais óbvias. Programadores, por exemplo, fazem mais do que apenas escrever código; eles também documentam e revisam códigos. Cada tarefa tem diferente grau de potencial para automação ou aprimoramento com IA, e uma análise sistemática pode ajudar a identificar onde a IA pode ser mais útil.
### Novos Fluxos de Trabalho e Oportunidades de Crescimento
A implementação da IA generativa não só pode economizar custos, mas também criar novas oportunidades de crescimento. Por exemplo, ao tornar a redação de cópias para websites mais eficiente, os profissionais de marketing podem testar múltiplas versões de conteúdo para identificar a mais eficaz. Além disso, empresas podem explorar a automatização de tarefas realizadas por seus clientes, oferecendo produtos ou serviços mais eficazes e personalizados. Este replanejamento de fluxos de trabalho pode resultar em modelos de negócios inovadores e maior valor agregado.
### Preocupações com a IA e Implicações Éticas
Com o uso crescente da IA, surgem preocupações sobre seu impacto na sociedade. Isso inclui o potencial de amplificação dos piores impulsos humanos, como preconceitos e desinformação, bem como a ameaça de perda de empregos devido à automação. A questão ética é central, destacando a necessidade de desenvolver e usar IA de maneira justa, transparente, segura e ética. Técnicas como o aprendizado por reforço com feedback humano (RLHF) estão sendo usadas para tornar os LLMs menos tendenciosos e mais alinhados com valores humanos.
### Inteligência Artificial Geral (AGI) e o Futuro da IA
A IA Geral (AGI) é um conceito de inteligência artificial capaz de realizar qualquer tarefa intelectual que um humano possa. Apesar do entusiasmo, estamos ainda longe de alcançar a AGI. Entretanto, a IA generativa já está provocando transformações significativas, especialmente entre trabalhadores do conhecimento. As estimativas indicam que a AGI poderá revolucionar setores inteiros, criando novos empregos e oportunidades de crescimento, ao mesmo tempo em que levanta questões sobre seu impacto potencial na sociedade e na economia.
### Conclusão
A IA generativa oferece vastas oportunidades para melhorar a eficiência e criar novos valores nos negócios. No entanto, é crucial abordar suas implicações éticas e sociais para garantir que a tecnologia seja usada de maneira responsável e benéfica. Empresas e profissionais devem se preparar para integrar a IA generativa em seus processos, aproveitando seu potencial para inovação e crescimento, ao mesmo tempo em que garantem o desenvolvimento responsável e ético da IA.
---
# Organizador – Azure Floripa
URL: https://www.orafaelferreira.com/artigos/azure-floripa
Publicado: 2024-07-21
Categoria: Organizador Grupo de Comunidade
Tempo de leitura: 3 min de leitura
> A comunidade Azure Floripa evoluiu para o Azure User Group Florianópolis, ligado ao Azure User Groups Brasil, com foco em conteúdo prático sobre Azure.
### Introdução
Nossa comunidade tem o objetivo principal de explorar e apresentar as diversas soluções e serviços disponíveis na nuvem da Microsoft. Nosso objetivo é claro: compartilhar conhecimento através das experiências vividas e contadas por nossos palestrantes, enriquecendo o grupo com insights valiosos e práticos sobre o que há de mais inovador no mundo Azure.
Além claro, de fortalecer a comunidade Azure em Florianópolis, visando fomentar o aprendizado e networking entre os participantes da comunidade.
### Evolução da comunidade
O **Azure Floripa** cresceu e hoje faz parte de uma iniciativa maior: o **Azure User Group Florianópolis**, conectado ao movimento nacional do **Azure User Groups Brasil**.
Na prática, a comunidade local continua com o mesmo propósito de fortalecer o ecossistema Azure na região, mas agora dentro de uma estrutura mais ampla, integrada a outras branches pelo Brasil.
Para acompanhar essa nova fase da comunidade, veja também o artigo:
* [**Organizador – Azure User Groups Brasil**](https://www.orafaelferreira.com/artigos/azure-user-groups-brasil)
Juntou curiosidade + vontade de ajudar? Então o grupo é pra você! 🎉
## Azure Floripa
[](https://www.youtube.com/@AzureFloripa)
* 🌐 [Site - Azure Floripa](https://azurefloripa.com.br/)
* 🔗 [Nossos links](https://linktr.ee/AzureFloripa)
* ▶️ [Youtube - Azure Floripa](https://www.youtube.com/channel/UCXgiLXOwNL33-86Xl_2KMgg)
### Eventos Organizados
| Data | Evento | Formato |
|------|--------|---------|
| 02 set 2024 | [**DP‑900: Fundamentos de Dados do Azure**](https://www.orafaelferreira.com/artigos/curso-dp-900) | Presencial |
| 10 jun 2024 | [**AZ‑900: Fundamentos do Azure**](https://www.orafaelferreira.com/artigos/curso-az-900) | Presencial |
| 10 abr 2024 | [**Global Azure 2024 feat. Azure Floripa**](https://www.orafaelferreira.com/artigos/global-azure24) | Online |
| 10 abr 2025 | [**Global Azure 2025 feat. Azure Floripa**](https://www.orafaelferreira.com/artigos/global-azure25) | Online |
| 10 abr 2025 | [**Global Azure 2025 – Azure Floripa**](https://www.meetup.com/azure-floripa/events/306207034/?eventOrigin=group_upcoming_events)| Presencial |
---
### Conhecendo as vertentes do Copilot e o que ele pode fazer no Azure com Marcelo Souza
[](https://www.youtube.com/watch?v=R9lFLWeNlbU)
### Governança Azure: Você Precisa Estar Atento! com Osanam Giordane
[](https://www.youtube.com/watch?v=oLDXUuOyIjA)
### Azure Workbooks para Otimização de Custos com FinOps
[](https://www.youtube.com/watch?v=TWGizKIBOXc)
### Como implantar uma infraestrutura em larga escala com Azure DevOps e Terraform
[](https://www.youtube.com/watch?v=Pb-rL-Mz-sI)
### Desvendando o Service Principal x Managed Identities no Entra ID
[](https://www.youtube.com/watch?v=lxxyxDwvsDU)
### Trajetória Internacional - Do queijo minas ao queijo Gouda
[](https://www.youtube.com/watch?v=Ne-76V9XvxA)
### Mesa Redonda - Transição de carreira é possível? + Carreira de TI, além da área técnica
[](https://www.youtube.com/watch?v=6drxvyPhmMc)
### #SuperLive Vamos apoiar o Rio Grande do Sul
[](https://www.youtube.com/watch?v=F-cLo4f3Hew&ab_channel=AzureFloripa)
### A importância de implementar Microsoft Purview para não ter vazamento de dados no Copilot
[](https://www.youtube.com/watch?v=X3EV4zdh8BA)
### Migrando Logic Apps com Juliano Custodio
[](https://www.youtube.com/watch?v=UhZ6abo-kYk)
### Azure OpenAI + Vision Novas Perspectivas com a IA Generativa com Osvaldo Alves
[](https://www.youtube.com/watch?v=9QXbtDhygz8&t)
### Mesa Redonda - Como consegui trabalhar somente com Azure + Certificações
[](https://www.youtube.com/watch?v=SEz3UgW3dMM&t)
**Curtiu?**
Fica o convite: participe, compartilhe e ajude a comunidade a crescer. 🚀
Nos vemos no próximo encontro!
---
# Organizador – Cloud Native Santa Catarina
URL: https://www.orafaelferreira.com/artigos/cncfsc
Publicado: 2024-07-21
Categoria: Organizador Grupo de Comunidade
Tags: Kubernetes
Tempo de leitura: 1 min de leitura
> Minha atuação como organizador do Cloud Native Santa Catarina, comunidade oficial da CNCF que promove tecnologias cloud native e open source na região.
### Sobre o capítulo
O **Cloud Native Santa Catarina** é uma comunidade oficial apoiada pela **Cloud Native Computing Foundation (CNCF)**, criada para promover tecnologias cloud native, cultura open source e discussões técnicas conectadas à realidade de quem constrói e opera plataformas modernas.
A comunidade reúne profissionais interessados em temas como **Kubernetes, observabilidade, platform engineering, containers, service mesh e arquiteturas cloud native**, criando um espaço contínuo de aprendizado, networking e troca de experiências.
Atuo como organizer da comunidade **desde janeiro de 2025**, apoiando o planejamento e a execução dos meetups, a curadoria dos encontros e o crescimento consistente da comunidade em Santa Catarina.
Atuamos com base em **Florianópolis**, mas também ajudamos a expandir a presença da comunidade com iniciativas em outras cidades da região.
[Site oficial do grupo:](https://community.cncf.io/cloud-native-santa-catarina/)
Comunidades técnicas encurtam a curva de aprendizado, aproximam profissionais com interesses parecidos e ajudam a transformar conhecimento disperso em experiências compartilhadas.
No caso do **Cloud Native Santa Catarina**, isso significa criar um ambiente em que pessoas possam aprender com implementações reais, discutir boas práticas e se aprofundar em tecnologias open source que hoje são fundamentais para times de plataforma, infraestrutura e desenvolvimento.
Também é uma forma concreta de apoiar a evolução profissional de quem está começando e de quem já atua na área, seja através de networking, troca de referências, oportunidades de palestrar ou participação em eventos presenciais.
### Cloud Native Santa Catarina
Se você curte o universo cloud native, open source e engenharia de plataformas, vale acompanhar e participar da comunidade.
* 🌐 [Linktree oficial](https://linktr.ee/cloudnativesc)
* 🤝 [Community Group no Bevy](https://community.cncf.io/cloud-native-santa-catarina/)
* 📸 [Instagram](https://www.instagram.com/cncf.sc/)
* 💼 [LinkedIn](https://www.linkedin.com/company/cncfsc/)
* ▶️ [YouTube](https://www.youtube.com/@cloudnativesc)
Esse esforço contínuo fortalece o ecossistema local, amplia o alcance da comunidade e incentiva a adoção de tecnologias open source com base em experiências reais de mercado.
---
# Organizador – DevOpsDays Florianópolis
URL: https://www.orafaelferreira.com/artigos/comu-dod-floripa
Publicado: 2024-07-21
Categoria: Organizador Grupo de Comunidade
Tempo de leitura: 1 min de leitura
> Minha atuação desde 2023 na organização do DevOpsDays Florianópolis: coordenação de eventos, suporte a speakers e engajamento da comunidade DevOps local.
### Sobre a comunidade
Faço parte do time de organização do **DevOpsDays Florianópolis** desde **2023**, contribuindo para a continuidade e o fortalecimento da comunidade local em torno de práticas DevOps, colaboração entre times e troca de experiências reais de mercado.
O **DevOpsDays** é uma série global de conferências guiadas pela comunidade, focada em desenvolvimento de software, operações de TI, automação, cultura e nos pontos de interseção entre pessoas, processos e tecnologia.
Como organizer, apoio diferentes frentes para manter a comunidade ativa e relevante entre uma edição e outra, ajudando a transformar o evento em um ponto de encontro recorrente para profissionais da região.
Além do evento em si, também contribuo para manter a comunidade engajada, incentivar novas participações e apoiar a entrada de novos palestrantes e colaboradores.
### Edições organizadas
* 📅 [**DevOpsDays Florianópolis 2024**](https://www.orafaelferreira.com/artigos/eventodod-floripa) — 16 de novembro de 2024
* 📅 [**DevOpsDays Florianópolis 2025**](https://www.orafaelferreira.com/artigos/devopsdays-florianopolis-2025) — 6 de dezembro de 2025
### Por que isso importa
Esse envolvimento contínuo ajuda a sustentar uma comunidade DevOps forte na região, promovendo compartilhamento de conhecimento, colaboração entre profissionais e crescimento técnico em torno de temas que impactam diretamente a forma como times entregam software.
Também cria espaço para conversas mais práticas sobre cultura, automação, confiabilidade, observabilidade e melhoria contínua, aproximando pessoas com desafios semelhantes em contextos reais.
### Conecte-se
* 🔗 [**Linktree**](https://linktr.ee/devopsdaysfln)
* 🌐 [**Site DevOpsDays**](https://devopsdays.org/)
* 📷 [**Instagram**](https://www.instagram.com/devopsdaysfln/)
* 💼 [**LinkedIn**](https://www.linkedin.com/company/12596194/admin/dashboard/)
Estamos sempre procurando **voluntários, patrocinadores e novos palestrantes**.
Participar da organização do **DevOpsDays Florianópolis** desde 2023 significa ajudar a manter viva uma comunidade técnica local conectada a uma iniciativa global, com foco em troca de experiências, colaboração e evolução profissional.
Esse trabalho contínuo contribui para o crescimento do ecossistema regional e para a formação de um espaço cada vez mais aberto a novas conexões, novos speakers e novas discussões.
> *“Compartilhar é multiplicar.”* – cultura DevOps
---
# DevOpsDays Florianópolis 2024
URL: https://www.orafaelferreira.com/artigos/eventodod-floripa
Publicado: 2024-07-21
Categoria: Organização de Eventos
Tempo de leitura: 1 min de leitura
> Relato do DevOpsDays Florianópolis 2024, que reuniu mais de 150 participantes em um dia inteiro de talks, open spaces e networking sobre cultura DevOps.
O **DevOpsDays** é uma conferência global que une desenvolvimento, operações e cultura DevOps.
Em **16 de novembro de 2024**, Floripa recebeu +150 participantes para um dia inteiro de talks, open‑spaces e networking.
🌐 **Site oficial:** [DevOpsDays Florianópolis 2024](https://devopsdays.org/events/2024-florianopolis/welcome/)
📲 **Siga-nos nas redes sociais:** [Linktree](https://linktr.ee/devopsdaysfln)
### Galeria 📸
**Obrigado!** A mágica só acontece graças a voluntários, patrocinadores e à comunidade DevOps que compareceu em peso.
Nos vemos no **DevOpsDays Floripa 2025**! 🚀
---
# KCD Floripa Brazil 2024
URL: https://www.orafaelferreira.com/artigos/kcd-floripa24
Publicado: 2024-07-21
Categoria: Organização de Eventos
Tempo de leitura: 1 min de leitura
> Relato do KCD Floripa Brazil 2024, evento da comunidade Cloud Native Santa Catarina que reuniu profissionais de Kubernetes e código aberto em Florianópolis.
### Introdução
Os **Kubernetes Community Days (KCDs)** são eventos organizados pela comunidade que reúnem entusiastas e profissionais interessados no universo nativo da nuvem e de código aberto. Promovendo educação, colaboração e networking, os KCDs são oficialmente apoiados pela **Cloud Native Computing Foundation (CNCF)** e realizados localmente para fortalecer as comunidades regionais.
Em 2024, Florianópolis foi palco do **KCD Floripa**! Foi uma oportunidade única de aprender, se conectar com especialistas e explorar as tendências mais recentes do mundo Cloud Native.
🌐 **Site oficial:** [KCD Floripa 2024](https://community.cncf.io/events/details/cncf-kcd-brasil-presents-kcd-floripa-brasil-2024/)
👉 **Acesse nossos links:** [Linktree do evento](https://linktr.ee/cloudnativesc)
[](https://www.credly.com/badges/7091a4a1-5ab1-4a3d-a91a-8eb6407e72d5/public_url "Organizer: 2024 KCD Floripa")
---
---
# Utilizando Azure Workbooks para Otimização de Custos com FinOps
URL: https://www.orafaelferreira.com/artigos/azure-workbooks
Publicado: 2024-07-16
Categoria: Artigos
Tags: GreenOps
Tempo de leitura: 8 min de leitura
> A gestão eficaz dos custos na nuvem é um algo real e impactante para muitas organizações que adotaram a computação em nuvem.
### Introdução
A gestão eficaz dos custos na nuvem é um algo real e impactante para muitas organizações que adotaram a computação em nuvem. O FinOps ([Caso queira saber mais sobre FinOps, visite o meu artigo anterior](https://www.orafaelferreira.com/artigos/finops-foundation-cloud)), ou Operações Financeiras, é um conjunto de práticas que combinam Finanças e DevOps para otimizar a utilização e o custo dos recursos na nuvem. Uma ferramenta poderosa que a Microsoft Azure oferece para ajudar nessa tarefa é o Azure Workbooks. Neste artigo, irei utilizar o Azure Workbooks. Mas o que são Azure Workbooks?
### O que são [Azure Workbooks](https://learn.microsoft.com/pt-br/azure/azure-monitor/visualize/workbooks-overview)?
Azure Workbook são dashboards interativos e modulares que são usados para criar relatórios e visualizações no Azure Monitor. Eles permitem criar visões personalizadas que podem incluir métricas, logs e dados de outras fontes do Azure, proporcionando uma visão consolidada e interativa do ambiente de nuvem.
### Principais Benefícios do Azure Workbooks
- **Visualizações Interativas:** Crie gráficos, tabelas e relatórios interativos que podem ser personalizados para atender às necessidades específicas do negócios e operações.
- **Integração com Dados do Azure:** Combine dados de várias fontes do Azure, incluindo logs de atividades, métricas de desempenho e informações de faturamento.
- **Compartilhamento e Colaboração:** Os Workbooks podem ser compartilhados com diferentes equipes, facilitando a colaboração entre finanças, operações e TI.
- **Automação e Atualização Contínua:** Configure atualizações automáticas para garantir que os dados exibidos estejam sempre atualizados.
### Como Azure Workbooks Apoia o FinOps
1. **Monitoramento de Custos em Tempo Real**
- Utilize Azure Workbooks para criar dashboards que monitoram os custos em tempo real. Isso permite uma resposta rápida a quaisquer desvios ou aumentos inesperados de custo.
2. **Análise de Tendências de Consumo**
- Análises históricas de consumo de recursos podem ser visualizadas através de gráficos de tendência. Isso ajuda a identificar padrões de uso que podem ser otimizados.
3. **Alocação de Custos**
- Crie relatórios detalhados para alocação de custos entre diferentes departamentos ou projetos. Isso é essencial para entender quais áreas estão consumindo mais recursos e como otimizar a alocação.
4. **Identificação de Recursos Subutilizados**
- Utilize relatórios de utilização de recursos para identificar instâncias e serviços subutilizados que podem ser redimensionados ou desligados para economizar custos.
5. **Planejamento e Orçamentação**
- Utilize dados históricos e previsões para ajudar no planejamento de orçamentos futuros. Azure Workbooks pode integrar dados de várias fontes para fornecer uma visão abrangente para o planejamento financeiro.
6. **Gerenciamento de Recursos Órfãos**
- Recursos órfãos são aqueles que não estão mais sendo utilizados ativamente, mas continuam a gerar custos. Identificar e gerenciar recursos órfãos ajuda a economizar dinheiro, prevenir configurações incorretas e simplificar a gestão operacional do ambiente Azure.
### Exemplo Prático 1: Cost Optimization Workbook
#### Configuração Inicial
- [Deploy to Azure](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fquickstarts%2Fmicrosoft.costmanagement%2Foptimization-workbook%2Fazuredeploy.json/createUIDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fquickstarts%2Fmicrosoft.costmanagement%2Foptimization-workbook%2FcreateUiDefinition.json)
- Acesse o Azure Portal e navegue até o Monitor.
- Selecione "Workbooks" no menu e verifique se a sua assinatura está selecionada no filtro de assinaturas.
- Selecione o "Cost Optimization Workbook".
#### Principais Componentes do Workbook
- **Visão Geral:** Baseado no Microsoft Azure Well-Architected Framework (WAF) ([Caso queira saber mais sobre o WAF, visite o meu artigo anterior](https://www.orafaelferreira.com/artigos/well-architect-foundation-cloud)), fornece princípios para equilibrar objetivos de negócios com necessidades tecnológicas, reduzindo desperdícios e melhorando a eficiência operacional.
- **Recursos e Governança:** Indica funcionalidades implementadas que seguem os princípios de Otimização de Custos e Governança de Custos.
- **Pré-requisitos:** Requer funções mínimas de Reader e Workbook Contributor para importar e salvar o workbook, além de ações de "Quick Fix" documentadas com permissões específicas.
Na aba Usage optimization, temos a opção Top 10 services:
### Exemplo Prático 2: Azure Orphaned Resources Workbook
O Azure Orphaned Resources Workbook centraliza recursos órfãos em ambientes Azure, ajudando a melhorar a eficiência através da economia de dinheiro, prevenção de configurações incorretas e simplificação operacional.
#### Como Utilizar o [Azure Orphaned Resources Workbook](https://github.com/dolevshor/azure-orphan-resources)
1. **Importação do Workbook**
- Acesse o Azure Portal e vá para 'Azure Workbooks'.
- Clique em '+ Create' e depois em '+ New'.
- Abra o Editor Avançado usando o botão '' na barra de ferramentas.
- Selecione o 'Gallery Template'.
- Substitua o código JSON pelo código fornecido para ['Azure Orphaned Resources v2.0'](https://github.com/dolevshor/azure-orphan-resources/tree/main/Workbook) **OBS: Deixei o link para você copiar o código e sempre utilizar a versão mais atual**
- Clique em 'Apply' e depois em 'Save'.
- Insira um título, assinatura, grupo de recursos e localização para o workbook.
- Clique em 'Save'.
2. **Visualização do Workbook**
- Navegue até 'Workbooks' e clique no workbook 'Orphaned Resources'.
#### Principais Componentes do Workbook
- **Tipos de Recursos Incluídos:**
- Compute
- App Service Plans
- Storage
- Managed Disks
- Public IPs
- Load Balancers
- Application Gateways
- Virtual Networks
- Private Endpoints
- Virtual Network Gateways
- Outros (Resource Groups, API Connections, Certificates)
#### Benefícios do Workbook
- **Economia de Dinheiro:** Identifica recursos órfãos que ainda geram custos desnecessários.
- **Prevenção de Misconfiguração:** Ajuda a evitar configurações incorretas mantendo a infraestrutura organizada.
- **Simplificação Operacional:** Centraliza a visualização de recursos órfãos, facilitando a gestão e manutenção do ambiente Azure.
#### Abaixo seguem alguns exemplos:
Orphaned App Service Plans:
Orphaned Application Gateway:
Orphaned Managed Disks, podemos fazer o download do conteúdo conforme imagem:
Esse é um exemplo da planilha que é exportada, podemos então apresentar aos times responsáveis para possível exclusão dos recursos.
### Exemplo Prático 3: Azure FinOps Workbook
O Azure FinOps Workbook fornece insights, documentos chaves e orientações sobre a implementação de FinOps e otimização de custos no Azure. Ele visualiza os dados do seu ambiente Azure junto com recomendações e guias relevantes, incentivando uma abordagem orientada por dados.
#### Como Utilizar o [Azure FinOps Workbook](https://github.com/ms-sambell/azure-finops-workbook/tree/main?tab=readme-ov-file)
1. **Importação do Workbook**
- Copie o [conteúdo](https://github.com/ms-sambell/azure-finops-workbook/blob/main/workbook.json) do arquivo `workbook.json`.
- Acesse a página de Azure Workbooks e clique em "New".
- Clique no botão de código ``.
- Cole o conteúdo copiado na página e clique em "Apply".
- Salve o workbook (se tiver permissões) e clique em "Done Editing".
#### Principais Componentes do Workbook
- **Inclusões:**
- Auditoria de Licença Híbrida
- Auditoria de Tagging
- Exemplos práticos de FinOps / Automação
- Insights de otimização de custos para Storage Accounts, AKS, Log Analytics, recursos órfãos, Recovery Services, App Services e VMs.
#### Requisitos para Utilização
- **Permissões:** Acesso de leitura aos recursos que você está investigando no Azure. Para salvar o workbook, você precisa de permissões para criar um Azure Workbook.
- **AKS:** Informações de AKS requerem o uso do Container Insights.
- **Recomendação:** Acesso de leitura sobre toda a assinatura/grupos de gerenciamento para ativar todos os painéis do workbook.
Na sessão de Governance temos Tag:
E essa que considere uma das melhoras melhor: Cost Optimization
### Reflexão
Mas você deve estar se perguntando, a mas vou utilizar somente um, por exemplo, o último do FinOps que possui todas as informações. Mas lembre-se sempre, nenhum remédio irá te curar de todas as dores, nada melhor que usar algo específico para a sua dor!
### GreenOps: Como Azure Workbooks é um Aliado na Gestão Sustentável
Azure Workbooks pode ser um aliado poderoso para práticas de GreenOps, fornecendo dashboards e insights que facilitam a gestão sustentável nas operações de TI. Para mais informações sobre GreenOps, visite meu artigo completo [aqui](https://www.orafaelferreira.com/artigos/finops-foundation-cloud). Aqui estão algumas formas de como Azure Workbooks pode ajudar:
1. **Identificação de Recursos Subutilizados**
- Azure Workbooks ajuda a identificar recursos subutilizados, permitindo ajustes ou desativações para reduzir o consumo de energia e os custos operacionais.
2. **Análise de Padrões de Uso**
- Fornece gráficos e análises que permitem observar padrões de uso, possibilitando ajustes operacionais para otimizar o uso de energia.
3. **Otimização de Custos e Recursos**
- Facilita a identificação de áreas para redução de custos, alinhando a gestão de recursos com os objetivos de sustentabilidade.
4. **Implementação de Práticas Sustentáveis**
- Com os insights obtidos, é possível implementar práticas que promovam a sustentabilidade, como a escolha de recursos energeticamente eficientes.
Ao integrar Azure Workbooks em suas práticas de GreenOps, você pode melhorar a sustentabilidade e a eficiência de suas operações de TI.
### Conclusão
Azure Workbooks é uma ferramenta poderosa que pode ser utilizada para apoiar práticas de FinOps, proporcionando uma melhor visibilidade e controle sobre os custos na nuvem. Ao integrar dados de diversas fontes e criar visualizações interativas, as organizações podem otimizar sua utilização de recursos, melhorar o planejamento financeiro e garantir uma operação de nuvem mais eficiente e econômica.
---
---
# Antes do Cloud Native: Construindo uma Fundação Sólida para a Nuvem Impactando um Futuro Sustentável
URL: https://www.orafaelferreira.com/artigos/antes-cloud-native-fundacao-solida
Publicado: 2024-07-14
Categoria: Artigos
Tags: GreenOps, Terraform
Tempo de leitura: 38 min de leitura
> Como Green Computing, Cloud Foundation, DevOps, FinOps e Observabilidade constroem uma base sólida para a nuvem e impactam a sustentabilidade ambiental.
### Introdução
Em um mundo cada vez mais digital, inovações em tecnologias Cloud Native não são apenas uma questão de avanço tecnológico, mas também impactam mudança social e ambiental. Esta jornada começou com a compreensão de como uma Cloud Foundation, DevOps, FinOps, e a Observabilidade não apenas definem o futuro de uma empresa, mas impactam diretamente em uma responsabilidade social e sustentabilidade ambiental.
### O Papel da Computação Verde
A Green Computing vai além da eficiência energética, englobando a escolha de materiais sustentáveis, redução de resíduos eletrônicos e promoção da reciclagem. Em data centers, práticas como uso de energia renovável e otimização de servidores são fundamentais para reduzir o impacto ambiental.
### Impacto Ambiental
A conscientização sobre o impacto ambiental da tecnologia é crucial para promover práticas sustentáveis no setor de TI. Aqui estão alguns dados que destacam a importância da eficiência energética e da gestão ambiental responsável em tecnologias de TI:
1. **Resíduos Eletrônicos Globais**: Em 2019, aproximadamente 54 milhões de toneladas de resíduos eletrônicos foram gerados mundialmente, mas somente 17% receberam reciclagem adequada.
2. **Exportação de Resíduos Eletrônicos dos EUA**: As regulamentações federais norte-americanas atualmente permitem a exportação de lixo eletrônico, o que representa uma ameaça global à saúde humana. Estima-se que entre 5% a 30% dos 40 milhões de computadores usados nos EUA foram exportados para países em desenvolvimento em 2010. Em 2016, a Basel Action Network descobriu que 34% do lixo eletrônico monitorado nos EUA foi enviado para o exterior, quase todo para países em desenvolvimento.
3. **Eficiência Energética em Data Centers**: Em 2014, os data centers dos EUA consumiram 70 bilhões de kWh de eletricidade, As tecnologias e estratégias de design eficientes existentes podem reduzir o uso de energia dos servidores em 25% ou mais, enquanto as melhores práticas de gerenciamento e consolidação de servidores podem diminuir o consumo de energia em até 20%. A eletricidade utilizada por servidores e data centers nos EUA resulta na emissão de 28,4 milhões de toneladas métricas de CO2e anualmente.
4. **Teletrabalho e Consumo de Energia**: O teletrabalho durante a pandemia de COVID-19 em 2020 levou a uma redução de 13% no consumo de energia relacionado ao trabalho e a uma diminuição de 14% nas emissões de gases de efeito estufa.
5. **Redução de Energia em Equipamentos de Escritório**: Em 2018, computadores e equipamentos de escritório foram responsáveis por 13% do consumo total de eletricidade (227 bilhões de kWh) em edifícios de escritórios. A implementação de modos de baixo consumo de energia em equipamentos de escritório poderia reduzir seu consumo energético em 23%. Se todos os computadores desktop e impressoras fossem desligados à noite, o consumo de energia poderia ser reduzido em mais 9%.
Estas estatísticas destacam a necessidade de práticas sustentáveis no uso e gestão de tecnologias de TI, reforçando a importância de estratégias conscientes em computação verde e sustentabilidade ambiental.
[Fonte: Center for Sustainable Systems](https://css.umich.edu/factsheets/green-it-factsheet)
### Padrões de Software Verde
A Green Software Foundation estabeleceu um banco de dados de padrões de software verde, que são mantidos e revisados por especialistas. Estes padrões são essenciais para garantir que a aplicação diminua emissões de carbono. O catálogo de padrões disponibilizado é amplo e abrange uma variedade de categorias, garantindo que profissionais de software encontrem práticas aplicáveis aos seus respectivos campos, tecnologias ou domínios.
- **Green Software Foundation:** [Informações sobre padrões e práticas sustentáveis](https://greensoftware.foundation/)
- **Green Software Patterns:** [Documentação sobre padrões de software verde.](https://patterns.greensoftware.foundation/)
### Princípios, Padrões e Práticas
Os princípios de software verde fornecem um conjunto fundamental de competências necessárias para definir, executar e construir software sustentável. Já os padrões oferecem exemplos práticos de como aplicar esses princípios em cenários do mundo real, de forma neutra em relação a fornecedores. As práticas são padrões aplicados a produtos específicos de fornecedores, orientando os profissionais sobre como usar esses produtos de maneira mais sustentável.
### Estratégias de Implementação
Na implementação de infraestruturas Cloud Native bem desenhadas, a adoção de frameworks bem-estruturados, como o Cloud Adoption Framework e o Well-Architected Framework, são essenciais. Esses frameworks auxiliam na criação de sistemas que são eficientes e performáticos, mas também ambientalmente responsáveis.
#### Cargas de Trabalho Sustentáveis no Azure
Abordando a sustentabilidade dentro do Azure, existe uma seção do Microsoft Azure Well-Architected Framework destinada a oferecer diretrizes para enfrentar os desafios de criação de ambientes com cargas de trabalho sustentáveis. Essas diretrizes aplicam práticas recomendadas com uma base técnica para construir e operar soluções sustentáveis, atendendo às necessidades comerciais e promovendo práticas ambientalmente responsáveis no Azure.
##### O que é uma carga de trabalho sustentável?
Refere-se a uma coleção de softwares que suportam um objetivo comercial comum, focando no impacto ambiental destas cargas de trabalho. Uma carga de trabalho sustentável descreve como prática de criar soluções que maximizam a utilização, minimizando o desperdício e a pegada ambiental. A eficiência das cargas de trabalho na nuvem combina otimização de custos, redução das emissões de carbono e otimização do consumo de energia.
##### Desafios Comuns na Implementação de Cargas de Trabalho Sustentáveis
Ao implementar cargas de trabalho sustentáveis, especialmente no contexto do Azure, enfrentamos desafios únicos:
- **Alinhamento com Metas de Sustentabilidade:** Avaliar e ajustar cargas de trabalho existentes para garantir que estejam em conformidade com os objetivos ambientais estabelecidos.
- **Design Otimizado para o Meio Ambiente:** Criar cargas de trabalho que sejam eficientes e ecologicamente corretas por natureza, minimizando o impacto ambiental.
- **Medição das Emissões:** Monitorar e acompanhar rigorosamente as emissões de carbono associadas às cargas de trabalho para avaliar o progresso em direção às metas de sustentabilidade.
##### Principais Áreas de Design para Sustentabilidade
Ao considerar a sustentabilidade em cargas de trabalho, focamos nas seguintes áreas principais de design:
1. **Design do Aplicativo:** Incorporar padrões de nuvem sustentáveis para desenvolver cargas de trabalho ecologicamente corretas.
2. **Plataforma de Aplicativos:** Escolher ambientes de hospedagem e dependências que priorizem a eficiência energética e a sustentabilidade.
3. **Testes:** Implementar estratégias de CI/CD e automação para realizar testes de software de forma mais sustentável.
4. **Procedimentos Operacionais:** Estabelecer processos que suportem operações sustentáveis e redução do impacto ambiental.
- **Sustentabilidade Além de Desempenho e Custo**
Além da eficiência de desempenho e otimização de custos, outras áreas como segurança, confiabilidade e excelência operacional são essenciais para criar cargas de trabalho sustentáveis de longo prazo no Azure.
- **Benefícios do Carbono da Computação em Nuvem:** [Um estudo da Nuvem da Microsoft](https://info.microsoft.com/ww-landing-Carbon-Benefits-of-Cloud-Computing.html?lcid=pt-br) sobre eficiência energética e de carbono do Azure.
##### Azure Carbon Optimization
O Azure Carbon Optimization é uma ferramenta inovadora da Microsoft que capacita organizações a medir e reduzir o impacto de carbono de sua infraestrutura na nuvem. Oferecendo dados detalhados de emissões por recursos, assinaturas e localizações, esta ferramenta integra-se perfeitamente ao portal do Azure, permitindo um acesso simplificado e baseado em permissões RBAC do Azure. Com recomendações práticas para otimização de recursos, o Azure Carbon Optimization não apenas ajuda a alcançar metas de sustentabilidade, mas também promove uma gestão de recursos mais eficiente e econômica. Este serviço destaca o compromisso da Microsoft com a responsabilidade ambiental, fornecendo insights valiosos e ações concretas para reduzir a pegada de carbono na nuvem. Outras ofertas de sustentabilidade da Microsoft [Microsoft Sustainability Manager,](https://learn.microsoft.com/en-us/industry/sustainability/sustainability-manager-overview) [Painel de Impacto de Emissões](https://learn.microsoft.com/en-us/power-bi/connect-data/service-connect-to-emissions-impact-dashboard?toc=%2Findustry%2Fsustainability%2Ftoc.json&bc=%2Findustry%2Fbreadcrumb%2Ftoc.json) e [Os insights de emissões do Microsoft Azure (versão prévia)](https://learn.microsoft.com/en-us/industry/sustainability/sustainability-data-solutions-overview)
### O que é Green Software?
Podemos dizer que Green Software é uma disciplina emergente que está diretamente envolvida por ciência climática, design de software, mercados de eletricidade, hardware e design de data centers. É focada na criação de software que seja eficiente em termos de carbono, emitindo o mínimo possível de carbono.
### Como Ser um Praticante de Green Software
O que um praticante de Green Software deve conhecer:
- **Eficiência de Carbono:** Emitir a menor quantidade de carbono possível.
- **Eficiência Energética:** Usar a menor quantidade de energia possível.
- **Consciência de Carbono:** Fazer mais quando a eletricidade for mais limpa e menos quando for mais suja.
- **Eficiência de Hardware:** Usar a menor quantidade de carbono incorporado possível.
- **Medição:** O que não pode ser medido, não pode ser melhorado.
- **Compromissos Climáticos:** Entender o mecanismo exato de redução de carbono.
### Iniciativas para um Impacto Ambiental Positivo
Na busca pela sustentabilidade e redução da pegada de carbono, várias estratégias podem ser empregadas, sendo as mais comuns o abatimento, a compensação e a neutralização de carbono. Vamos explorar cada uma delas:
1. **Abatimento:** Esta estratégia foca na redução direta das emissões de gases de efeito estufa. Isso pode ser alcançado através da implementação de tecnologias mais limpas, mudança de comportamentos e práticas operacionais, como a utilização de fontes de energia renováveis e a otimização da eficiência energética em processos e edifícios.
2. **Compensação:** A compensação envolve o investimento em projetos externos que reduzem as emissões de carbono, como projetos de reflorestamento ou de energia renovável. Esses projetos geram créditos de carbono, que podem ser utilizados para "compensar" as emissões que não podem ser eliminadas internamente.
3. **Neutralização:** A neutralização de carbono é o processo de alcançar um equilíbrio líquido zero nas emissões de carbono, combinando abatimento com compensações para neutralizar completamente o impacto de carbono de uma organização ou produto. Isso é frequentemente referido como alcançar "carbono neutro" ou "net zero".
Cada uma dessas estratégias desempenha um papel importante na mitigação das mudanças climáticas e na transição para uma economia de baixo carbono. No contexto de Cloud Native e Green Software, esses compromissos orientam as decisões e práticas, desde o planejamento e design de software até a escolha de fornecedores e tecnologias.
Explorando novas fronteiras em sustentabilidade, a Microsoft testou um [Datacenter Subaquático](https://news.microsoft.com/pt-br/no-fundo-do-mar-a-microsoft-testa-um-datacenter-rapido-de-implantar-que-pode-fornecer-conectividade-a-internet-por-anos/), visando uma implementação rápida e um menor impacto ambiental. Este projeto demonstra o potencial de soluções inovadoras em data centers para alcançar uma maior sustentabilidade.
Para entender melhor como a eficiência energética é implementada na prática, confira este [Tour virtual em um dos datacenters da Microsoft](https://news.microsoft.com/pt-br/microsoft-revela-tour-virtual-em-um-de-seus-datacenters/#:~:text=A%20Microsoft%20disponibilizou%20hoje%20um,hardware%20e%20software%20que%20mant%C3%AAm), onde são empregadas tecnologias inovadoras para otimizar o uso de energia.
### Importância da Medição e Avaliação
Uma medição das emissões de gases de efeito estufa é ideal para compreender e melhorar o impacto ambiental das organizações. Abaixado dois exemplos de métricas:
- **Protocolo de Gases de Efeito Estufa (GHG Protocol):** Uma ferramenta internacionalmente reconhecida para a contabilização e relatório de emissões de GEE, oferecendo um quadro abrangente para medir emissões diretas e indiretas.
- **Intensidade de Carbono de Software (SCI):** Uma métrica específica para avaliar a quantidade de emissões de GEE por unidade de funcionalidade em aplicações de software, ajudando desenvolvedores e organizações de tecnologia a otimizarem o impacto ambiental de suas soluções.
### Ações para Redução de Carbono
Três ações essenciais para reduzir as emissões de carbono do software:
1. **Utilizar menos recursos físicos:** Reduzindo a necessidade de hardware e energia para sua produção e funcionamento.
2. **Reduzir o consumo de energia:** Otimizando o software para ser mais eficiente em termos de energia.
3. **Uso inteligente de energia:** Preferindo fontes de energia de baixo carbono.
### Cultura DevOps e FinOps
A cultura DevOps, com seu foco em eficiência e automação, está alinhada com os objetivos de sustentabilidade. O FinOps, concentrando-se na otimização de custos e recursos, permitindo criar infraestruturas que maximizam a eficiência e minimizam o desperdício, apoiando a sustentabilidade no longo prazo.
### Observabilidade e Sustentabilidade
A observabilidade detalhada é um componente crítico para a construção de sistemas Cloud Native sustentáveis. Ela envolve a coleta, monitoramento e análise de dados, permitindo uma compreensão profunda do comportamento do sistema e o uso dos recursos. Ao aplicar práticas de observabilidade, as equipes de TI podem identificar e mitigar ineficiências, reduzir o consumo de energia e melhorar a performance, alinhando-se assim aos princípios de sustentabilidade.
### Computação Verde e Cloud Native
A integração da computação verde no Cloud Native reflete uma mudança cultural significativa, onde cada dado processado, leva em conta seu impacto ambiental. Ao implementar padrões de software verde, como os propostos pela Green Software Foundation, estamos garantindo que o caminho para inovações, respeitem o nosso meio ambiente, demonstrando que é possível alcançar excelência tecnológica sem comprometer a saúde do nosso planeta.
### Contribuição para o Ecosistema Open Source
A adoção de práticas sustentáveis oferece uma oportunidade para contribuir de volta ao ecosistema Open Source. Desenvolvendo melhorias e plugins baseados em observações detalhadas e compartilhando conhecimento e melhores práticas, as organizações não apenas se beneficiam, mas também enriquecem o Open Source. Esta colaboração e compartilhamento são fundamentais para fortalecer a comunidade e promover um futuro promissor para tecnologias Cloud Native.
### GreenOps: o futuro já chegou?
Pesquisas da Gartner revelam que as tecnologias voltadas para a sustentabilidade estão entre as três principais tendências para 2024. A projeção é que, até 2027, cerca de 25% da remuneração dos CIOs será determinada pelo impacto de suas iniciativas tecnológicas sustentáveis.
### Conclusão: Um Chamado para a Mudança
Como profissionais de tecnologia, temos a possibilidade de liderar a transformação para práticas sustentáveis. Podemos adotar princípios de sustentabilidade, contribuindo ativamente para um futuro mais verde. Este artigo serve como auxílio para todos os profissionais de TI e todas áreas que tem interesse em integrar a sustentabilidade em suas práticas, promovendo um avanço tecnológico que proteja nosso planeta para as futuras gerações.
Ao adotar práticas sustentáveis e responsáveis, não estamos apenas moldando o futuro da tecnologia, mas também o futuro do nosso planeta e da humanidade. Cada passo em direção à sustentabilidade é um passo em direção a um legado duradouro que beneficiará não apenas a nossa geração, mas muitas que virão.
#### Ferramenta de Revisão de Avaliação
Avalie sua aplicação do Microsoft Sustainability Manager em diferentes estágios do processo de implementação, examinando várias categorias para orientar um deployment bem estruturado.
**Em qual fase ou etapa você gostaria de avaliar a implementação da sua solução Microsoft Sustainability Manager?**
Inicie sua avaliação com a [Microsoft Sustainability Manager - Avaliação Bem-Estruturada](https://learn.microsoft.com/pt-br/assessments/333d9326-e34c-40e1-88d9-8342afceec36/).
- **Planejamento:** Avalie a prontidão do planejamento do MVP do seu Sustainability Manager.
- **Design:** Avalie as considerações de design do seu Sustainability Manager.
- **Go-Live:** Avalie a prontidão para implantação e entrada em funcionamento do seu Sustainability Manager.
Existem um segunda opção de avaliação. Examine sua carga de trabalho por meio da lente de sustentabilidade.
Inicie sua avaliação com a [Sustentabilidade - Revisão Bem Arquitetada](https://learn.microsoft.com/pt-br/assessments/f236012a-0070-45db-b94c-fe8de0799f38/).
---
[](https://www.credly.com/badges/11e2e57b-47a9-48ca-af23-41cbb45c01ef/public_url "LFC131: Green Software for Practitioners")
---
# Plataformização de Arquitetura de Dados com Backstage.io e IAC - TDC Florianópolis - Trilha Arquitetura de Dados 2024
URL: https://www.orafaelferreira.com/artigos/talk-tdc
Publicado: 2024-06-25
Categoria: Palestras
Tags: Platform Engineering
Tempo de leitura: 3 min de leitura
> No TDC Florianópolis 2024, tive a honra de palestrar na Trilha de Arquitetura de Dados, ao lado de meu amigo Cláudio Filipe Lima Rapôso.
##### Introdução
No TDC Florianópolis 2024, tive a honra de palestrar na [Trilha de Arquitetura de Dados](https://thedevconf.com/tdc/2024/florianopolis/trilha-arquitetura-de-dados), ao lado de meu amigo [Cláudio Filipe Lima Rapôso](https://www.linkedin.com/in/cfraposo/). Nossa palestra focou na Plataformização de Arquitetura de Dados utilizando Backstage.io e IaC (Infrastructure as Code), trazendo a importância de uma gestão eficiente e automatizada na infraestrutura.
##### Data e Local
- **Data:** Sexta-feira, 14 de Junho de 2024
- **Local:** CentroSul, Av. Governador Gustavo Richard, 850 / Centro Florianópolis - SC
##### O Evento
O [TDC](https://thedevconf.com/tdc/2024/index.html) é um evento de destaque no cenário tecnológico brasileiro, oferecendo um local para profissionais de TI compartilharem conhecimentos, experiências e inovações.
##### O Tema da Palestra
Nossa apresentação abordou a plataformização da arquitetura de dados com Backstage.io e Terraform, ferramentas essenciais para a centralização e automação dos serviços relacionados aos dados.
##### Análise da Palestra
A palestra explorou a visão e os desafios da criação de uma plataforma unificada para gerenciar infraestruturas de cloud, destacando a complexidade crescente dessas arquiteturas e a necessidade de consistência e eficiência entre múltiplas equipes. Demonstramos como o uso de Infraestrutura como Código (IaC) com ferramentas como Terraform e Backstage.io pode facilitar essa unificação e governança centralizada.
Os principais pontos abordados foram:
- **Visão e Desafios**: Planejamento eficiente para integração na nuvem.
- **Ferramentas Mágicas**: Integração do Backstage.io com Terraform para suporte multi-cloud, automação e eficiência.
- **Escolha do Ferramental**: Plataforma open-source que facilita a criação de templates dinâmicos para desenvolvimento, infraestruturas e DevOps.
- **Benefícios**: Aumento na produtividade, redução de erros humanos, aceleração no time-to-market e satisfação do cliente.
- **Slides da Apresentação:** [Plataformização de Arquitetura de Dados com Backstage.io e IAC](https://stoblobcertificados011.blob.core.windows.net/palestras/TDC.pdf)
##### Momentos Destacados
Durante a palestra, demonstramos casos práticos de como essas ferramentas podem simplificar e otimizar o fluxo de trabalho em projetos de dados. Compartilhamos insights sobre a integração de Backstage.io com Terraform para criar uma infraestrutura robusta e escalável, que pode ser gerida de forma eficiente. E para quem se perguntou da qualidade das fotos, sim, é isso, tivemos um fotógrafo profissional ([Erivaldo Lopes](https://www.linkedin.com/in/erivaldolopes/))!
##### Reflexões e Aprendizados
Palestrar no TDC Floripa foi uma experiência enriquecedora. Além de compartilhar conhecimento, tive a oportunidade de aprender com outros profissionais e expandir minha rede de contatos. A interação com o público foi dinâmica, com perguntas que geraram discussões profundas sobre os desafios e oportunidades na arquitetura de dados.
##### Certificado
##### Conclusão
Eventos como o TDC são cruciais para o avanço da tecnologia no Brasil, oferecendo uma plataforma para troca de conhecimentos e experiências. A trilha de Arquitetura de Dados, em particular, destacou-se por sua relevância e pelos insights valiosos compartilhados pelos palestrantes.
Que venham os próximos desafios e oportunidades!
---
---
# Episódio Especial do Podcast LowOpsCast no TDC
URL: https://www.orafaelferreira.com/artigos/podcast
Publicado: 2024-06-23
Categoria: Registro Eventos Presenciais
Tempo de leitura: 3 min de leitura
> Gravei um episódio especial do LowOpsCast no TDC Florianópolis 2024, com apoio da Ambev Tech, entrevistando profissionais da comunidade sobre cloud e DevOps.
### Introdução
No maior evento de desenvolvimento de software da América Latina, The Developer’s Conference (TDC), tive a oportunidade de gravar um episódio especial do meu podcast [LowOpsCast](https://open.spotify.com/show/0U4kcZT2Cwn4CqQGg4Ywcj?si=f725a4c467144597). Com o apoio da Ambev Tech, entrevistei profissionais incríveis que compartilharam suas experiências e insights sobre a sensação de palestrar no TDC e coordenar as trilhas, além de discussões sobre edições passadas. Neste artigo, vou contar como foi essa experiência.
### O que é The Developer’s Conference?
O The Developer’s Conference [TDC](https://thedevconf.com/tdc/2024/index.html)é o maior encontro de profissionais de tecnologia do Brasil. Este evento dinâmico conecta organizadores de meetups, palestrantes, empresas e patrocinadores, criando uma plataforma única que empodera o ecossistema tecnológico local. Durante o TDC, são apresentadas as tendências mais atuais e relevantes por meio de mais de dez trilhas paralelas diárias, cada uma organizada por especialistas da área.
### A Experiência de Gravação
Foi criado um espaço de estúdio de gravação no evento. Durante o episódio, entrevistei duas turmas de participantes, cada uma composta por três convidados. O bate-papo foi repleto de histórias inspiradoras e insights para futuros palestrantes do TDC.
#### Primeira Entrevista: Erivaldo, Claudio e Marina
Na segunda parte do nosso episódio, conversei com Amin, Rafael e Thiago.
Nesta primeira rodada, contou com Erivaldo, Claudio e Marina.
#### Segunda Entrevista: Amin, Rafael e Thiago
Na segunda parte do nosso episódio, conversei com Amin, Rafael e Thiago.
### Bastidores e Momentos Marcantes
As fotos dos bastidores dizem por si só. A energia do TDC e o suporte da Ambev Tech criaram um ambiente perfeito para a troca de conhecimentos e ideias. Cada momento foi capturado em fotos, que ilustram a dedicação e entusiasmo de todos os envolvidos.
### Apoiadores e Parceiros
Gostaria de agradecer à Ambev Tech e toda equipe do TDC pelo seu apoio. Eles não apenas patrocinaram o estúdio de gravação, mas também contribuíram para a qualidade e o alcance do nosso conteúdo.
### Conclusão
O episódio especial do podcast gravado no The Developer’s Conference foi uma experiência única e enriquecedora. Agradeço a todos os nossos convidados e apoiadores que tornaram isso possível. Fique atento para mais episódios e continue nos acompanhando para insights sobre como alavancar sua carreira.
---
---
# Plataformização da Cloud Foundation com Backstage: Desvendando os Segredos da Eficiência na Nuvem com Developer Experience - Esquenta TDC - KuberTENes Birthday Bash Santa Catarina + Azure Floripa + API Floripa
URL: https://www.orafaelferreira.com/artigos/kubertenes
Publicado: 2024-06-17
Categoria: Palestras
Tags: Platform Engineering
Tempo de leitura: 3 min de leitura
> No dia 11 de junho de 2024, rolou o KuberTENes Birthday Bash Santa Catarina, um evento organizado pela comunidade Cloud Native Santa Catarina.
No dia 11 de junho de 2024, rolou o [**KuberTENes Birthday Bash Santa Catarina**](https://community.cncf.io/events/details/cncf-cloud-native-santa-catarina-presents-6o-kubertenes-birthday-bash-santa-catarina/), um evento organizado pela comunidade [**Cloud Native Santa Catarina**](https://community.cncf.io/cloud-native-santa-catarina/). Este evento híbrido foi realizado para comemorar os 10 anos do Kubernetes, uma tecnologia que revolucionou o mundo da computação em nuvem e continua a ser um pilar essencial para arquiteturas modernas.
O evento não apenas celebrou uma década de Kubernetes, mas também serviu como um pré-esquenta para o The Developer's Conference (TDC), que aconteceu nos dias seguintes. Tivemos uma agenda repleta de palestras.
### Agenda do Meetup
#### Kubernetes 10 Anos: Hacking Kubernetes v1.0.0
A abertura do evento trouxe uma retrospectiva dos 10 anos de Kubernetes, onde [Amim Knabben](https://www.linkedin.com/in/amim/) subiu uma versão do Kubernetes 1.0.0 ao vivo, mostrando na prática a evolução da plataforma.
#### Plataformização da Cloud Foundation com Backstage: Desvendando os Segredos da Eficiência na Nuvem com Developer Experience
Uma palestra do **Azure Floripa** ([eu](https://www.linkedin.com/in/orafaelferreiraa/) e o [Cláudio Raposo](https://www.linkedin.com/in/cfraposo/)), que abordou como a plataformização da Cloud Foundation com Backstage pode otimizar a eficiência na nuvem, melhorando a experiência dos desenvolvedores.
#### Envoy: Explorando Edge Proxy, Service Proxy e API Gateway
Apresentação do **API Floripa** com [Rafael Mateus](https://www.linkedin.com/in/rafaelbmateus/) sobre o Envoy, detalhando suas funcionalidades como Edge Proxy, Service Proxy e API Gateway, e como ele pode ser integrado a arquiteturas modernas de microsserviços.
#### AWS Party Rock
Apresentação do [Flávio Pimenta](https://www.linkedin.com/in/flaap/) sobre a ferramenta open source da AWS Party Rock, destacando suas funcionalidades e benefícios para projetos com IA.
#### Comemoração do Aniversário do Kubernetes
Teve a comemoração do aniversário do Kubernetes, onde cantamos parabéns e cortamos o bolo, devorando todas essas delicias.
#### Eficiência em Logs com Grafana Loki e Kubernetes
[Erivaldo Lopes](https://www.linkedin.com/in/erivaldolopes/) nos levou a uma exploração profunda de como o Grafana Loki pode ser utilizado em conjunto com Kubernetes para gerenciamento eficiente de logs, uma ferramenta crucial para monitoramento e observabilidade.
E para quem se perguntou da qualidade das fotos, sim, é isso, tivemos um fotógrafo profissional!
#### Encerramento
Seguimos com um animado happy hour, proporcionando uma excelente oportunidade para networking e risadas. Um ambiente descontraído e divertido, permitindo uma troca de ideias mais informal e a formação de novas conexões profissionais.
Se você não teve a oportunidade de comparecer a este evento, não se preocupe, você pode conferir a gravação no Youtube:
[](https://www.youtube.com/watch?v=iACjUNbhnaM)
---
# Curso AZ-900 - Fundamentos da Azure 2024
URL: https://www.orafaelferreira.com/artigos/curso-az-900
Publicado: 2024-06-10
Categoria: Organização de Eventos
Tempo de leitura: 2 min de leitura
> Agradecimento pelo Sucesso do Evento AZ-900: Fundamentos do Azure 📢
Agradecimento pelo Sucesso do Evento AZ-900: Fundamentos do Azure 📢
Gostaríamos de expressar nossa mais sincera gratidão a todos que participaram do evento AZ-900: Fundamentos do Azure, realizado 08 de junho de 2024, na Igreja Batista de Forquilhinhas que cedeu toda infraestrutura para acontecer o evento.
Foi uma oportunidade incrível para explorar os conceitos fundamentais da computação em nuvem e os serviços da plataforma Azure da Microsoft. A presença e o entusiasmo de cada um de vocês foram essenciais para o sucesso do evento.
Durante o curso, abordamos tópicos cruciais como os modelos de serviço (IaaS, PaaS, SaaS), alta disponibilidade, escalabilidade, resiliência, e muitos outros. A dedicação dos alunos e a qualidade das interações foram destacáveis, enriquecendo o aprendizado e preparando todos para o exame de certificação AZ-900.
Agradecemos a todos os participantes por tornarem este evento memorável. Estamos ansiosos para vê-los avançar em suas carreiras de TI e explorar novas certificações no ecossistema do Azure.
- **Saiba mais:** [AZ-900 - Fundamentos da Azure](https://www.eventbrite.com.br/e/az-900-tickets-885187528727)
- [**Post Linkedin**](https://www.linkedin.com/posts/rafaelmaferreira_ai900-fundamentos-az900-activity-7205901535577300992-nB1S?utm_source=share&utm_medium=member_desktop)
- **Slides da Apresentação:** Utilizado Material Oficial da Microsoft fornecido para MCT's.
Até o próximo evento!
Spoilers: Será o DP900 #Fundamentos de Dados do Azure
Instrutores:
👨🏫 [Cláudio Raposo](https://www.linkedin.com/in/cfraposo/) - [Msc Degree at MUST University | Microsoft MVP | Microsoft MCT ]
Especialista em Desenvolvimento de Software, com mais de 10 anos de experiência e formação em Análise de Sistemas e Engenharia.
👨🏫 [Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/) (eu) - [Microsoft MCT]
Senior DevOps Engineer com especialização arquiteturas em nuvem Azure com mais de uma década de experiência em TI, 17 certificações técnicas e formado em Ciência da Computação.
#AZ900 #AzureFundamentals #CloudComputing #MicrosoftAzure #Certificação #ConectaCloud #TI #Agradecimento #Evento #IgrejaBatistaForquilhinhas #MicrosoftMVP #MicrosoftMCT #mvp #mvpbuzz #mvpbr
---
# Configuração de um repositório no Github
URL: https://www.orafaelferreira.com/artigos/config-repository
Publicado: 2024-06-06
Categoria: Artigos
Tempo de leitura: 5 min de leitura
> Este artigo serve como uma base introdutória para futuros tutoriais relacionados à configuração de repositórios no GitHub.
### Introdução
Este artigo serve como uma base introdutória para futuros tutoriais relacionados à configuração de repositórios no GitHub. Vamos abordar os passos iniciais para criar e configurar um repositório no GitHub, adicionar uma chave SSH para autenticação segura e realizar operações básicas de Git.
#### Primeiramente, O que é Git?
Git é um sistema de controle de versão distribuído, amplamente utilizado por desenvolvedores em todo o mundo para gerenciar e acompanhar mudanças no código-fonte durante o desenvolvimento de software. Ele permite que múltiplos desenvolvedores trabalhem no mesmo projeto simultaneamente, mantendo um histórico completo de todas as alterações e facilitando a colaboração e o gerenciamento de versões.
#### O GitHub é de comer?
GitHub é uma plataforma de hospedagem de repositórios Git na nuvem. Ele fornece uma interface web amigável e uma série de ferramentas e funcionalidades que facilitam o gerenciamento de projetos de software, colaboração entre desenvolvedores, revisão de código e integração contínua. Além disso, GitHub é um ponto de encontro para desenvolvedores de todo o mundo compartilharem projetos open source, contribuírem com melhorias e colaborarem em projetos de interesse comum.
Neste artigo, vamos guiá-lo através dos passos necessários para começar a utilizar Git e GitHub, desde a criação de um repositório até a configuração de chaves SSH e a execução de operações básicas de Git.
### Passo 1: Criação de um novo repositório no GitHub
1. Acesse GitHub e faça login na sua conta.
2. Clique no ícone "+" no canto superior direito e selecione "New repository".
3. Nomeie seu repositório como example.
4. Selecione a opção "Public" para tornar o repositório acessível a todos.
5. Não adicione um README, pois vamos seguir com comandos para criar e configurar um manualmente.
6. Clique em "Create repository".
**GitHub:** [example](https://github.com/orafaelferreiraa/example)
### Passo 2: Adicionar chave SSH ao GitHub
1. No GitHub, clique na sua foto no canto superior direito e vá para "Settings".
2. No menu lateral, selecione "SSH and GPG keys".
3. Clique em "New SSH key".
### Passo 3: Gerar uma chave SSH
Abra o terminal e gere uma chave SSH com o comando:
```bash
ssh-keygen
```
OBS: Para fins didáticos, estou gerando uma chave sem senha para facilitar nosso laboratório. Crianças, nunca façam isso em produção :D
```bash
cat /home/raafel/.ssh/id_rsa.pub
```
Copie toda a informação que e exibida após o comando cat e retorne para o GitHub.
Na mesma tela que paramos, coloque o nome do seu computador, por exemplo: vm-example no titulo e copie o conteúdo da chave, conforme imagem abaixo:
### Passo 4: Configuração mínima para o Git
Realize a configurção mínima para o git, lembre-se de alterar suas informações:
```bash
git config --global user.name "orafaelferreira"
git config --global user.email rafael.low1@gmail.com
```
### Passo 5: Fazer o push dos arquivos para o repositório
Vamos agora fazer o push dos arquivos do seu projeto para o repositório. Conforme a dica do próprio GitHub, não se esqueça de mudar: "git add README.md" para "git add .":
```bash
echo "# example" >> README.md
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:orafaelferreira/example.git
git push -u origin main
```
Dando um Check no GitHub:
### Curiosidades e Dicas Extras
#### História do GitHub
- **Fundação**: O GitHub foi fundado em 2008 por Tom Preston-Werner, Chris Wanstrath, PJ Hyett e Scott Chacon. Desde então, cresceu exponencialmente e se tornou a plataforma de hospedagem de código mais popular do mundo.
- **Aquisição pela Microsoft**: Em 2018, o GitHub foi adquirido pela Microsoft por 7,5 bilhões de dólares. A aquisição ajudou a expandir ainda mais a base de usuários e as funcionalidades da plataforma.
#### Por que usar SSH para autenticação?
- **Segurança**: O uso de chaves SSH para autenticação é mais seguro do que senhas tradicionais. As chaves SSH são criptograficamente mais robustas e difíceis de serem comprometidas.
- **Facilidade de uso**: Uma vez configurada, a autenticação SSH facilita o processo de clonagem e push para repositórios sem a necessidade de inserir senhas repetidamente.
#### Boas práticas para commits no GitHub
- **Commits frequentes e significativos**: Faça commits frequentes com mensagens claras e descritivas. Isso ajuda a manter o histórico de alterações organizado e facilita o rastreamento de mudanças.
- **Mensagens de commit**: Escreva mensagens de commit detalhadas que expliquem o que foi alterado e por quê. Por exemplo: "Adiciona função de login com autenticação OAuth para melhorar a segurança do usuário".
#### Usando arquivos README
- **Informações essenciais**: Um arquivo README.md bem escrito é fundamental para qualquer repositório. Ele deve conter uma visão geral do projeto, instruções de instalação, exemplos de uso e informações sobre como contribuir.
- **Markdown**: Aproveite o poder do Markdown para formatar seu README com títulos, listas, links e imagens. Um README bem formatado torna o projeto mais acessível e fácil de entender.
#### Integração com CI/CD
- **GitHub Actions**: Use GitHub Actions para configurar pipelines de CI/CD diretamente no seu repositório. Isso permite automações como testes automatizados, linting, deployments e muito mais.
#### Ferramentas e Extensões Úteis
- **GitHub Desktop**: Uma aplicação oficial do GitHub que facilita a utilização de Git e GitHub através de uma interface gráfica amigável.
- **Extensões de Navegador**: Extensões como "Refined GitHub" para Chrome e Firefox melhoram a interface do GitHub com recursos adicionais e melhorias de usabilidade.
#### Comunidade e Colaboração
- **Contribuição Open Source**: Contribuir para projetos open source no GitHub é uma excelente maneira de ganhar experiência prática, aprender novas habilidades e fazer networking com outros desenvolvedores.
- **GitHub Discussions**: Use as discussões do GitHub para colaborar com outros desenvolvedores, resolver problemas e compartilhar ideias sobre o projeto.
### Conclusão
Configurar um repositório no GitHub é uma tarefa essencial para desenvolvedores e profissionais de TI. Este guia introdutório abordou os passos necessários para criar e configurar um repositório, adicionar uma chave SSH para autenticação segura e realizar operações básicas de Git. Esta base servirá como referência para futuros tutoriais mais avançados.
---
# Guia de Criação de Maquinas Virtuais no Microsoft Azure
URL: https://www.orafaelferreira.com/artigos/criacao-vm
Publicado: 2024-06-05
Categoria: Artigos
Tempo de leitura: 5 min de leitura
> Passo a passo para criar máquinas virtuais Linux e Windows no Microsoft Azure, com Resource Group, VNet, NSG e conexão via SSH e Remote Desktop.
### Introdução
Este artigo será uma base introdutória essencial para os próximos conteúdos que virão, onde exploraremos mais a fundo a criação e gerenciamento de máquinas virtuais no Microsoft Azure. Aqui, abordaremos os passos iniciais para criar máquinas virtuais tanto para Linux quanto para Windows, fornecendo um fundamento para as futuras discussões e tutoriais.
Criar máquinas virtuais no Microsoft Azure pode parecer uma tarefa complicada, mas com este guia passo a passo, você verá que é mais simples do que parece. Vamos explorar a criação de máquinas virtuais tanto para Linux quanto para Windows. Vamos começar!
### Passo 1: Criação do Resource Group
Antes de criar qualquer recurso no Azure, precisamos de um Resource Group, que funciona como um contêiner lógico para todos os recursos relacionados. Vamos criar um Resource Group chamado `rg-example`.
1. Acesse o portal do Azure.
2. Vá para "Resource Groups" e clique em "Create".
3. Nomeie seu Resource Group como `rg-example`.
4. Selecione a região desejada.
5. Clique em "Review + Create" e, em seguida, "Create".
### Passo 2: Criação da Virtual Network
A próxima etapa é criar uma Virtual Network (VNet), que permite a comunicação entre recursos do Azure.
1. Vá para "Virtual Networks" e clique em "Create".
2. Nomeie a VNet como `vnet-example`.
3. Selecione o Resource Group `rg-example`.
4. Configure o endereço IP e as sub-redes conforme necessário.
5. Clique em "Review + Create" e, em seguida, "Create".
### Passo 3: Criação da NSG (Network Security Group)
O Network Security Group (NSG) é responsável por controlar o tráfego de rede para as VMs. Vamos criar um NSG chamado `nsg-example`.
1. Vá para "Network Security Groups" e clique em "Create".
2. Nomeie o NSG como `nsg-example`.
3. Selecione o Resource Group `rg-example`.
4. Clique em "Review + Create" e, em seguida, "Create".
### Passo 4: Anexar o NSG à Subnet
Depois de criar o NSG, precisamos anexá-lo à Subnet `default` da nossa VNet `vnet-example`.
1. Acesse o NSG `nsg-example` e selecione a settings > Subnet.
2. Associate, selecione a subnet `default` e salve as alterações.
### Passo 5: Criação da Virtual Machine Linux
Vamos criar a VM com nome vm-example dentro do rg-example com o tipo de segurança: Standard.
1. Vá para "Virtual Machines" e clique em "Create".
2. Selecione o Resource Group `rg-example`.
3. Nomeie a VM como `vm-example`.
4. Altere o tipo de segurança para Standard.
5. Selecione "Ubuntu Server 20.04 LTS ARM64 Gen2" como a imagem.
6. Selecione "Arm64" como a arquitetura (para maior eficiência energética e de processamento).
7. Configure a VM com o tamanho `Standard_D2ps_v5`.
8. Escolha a autenticação por senha e defina uma senha.
9. Certifique-se de que a VM não tenha portas de entrada públicas configuradas.
**Saiba Mais:** [Máquinas Virtuais do Azure com processadores baseados em Arm do Ampere Altra](https://azure.microsoft.com/pt-br/updates/generally-available-new-azure-virtual-machines-with-ampere-altra-armbased-processors/)
10. Na seção "Networking", certifique-se de que a VM esteja na VNet `vnet-example` e na Subnet `default`.
11. Selecione "Review + Create" e, em seguida, "Create".
Após a criação, precisamos liberar a porta SSH 22 no NSG `nsg-example` para acessar a VM.
1. Acesse o NSG `nsg-example`.
2. Adicione uma regra de entrada para permitir o tráfego na porta 22.
#### Conectando-se à VM Linux
Após a VM estar em execução verifique qual IP público foi atribuído à VM , copie o IP público e conecte-se via SSH:
```bash
ssh usuario@IPX.XXX.XXX.XX
```
No meu caso:
```bash
ssh raafel@172.210.28.194
```
De preferência, atualize os pacotes do sistema:
```bash
sudo apt-get update
sudo apt-get upgrade -y
```
### Criação da Virtual Machine Windows 11
Vamos criar uma VM com Windows 11 dentro do nosso `rg-example`, com o nome `vm-example-win`, tipo de segurança `Standard` e imagem `Windows 11 Pro`.
1. Vá para "Virtual Machines" e clique em "Create".
2. Selecione o Resource Group `rg-example`.
3. Nomeie a VM como `vm-example-win`.
4. Altere o tipo de segurança para Standard.
5. Selecione "Windows 11 Pro" como a imagem.
6. Configure a VM com o tamanho `Standard_B4ms` para testes mais rápidos.
7. Escolha a autenticação por senha e defina uma senha de sua preferência (não se esqueça de anotar a senha).
8. Certifique-se de que a VM não tenha portas de entrada públicas configuradas. Confirme a licença.
9. Na seção "Networking", certifique-se de que a VM esteja na VNet `vnet-example` e na Subnet `default`, e que não seja atribuído um NSG à NIC.
10. Selecione "Review + Create" e, em seguida, "Create".
Após a criação, precisamos liberar a porta RDP no NSG `nsg-example` para acessar a VM.
1. Acesse o NSG `nsg-example`.
2. Adicione uma regra de entrada para permitir o tráfego na porta RDP.
#### Conectando-se à VM Windows
1. No seu computador com Windows, abra o aplicativo "Remote Desktop Connection" (procure por "Remote" no menu Iniciar).
2. Copie o IP público atribuído à VM `vm-example-win`, digite no Remote Desktop Connection, clique no botão conectar, escolha "Use another account", e digite o usuário e senha que foram criados anteriormente. Clique em "OK".
3. Confirme o certificado de segurança quando solicitado:
---
### Conclusão
Criar máquinas virtuais no Azure é um processo estruturado que envolve a criação de vários componentes, como Resource Groups, Virtual Networks e Network Security Groups. Seguindo este guia, você pode configurar rapidamente VMs Linux e Windows para atender às suas necessidades. Lembre-se de sempre garantir a segurança das suas VMs e otimizar suas configurações para o melhor desempenho.
A flexibilidade e o poder do Azure permitem que você adapte a infraestrutura de TI às demandas específicas do seu projeto, seja ele para desenvolvimento, teste ou produção. Utilize as práticas recomendadas para maximizar a eficiência e a segurança de suas VMs.
Se tiver dúvidas ou precisar de mais detalhes, não hesite em entrar em contato. Espero que este guia tenha sido útil para você!
---
# GreenOps na Cloud: Construindo o Futuro com Sustentabilidade - Tech Connection Balneário Camburiú 2024
URL: https://www.orafaelferreira.com/artigos/tc-bc24
Publicado: 2024-06-02
Categoria: Palestras
Tempo de leitura: 2 min de leitura
> No Tech Connection 2024, realizado em Balneário Camboriú, trouxe uma palestra com tema crucial para o futuro da tecnologia e do planeta: GreenOps na Cloud.
No Tech Connection 2024, realizado em Balneário Camboriú, trouxe uma palestra com tema crucial para o futuro da tecnologia e do planeta: **GreenOps na Cloud**. Este conceito, ainda emergente, tem como foco a sustentabilidade no uso de recursos em ambientes de nuvem, conectando práticas de DevOps com objetivos ambientais.
### O Que é GreenOps?
GreenOps, ou "Operações Verdes", é uma abordagem que integra práticas de eficiência ambiental na gestão de infraestrutura e operações de TI. No contexto da computação em nuvem, isso significa otimizar o uso de recursos como energia, armazenamento e processamento, reduzindo desperdícios e a pegada de carbono associada.
### A Conexão com a Cloud
A computação em nuvem é um motor poderoso para a inovação, mas também consome uma quantidade significativa de energia. Data centers globais, especialmente os que operam serviços de nuvem, já representam mais de 1% do consumo global de eletricidade.
Por outro lado, a nuvem também oferece uma oportunidade única para a sustentabilidade, graças à:
- **Elasticidade**: Permite ajustar recursos dinamicamente para evitar desperdícios.
- **Escala**: Grandes provedores como Microsoft Azure, AWS e Google Cloud utilizam data centers com eficiência energética de ponta.
- **Automação**: Ferramentas podem monitorar e ajustar a utilização automaticamente.
A palestra destacou como esses fatores podem ser explorados por meio de práticas GreenOps para reduzir custos e impulsionar a sustentabilidade.
### Práticas de GreenOps na Cloud
Durante a apresentação, foram discutidas várias práticas que podem ser implementadas para incorporar GreenOps no dia a dia de times de TI. Entre elas:
- **Monitoramento de Métricas Ambientais**: Ferramentas de nuvem como Azure Sustainability Calculator e AWS Carbon Footprint permitem medir o impacto ambiental do uso da nuvem.
- **Configuração de Escalabilidade Automatizada**: Configurar auto-scaling para evitar servidores subutilizados.
- **Gerenciamento de Workloads**: Agendar workloads de menor prioridade para horários de baixa demanda energética nos data centers.
- **Uso de Zonas de Energia Renovável**: Escolher regiões de data centers que utilizam fontes de energia limpa.
- **Desligamento de Recursos Ociosos**: Automatizar o desligamento de VMs e recursos não utilizados.
### Conclusão: A Importância da Ação
O GreenOps na Cloud é mais do que uma tendência; é uma necessidade. Empresas que adotam práticas sustentáveis podem não apenas reduzir custos, mas também melhorar sua reputação e contribuir para um futuro mais verde.
---
---
# Simplificando a Utilização do Static Web Apps no Azure
URL: https://www.orafaelferreira.com/artigos/azure-static-web-apps
Publicado: 2024-05-24
Categoria: Artigos
Tempo de leitura: 12 min de leitura
> Os Azure Static Web Apps são um serviço que cria e implanta automaticamente aplicativos Web full stack no Azure a partir de um repositório de códigos.
### Introdução
Os [Azure Static Web Apps](https://learn.microsoft.com/pt-br/azure/static-web-apps/) são um serviço que cria e implanta automaticamente aplicativos Web full stack no Azure a partir de um repositório de códigos. Este serviço é personalizado para o fluxo de trabalho diário de um desenvolvedor, criando e implantando aplicativos baseados em alterações de código feitas em repositórios GitHub ou Azure DevOps.
Ao criar um recurso dos [Azure Static Web Apps](https://learn.microsoft.com/pt-br/azure/static-web-apps/overview), o Azure monitora um branch de sua escolha e, Sempre que você faz push de commits ou aceita pull requests, um build é executado automaticamente e seu aplicativo juntamente com sua API é implantado no Azure.
Este serviço é ideal para aplicativos Web que utilizam bibliotecas e frameworks como Angular, React, Svelte, Vue ou Blazor, onde a renderização do lado do servidor não é necessária. Os arquivos estáticos (HTML, CSS, JavaScript, imagens) são distribuídos globalmente, proporcionando um fornecimento de arquivos rápido e eficiente, enquanto os pontos de extremidade da API são hospedados usando uma arquitetura serverless.
#### Principais Recursos:
- **Hospedagem para conteúdo estático**: HTML, CSS, JavaScript e imagens.
- **Suporte integrado à API**: Usando Azure Functions gerenciado, com opções de integração com aplicações de funções existentes, aplicativos Web, contêineres ou instâncias do Gerenciamento de API.
- **Integração com GitHub e Azure DevOps**: Alterações no repositório disparam compilações e implantações.
- **Distribuição global**: Conteúdo estático colocado mais perto dos usuários (edge computing).
- **Certificados SSL gratuitos**: Renovados automaticamente.
- **Domínios personalizados**: Para personalizações da marca no aplicativo.
- **Modelo de segurança contínua**: Proxy reverso ao chamar APIs, sem necessidade de configuração de CORS.
- **Integrações do provedor de autenticação**: Com Microsoft Entra ID e GitHub.
- **Regras de roteamento de back-end**: Controle total sobre conteúdo e rotas.
- **Versões de preparo**: Alimentadas por pull requests para pré-visualização antes da publicação.
- **Suporte da CLI**: Via CLI do Azure para criar recursos de nuvem e CLI de Azure Static Web Apps para desenvolvimento local.
### Documentação de API
No desenvolvimento de software, a documentação desempenha um papel crucial para garantir que as APIs sejam compreensíveis e utilizáveis por outros desenvolvedores. Ferramentas como Doxygen oferecem abordagens diferentes para documentar APIs, cada uma com suas vantagens. Neste artigo, vamos explorar como configurar uma API simples utilizando Doxygen para documentação técnica detalhada, e hospedar a documentação no Azure Static Web Apps.
### Objetivo
O objetivo deste artigo é fornecer um guia passo a passo para:
1. Criar uma API simples com Python e Flask.
2. Documentar o código utilizando Doxygen.
3. Criação simplificada do Static Web Apps.
### Pré-requisitos
Antes de começarmos, você precisará ter:
- Uma conta no Azure com permissões para criar recursos.
- Uma conta no GitHub.
### Passo 1: Criação do Resource Group
Criando o Resource Group com nome `rg-swa`, Review + Criar.
### Passo 2: Criação da Virtual Network
Criando a Virtual Network com nome `vnet-swa` dentro do Resource Group `rg-swa` com as opções padrão.
### Passo 3: Criação da NSG (Network Security Group)
Seguindo, criação do NSG `nsg-swa` com as opções padrão dentro do Resource Group `rg-swa`.
### Passo 4: Anexar o NSG à Subnet
Após finalizar, acesse o recurso, e anexe o NSG à Subnet `default` que está dentro da `vnet-example` para liberações de portas de forma centralizada e facilitada:
### Passo 5: Criação da Virtual Machine Linux
Vamos criar a VM com nome `lnx-swa` dentro do `rg-swa` com o tipo de segurança: `Standard`.
A imagem será uma `Ubuntu Server 20.04 LTS ARM64 Gen2`. A arquitetura da VM será `Arm64` para maior eficiência energética e de processamento. O tamanho será uma `Standard_D2ps_v5` compatível com a arquitetura. A autenticação será feita por senha, de acordo com a preferência de cada um e sem portas de entradas públicas.
**Saiba Mais:** [Máquinas Virtuais doß Azure com processadores baseados em Arm do Ampere Altra](https://azure.microsoft.com/pt-br/updates/generally-available-new-azure-virtual-machines-with-ampere-altra-armbased-processors/)
Certifique-se de que não seja criado um novo NSG e selecione a opção para apagar o IP público e a NIC junto com a VM.
Depois seguimos com a instalação padrão.
Precisamos liberar a porta SSH 22 dentro do nsg-swa para seguir com os procedimentos:
Verifique qual IP público foi atribuído à VM `vm-lnx`, copie e abra um terminal para conexão ssh:
```bash
ssh usuario@IPX.XXX.XXX.XX
```
No meu caso:
```bash
ssh rafael@172.203.234.14
```
De preferência, atualize os pacotes do sistema:
```bash
sudo apt-get update
sudo apt-get upgrade -y
```
### Passo 6: Configurar a API com Python e Flask
##### Instale o Python:
```bash
sudo apt-get install python3 python3-pip -y
```
##### Estrutura do Projeto
Vamos estruturar nosso projeto da seguinte forma:
```yaml
/meu_projeto
/docs
/doxygen_docs
/src
Doxyfile
app.py
```
Crie um diretório para o projeto e navegue até ele:
```bash
mkdir -p meu_projeto/docs
mkdir -p meu_projeto/src
cd meu_projeto/src
```
#### Criando a API com Flask
Primeiramente instale o Flaks:
```bash
pip install Flask
```
Crie e edite o arquivo `app.py` com o seguinte conteúdo:
```bash
vim app.py
```
```yaml
from flask import Flask, jsonify, request
app = Flask(__name__)
@app.route('/')
def home():
return "Bem-vindo à API!"
@app.route('/hello', methods=['GET'])
def hello():
name = request.args.get('name', 'Mundo')
return jsonify(message=f"Olá, {name}!")
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
```
OBS1: IMPORTANTE - Para sair do Vim Aperte a tecla ESC depois `:wq` para sair salvando (write + quit (eu acho que seja isso)) e tecla ENTER.
OBS2: Você que é da área de Infra/DevOps/Cloud, não se atente ao código, estamos usando um código fake para subirmos a infra.
Vamos testar a API:
```bash
python3 app.py
```
Inicie a aplicação e acesse `http://172.203.234.14:5000/` no navegador. Porém a página não irá carregar, porque não liberamos a porta `5000` dentro do `nsg-swa`. Vamos lá!
E como mágica, teremos:
OBS: Para sair aperte com as teclas `CTRL + C`.
### Passo 7: Adicionar Doxygen para Documentação do Código-Fonte
O Doxygen é uma ferramenta de documentação que gera documentação em vários formatos (como HTML, PDF, etc.) a partir de comentários anotados no código-fonte. Vamos entender como ele funciona e como você pode usá-lo:
#### Passos Básicos para Usar o Doxygen
##### Instalação do Doxygen:
- Windows: Baixe o instalador do site oficial do Doxygen e siga as instruções de instalação.
- Linux/MacOS: Utilize um gerenciador de pacotes. Por exemplo, no Ubuntu, você pode usar:
``` bash
sudo apt-get install doxygen
```
#### Configuração do Doxygen
Primeiramente criamos o arquivo Doxyfile com o comando `doxygen -g Doxyfile`, dentro da pasta src:
``` bash
doxygen -g Doxyfile
```
Seguindo, atualize o Doxyfile com as seguintes configurações:
```bash
vim Doxyfile
```
```bash
PROJECT_NAME = "Minha API Flask"
OUTPUT_DIRECTORY = ../docs/doxygen_docs
INPUT = ./app.py
RECURSIVE = NO
GENERATE_HTML = YES
GENERATE_LATEX = NO
```
Para facilitar a edição, você pode procurar uma palavra especifica saindo do modo INSERT, apertando a tecla ESC e digitar: `/` seguido da palavra que procurar no documento e apertando a tecla ENTER. Por exemplo:
```bash
/INPUT
```
Assim você consegue encontrar determinadas palavras de forma facilitada no editor vim :D.
Não se esqueça, para sair do Vim Aperte a tecla ESC depois `:wq` para sair salvando
#### Instalando o Graphviz
O Doxygen usa o Graphviz para gerar gráficos de dependência e diagramas de classes. Vou orientá-lo na instalação do Graphviz:
```bash
sudo apt-get install graphviz -y
```
#### Geração da Documentação do Doxygen
Execute o comando para gerar a documentação:
```bash
doxygen Doxyfile
```
A documentação será gerada no diretório ~/meu_projeto/docs/doxygen_docs.
### Passo 8: Fazer o Deploy no Azure Static Web Apps
No portal da Azure, crie um Static Web App dentro do RG que estamos usando para o laboratório: `rg-swa`. O tipo de Plano será: `Standard`. Vamos simular um ambiente de produção, iremos criar um Static Web Apps com private endpoint. Deixe a opção Deployment details como outros, conforme imagem abaixo:
#### Adição de um Private Endpoint
Vá até a seção de "Settings" do seu Static Web App. Selecione a opção Add, e Express:
Aparecerá uma nova janela, onde iremos nomear o Private Endpoint como: `pvt-swa` e associa-lo a subnet `default` da `vnet-swa`. Será criado automaticamente um DNS para resolver o nome do Static Web App para o endereço IP privado do Private Endpoint.
### Passo 9: Criação de um Repositório no GitHub
Crie um novo repositório no GitHub, irei deixar público para quem tiver interesse em visitar e conhecer mais, selecionei a criação de um readme nomeei como: `static-web-app`, não vamos adicionar README para seguir com os futuros.
**Github:** [static-web-app](https://github.com/orafaelferreiraa/static-web-app)
Precisamos adicionar a chave ssh da VM linux ao teu GitHub, clique na sua foto no canto superior direito, settings, SSH and GPG Keys:
Add SSH Key:
Agora, precisamos retornar à VM-lnx e gerar uma nova chave SSH:
```bash
ssh-keygen
```
OBS: Para fins didáticos, estou gerando uma chave sem senha para facilitar nosso laboratório. Crianças, nunca façam isso em produção :D
```bash
cat /home/rafael/.ssh/id_rsa.pub
```
Copie toda a informação que e exibida após o comando cat e retorne para o GitHub.
Na mesma tela que paramos, coloque o nome da VM, por exemplo: `lnx-swa` no titulo e copie o conteúdo da chave, conforme imagem abaixo:
Retorne a VM e faça a configurção mínima para o git, lembre-se de alterar suas informações:
```bash
git config --global user.name "orafaelferreira"
git config --global user.email rafael.low1@gmail.com
```
Vamos entrar no diretório html para fazer o push dos arquivos para o GitHub:
```bash
cd meu_projeto/docs/doxygen_docs/html/
```
E então vamos fazer o push dos arquivos do seu projeto para o repositório, conforme dica do proprio GitHub, não se esqueça de mudar: `git add README.md` para `git add .`:
```bash
echo "# static-web-app" >> README.md
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:orafaelferreira/static-web-app.git
git push -u origin main
```
Dando um Check no GitHub:
#### Criação de Secret no GitHub
Pensando sempre em segurança com zero trust, vamos criar um segredo no repositório para armazenar o token de deployment.
No portal da Azure, no swa - Static Web App, clique em Manage deployment token e copie o token.
De volta ao GitHub, clique em Settings, Secrets and variables, actions, new repository secret:
Digite o nome conforme exemplo:
```bash
AZURE_STATIC_WEB_APPS_API_TOKEN
```
e cole o Deployment token:
Adicionar
#### Configuração do Workflow do GitHub Actions
No seu repositório GitHub, vá até a aba "Actions" e selecione a opcão: "Crie um workflow você mesmo":
Crie um arquivo `.github/workflows/deploy.yml` com o seguinte conteúdo **OBS: apague os espaços após o $ entre as { { e } }**
```yaml
name: Deploy Static Web App
on:
push:
branches:
- main
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout repository content
uses: actions/checkout@v2
- name: Deploy Static Web App
uses: Azure/static-web-apps-deploy@v1
with:
azure_static_web_apps_api_token: ${ { secrets.AZURE_STATIC_WEB_APPS_API_TOKEN } }
repo_token: ${ { secrets.GITHUB_TOKEN } }
action: "upload"
app_location: "/"
output_location: "docs/doxygen_docs/html"
```
Não se esqueça de clicar no botão: `commit changes`:
E voilá, pipeline executando:
### Passo 11: Criação da Virtual Machine Windows 11
Já que não colocamos o Static Web App na internet, ele está apenas acessível na nossa rede interna. Precisamos criar uma VM, por exemplo, com Windows 11 para visualizar o deploy do Static Web App no navegador.
Dentro do nosso `rg-swa`, com o nome: `win-swa`, com tipo de segurança `Standard` e imagem `Windows 11 Pro`.
Escolhi o tamanho `Standard_B4ms` para ser mais rápido nos testes. Criei um usuário e senha de sua preferência (não se esqueça de anotar a senha rs).
Sem porta de entrada pública, iremos configurar depois manualmente. Confirme a licença.
Certifique-se de que esteja na Vnet correta: `vnet-swa`, na subnet: `default`, e que não seja atribuído um NSG à NIC:
Depois opções default. Finalizando precisamos liberar a porta RDP no `nsg-swa`, settings, Inbound security rules, add, Services, RDP:
Estou usando Windows, portanto, procure no Iniciar `Remote` e abra o Remote Desktop Connection:
Copie o IP público, digite no Remote Desktop Connection, clique no botão conectar, escolha uma conta diferente, digite o usuário e senha que foram criados anteriormente e clique em ok:
Confirme o certificado:
### Finalizando: Verificação do Deploy
Vamos testar via navegador web. Acesse a URL do seu Static Web App, retorne ao portal da Azure e copie o endereço de domínio para colar na VM Windows 11:
- https://black-sand-0051c0f0f.5.azurestaticapps.net
**OBS: Esse é o nome padrão que vem. Podemos alterá-lo validando nosso domínio externo e configurando ainda mais nossa aplicação dentro do nosso recurso Azure Static Web App.**
E se testarmos fora da nossa rede interna, por exemplo, utilizando a rede externa do nosso computador:
Acesso negado, conforme o esperado :D
Podemos ainda configurar senhas de visitantes. Por exemplo, se fosse uma API para consultar holerites, com dados sensíveis, dentro do portal da Azure na seção de configurações do Static Web App:
E então:
Digitando a senha conseguimos acessar a API:
### Desenho Arquitetura
### Conclusão
Neste artigo, aprendemos como configurar uma Virtual Machine no Azure (Resource Group, Virtual Network, Network Security Group, Disco, Network Interface, Public IP address). Configuramos uma API simples utilizando Python e Flask, documentamos a API com Doxygen e hospedamos a documentação no Azure Static Web Apps (Private Endpoint + Private DNS). Utilizamos o GitHub para hospedar o código e implementamos pipelines com GitHub Actions para realizar o deploy automático no Azure Static Web Apps. Este guia fornece uma abordagem abrangente para garantir que sua API seja bem documentada e acessível, utilizando o provedor de nuvem Azure. Se você tiver dúvidas estou à disposição para ajudar.
---
# Global Azure feat Azure Floripa 2024
URL: https://www.orafaelferreira.com/artigos/global-azure24
Publicado: 2024-05-18
Categoria: Organização de Eventos
Tempo de leitura: 4 min de leitura
> Como foi o Global Azure 2024 com o Azure Floripa: um evento global para aprender e compartilhar conhecimento sobre a plataforma de cloud computing da Microsoft.
## Global Azure 2024 feat. Azure Floripa: Um Evento Incrível!
Estamos entusiasmados em compartilhar que o Global Azure 2024 foi um sucesso e o Azure Floripa marcou presença! Este evento global foi uma oportunidade incrível para aprender e compartilhar conhecimentos sobre a plataforma de Cloud Computing da Microsoft, o Azure. Com a participação de desenvolvedores, arquitetos e IT-pros, o evento foi totalmente gratuito e proporcionou uma experiência enriquecedora para todos os participantes.
### Organizadores
- **[Rafael Martin Alves Ferreira](https://www.linkedin.com/in/orafaelferreiraa/)**
- **[Vinicius Deschamps](https://www.linkedin.com/in/viniciusdeschamps/)**
### O que foi o Global Azure?
O Global Azure foi um evento anual que ocorreu simultaneamente em várias partes do mundo, com o objetivo de disseminar conteúdos sobre o Microsoft Azure entre a comunidade técnica. O evento incentivou o uso da plataforma Azure e promoveu a troca de conhecimentos e experiências entre os participantes. Este ano, o evento aconteceu nos dias 18, 19 e 20 de abril de 2024.
### Por que Conferir?
- **Conteúdo de Qualidade:** Aprendemos com líderes de comunidades técnicas de classe mundial.
- **Networking:** Conecte-se com outros profissionais de TI e desenvolvedores que compartilham o mesmo interesse em Azure.
- **Flexibilidade:** Participamos de eventos locais ou online, de acordo com nossa conveniência.
### Palestras e Sessões
#### Azure Copilot
[](https://www.youtube.com/watch?v=ql5zFgKBLzo)
#### Purview e Copilot
[](https://www.youtube.com/watch?v=O-IUocsjkpo)
#### Usando o serviço Azure Open AI com suas aplicações
[](https://www.youtube.com/watch?v=8Xug8yks1hI)
#### Potencializando a Inclusão Digital com Azure AI Services
[](https://www.youtube.com/watch?v=XXgXG8izo-A)
#### Projetando arquiteturas seguras no Azure
[](https://www.youtube.com/watch?v=z09q03ccba0)
#### VPN no Azure com Autenticação pelo Entra ID e Acesso Condicional
[](https://www.youtube.com/watch?v=P-kyMJJ-C30)
#### Protegendo suas aplicações web com Application Gateway e WAF
[](https://www.youtube.com/watch?v=sdvIPY9uo7M)
#### Protegendo identidades e acessos em uma escala empresarial global
[](https://www.youtube.com/watch?v=TvhCgo_PD88)
#### Abordagens Práticas para a Segurança na Nuvem
[](https://www.youtube.com/watch?v=uc8B4wpq5c8)
#### Ataque de Ransomware Com Defender for Endpoint & Microsoft Sentinel
[](https://www.youtube.com/watch?v=M4B9C_uI1kM)
#### Estendendo segurança e gestão de workloads multi-cloud com Azure Arc
[](https://www.youtube.com/watch?v=xxcq-oSyHJc)
#### Pontos de Atenção Fundamentais em FinOps
[](https://www.youtube.com/watch?v=UbCX-wDQQls)
#### Azure a Serviço da Saúde, Transformação digital de um dos pilares do SUS
[](https://www.youtube.com/watch?v=wQsQk9iO65E)
#### Plataformizando Soluções com Azure e Terraform
[](https://www.youtube.com/watch?v=fgwbfLrKT74)
#### Serviços de mensageria do Azure e a integração com a plataforma do Azure IoT
[](https://www.youtube.com/watch?v=Se77jzrj4lc)
#### Governança no Azure - Recursos e práticas para organizar seu ambiente em Nuvem
[](https://www.youtube.com/watch?v=w1b4uv_XRdQ)
#### GreenOps: Da Fundação à Inovação Sustentável na Cloud Azure
[](https://www.youtube.com/watch?v=etnQCHbIg2I)
### Por Que Fizemos Isso?
A resposta é simples: somos apaixonados por aprendizado e tecnologia! O Global Azure foi uma oportunidade de reunir pessoas de todo o mundo para aprender e compartilhar conhecimento sobre Azure.
### Destaques e Premiações
Devido ao grande impacto que o Azure Floripa teve no Global Azure e como forma de incentivar os compartilhadores de conteúdo e grandes responsáveis pela entrega de conhecimento, selecionamos as palestras com mais visualizações por trilha e presenteamos com gift cards do iFood!
Gostaríamos de presentear todos os palestrantes, mas como ainda não é possível, espero que se sintam representados pelos ganhadores:
- **Rafael Alves Amaral**, primeiro dia, trilha de Inteligência Artificial ([Azure Copilot](https://lnkd.in/dQJEWc5k))
- **Raphael Custódio**, segundo dia, trilha de Segurança ([Ataque de Ransomware com Defender for Endpoint & Microsoft Sentinel](https://lnkd.in/drwJpPGa))
- **Rodrigo Paliosa**, terceiro dia, trilha de Overview ([Pontos de Atenção Fundamentais em FinOps](https://lnkd.in/dqPBTZFn))
### Quer Fazer Parte da Comunidade Azure Floripa?
Então acesse e se inscreva em nossas redes sociais:
- **[WhatsApp](https://chat.whatsapp.com/HSpFnNyo9ZLD4RJrvEcrrl)**
- **[YouTube](https://lnkd.in/dtX9uKEk)**
- **[Visite nosso site](https://lnkd.in/d8vBRFpm)**
Saiba mais: [Global Azure](https://globalazure.net/)
---
# Antes do Cloud Native: Construindo uma Fundação Sólida para a Nuvem Impactando um Futuro Sustentável - KCD São Paulo - Brasil 2024
URL: https://www.orafaelferreira.com/artigos/kcdsp24
Publicado: 2024-02-25
Categoria: Palestras
Tags: GreenOps
Tempo de leitura: 2 min de leitura
> No dia 24 de fevereiro de 2024, tive a oportunidade de palestrar no Kubernetes Community Days (KCD) Brasil, realizado na Natura NASP, em São Paulo.
No dia 24 de fevereiro de 2024, tive a oportunidade de palestrar no **Kubernetes Community Days (KCD) Brasil**, realizado na Natura NASP, em São Paulo. Esse evento híbrido foi um marco no cenário Cloud Native no Brasil, reunindo especialistas, entusiastas e líderes da área para dois dias de aprendizado, troca de ideias e networking.
### Minha Palestra: "Antes do Cloud Native: Construindo uma Fundação Sólida para a Nuvem Impactando um Futuro Sustentável"
Com base na importância de uma base robusta para adoção da nuvem, minha palestra trouxe insights práticos e estratégicos sobre:
- **Framework de Adoção da Nuvem (CAF):** Uma abordagem estruturada para ajudar organizações a planejar, adotar e gerenciar sua migração para a nuvem.
- **Landing Zones:** A construção de ambientes otimizados para crescimento sustentável na nuvem, com governança, segurança e escalabilidade em mente.
- **DevOps e Sustentabilidade:** Mostrei como práticas de DevOps e observabilidade se integram a esforços de sustentabilidade, como **GreenOps**, para maximizar eficiência e reduzir impactos ambientais.
Os pontos altos foram os debates sobre o impacto de práticas sustentáveis e as ferramentas disponíveis para viabilizar um futuro verde no mundo tecnológico.
[](https://www.credly.com/badges/a6940f87-b34a-497e-8c1e-93545075c0ee/public_url "Contributor - KCD São Paulo, Brazil 2024")
### Destaques do KCD Brasil 2024
Além da minha contribuição, o evento contou com uma agenda diversificada e de alto nível:
- **Palestras Impactantes:** Tópicos como GitOps, DevSecOps, monitoramento em containers e transformação digital foram abordados por especialistas renomados, incluindo apresentações de organizações como Grafana, AWS, Red Hat, Sysdig e ThoughtWorks.
- **Participação Híbrida:** O modelo híbrido permitiu que participantes de todo o Brasil (e do mundo) acompanhassem as sessões virtuais e presenciais.
- **Mentorias e Conexões:** Sessões de mentoria e networking proporcionaram uma troca rica entre palestrantes e participantes, fortalecendo a comunidade Cloud Native.
### Reflexões e Próximos Passos
Palestrar em eventos como o KCD Brasil é sempre uma experiência transformadora. Compartilhar conhecimento, aprender com outros e discutir as tendências que moldam o futuro da tecnologia é algo que fortalece nossa comunidade e impulsiona inovações.
Se você não participou deste ano, recomendo acompanhar as próximas edições. E, claro, considere submeter sua palestra—o KCD é uma plataforma incrível para amplificar sua voz e ideias no cenário Cloud Native.
**Nos vemos nos próximos eventos!** 🚀
---
---
# Antes do Cloud Native: Construindo uma Fundação Sólida para a Nuvem Impactando um Futuro Sustentáve - Cloud Native Floripa - 2º Edição
URL: https://www.orafaelferreira.com/artigos/2meetcncf
Publicado: 2024-02-22
Categoria: Palestras
Tags: GreenOps
Tempo de leitura: 2 min de leitura
> Palestrei no 2º Cloud Native Floripa Meetup sobre como construir uma fundação sólida para a nuvem com foco em sustentabilidade, na A Fábrica Working Bar.
No dia 21 de fevereiro de 2024, tive o prazer de palestrar no 2º Cloud Native Floripa Meetup, organizado pelo Community Group Cloud Native Santa Catarina. O evento realizado na "[A Fábrica Working Bar](https://www.afabricaworkingbar.com/coworking)".
### Minha Palestra: "Antes do Cloud Native: Construindo uma Fundação Sólida para a Nuvem Impactando um Futuro Sustentável"
Falei sobre como construir uma base sólida para adoção da nuvem. A palestra abordou conceitos como:
- **Cloud Adoption Framework (CAF):** Um framework que ajuda organizações a estruturar sua transição para a nuvem de maneira eficiente e segura, destacando a importância de pilares como governança, segurança e gestão operacional.
- **Landing Zones:** Criar ambientes Cloud escaláveis e organizados, preparando empresas para o crescimento sustentado.
- **FinOps e Sustentabilidade:** Explorei práticas financeiras em Cloud Native, aliadas a conceitos de GreenOps, podem maximizar o valor obtido da nuvem, reduzindo o impacto ambiental e os custos.
A interação com o público foi sensacional, explorar maneiras de incorporar práticas sustentáveis no dia a dia das organizações e as oportunidades que tecnologias emergentes, como Kubernetes, oferecem para amplificar esses esforços.
### O Que Torna um Meetup Diferente?
O meetup não foi apenas uma oportunidade de aprender e compartilhar conhecimento técnico, mas também de conectar pessoas com diferentes trajetórias na área de tecnologia.
**Destaques do evento incluem:**
- **Palestras de alto nível:** Além da minha, tivemos a excelente apresentação de **Erivaldo Lopes**, que trouxe insights sobre escalabilidade no Kubernetes com Cluster API e Cluster Autoscaler.
- **Ambiente descontraído:** O local, um coworking-bar, criou uma atmosfera que estimulou networking e troca de ideias de forma natural.
### Reflexões Finais
Eventos como o Cloud Native Floripa são mais do que encontros técnicos, eles simbolizam o crescimento e a força das comunidades de tecnologia locais. Participar em meetups como esse, podemos ver o poder da colaboração e o impacto que podemos causar juntos ao compartilhar conhecimento.
Se você também é apaixonado por tecnologia, recomendo participar desses eventos e quem sabe, contribuir como palestrante. Afinal, cada voz conta na construção de um futuro mais conectado e sustentável!
---
---
# Construindo uma Fundação Sólida para a Nuvem: Monitoria e Observabilidade para Performance e Eficiência em Ambientes Cloud Native
URL: https://www.orafaelferreira.com/artigos/observabilidade-foundation-cloud
Publicado: 2024-01-17
Categoria: Artigos
Tempo de leitura: 9 min de leitura
> Monitoria e observabilidade em ambientes Cloud Native: diferenças, pilares, SLIs, SLOs e SLAs, quatro sinais de ouro, custo dos logs e melhoria contínua.
## Introdução
No contexto atual de tecnologias Cloud Native e microsserviços, exige uma abordagem robusta necessária de monitoria e observabilidade como componentes fundamentais para a garantia de eficiência operacional e performance. Este artigo, explora como a observabilidade detalhada pode fornecer insights valiosos para otimizar o desempenho e a sustentabilidade em ambientes Cloud Native.
### O Papel da Monitoria e Observabilidade
A monitoria e observabilidade são essenciais no ciclo de vida do software, especialmente em ambientes complexos de microsserviços. Elas não apenas facilitam o diagnóstico e a resolução de problemas, mas também ajudam na otimização de recursos e na tomada de decisões baseadas em dados. Veremos como essas práticas se somam e se complementam, proporcionando uma visão mais profunda dos sistemas.
#### O Que São e Por Que São Importantes?
- **Monitoria:** Refere-se ao ato de coletar, processamento e exibição de dados quantitativos de sistemas: CPU, memória e tráfego de rede.
- **Observabilidade:** Evolução da monitoria, permite compreender sistemas complexos a partir de dados externos, abrangendo métricas, tracings e logs.
#### Diferença entre Monitoria e Observabilidade
- Enquanto a monitoria fornece dados quantitativos, a observabilidade permite compreender a complexidade e os detalhes das informações obtidas, permitindo perguntas detalhadas sobre o comportamento do sistema.
### A Importância da Observabilidade
A observabilidade vai além da simples monitoria de sistemas. Ela envolve uma análise aprofundada e contínua do comportamento e performance de sistemas em nuvem
- **Identificação Proativa de Problemas:** A observabilidade permite diagnósticos rápidos e precisos, reduzindo o tempo de inatividade e melhorando a confiabilidade do sistema.
- **Otimização de Recursos:** Insights detalhados sobre o uso dos recursos ajudam a aprimorar a eficiência e reduzir os custos operacionais.
- **Tomada de Decisão Baseada em Dados:** Decisões estratégicas são embasadas em dados concretos, garantindo a sustentabilidade e eficiência a longo prazo.
### Pilares da Observabilidade
- **Metricas:** Avaliam o desempenho dos sistemas e hosts, fornecendo dados para otimização.
- **Logs:** Revelam padrões ocultos e ajudam na resolução de problemas.
- **Trace:** Rastreiam requisições e transações em microsserviços, identificando gargalos e otimizando a performance.
### Ferramentas em Destaque
- **Prometheus:** Utilizada para coleta e armazenamento de métricas. O Prometheus é uma ferramenta poderosa para o monitoramento de sistemas e serviços, oferecendo uma robusta plataforma para a coleta e análise de dados em tempo real.
- **Elasticsearch, Logstash, e Kibana (ELK Stack):** Amplamente utilizada para o gerenciamento e análise de logs. Esta combinação de ferramentas permite a coleta, enriquecimento, armazenamento e análise visual de logs de diversos sistemas e aplicações.
- **Jaeger:** Uma ferramenta de rastreamento distribuído que ajuda na monitoração e solução de problemas em arquiteturas de microsserviços. O Jaeger coleta, armazena e visualiza rastreamentos de transações, facilitando a identificação e a análise de problemas de desempenho em sistemas complexos.
- **Grafana:** Essencial para visualização de dados e criação de dashboards. Grafana permite transformar dados de várias fontes em representações visuais ricas, facilitando a análise e interpretação de métricas complexas.
- **OpenTelemetry:** Focada na coleta e exportação de dados de telemetria. OpenTelemetry veio para fornece uma padronização de exportar dados para observar métricas, rastreamentos e logs, facilitando a integração e a análise de dados.
- **Kube-Prometheus:** Uma coleção de componentes Open Source para o monitoramento nativo de Kubernetes, incluindo Prometheus, Grafana e Alertmanager, juntamente com as configurações necessárias para sua implementação. Kube-Prometheus facilita o monitoramento abrangente dos clusters Kubernetes, integrando-se de maneira eficiente com o ecossistema do Kubernetes.
Estas ferramentas, conseguem formar um ecossistema completo para a implementação eficaz da observabilidade, desde a coleta de dados até a análise e visualização, facilitando o monitoramento e a tomada de decisão baseada em dados concretos.
### Importância dos SLIs, SLOs e SLAs
Estes indicadores são cruciais para medir e estabelecer metas claras de qualidade, alinhando o desempenho e a disponibilidade do produto com as expectativas dos usuários.
### Implementando SLIs, SLOs e SLAs
- **SLIs (Service Level Indicators):** Métricas quantitativas que medem o desempenho do serviço em relação ao SLO estabelecido.
- **SLOs (Service Level Objectives):** Metas de desempenho específicas que um serviço se compromete a alcançar para atender ao SLA.
- **SLAs (Service Level Agreements):** Acordos formais sobre os níveis de serviço entre provedores e clientes.
### Os Quatro Sinais de Ouro
Com a observabilidade conseguimos manter a saúde e a eficiência dos sistemas. The Four Golden Signals ajudam a entender o comportamento de uma aplicação ou serviço. Vamos detalhar cada um desses sinais:
#### Latência
- **Descrição:** Mede o tempo de resposta das requisições e seu impacto na experiência do usuário.
- **Métodos de Medição:**
- Tempo de respostas das requisições.
- Separando a latência de requisições bem e malsucedidas.
#### Tráfego
- **Descrição:** Refere-se ao volume de demanda do serviço ou aplicação, essencial para entender padrões de uso.
- **Métodos de Medição:**
- Quantidade de requisições por segundo.
- Agrupamento de requisições em grupos específicos para análise mais detalhada.
#### Erros
- **Descrição:** Tipos de falhas no sistema, fundamentais para a detecção de problemas.
- **Métodos de Medição e Categorização:**
- Categorização de códigos de status HTTP (404, 500, etc.).
- Identificação de exceções lançadas pela aplicação.
#### Saturação
- **Descrição:** Indica o nível de utilização dos recursos, sinalizando sobrecarga e a necessidade de escalabilidade.
- **Métodos de Medição:**
- Medição da sobrecarga de recursos (CPU, memória, disco, rede).
Cada um destes sinais oferece insights valiosos sobre diferentes aspectos do sistema e, quando monitorados juntos, proporcionam uma visão abrangente da saúde e desempenho da aplicação ou serviço.
### Logs São Caros
O gerenciamento de logs é uma parte crítica da observabilidade, mas pode se tornar inviável se não for feito de maneira estratégica. A eficácia e o custo dos logs dependem de como são utilizados e gerenciados dentro de uma organização.
#### Caro para Quem Não Sabe o Que Fazer com Eles
- **Definição de Objetivos:** Sem uma compreensão clara do que se pretende alcançar com os logs, eles podem se tornar apenas um amontoado de dados sem valor agregado.
- **Coleta Seletiva:** É essencial definir o que é importante coletar. A coleta indiscriminada de logs pode levar a custos desnecessários e a um excesso de informações.
#### Logs Sem Análise: Dinheiro Gasto à Toa
- **Análise de Logs:** Logs que não são regularmente revistos ou analisados podem representar um gasto inútil. É crucial ter alguém que monitore e analise os logs para extrair insights valiosos.
- **Ação Baseada em Logs:** A verdadeira utilidade dos logs vem da ação tomada com base nas informações coletadas. Sem ação, os logs não passam de dados sem uso.
#### Estratégias para Gerenciamento de Custos de Logs
- **Ferramentas Eficientes:** O uso de ferramentas apropriadas para o gerenciamento de logs pode ajudar a reduzir custos, fornecendo análise e armazenamento eficientes.
- **Políticas de Retenção:** Definir políticas de retenção adequadas ajuda a manter apenas os logs necessários, reduzindo o armazenamento e os custos associados.
Ao abordar os logs com uma estratégia clara, focada na coleta seletiva e na análise eficaz, as organizações podem transformar o que seria um custo em um investimento valioso que apoia a tomada de decisão baseada em dados e melhora contínua dos sistemas.
### Observabilidade: Um Ciclo Infinito de Melhoria
- **Fundamental para o Negócio:** A ausência de observabilidade em uma aplicação sugere que ela pode não ser considerada vital para o negócio. A observabilidade contínua garante que os sistemas sejam confiáveis e performáticos.
- **Equipe Dedicada:** Idealmente, cada aplicação deve ter uma equipe dedicada focada em sua observabilidade, garantindo atenção contínua e melhorias constantes.
#### Quem Não Mede, Não Gerencia
- **Maturidade Organizacional:** Implementar a observabilidade exige maturidade organizacional. É um processo complexo que necessita de uma abordagem detalhada e dedicada.
- **Desafios da Implementação:** A implantação de sistemas de observabilidade não é trivial. Exige um entendimento profundo dos sistemas e uma integração efetiva com as práticas de DevOps.
### Cultura de Observabilidade
A criação de uma cultura que valoriza a observabilidade é crucial para o sucesso em ambientes dinâmicos e competitivos.
#### Incentivando a Colaboração
- **Colaboração Interfuncional:** Desenvolvedores, operações e equipes de QA devem trabalhar juntos para identificar e resolver problemas de forma rápida e eficaz.
- **Resolução Rápida de Problemas:** Uma cultura focada na observabilidade permite que problemas sejam identificados e resolvidos rapidamente, minimizando o impacto negativo no desempenho e na experiência do usuário.
Uma cultura de observabilidade robusta não só melhora a confiabilidade e a performance dos sistemas,
### "O Lento é o Novo Parado"
No mundo dinâmico da tecnologia atual, onde a eficiência e a rapidez são cruciais, "o lento é o novo parado". A observabilidade permite identificar rapidamente áreas onde o sistema está operando de forma mais lenta do que o ideal, possibilitando correções antes que se tornem problemas maiores.
#### Implicações para o Desempenho do Sistema
- **Expectativas de Desempenho:** Em uma era onde tudo é instantâneo, um sistema lento pode ser tão prejudicial quanto um sistema inoperante. Usuários e clientes esperam respostas rápidas e eficientes.
- **Percepção do Usuário:** Atrasos, mesmo que breves, podem afetar negativamente a percepção do usuário sobre a aplicação, levando à insatisfação e possível perda de clientes.
### Computação Verde e Observabilidade
- A relação entre práticas de observabilidade e computação verde, destaca-sem práticas de monitoramento que contribuem para a redução de poder de processamento sem utilização, gerando uma redução no impacto ambiental.
- Implementação de soluções de monitoramento avançado para uma análise contínua e detalhada dos sistemas.
- Utilização de observabilidade alinhada com as operações de TI junto com os princípios de sustentabilidade, reduzindo a pegada de carbono.
### Conclusão e Chamado à Ação
Destaco a importância de adotar práticas de monitoria e observabilidade desde o início do desenvolvimento do projeto. Encorajo os iniciantes não apenas aprendam, mas também contribuam ativamente com a comunidade, compartilhando suas descobertas e melhores práticas.
Este artigo destina-se a servir como uma referência abrangente e ponto de partida para aqueles que estão começando sua jornada em ambientes Cloud Native, focando na importância crítica da monitoria e observabilidade para garantir sistemas eficientes, confiáveis e sustentáveis.
---
# Azure Backup should be enabled for Virtual Machines
URL: https://www.orafaelferreira.com/artigos/azure-backup-virtual-machines
Publicado: 2024-01-15
Categoria: Artigos
Tags: Terraform
Tempo de leitura: 25 min de leitura
> Por que a policy Azure Backup should be enabled for Virtual Machines é essencial em ambientes corporativos e os riscos de não ter backup automático em VMs.
### Visão Geral
Vamos explorar por que a policy **"Azure Backup should be enabled for Virtual Machines"** (ID: 013e242c-8828-4970-87b3-ab247555486d) é essencial em ambientes corporativos. Como continuação dos fundamentos de Azure Policy, vamos detalhar os riscos de não ter backup automático em VMs, o funcionamento técnico dessa policy, sua relação com boas práticas e compliance (Azure Security Benchmark, ISO 27001, LGPD, GDPR, CMMC) e como aplicá-la na prática para melhorar a continuidade de negócios. Também abordaremos mecanismos de remediação – desde habilitar backup manualmente, com IAC (Infraestrutura como código) e via Azure Policy.
### Riscos de não habilitar backup em máquinas virtuais
Não realizar backups automáticos de máquinas virtuais pode ocasionar riscos significativos. Em caso de falhas, erro humano ou ataque cibernético, uma VM sem backup pode resultar em **perda irreversível de dados**, comprometendo a integridade e disponibilidade das informações e interrompendo operações críticas do negócio. Por exemplo, se um servidor de banco de dados em produção for perdido e não possuia backup, a empresa irá enfrentar **horas (ou dias) de indisponibilidade** e perda de dados transacionais importantes.
**Alguns riscos reais de não ter backup habilitado em VMs incluem:**
- **Perda de Dados e Impacto Financeiro:** Dados armazenados apenas no disco da VM ficam suscetíveis a falhas. Um colapso de disco ou exclusão acidental pode significar perda permanente de informações valiosas, gerando prejuízos financeiros e operacionais.
- **Continuidade do Negócio Comprometida:** Sem backups, a recuperação de uma VM crítica pode ser inviável, resultando em **downtime prolongado** e possíveis violações de SLAs.
- **Ataques de Ransomware:** VMs sem backup tornam a empresa mais vulnerável. Em um ataque de ransomware, se não houver cópias de segurança recentes, a única opção pode ser pagar resgate (sem garantia de sucesso) ou perder os dados. Com backups, é possível restaurar o sistema ao estado pré-ataque. Além disso, o Azure Backup oferece recursos de segurança como *Soft Delete* e *MFA* no ato da exclusão, protegendo as cópias contra tentativas maliciosas de apagá-las.
- **Compliance e Reputação:** A ausência de backup pode gerar não-conformidade com normas de proteção de dados e continuidade. Um incidente de perda definitiva de informações pode resultar em multas regulatórias e danificar a reputação da empresa.
### Como funciona a Azure Policy "Azure Backup should be enabled for Virtual Machines"
Essa Azure Policy é uma definição *built-in* da Microsoft criada para garantir que as VMs tenham backup habilitado. Trata-se de uma policy do tipo **AuditIfNotExists** (modo **Indexed**), ou seja, **não** impede a criação da VM, mas **audita** o ambiente e **marca como não conformes** as VMs que não possuam item de backup registrado em um **Recovery Services Vault**.
#### Detalhes técnicos principais
- **Modo e Efeito:** Funciona em modo Indexed e o efeito padrão é AuditIfNotExists. Para cada recurso do tipo Microsoft.Compute/virtualMachines, a policy verifica a existência de um recurso de backup (Microsoft.RecoveryServices/vaults/backupProtectedItems). Se não houver, marca a VM como não conforme.
- **Condição (rule):** Aplica-se a todas as VMs, **exceto** VMs geradas por serviços gerenciados como Azure Databricks e Azure OpenShift, onde o backup tradicional do Azure VM não se aplica.
- **Checagem de Compliance:** Caso a VM não esteja em um cofre de backup, a policy gera a não-conformidade. A severidade é listada como "Low" no portal, mas, do ponto de vista de continuidade de negócios, o risco é alto.
- **Aplicação em Escala:** Ao atribuí-la no nível de *Subscription* ou *Resource Group*, a policy auditará continuamente VMs novas e existentes. Se a VM for criada sem backup, aparecerá como **non-compliant**.
Em um ambiente corporativo enterprise, com muitas VMs, essa Azure Policy dá visibilidade proativa, permitindo identificar instâncias não protegidas pelo Azure Backup.
### Alinhamento com melhores práticas e benchmarks de segurança
Habilitar backups automáticos em VMs é tanto uma recomendação de boas práticas quanto um requisito em diversos frameworks de segurança e conformidade. Confira alguns exemplos:
| **Padrão/Benchmark** | **Controle/Norma** | **Requisito relacionado a backup** |
|----------------------|-------------------|-------------------------------------|
| **Azure Security Benchmark (v3)** | **BR-1 – Backup and Recovery** | "Ensure backup of business-critical resources, either during resource creation or enforced through policy." O ASB recomenda habilitar backup em VMs e cita Azure Policy. |
| **ISO/IEC 27001:2013** | **A.12.3.1 – Backup de informações** | Requer cópias de segurança periódicas e testadas regularmente. O backup de VMs garante disponibilidade de dados após incidentes. |
| **LGPD (Lei 13.709/2018)** | **Art. 46 – Segurança da Informação** | Exige medidas para proteger dados pessoais contra destruição ou perda acidental/ilícita. Manter backups de VMs que tratam dados pessoais ajuda a prevenir perda total. |
| **GDPR (Regulamento Geral de Proteção de Dados)** | **Art. 32(1)(c)** – Segurança do Processamento | Determina a capacidade de restabelecer a disponibilidade de dados pessoais em caso de incidente. Backups de VMs são essenciais para cumprir essa obrigação. |
| **CMMC (Cybersecurity Maturity Model)** | **RE.2.137 & RE.3.139** – Recovery | Exigem backups regulares e testados (Nível 2) e backups completos e resilientes (Nível 3). A Azure Policy garante que nenhuma VM fique sem backup. |
Manter backups automáticos suporta diretamente controles de continuidade de negócio e proteção de dados em vários âmbitos. Frameworks adicionais, como *CIS Controls v8* e *NIST SP 800-53 (CP-9)*, também exigem backups. Logo, habilitar backup em VMs contribui para uma postura de segurança robusta e alinhada aos principais padrões de segurança.
### Continuidade de negócios e recuperação de desastres
Em termos de **Disaster Recovery (DR)** e **Business Continuity (BC)**, ter backups habilitados para VMs é essencial. Essa policy automatiza a garantia de que as VMs tenham backup, alinhando-se a **RTO** (Recovery Time Objective) e **RPO** (Recovery Point Objective) definidos pela empresa.
- **RPO (Recovery Point Objective):** Quantidade aceitável de perda de dados em termos de tempo. Com backups regulares, você mantém um RPO baixo, pois nenhum servidor fica fora do ciclo de backup.
- **RTO (Recovery Time Objective):** Tempo necessário para restaurar um sistema após falha. Com backups ativos, a restauração é mais rápida, reduzindo downtime.
- **Recuperação Granular vs. Completa:** O Azure Backup para VMs gera pontos de recuperação armazenados em cofres *Recovery Services*. É possível restaurar a VM inteira ou apenas arquivos específicos.
- **Cross-Region Restore:** O Azure Backup suporta restauração cruzada entre regiões (quando habilitado com GRS), garantindo recuperação mesmo se uma região inteira estiver indisponível.
**Backups regulares e testados** são parte de qualquer plano de continuidade de negócios. A policy "Backup should be enabled for VMs" garante a existência de backup, mas cabe à empresa testar as restaurações e validar RPO/RTO.
### Aplicação prática e remediação (habilitando os backups)
Identificar VMs sem backup é só o primeiro passo. O próximo é **habilitar o Azure Backup**:
#### 1. Habilitando Policy via Portal (manual):
- Acesse a VM no portal Azure e clique em *Policy*.
- Vá até Definitions, Procure *Azure Backup should be enabled for Virtual Machines*.
- Clique em *Assign policy*.
- Selecione *Escopo* e a Subscription.
- Review + Create.
Ai só esperar e ir verificar:
#### 2. Habilitando backup via Portal (manual):
- Acesse a VM no portal Azure e clique em *Backup*.
- Escolha (ou crie) um *Recovery Services Vault*.
- Configure a frequência e retenção (política de backup).
- Clique em *Enable Backup*.
Agora o vault vai ser criado, porém a policy ainda não estará em compliance, será necessário executar o job do backup:
Agora ficando compliance:
#### 3. Habilitando backup via Azure Policy (automatizado):
Use políticas do tipo **DeployIfNotExists** para configurar automaticamente o backup em VMs não protegidas. Exemplos:
- *Configure backup on VMs of a location to an existing central vault*
- *Configure backup on VMs with a given tag to a new Recovery Services vault*
Ao atribuir essas políticas, o Azure habilita o backup conforme o cofre definido.
#### 4. Terraform:
No exemplo usando Terraform, dividimos a configuração em duas etapas. Primeiro, criamos a máquina virtual sem backup habilitado (para mostrar que a Azure Policy com efeito AuditIfNotExists não bloqueia a criação, apenas audita a conformidade). Em seguida, adicionamos os recursos de backup (Recovery Services Vault e a associação da VM a esse vault).
##### Etapa 1: Criando VM sem backup habilitado
Nesta etapa, definimos os recursos básicos: grupo de recursos, rede virtual, interface de rede e a máquina virtual em si, sem configurar backup. A Azure Policy de tipo AuditIfNotExists irá permitir a criação da VM, mas marcará esse recurso como não conforme por não ter backup habilitado. E vamos para os passos com terraform
OBS: lembre-se de estar autenticado com azure:
```bash
az login
```
Vamos criar o seguinte arquivo: "main.tf"
```hcl
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0"
}
}
required_version = ">= 1.1.0"
}
provider "azurerm" {
features {}
}
## Definição do Resource Group
resource "azurerm_resource_group" "rg" {
name = "rg-exemplo-backup"
location = "eastus"
}
## Rede virtual com uma sub-rede
resource "azurerm_virtual_network" "vnet" {
name = "vnet-exemplo"
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
}
resource "azurerm_subnet" "subnet" {
name = "subnet-exemplo"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
address_prefixes = ["10.0.1.0/24"]
}
## Interface de rede para a VM
resource "azurerm_network_interface" "nic" {
name = "nic-exemplo"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
ip_configuration {
name = "nic-ipcfg"
subnet_id = azurerm_subnet.subnet.id
private_ip_address_allocation = "Dynamic"
}
}
## Máquina Virtual (Linux) sem backup habilitado
resource "azurerm_linux_virtual_machine" "vm" {
name = "vm-exemplo"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
size = "Standard_B1s"
admin_username = "azureuser"
admin_password = "P@ssw0rd12345!"
disable_password_authentication = false
network_interface_ids = [
azurerm_network_interface.nic.id
]
os_disk {
name = "osdisk-exemplo"
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "UbuntuServer"
sku = "18.04-LTS"
version = "latest"
}
}
```
Executar os seguintes comandos:
```bash
terraform init
```
```bash
terraform validate
```
```bash
terraform plan
```
```bash
terraform apply --auto-approve
```
Podemos ver que ela ficou 'Non-compliant':
##### Etapa 2: Habilitando backup na VM (Recovery Services Vault + Protected Item)
Agora, adicionamos os recursos de backup via IaC. Vamos criar um Recovery Services Vault (cofre de backup) e então habilitar o backup da VM criando um Backup Protected Item. Esse item associa a VM ao vault, aplicando uma política de backup definida.
```hcl
## Recovery Services Vault para armazenar os backups
resource "azurerm_recovery_services_vault" "vault" {
name = "vault-backups-exemplo"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
sku = "Standard"
}
## Política de backup para VMs (diária às 23:00, retenção de 7 dias)
resource "azurerm_backup_policy_vm" "policy" {
name = "policy-diaria"
resource_group_name = azurerm_resource_group.rg.name
recovery_vault_name = azurerm_recovery_services_vault.vault.name
backup {
frequency = "Daily"
time = "23:00"
}
retention_daily {
count = 7
}
}
## Habilitando o backup na VM
resource "azurerm_backup_protected_vm" "backup_associacao" {
resource_group_name = azurerm_resource_group.rg.name
recovery_vault_name = azurerm_recovery_services_vault.vault.name
source_vm_id = azurerm_linux_virtual_machine.vm.id
backup_policy_id = azurerm_backup_policy_vm.policy.id
}
```
No trecho acima, azurerm_backup_protected_vm cria a associação de backup. Ao aplicar essas configurações, a VM passa a ter backup ativado no cofre especificado, atendendo à exigência da Azure Policy.
Primeiro executamos:
```bash
terraform plan
```
Para validar se nada vai quebrar ou destruir a VM:
Depois executamos:
```bash
terraform apply --auto-approve
```
AGORA podemos ter certeza que não irá destruir nossa vm beta tester:
**Por que estamos fazendo isso?**
Imagine ter um ambiente com 10 vms, talvez seja simples. Mas em um caso onde temos mais de mil VMs? E se modificarmos o nosso "módulo" das VMs sem antes testar. Por isso é importante existir um versionamento de módulo, geração de TAGs!
Porém ela ainda vai ficar com status de 'Non-compliant', precisamos executar o job de backup:
Podemos forçar o assessment da policy, para isso podemos usar o comando:
```bash
az policy state trigger-scan --subscription
```
E assim depois podemos analisar que ela ficou em compliance:
#### 5. Bicep 💪🏻
A seguir, temos o mesmo cenário implementado em Bicep. Assim como no exemplo Terraform, primeiro definimos a VM sem backup e depois incluímos o Recovery Services Vault e a configuração de backup da VM. A sintaxe do Bicep permite aninhar recursos do Azure de forma declarativa.
##### Etapa 1: Criando VM sem backup habilitado
Nesta etapa inicial do Bicep, criamos a infraestrutura básica sem nenhum backup configurado para a VM. Novamente, a policy AuditIfNotExists apenas auditará a VM (não impedirá a criação).
```bicep
@description('Local da implantação')
param location string = resourceGroup().location
@description('Nome de usuário administrador para a VM')
param adminUsername string = 'azureuser'
@description('Senha de administrador')
@secure()
param adminPassword string
// Rede virtual e sub-rede
resource vnet 'Microsoft.Network/virtualNetworks@2021-02-01' = {
name: 'vnet-exemplo'
location: location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: 'subnet-exemplo'
properties: {
addressPrefix: '10.0.1.0/24'
}
}
]
}
}
resource nic 'Microsoft.Network/networkInterfaces@2021-02-01' = {
name: 'nic-exemplo'
location: location
properties: {
ipConfigurations: [
{
name: 'nic-ipcfg'
properties: {
subnet: {
id: vnet.properties.subnets[0].id
}
privateIPAllocationMethod: 'Dynamic'
}
}
]
}
}
resource virtualMachine 'Microsoft.Compute/virtualMachines@2022-03-01' = {
name: 'vm-exemplo'
location: location
properties: {
hardwareProfile: {
vmSize: 'Standard_B1s'
}
osProfile: {
computerName: 'vm-exemplo'
adminUsername: adminUsername
adminPassword: adminPassword
linuxConfiguration: {
disablePasswordAuthentication: false
}
}
storageProfile: {
osDisk: {
createOption: 'FromImage'
name: 'osdisk-exemplo'
caching: 'ReadWrite'
managedDisk: {
storageAccountType: 'Standard_LRS'
}
}
imageReference: {
publisher: 'Canonical'
offer: 'UbuntuServer'
sku: '18.04-LTS'
version: 'latest'
}
}
networkProfile: {
networkInterfaces: [
{
id: nic.id
}
]
}
}
}
```
Para fazer o deploy, primeiro criamos o RG pelo portal, e depois:
```powershell
New-AzResourceGroupDeployment -Name main -TemplateFile main.bicep
```
Precisamos passar o nome do ResourceGroup e adminPassword:
E podemos atualizar a página de 'Compliance':
##### Etapa 2: Habilitando backup na VM (Recovery Services Vault + Protected Item)
```bicep
// Recovery Services Vault para armazenar os backups
resource vault 'Microsoft.RecoveryServices/vaults@2024-10-01' = {
name: 'vault-backups-exemplo'
location: location
sku: {
name: 'Standard'
}
properties: {
publicNetworkAccess: 'Enabled'
}
}
// Política de backup para VMs
resource backupPolicy 'Microsoft.RecoveryServices/vaults/backupPolicies@2024-10-01' = {
name: 'policy-diaria'
parent: vault
properties: {
backupManagementType: 'AzureIaasVM'
schedulePolicy: {
schedulePolicyType: 'SimpleSchedulePolicy'
scheduleRunFrequency: 'Daily'
scheduleRunTimes: [
'2023-01-01T23:00:00Z'
]
}
retentionPolicy: {
retentionPolicyType: 'LongTermRetentionPolicy'
dailySchedule: {
retentionTimes: [
'2023-01-01T23:00:00Z'
]
retentionDuration: {
count: 7
durationType: 'Days'
}
}
}
}
}
// Associação da VM ao backup
var containerName = 'iaasvmcontainer;iaasvmcontainerv2;${resourceGroup().name};${virtualMachine.name}'
var protectedItemName = 'vm;iaasvmcontainerv2;${resourceGroup().name};${virtualMachine.name}'
resource vmBackup 'Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems@2024-10-01' = {
name: '${vault.name}/Azure/${containerName}/${protectedItemName}'
properties: {
protectedItemType: 'Microsoft.Compute/virtualMachines'
policyId: backupPolicy.id
sourceResourceId: virtualMachine.id
}
}
```
Agora vamos executar o backup da VM manualmente para podermos ver a Policy em conformidade:
#### 6. Exceções e cenários especiais:
Se VMs não precisam de backup (por design ou custo), use filtros ou *Not Scopes*. Porém, cada VM fora do backup é um ponto de falha em potencial; avalie bem as exceções.
Conforme as VMs passam a ter backup, a **postura de compliance** melhora. Você pode monitorar no *Azure Policy* ou no *Azure Security/Defender for Cloud* a métrica de conformidade subindo.
### Conclusão
A Azure Policy **"Azure Backup should be enabled for Virtual Machines"** age como o famoso "dedo duro", evitando que VMs fiquem desprotegidas. Ela permite que times de engenharia de nuvem e DevOps **implementem de forma consistente a prática de backup**, reduzindo riscos de perda de dados, interrupções prolongadas e exposição a ataques.
Para a empresa, ter essa política ativa **facilita auditorias e compliance**, evidenciando controles de continuidade alinhados a frameworks reconhecidos (Azure Security Benchmark, ISO 27001 etc.). Em auditorias ou certificações, backups ativos em todas as VMs indicam maturidade em **governança de nuvem**.
Lembre-se: **backup não substitui outras camadas de segurança** (replicação, failover, etc.), mas é a base de **uma estratégia sólida de recuperação de desastres**. Habilitar o Azure Backup em VMs (e usar Azure Policy para garantir isso) é uma decisão de **baixo esforço** e **alto impacto** para aumentar a resiliência.
#### Fontes e Referências
- [Azure Backup](https://learn.microsoft.com/azure/backup/)
- [Azure Policy](https://learn.microsoft.com/azure/governance/policy/)
- [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html)
- [LGPD](https://jusbrasil.com.br/artigos/731613780/lei-geral-de-protecao-de-dados)
- [GDPR](https://privacy-regulation.eu/)
- [CMMC](https://www.cmmcab.org/)
---
# Construindo uma Fundação Sólida para a Nuvem com FinOps: Maximizando os Custos em Ambientes Cloud Native
URL: https://www.orafaelferreira.com/artigos/finops-foundation-cloud
Publicado: 2024-01-15
Categoria: Artigos
Tags: GreenOps
Tempo de leitura: 10 min de leitura
> O que é FinOps, seus princípios, personas e primeiros passos de adoção, além de como integrar DevOps e Kubecost para governar custos em ambientes Cloud Native.
### O que é FinOps?
FinOps é uma estrutura operacional e prática cultural que maximiza o valor comercial da nuvem. Ela envolve a colaboração entre equipes de engenharia, finanças e negócios permitindo a tomada de decisões baseadas em dados afim de criar responsabilidade financeira. FinOps é a união de “Finanças” e “DevOps”, enfatizando a comunicação e colaboração entre as equipes.
Conselho Consultivo Técnico da Fundação FinOps define FinOps como uma mudança cultural, onde a responsabilidade pelo uso da nuvem é compartilhada por todos, apoiada por um grupo central de práticas recomendadas. Essa abordagem multifuncional permite uma entrega mais rápida de produtos com maior controle financeiro e previsibilidade.
#### Estrutura FinOps
A estrutura FinOps é sobre trazer responsabilidade para gastos na nuvem. Independentemente de ser chamada de “Gestão Financeira em Nuvem”, “Engenharia Financeira em Nuvem”, ou outros nomes, a essência do FinOps é a responsabilidade financeira no modelo de gastos variáveis da nuvem. Isso envolve equipes distribuídas de engenharia e negócios trazendo compromissos e equilibrando entre velocidade, custo e qualidade nas decisões de arquitetura de nuvem e investimento.
Não trata-se apenas sobre economizar dinheiro, mas sobre como obter o máximo de valor da nuvem para impulsionar um crescimento de forma eficiente. Isso inclui a capacitação de equipes de engenharia para fornecer melhores recursos e aplicações mais rapidamente, e facilita uma conversa multifuncional sobre onde e quando investir.
#### Modelo de Maturidade FinOps
FinOps é uma prática iterativa, com a maturidade melhorando com a repetição. Uma organização no estágio inicial ("Crawl") é mais reativa, enquanto no estágio "Run", considera proativamente os custos nas escolhas de design de arquitetura e processos de engenharia.
#### Principais Partes Interessadas do Gerenciamento Financeiro em Nuvem
FinOps envolve várias partes interessadas, incluindo Executivos, Engenheiros, Praticantes de FinOps, Operações, Finanças e Aquisições, cada um desempenhando um papel diferente na prática de FinOps.
### Princípios do FinOps
Os Princípios do FinOps atuam como uma bússola orientadora para as atividades da prática de FinOps. Desenvolvidos pelos membros da FinOps Foundation e aprimorados através da experiência, esses princípios cobrem múltiplas nuvens e podem evoluir ao longo do tempo com a aquisição de novas experiências.
Existem seis princípios norteadores na prática de FinOps, que guiam as atividades e decisões dentro dessa abordagem. Esses princípios devem ser considerados como um todo e praticados integralmente:
#### 1. 🤝 Colaboração entre Equipes
- Equipes de finanças, tecnologia, produto e negócios trabalham juntas em tempo quase real.
- Colaboração contínua para eficiência e inovação.
#### 2. 📊 Decisões Baseadas no Valor do Negócio
- Métricas baseadas em valor econômico unitário e valor demonstram melhor o impacto nos negócios do que o gasto agregado.
- Decisões conscientes entre custo, qualidade e velocidade.
- Visão da nuvem como um motor de inovação.
#### 3. 🔗 Responsabilidade Compartilhada pelo uso da Nuvem
- Responsabilidade pelo uso e custo é descentralizada, com os engenheiros assumindo a propriedade dos custos desde o design da arquitetura até as operações contínuas.
- Equipes de produto e funcionalidades gerenciam seu próprio uso da nuvem em relação ao seu orçamento.
- Decisões descentralizadas sobre arquitetura econômica, uso de recursos e otimização.
#### 4. 📈 Relatórios Acessíveis e Oportunos
- Dados de FinOps devem ser processados e compartilhados assim que disponíveis.
- Visibilidade em tempo real promove melhor utilização da nuvem.
- Ciclos rápidos de feedback resultam em comportamento mais eficiente.
#### 5. 🌐 Equipe Centralizada no FinOps
- A equipe central incentiva, evangeliza e possibilita melhores práticas em um modelo de responsabilidade compartilhada.
- Compra executiva do FinOps e suas práticas e processos é necessária.
- Otimização de taxas, compromissos e descontos é centralizada para aproveitar as economias de escala.
#### 6.💡Aproveitamento do Modelo de Custo Variável
- O modelo de custo variável da nuvem deve ser visto como uma oportunidade para entregar mais valor, não como um risco.
- Preferência por planejamento iterativo ágil em vez de planos estáticos de longo prazo.
- Design de sistema proativo com ajustes contínuos em otimização da nuvem.
### Adotando FinOps – Começando
A adoção do FinOps em uma organização começa com a construção de uma apresentação informativa para outras equipes, colegas de trabalho e partes interessadas sobre os benefícios de construir uma prática de FinOps. É essencial obter suporte executivo amplo e compromisso para dedicar tempo e recursos necessários para a mudança cultural.
#### Os Direcionadores do FinOps: Os Primeiros Passos
Um papel chave para a adoção do FinOps é o "Direcionador". Abaixo estão algumas etapas e marcos importantes:
##### Etapa 1 – Planejando FinOps em uma Organização
1. **Faça sua pesquisa:** Identifique as partes interessadas chaves dentro da organização. Isso inclui procurar um Patrocinador Executivo e apoiadores para construir a iniciativa.
2. **Crie um plano:** Desenvolva um plano de futuro estado e identifique requisitos de ferramentas e um "lar" organizacional para a função FinOps.
3. **Apresente o roteiro:** Obtenha feedback do patrocinador executivo e ajuste conforme necessário, incluindo tamanho inicial da equipe, orçamento e cronograma.
4. **Efetuar a mobilização inicial de recursos:** Recrute outros líderes executivos como patrocinadores e obtenha aprovação de orçamento e contratação.
##### Etapa 2 – Socializando FinOps para Adoção na Organização
- **Promova os valores centrais da mudança.**
- **Crie conversas sobre FinOps com equipes impactadas.**
- **Defina um modelo inicial de FinOps.**
##### Etapa 3 – Preparando a Organização para FinOps
- **Avalie a prontidão para o FinOps.**
- **Envolver as partes interessadas.**
#### Personas
Ao propor a adoção de uma função FinOps dentro de uma organização, é necessário informar uma variedade de personas entre a equipe executiva.
#### Responsabilidade e Expectativas por Equipe (Modelagem RACI / DACI)
Definir expectativas e gerenciar a responsabilidade entre várias equipes e funções é fundamental para construir uma prática e cultura FinOps duradouras. Usando uma combinação de modelos RACI e DACI, podemos começar a mapear os princípios centrais do FinOps para as equipes e indicar melhor seu nível de envolvimento.
#### Apresentação Adotando FinOps na sua organização
Para ajudar a colocar todos os pontos apresentados foi criado uma [Apresentação](https://docs.google.com/presentation/d/17shQqIbmXMbjhAW26nD7qJeM9kqsbaDkTS9WzMk1okg/edit#slide=id.ged5e228ee8_0_0) aberto que qualquer praticante de FinOps pode usar como ponto de partida.
### The Azure FinOps Guide
Este guia centraliza informações e ferramentas de FinOps no Azure, permitindo uma melhor compreensão e otimização dos custos na nuvem. Os principais objetivos deste guia são:
1. **Identificar oportunidades de economia de custos:** Fornecendo insights detalhados sobre como os recursos podem ser otimizados para reduzir despesas desnecessárias.
2. **Otimizar a eficiência da nuvem:** Melhorando a utilização de recursos para maximizar o retorno sobre o investimento (ROI) em infraestrutura de nuvem.
3. **Ganhar uma melhor compreensão e controle dos custos na nuvem:** Ajudando as equipes a monitorar, relatar e controlar os gastos de forma eficaz, alinhando as decisões financeiras com os objetivos de negócios.
O guia é especialmente útil para organizações que utilizam serviços de nuvem do Azure e buscam otimizar seus custos, incluindo tomadores de decisão financeira, engenheiros de nuvem, profissionais de TI e fornecedores independentes de software (ISVs). Ele também incentiva a colaboração entre equipes de engenharia, finanças e negócios, promovendo uma prática cultural onde todos assumem responsabilidade pelo uso e custo da nuvem.
Para mais detalhes e acesso ao conteúdo completo, você pode visitar o [The Azure FinOps Guide](https://techcommunity.microsoft.com/t5/fasttrack-for-azure/the-azure-finops-guide/ba-p/3704132).
### Visão Geral
A adoção de tecnologias Cloud Native está se tornando cada vez mais essencial para as empresas que buscam inovação e agilidade. No entanto, para garantir uma transição bem-sucedida, é crucial estabelecer uma base sólida que não apenas suporte a eficiência técnica, mas que também promova a sustentabilidade. Vamos explorar o papel vital da FinOps e práticas sustentáveis na construção de uma infraestrutura robusta e responsável em ambientes Cloud Native.
### A Importância da Cultura Organizacional e Técnica
A transformação digital transcende a mera adoção de novas tecnologias; ela exige uma mudança substancial na cultura organizacional. A forma como uma empresa abraça a cultura Cloud Native tem um impacto profundo na eficiência operacional e na sustentabilidade. Uma cultura organizacional bem desenvolvida é a base para uma adoção bem-sucedida e sustentável das tecnologias Cloud Native.
### A Revolução do DevOps e a Eficiência do FinOps
A integração de DevOps com FinOps abre um novo horizonte para as empresas, combinando eficiência técnica com sustentabilidade financeira. Esta sinergia permite que as organizações otimizem seus recursos, reduzam custos e, ao mesmo tempo, mantenham um alto padrão de inovação e eficiência operacional.
### Governança de Custo com [Kubecost](https://www.kubecost.com/)
A governança de custos é crucial para gerenciar as finanças em ambientes de Kubernetes, como o Azure Kubernetes Service (AKS). O Kubecost é uma ferramenta poderosa que ajuda as organizações a entender, gerenciar e otimizar os custos de seus clusters Kubernetes. Suas principais funcionalidades incluem:
- **Alocação de Custos Detalhada:** Permite atribuir custos a níveis como implantação, serviço, rótulo, pod ou namespace, facilitando uma visão precisa e detalhada das despesas.
- **Monitoramento e Otimização:** Fornece ferramentas para monitorar o uso de recursos e sugerir melhorias na infraestrutura para reduzir custos e aumentar a eficiência.
- **Controle Proativo de Custos:** Implementa políticas para garantir que o uso de recursos esteja alinhado com os objetivos financeiros da organização, prevenindo desperdícios e otimizando o orçamento.
Para saber mais:
- [Kubecost no Microsoft Learn](https://learn.microsoft.com/pt-br/azure/cloud-adoption-framework/scenarios/app-platform/aks/cost-governance-with-kubecost)
- [Kubecost na FinOps Foundation](https://www.finops.org/members/kubecost/)
### Maximizando a Transparência com Observabilidade
A observabilidade desempenha um papel crucial na maximização da eficiência operacional. Ao fornecer insights detalhados sobre o desempenho e as necessidades de um ambiente Cloud Native, as organizações podem identificar áreas para melhoria, otimizando tanto o desempenho quanto a sustentabilidade.
### Benefícios para o Ecosistema Open Source
A adoção de práticas robustas em Cloud Native beneficia imensamente a comunidade Open Source. Uma base sólida facilita a implementação de soluções Open Source de maneira eficiente e segura, enriquecendo o ecossistema com contribuições valiosas e promovendo uma cultura de inovação aberta e colaborativa.
#### E falando de Open Source, temos o OpenCost
E se você preferir uma ferramenta open source? O OpenCost é uma solução de código aberto para monitoramento e alocação de custos em tempo real em ambientes Kubernetes. Desenvolvido e suportado por uma comunidade de especialistas em Kubernetes, incluindo grandes players como AWS, Google Cloud, e Microsoft, o OpenCost oferece uma visão transparente dos gastos em Kubernetes.
Principais funcionalidades do OpenCost incluem:
- **Alocação de Custos em Tempo Real:** Detalhamento de custos até o nível de contêiner, baseado em conceitos do Kubernetes.
- **Precificação Dinâmica de Ativos:** Integrações com APIs de faturamento de AWS, Azure, GCP, e suporte para clusters on-premises com preços personalizados.
- **Monitoramento de Recursos em Cluster:** Inclui CPU, GPU, memória, balanceadores de carga e volumes persistentes.
- **Monitoramento de Custos Fora do Cluster:** Rastreia custos de serviços gerenciados como armazenamento e bancos de dados.
- **Integração com Ferramentas de Código Aberto:** Exportação de dados para Prometheus e outras ferramentas open source.
Para mais informações, acesse [OpenCost](https://www.opencost.io/).
### Conclusão e Chamado à Ação
Ao adotar tecnologias Cloud Native, práticas de FinOps e estratégias sustentáveis, as empresas se tornam líderes na promoção de um futuro Cloud Native sustentável. É um chamado à ação para todos os profissionais e líderes de TI: engajem-se, inovem e liderem o caminho para um futuro mais sustentável e eficiente.
#### Ferramenta de revisão de avaliação
Use as diretrizes de FinOps para avaliar as lacunas de recursos da sua organização. Obtenha recomendações para maximizar o valor dos negócios na nuvem usando boas práticas de FinOps.
Inicie sua avaliação com a [Revisão do FinOps](https://learn.microsoft.com/pt-br/assessments/ad1c0f6b-396b-44a4-924b-7a4c778a13d3/).
Para mais informações sobre [O que é FinOps?](https://www.finops.org/) segue documentação que foi base desse artigo.
---
# Construindo uma Fundação Sólida para a Nuvem: A importancia da Cultura DevOps e sua Sinergia com Cloud Native na Fundação Cloud
URL: https://www.orafaelferreira.com/artigos/devops-foundation-cloud
Publicado: 2024-01-08
Categoria: Artigos
Tempo de leitura: 6 min de leitura
> Como a cultura DevOps e sua sinergia com Kubernetes e Cloud Native formam a base de uma fundação cloud sólida: práticas, prós, contras e avaliação.
Em um mundo impulsionado pela tecnologia, a fundação cloud *robusta* se torna um pilar essencial. Este artigo explora a cultura DevOps e sua integração com Kubernetes, destacando como essas práticas revolucionam a entrega de software e fortalecem as práticas Cloud Native. Vamos mergulhar no universo de DevOps e Kubernetes para entender como eles moldam uma fundação cloud que suporta inovação contínua, promovendo operações sustentáveis e eficientes.
### O Que é DevOps?
DevOps representa a fusão entre desenvolvimento (Dev) e operações (Ops), unindo pessoas, processos e tecnologia para aprimorar o planejamento, desenvolvimento, entrega de produtos e operações de aplicativos. A cultura DevOps aumenta a confiança nos aplicativos criados, responde melhor às necessidades dos clientes e atinge as metas de negócios mais rapidamente. Permite a entrega contínua de valor aos clientes, criando produtos melhores e mais confiáveis.
### Inovação Através da Cultura DevOps
A cultura DevOps é mais do que práticas e ferramentas, é um ecossistema que promove a colaboração, o aprendizado contínuo e a melhoria constante. Esta cultura quebra barreiras entre desenvolvimento e operações, acelerando o ciclo de vida do software e elevando a qualidade. Entre os benefícios, destacam-se a melhoria contínua, ciclos de lançamento mais rápidos, resposta ágil a mudanças e colaboração efetiva. Por outro lado, desafios como implementação, habilidades abrangentes, riscos de segurança e custos iniciais são reais e exigem atenção.
### DevOps e o Ciclo de Vida do Aplicativo
DevOps influencia todas as fases do ciclo de vida do aplicativo, desde o planejamento até as operações. Esta abordagem integrada garante que todas as funções participem em cada fase, promovendo uma entrega mais eficiente e de qualidade.
### A Sinergia com Cloud Native
Kubernetes não é apenas uma ferramenta de orquestração de contêineres, mas um complemento poderoso para o DevOps. Ele amplia os princípios do DevOps, fornecendo automação, escalabilidade e gestão desafiadora de infraestrutura, essenciais para práticas eficazes de Cloud Native.
### Construindo uma Fundação Cloud com DevOps e Cloud Native
Uma fundação cloud eficaz transcende a tecnologia, baseando-se em cultura e práticas que promovem crescimento e adaptação. A integração de DevOps e Kubernetes é essencial, fornecendo o framework necessário para uma transição eficiente para a nuvem e operação otimizada.
### Implementando Práticas de DevOps no Ciclo de Vida do Aplicativo
A implementação do DevOps envolve práticas como CI/CD, controle de versão, desenvolvimento ágil, infraestrutura como código (IaC), gerenciamento de configuração e monitoramento contínuo. Essas práticas transformam a maneira como o software é planejado, desenvolvido, entregue e operado.
### Adotando uma Cultura de DevOps
Adotar uma cultura de DevOps requer mudanças profundas na forma como as equipes trabalham e colaboram. Esta cultura é marcada por colaboração, visibilidade, ciclos de lançamento mais curtos e aprendizagem contínua, fatores essenciais para equipes de alto desempenho.
O acrônimo CALMS é um framework que representa um conjunto de práticas e valores fundamentais para a adoção e sucesso do DevOps. Ele foi desenvolvido para fornecer uma estrutura abrangente que ajuda as organizações a avaliar e aprimorar suas iniciativas DevOps. Cada letra do acrônimo CALMS representa um aspecto-chave:
- **Cultura (Culture):**
Refere-se à mudança de mentalidade dentro da organização, enfatizando a colaboração, a comunicação e a integração entre as equipes de desenvolvimento, operações e outras funções. A cultura DevOps prioriza a aprendizagem contínua, a responsabilidade compartilhada e a inovação.
- **Automação (Automation):**
Foca na automação dos processos de desenvolvimento, testes, implantação e infraestrutura. Isso inclui a prática de integração e entrega contínuas (CI/CD), infraestrutura como código (IaC), e automação de testes, reduzindo o esforço manual e aumentando a eficiência.
- **Lean (Lean):**
Adota princípios e práticas Lean para otimizar e agilizar processos, reduzir desperdícios e melhorar continuamente. O Lean incentiva a entrega incremental de valor, a eliminação de atividades desnecessárias e a maximização do fluxo de trabalho.
- **Medição (Measurement):**
Enfatiza a importância de medir e monitorar o desempenho, a qualidade e a eficácia de processos, produtos e serviços. Métricas e feedbacks contínuos são fundamentais para entender o impacto das mudanças e para tomar decisões baseadas em dados.
- **Compartilhamento (Sharing):**
Encoraja o compartilhamento de conhecimento, experiências e melhores práticas dentro e entre equipes. Isso pode incluir a colaboração em código, documentação, soluções de problemas e inovações, fortalecendo a cultura organizacional e promovendo a aprendizagem coletiva.
#### Prós da Cultura DevOps:
- **Melhoria Contínua**: Ao adotar DevOps, as organizações incentivam o crescimento constante, resultando em produtos de alta qualidade e maior satisfação do cliente.
- **Ciclos de Lançamento Mais Rápidos**: Com a integração e entrega contínuas, novas funcionalidades e correções são lançadas com mais rapidez, mantendo a competitividade no mercado.
- **Resposta Ágil a Mudanças**: A capacidade de responder rapidamente às necessidades dos clientes e às mudanças do mercado é amplamente melhorada.
- **Colaboração e Comunicação**: DevOps quebra os silos tradicionais, promovendo uma colaboração efetiva que é fundamental para o sucesso em ambientes complexos.
#### Contras da Cultura DevOps:
- **Desafios de Implementação**: A mudança para uma cultura DevOps pode enfrentar resistência e exige uma mudança de mentalidade em toda a organização.
- **Necessidade de Habilidades Abrangentes**: Os profissionais podem precisar expandir suas habilidades para se adaptarem a um ambiente DevOps, o que requer investimento em treinamento.
- **Riscos de Segurança**: A frequência elevada de lançamentos pode introduzir vulnerabilidades se as práticas de segurança não estiverem integradas ao pipeline de desenvolvimento.
- **Custos Iniciais**: A adoção de DevOps pode ser cara a curto prazo, com investimentos necessários em ferramentas e reestruturação de equipes.
#### Ferramenta de revisão de avaliação
Entenda as funcionalidades atuais em todo o ciclo de vida da versão do software e identifique rapidamente as oportunidades de aprimoramento com base nas práticas de DevOps da Microsoft.
Inicie sua avaliação com a [Avaliação de capacidade de DevOps](https://learn.microsoft.com/pt-br/assessments/56ec577c-acb6-4c7b-ad13-e224b0846153/).
### Conclusão
A cultura DevOps e o Kubernetes são essenciais para qualquer organização que busca uma forte presença na nuvem. Este artigo discute não apenas o 'como', mas também o 'porquê' essas práticas são indispensáveis e como impactam positivamente a sustentabilidade e o sucesso a longo prazo na nuvem. Encorajamos a reflexão sobre como essas práticas podem ser aplicadas em sua jornada para a nuvem.
Para mais informações sobre [O que é DevOps?](https://learn.microsoft.com/pt-br/devops/what-is-devops) em uma perspectiva da Microsoft, segue documentação que foi base desse artigo.
---
# Construindo uma Fundação Sólida para a Adoção da Nuvem: Integrando Landing Zones com Azure Cloud Foundation
URL: https://www.orafaelferreira.com/artigos/foundation-lz
Publicado: 2024-01-02
Categoria: Artigos
Tempo de leitura: 7 min de leitura
> Como Landing Zones e o Azure Cloud Foundation estruturam a adoção da nuvem: áreas de design, princípios-chave, aceleradores e implementações de referência.
No mundo acelerado da tecnologia, a adoção da nuvem evoluiu de uma tendência para uma necessidade estratégica. Enquanto empresas buscam agilidade e inovação, emerge a complexidade de construir uma infraestrutura de nuvem robusta e escalável. Aqui, exploramos a integração das Landing Zones com a Foundation de Cloud, descobrindo como essas estratégias moldam o sucesso na nuvem.
### A Essência das Landing Zones
Imagine entrar em um território desconhecido sem um mapa ou um guia, é assim que se sente entrar em um ambiente de nuvem sem as Landing Zones. Landing Zones no Azure são como bases estratégicas, configuradas para acolher e gerenciar seus recursos de nuvem com eficiência. Elas são o ponto inicial onde a segurança, a conformidade e a governança se encontram, garantindo que cada componente da sua infraestrutura esteja alinhado com os melhores padrões e práticas.
### Landing Zones: O Início de Uma Jornada Estruturada
As Landing Zones são mais do que simples espaços de trabalho, elas definem o contexto para o seu ambiente de nuvem. Uma Landing Zone bem projetada no Azure significa:
- **Estrutura:** Implementação de uma arquitetura modular e escalável.
- **Segurança e Conformidade:** Configurações de segurança desde o início, adaptando-se a padrões específicos da indústria.
- **Governança:** Estruturas de governança integradas para um controle eficiente.
### Entendo mais o Azure Cloud Foundation
Enquanto as Landing Zones são o ponto de partida, a Foundation Cloud no Azure é o alicerce sobre o qual seu ambiente digital é construído. É uma abordagem metodológica que engloba:
- **Estratégia e Planejamento:** Definindo metas claras para sua jornada na nuvem.
- **Operacionalização:** Implementação de práticas para garantir operações eficientes e contínuas.
- **Gerenciamento Otimizado:** Foco na eficiência operacional e na otimização de custos.
### Integrando Landing Zones com Azure Cloud Foundation
Quando Landing Zones e Azure Cloud Foundation trabalham em harmonia, elas criam uma sinergia poderosa. Esta combinação permite:
- **Agilidade e Escalabilidade:** Adaptando-se rapidamente às mudanças e crescendo com as demandas do negócio.
- **Inovação Sustentável:** Fornecendo uma plataforma para inovação contínua.
- **Resiliência e Confiabilidade:** Construindo uma infraestrutura confiável e resiliente.
### Áreas de Design de Ambiente
Seja qual for a opção de implantação, você deve considerar cuidadosamente cada área de design. Suas decisões afetam a base da plataforma da qual cada zona de destino depende. As áreas de design são indicadas com as letras "A" até "I" para ilustrar a hierarquia da organização de recursos na arquitetura conceitual.
- **A - Cobrança do Azure e tenants do Active Directory:** Criação de tenants, registro e configuração de cobrança como etapas iniciais importantes.
- **B - Gerenciamento de identidade e acesso:** Fundamento para qualquer arquitetura segura e totalmente em conformidade na nuvem pública.
- **E - Topologia de rede e conectividade:** Aspectos fundamentais de qualquer arquitetura de nuvem.
- **C - Organização do recurso:** Considerações de design de assinatura e hierarquia de grupo de gerenciamento para governança, gerenciamento de operações e adoção.
- **F - Segurança:** Implementação de controles e processos para proteger ambientes de nuvem.
- **D, G, H - Gerenciamento:** Linha de base de gerenciamento para operações estáveis e contínuas.
- **C, D - Governança:** Automatização da auditoria e imposição de políticas de governança.
- **I - Automação de plataforma e DevOps:** Alinhamento das melhores ferramentas e modelos para implantação de zonas de aterrissagem e recursos de suporte.
### Processo da Área de Design
Avalie cada área de design para compreender as alterações que talvez você precise fazer nas opções de implementação da zona de destino do Azure. A avaliação em sequencia das áreas de design simplifica o design de ambientes complexos, ajudando na tomada de decisões críticas sobre o seu ambiente.
### Cinco Princípios-Chave para Construir uma Landing Zone
#### 1. Redes
- **Objetivo:** Manter conectividade e flexibilidade.
- **Soluções Destacadas:**
- Azure ExpressRoute
- Qualidade de Serviço em Conectividade
- Firewalls e DMZ em Roteamento
- Mapeamento de Endereços IP
#### 2. Identidade
- **Objetivo:** Assegurar acesso seguro através de gerenciamento de identidade robusto.
- **Soluções Destacadas:**
- Microsoft Entra ID
- Autenticação Single Sign-on
- Regras de Autenticação
- Controle de Acesso Baseado em Funções (RBAC)
#### 3. Governança
- **Objetivo:** Implementar governança eficaz com políticas de conformidade.
- **Soluções Destacadas:**
- Azure Policy
- Políticas Aplicáveis
- Ambientes em Conformidade
- Gerenciamento de Assinaturas
#### 4. Segurança
- **Objetivo:** Proteger dados com controles de segurança avançados.
- **Soluções Destacadas:**
- Azure Sentinel
- Detecção de Ameaças
- Proteção integrada
- Proteção de Dados
#### 5. Gerenciamento
- **Objetivo:** Monitorar desempenho e garantir resiliência do ambiente.
- **Soluções Destacadas:**
- Azure Monitor
- Monitoramento Contínuo
- Automação
- Resiliência
### Acelerador de Landing Zones
O [Acelerador de Landing Zones](https://aka.ms/caf/ready/accelerator) da Plataforma é uma ferramenta pronta para uso, conhecida como Acelerador do Portal da Landing Zones do Azure. Essa ferramenta implanta uma arquitetura conceitual e aplica configurações padrão a componentes chave, incluindo grupos de gerenciamento e políticas. Ela é ideal para organizações cuja arquitetura conceitual se alinha com o modelo operacional planejado e a estrutura de recursos.
Caso você opte gerenciar o ambiente através do portal do Azure, o Acelerador do Portal da Landing Zones do Azure é a escolha certa. Para aqueles que preferem trabalhar com Bicep ou Terraform, existem opções específicas de implantação disponíveis para estas ferramentas.
### Implementação de Referência
Se sua empresa está buscando uma implementação inicial de zonas de destino que incorporem governança, segurança e um plano de controle de operações totalmente integrados desde o começo, existem várias abordagens para configurar seu ambiente Azure. Essas abordagens incluem o uso do portal do Azure ou a implementação via infraestrutura como código, oferecendo a possibilidade de transição entre esses métodos conforme sua organização evolui.
A tabela abaixo apresenta exemplos de implementações de referência alinhadas à arquitetura de escala empresarial recomendada.
- **Base de Escala Empresarial:** A fundação sugerida para adoção de escala empresarial. [Exemplo no GitHub](https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/wingtip/README.md) | [Implantar no Azure](https://portal.azure.com/#blade/Microsoft_Azure_CreateUIDef/CustomDeploymentBlade/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2FeslzArm.json/uiFormDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2Feslz-portal.json)
- **Hub e Spoke de Escala Empresarial:** Adiciona um módulo de rede hub e spoke à base de escala empresarial. [Exemplo no GitHub](https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/adventureworks/README.md) | [Implantar no Azure](https://portal.azure.com/#blade/Microsoft_Azure_CreateUIDef/CustomDeploymentBlade/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2FeslzArm.json/uiFormDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2Feslz-portal.json)
- **WAN Virtual de Escala Empresarial:** Incorpora um módulo de rede da WAN Virtual à base de escala empresarial. [Exemplo no GitHub](https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/contoso/Readme.md) | [Implantar no Azure](https://portal.azure.com/#blade/Microsoft_Azure_CreateUIDef/CustomDeploymentBlade/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2FeslzArm.json/uiFormDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2Feslz-portal.json)
- **Escala Empresarial para Pequenas Empresas:** Oferece uma arquitetura de rede hub e spoke para pequenas organizações. [Exemplo no GitHub](https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/treyresearch/README.md) | [Implantar no Azure](https://portal.azure.com/#blade/Microsoft_Azure_CreateUIDef/CustomDeploymentBlade/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2Fdocs%2Freference%2Ftreyresearch%2FarmTemplates%2Fes-lite.json/uiFormDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2Fdocs%2Freference%2Ftreyresearch%2FarmTemplates%2Fes-portal.json)
- **Escala Empresarial para o Azure Government:** Implementação de referência para o Azure Government, incluindo todas as opções em uma experiência unificada no portal. [Exemplo no GitHub](https://aka.ms/enterprisescale) | [Implantar no Azure Government](https://portal.azure.us/#blade/Microsoft_Azure_CreateUIDef/CustomDeploymentBlade/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2FeslzArm.json/uiFormDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FEnterprise-Scale%2Fmain%2FeslzArm%2Feslz-portal.json)
Cada implementação de referência provisiona recursos de plataforma no ambiente de destino escolhido. Detalhes adicionais sobre cada implementação e uma visão geral dos recursos implantados estão disponíveis através dos links do GitHub mencionados na tabela.
#### Ferramenta de revisão de avaliação
Examine a preparação da plataforma do Azure para que a adoção possa começar, avalie seu plano para criar uma zona de destino para hospedar cargas de trabalho que você planeja criar ou migrar para a nuvem. Esta avaliação foi desenvolvida para clientes com dois ou mais anos de experiência. Se você for novo no Azure, esta avaliação ajudará a identificar áreas de investimento para sua estratégia de adoção.
Inicie sua avaliação com a [Revisão da Landing Zone](https://learn.microsoft.com/pt-br/assessments/56ec577c-acb6-4c7b-ad13-e224b0846153/)
Gostou do assunto? Quer saber mais com reviews e novidades técnicas sobre Landing Zones direto da fonte? Aqui vai um canal do Youtube da própria Microsoft: [Customer Architecture & Engineering](https://www.youtube.com/@MicrosoftCAE)
Tudo isso nos leva a entender que cada pilar e cada assunto abordado tem um potencial enorme para ser explorado em profundidade. Podemos destrinchar cada tema, trazendo mais informações e insights relevantes para o dia a dia. Vamos nos aprofundar nesses assuntos, explorando os detalhes que são essenciais no contexto da adoção da nuvem e da implementação de infraestruturas robustas. Nos próximos artigos, abordaremos cada um desses temas com maior detalhamento, oferecendo uma visão clara e prática de como eles se aplicam no mundo real.
Para mais informações sobre [O que é uma Landing Zone do Azure?](https://learn.microsoft.com/pt-br/azure/cloud-adoption-framework/ready/landing-zone/) segue documentação que foi base desse artigo.
---
# Construindo uma Fundação Sólida para a Nuvem: Pilares do Well-Architected Framework e o Azure Cloud Adoption Framework
URL: https://www.orafaelferreira.com/artigos/well-architect-foundation-cloud
Publicado: 2023-12-11
Categoria: Artigos
Tempo de leitura: 4 min de leitura
> Os pilares do Well-Architected Framework e sua integração com o Azure Cloud Adoption Framework para construir uma infraestrutura de nuvem robusta e planejada.
Com o avanço da tecnologia e a crescente adoção de soluções em nuvem, tornou-se essencial para as organizações construírem uma infraestrutura de TI robusta e bem planejada. O [Well-Architected Framework](https://learn.microsoft.com/pt-br/azure/well-architected/) e o [Azure Cloud Adoption Framework](https://learn.microsoft.com/pt-br/azure/cloud-adoption-framework/) são dois conjuntos de práticas recomendadas que ajudam as empresas a alcançar esse objetivo. Neste artigo, vamos explorar os pilares do Well-Architected Framework e discutir a importância desses princípios em conjunto com o Azure Cloud Adoption Framework na construção de uma fundação sólida para a adoção da nuvem.
### Pilares do Well-Architected Framework
O Well-Architected Framework é uma abordagem criada pela Amazon Web Services (AWS) que orienta a construção de sistemas seguros, de alto desempenho, resilientes e eficientes. Este framework é composto por cinco pilares fundamentais seguidos por Princípios de design:
- ### Excelência Operacional
Como garantir operações eficientes e contínuas em sua infraestrutura na nuvem? Este pilar foca na capacidade de executar e monitorar sistemas para entregar valor comercial e melhorar continuamente processos e procedimentos. A automação de tarefas operacionais e o gerenciamento de incidentes são aspectos cruciais deste pilar.
- ### Segurança
Quais são as melhores práticas para proteger seus dados e recursos na nuvem? A segurança é a prioridade máxima, envolvendo a proteção de informações e sistemas. Aspectos como controle de acesso, criptografia de dados e conformidade com regulamentações são fundamentais para manter a integridade dos sistemas em nuvem.
- ### Confiabilidade
Como garantir que seus sistemas funcionem de maneira confiável e eficaz? A confiabilidade é sobre garantir que um sistema possa se recuperar de falhas e continuar operando. Isso inclui o design de sistemas tolerantes a falhas, com estratégias de backup e recuperação de desastres.
- ### Eficiência de Performance
O que fazer para otimizar o desempenho e usar eficientemente os recursos disponíveis? Este pilar enfatiza a seleção de recursos adequados para atender aos requisitos de desempenho, juntamente com a capacidade de se adaptar a mudanças na demanda e tecnologia sem excesso de provisionamento.
- ### Otimização de Custos
O objetivo aqui é evitar gastos desnecessários. Isso envolve compreender e controlar onde o dinheiro está sendo gasto, selecionar o modelo de preços mais econômico e analisar o consumo de recursos.
### Importância dos Pilares e sua Integração com o Azure Cloud Adoption Framework
Os pilares do Well-Architected Framework são fundamentais para garantir que a fundação da infraestrutura de nuvem deve ser construída de maneira eficiente e eficaz. No entanto, para que a adoção da nuvem seja bem-sucedida, é necessário um planejamento estratégico abrangente, que é onde o Azure Cloud Adoption Framework (CAF) entra.
#### Ferramenta de revisão de avaliação
Avalie sua carga de trabalho usando os pilares principais para identificar e priorizar oportunidades para melhorar a postura de suas cargas de trabalho.
Inicie sua avaliação com a [Revisão de Well-Architected do Azure](https://learn.microsoft.com/pt-br/assessments/azure-architecture-review/).
### Conclusão
A adoção da nuvem é uma jornada complexa que requer uma estratégia bem pensada e uma arquitetura sólida. Os pilares do Well-Architected Framework, juntamente com as orientações do Azure Cloud Adoption Framework, fornecem um caminho estruturado para que as organizações possam construir e otimizar suas infraestruturas em nuvem. Ao se alinhar com essas práticas recomendadas, as empresas podem garantir que estão preparadas para os desafios de TI atuais e futuros, maximizando a eficiência, a segurança e a escalabilidade de suas soluções em nuvem.
Para mais informações sobre o Well-Architected Framework e o Azure Cloud Adoption Framework, visite a documentação oficial da Microsoft em [Azure Well-Architected](https://learn.microsoft.com/pt-br/azure/well-architected/).
Espero que este artigo ajude você a entender melhor a importância de seguir os pilares do Well-Architected Framework e como o Azure CAF pode apoiar a sua jornada para a nuvem.
---
# Construindo uma Fundação Sólida para a Adoção da Nuvem com o Azure Cloud Adoption Framework
URL: https://www.orafaelferreira.com/artigos/foundation-cloud
Publicado: 2023-12-04
Categoria: Artigos
Tempo de leitura: 5 min de leitura
> Como o Azure Cloud Adoption Framework ajuda a construir uma fundação sólida para adoção da nuvem, da estratégia e planejamento à migração e governança.
### Introdução
A adoção da nuvem tornou-se crucial nas estratégias de transformação digital das organizações modernas. Com a promessa de escalabilidade, eficiência e inovação, a nuvem é uma força poderosa a ser considerada. No entanto, a migração para a nuvem sem uma estratégia coerente pode levar a desafios significativos. É aqui que o Azure Cloud Adoption Framework (CAF) aparece, fornecendo um roteiro estruturado para uma transição bem-sucedida ou (talvez) não?!
### Por que uma Fundação Sólida é Crucial?
Assim como a fundação de uma casa é crucial para a sua estabilidade e longevidade, uma fundação sólida é igualmente essencial para a adoção da nuvem. Sem uma base robusta, uma casa pode enfrentar rachaduras, infiltrações e até colapso sob condições adversas. Da mesma forma, sem uma estratégia bem definida e uma infraestrutura bem preparada, as iniciativas de nuvem podem se deparar com vulnerabilidades de segurança, sobrecarga de custos e um descompasso com as necessidades e objetivos do negócio. Uma abordagem estratégica e bem planejada é como um alicerce bem construído; ela suporta o peso dos seus projetos de TI e garante que sua transição para a nuvem seja tanto resiliente quanto capaz de se adaptar e crescer com as exigências futuras.
### O Azure Cloud Adoption Framework
O CAF do Azure é um guia abrangente que ajuda a garantir uma migração e operação bem-sucedidas na nuvem. Ele é dividido em seis etapas principais:
- 🔑 **Estratégia**: Define o motivo e os objetivos da migração para a nuvem.
- 📈 **Plano**: Desenvolve um plano de ação detalhado alinhado com a estratégia.
- 🛡️ **Pronto**: Prepara o ambiente de nuvem para a adoção.
- 🚀 **Adotar**: Implementa e migra cargas de trabalho para a nuvem.
- 📋 **Governar**: Estabelece políticas e mecanismos de governança.
- 💼 **Gerenciar**: Gerencia e otimiza as operações de nuvem.
- 🔐 **Segurança**: Assegura que todas as etapas, estejam fundamentadas em práticas de segurança e conformidade regulatória.
### Estratégia e Planejamento
Uma estratégia de nuvem bem definida é o primeiro passo para uma adoção bem-sucedida. Por que quero ir para Cloud? O que irei ganhar com a Cloud? Definir os resultados desejados e o caso de negócios fornece uma base sólida para o planejamento subsequente.
### Preparação e Conformidade
Antes de qualquer construção, um terreno deve ser preparado e nivelado, uma etapa que na arquitetura de nuvem é conhecida como a implementação de "landing zones". As "landing zones" são ambientes pré-configurados dentro da Azure que proporcionam uma estrutura modular e escalável para a implantação segura de recursos e serviços de nuvem. Elas são essenciais para a preparação do ambiente de nuvem, pois estabelecem as bases para a segurança, governança e conformidade desde o início. O Azure Cloud Adoption Framework fornece diretrizes detalhadas para configurar essas "landing zones" de acordo com as melhores práticas e padrões específicos da indústria. Ao seguir essas diretrizes, as organizações podem garantir que seu ambiente de nuvem esteja pronto para suportar os negócios de forma segura e eficiente. Em um artigo futuro, discutiremos a fundo as "landing zones", explorando como elas facilitam uma adoção de nuvem bem estruturada e ajudam a acelerar o valor entregue pela nuvem.
### Migração e Inovação
A migração para a nuvem oferece a oportunidade de reavaliar e otimizar as cargas de trabalho existentes, bem como inovar com novas soluções. O CAF fornece estratégias para ambos os cenários, ajudando a maximizar o valor da nuvem.
### Ferramentas e Templates
O Cloud Adoption Framework oferece recursos como ferramentas, modelos e avaliações para facilitar e agilizar a implementação de mudanças técnicas e promover uma adoção da nuvem mais rápida. Estes recursos são úteis em diferentes etapas do processo de adoção.
[Link](https://learn.microsoft.com/pt-br/azure/cloud-adoption-framework/resources/tools-templates)
### Gerenciamento Otimizado e Governança Contínua
Uma vez na nuvem, o gerenciamento contínuo e a governança são essenciais para manter a eficiência operacional e a conformidade. O CAF oferece práticas recomendadas para a gestão de recursos e a otimização de custos.
A adoção da nuvem é uma jornada transformadora que oferece oportunidades ilimitadas para inovação e crescimento. No entanto, a chave para desbloquear seu verdadeiro potencial reside na construção de uma fundação sólida que não apenas suporte suas cargas de trabalho atuais, mas também seja flexível o suficiente para se adaptar às necessidades futuras.
#### Ferramenta de revisão de avaliação
Avalie sua estratégia de adoção de nuvem e obtenha recomendações para criar ou avançar seu caso de negócios na nuvem.
Inicie sua avaliação com a [Processo de estratégia de adoção de nuvem](https://learn.microsoft.com/pt-br/assessments/8fefc6d5-97ac-42b3-8e97-d82701e55bab/).
### Conclusão
Tal como uma casa só perdura ao longo do tempo com uma fundação robusta e um planejamento cuidadoso, a adoção da nuvem requer uma base sólida para prosperar e se sustentar em um ambiente de TI em constante evolução. O Azure Cloud Adoption Framework é o alicerce sobre o qual você pode construir uma estratégia de nuvem resiliente, segura e alinhada aos objetivos da sua empresa. Desde a preparação do ambiente com "landing zones" até a implementação e gerenciamento contínuo, o CAF oferece um roteiro para navegar na complexidade da nuvem com confiança.
Fique atento para os próximos artigos, onde mergulharemos nas "landing zones" e exploraremos como elas desempenham um papel crucial na otimização da sua estratégia de nuvem. Se você está pronto para começar sua jornada na nuvem ou otimizar sua infraestrutura em nuvem existente, o Azure CAF pode ser o parceiro ideal para sua empresa. Vamos juntos construir uma arquitetura de nuvem que não é apenas funcional, mas também duradoura e escalável.
---
# Voluntariado no Projeto de Mentoria 3.0 do Canal da Cloud
URL: https://www.orafaelferreira.com/artigos/mentoriacloud23
Publicado: 2023-11-06
Categoria: Posts
Tempo de leitura: 2 min de leitura
> Minha experiência como mentor voluntário no Projeto de Mentoria de Carreira 3.0 do Canal da Cloud, entre agosto e dezembro de 2023, ajudando pessoas de TI.
Estou empolgado para compartilhar minha experiência como voluntário no Projeto de Mentoria de Carreira do Canal da Cloud durante o período de Agosto de 2023 a Dezembro de 2023. Esta iniciativa, impulsionada pela paixão pela tecnologia, reúne a comunidade técnica de TI para apoiar indivíduos que desejam avançar em suas carreiras na indústria de tecnologia.
O Projeto de Mentoria de Carreira do Canal da Cloud é uma iniciativa sem fins lucrativos que conta com a colaboração da comunidade técnica de TI para ajudar pessoas que desejam se desenvolver com tecnologia. Como voluntário neste projeto, eu me esforço para ajudar pessoas a traçar caminhos promissores na indústria de tecnologia. Através de orientação personalizada, compartilho conhecimentos, dicas e insights sobre tendências de mercado, ajudando os mentorados a desenvolver suas habilidades e alcançar seus objetivos profissionais.
Acredito que o acesso à educação e orientação é essencial para que todos possam prosperar no cenário tecnológico em constante evolução. Ao fazer parte deste projeto, tenho a oportunidade de dar um passo além e fazer a diferença na vida de indivíduos que buscam crescer e se destacar no mundo da tecnologia.
Se você estiver interessado em saber mais sobre este projeto ou gostaria de se envolver, sinta-se à vontade para entrar em contato. Juntos, podemos criar um futuro mais promissor na área de tecnologia!
- **Saiba mais:** [Post no LinkedIn sobre Mentoria](https://www.linkedin.com/posts/rafaelmaferreira_devops-mentoria-canaldacloud-activity-7095080582841327616--vqv?utm_source=share&utm_medium=member_desktop)
### Live de Encerramento da Mentoria 3.0
[](https://www.youtube.com/watch?v=x9pifyHOkZI)
### DEVOPS - EP 11 - Monitoramento e Observabilidade
[](https://www.youtube.com/watch?v=-rYhXprMJO4&ab_channel=UnicastCloudLab)
### DEVOPS - EP 10 - CI/CD com Azure DevOps ou GitHub Actions
[](https://www.youtube.com/watch?v=hxiluSC8E_U&t=910s)
### DEVOPS - EP 9 - Introdução a CI/CD (Pipelines, Jenkins)
[](https://www.youtube.com/watch?v=42-PW3dVF-Q&t=1s)
### DEVOPS - EP 8 - Aprofundando em IaC
[](https://www.youtube.com/watch?v=ObjlLPkrf1I&ab_channel=UnicastCloudLab)
### Listão dos Aprovados Mentoria 3.0
[](https://www.youtube.com/watch?v=aCDflhewrhI&t=568s)
---
# Lista dos eventos de Tecnologia Presenciais que eu já fui
URL: https://www.orafaelferreira.com/artigos/eventos
Publicado: 2023-10-30
Categoria: Registro Eventos Presenciais
Tags: Carreira
Tempo de leitura: 3 min de leitura
> Lista dos eventos de tecnologia presenciais de que já participei: experiências de aprendizado, networking e atualização sobre as tendências do mercado.
Olá pessoal! Quero compartilhar com vocês algumas das incríveis experiências que tive participando de eventos de tecnologia presenciais. Esses eventos foram oportunidades únicas para aprender, fazer networking e me manter atualizado sobre as últimas tendências tecnológicas. Vamos lá!
### Agenda 2026
| Mês | Evento |
|-----|--------|
| Ago | [**DevOpsDays Curitiba 2026**](https://devopsdays.org/events/2026-curitiba/welcome/) |
| Ago | [**MVP Conf Regional Curitiba 2026**](https://www.mvpconf.com.br/regional/curitiba/agosto-2026) |
| Jul | [**TDC 2026 Florianópolis - Trilha Software Security**](https://thedevconf.com/tdc/2026/florianopolis/trilha-software-security) |
| Jun | [**Microsoft Build //localhost:florianópolis**](https://developer.microsoft.com/pt-br/reactor/events/27206/) |
| Mai | [**Ctrl-Z - Code Island**](https://ctrl-z.codeisland.com.br/) |
| Abr | [**Global Azure User Group Floripa 2026**](https://www.meetup.com/azureusergroupsbrasil/events/313851322/) |
| Abr | [**SQL Saturday Joinville 2026**](https://sqlsaturday.com/2026-04-11-sqlsaturday1139/) |
| Abr | [**Sem Servidor Conf 2026 – Edição Floripa**](https://semservidor.com.br/sem-servidor-2026-edicao-floripa/) |
| Fev | [**Floripa - Meetup Codecon - #15**](https://eventos.codecon.dev/eventos/floripa-meetup-codecon-15) |
| Jan | [**92 Python Florianópolis, SC**](https://www.meetup.com/pt-br/floripa-python-meetup/events/312978297/?eventOrigin=group_past_events) |
| Mês | Evento |
|-----|--------|
### 2025
| Mês | Evento |
|-----|--------|
| Dez | [**DevOpsDays Florianópolis**](https://devopsdays.org/events/2025-florianopolis/welcome/) |
| Nov | [**DevOpsDays Porto Alegre**](https://devopsdays.org/events/2025-porto-alegre/welcome/) |
| Nov | [**DevOpsDays São Paulo**](https://devopsdays.org/events/2025-sao-paulo/welcome/) |
| Nov | [**1ª Semana Acadêmica de ADS - IFSC**](https://saads.framer.website/) |
| Out | [**Cloud Native Day - São Paulo 2025**](https://community.cncf.io/events/details/cncf-cloud-native-sao-paulo-city-presents-cloud-native-day-sao-paulo-2025-1/) |
| Out | [**MVP Conf - 2025 Brasil**](https://mvpconf.com.br/) |
| Out | [**8ª Edição Cultura DevOps - White Stone Dev Pedra Branca**](https://whitestonedev.com.br/#/eventos/8edicao) |
| Out | [**Esquenta MVP CONF - Curitiba**](https://www.hubingressos.com.br/evento/mvpconfcuritiba) |
| Set | [**TDC São Paulo (Trilha ARQUITETURA CLOUD) 2025**](https://thedevconf.com/tdc/2025/sao-paulo/trilha-arquitetura-cloud) |
| Set | [**Encontro das comunidades AWS User Group Floripa + DevOps Floripa 2025**](https://www.meetup.com/aws-user-group-floripa/events/310698392/?eventOrigin=group_events_list) |
| Set | [**devopsdays Curitiba 2025**](https://devopsdays.org/events/2025-curitiba/welcome/) |
| Ago | [**Hacking na Web Day Florianópolis 2025**](https://www.sympla.com.br/evento/hnwd-florianopolis-2025/2960275?referrer=orafaelferreira.com) |
| Jun | [**8° Meetup Cloud Native Santa Catarina**](https://community.cncf.io/events/details/cncf-cloud-native-santa-catarina-presents-8deg-meetup-cloud-native-santa-catarina/) |
| Jun | [**Bio Hack em Floripa: ProgramEarth & GitHub**](https://www.meetup.com/gittogether-brasil/events/308158374/?slug=gittogether-brasil&eventId=308158374) |
| Jun | [**Encontro da comunidade AWS User Group Florianópolis - Edição de Junho**](https://www.meetup.com/aws-user-group-floripa/events/308134123/?eventOrigin=group_upcoming_events) |
| Mai | [**Global Azure 2025 – Edição Azure Floripa**](https://www.meetup.com/pt-BR/azure-floripa/events/306207034/) |
| Abr | [**WhiteStone_dev - 7ª Edição Cripto - Especial Fênix**](https://www.sympla.com.br/evento/whitestone-dev-7-edicao-cripto-especial-fenix-a-retomada-da-comunidade-tech/2851067) |
| Abr | [**Esquenta MVP Conf Blumenau**](https://www.hubingressos.com.br/evento/mvpconfb) |
| Abr | [**SQL Saturday 2025 by Comunidado**](https://comunidado.com.br/) |
### 2024
| Mês | Evento |
|-----|--------|
| Nov | [**Code Island Cloud 2024**](https://cloud.codeisland.com.br/) |
| Nov | [**DevOpsDays Florianópolis**](https://devopsdays.org/events/2024-florianopolis/welcome/) |
| Nov | [**Tech Connection Floripa**](https://talkfloripa.com.br/) |
| Out | [**Tftec ao Vivo 2024**](https://www.tftec.com.br/tftecaovivo-2024/) |
| Out | [**Cloud Native SP #27 – Sustainability Day AWS**](https://community.cncf.io/events/details/cncf-cloud-native-sao-paulo-presents-27-cloud-native-sao-paulo-sustainability-day-na-aws/) |
| Set | [**Codecon Summit 2024**](https://codecon.dev/summit/programacao) |
| Jun | [**TDC 2024 – Trilha DevOps & SRE**](https://thedevconf.com/tdc/2024/florianopolis/trilha-devops-e-sre) |
| Jun | [**TDC 2024 – Trilha Cloud**](https://thedevconf.com/tdc/2024/florianopolis/trilha-cloud) |
| Jun | [**6º KuberTENes Birthday Bash SC**](https://community.cncf.io/events/details/cncf-cloud-native-santa-catarina-presents-6o-kubertenes-birthday-bash-santa-catarina/) |
| Jun | [**Tech Connection Balneário Camboriú**](https://talkfloripa.com.br/grade) |
| Mai | [**5º Cloud Native SC – Edição Floripa**](https://community.cncf.io/events/details/cncf-cloud-native-santa-catarina-presents-5o-cloud-native-santa-catarina-edicao-especial-floripa/) |
| Mai | [**Immersion Day AWS + NTT DATA**](https://www.sympla.com.br/evento/immersion-day-aws-e-ntt-data/2398471) |
| Mar | [**1º Meetup 2024 – Infosec Floripa**](https://www.eventbrite.com/e/1o-meetup-2024-infosec-floripa-tickets-860860014477) |
| Mar | [**Meetup Codecon #02**](https://eventos.codecon.dev/meetup-codecon-fln-02/) |
| Fev | [**KCD Brasil 2024**](https://community.cncf.io/events/details/cncf-kcd-brasil-presents-kcd-brasil-sao-paulo-2024/) |
| Fev | [**2º Cloud Native Floripa Meetup**](https://community.cncf.io/events/details/cncf-cloud-native-floripa-presents-2o-cloud-native-floripa-meetup/) |
| Fev | [**Meetup Codecon #01**](https://eventos.codecon.dev/meetup-codecon-floripa-01/) |
### 2023
| Mês | Evento |
|-----|--------|
| Dez | [**LINUXtips Meetup – Oracle**](https://www.youtube.com/live/RaMHnD3Ico4?app=desktop&si=s05HvlLHANQYv6bV) |
| Dez | [**Cloud Futures by Magalu Cloud**](https://cloudfutures.tech/) |
| Nov | [**14º Meetup DevOps Floripa**](https://www.meetup.com/devops-florianopolis/events/297529400/) |
| Nov | [**Code Island Summit 2023**](https://summit.codeisland.com.br/) |
| Nov | [**3º Meetup API Floripa**](https://www.sympla.com.br/evento/3-meetup-comunidade-api-floripa/2220166) |
| Nov | [**DevOpsDays Florianópolis 2023**](https://devopsdays.org/events/2023-florianopolis/program) |
| Nov | [**Proud Tech by Softplan**](https://www.proudtech.com.br/) |
| Out | [**Codecon <Feature>**](https://www.codecon.dev/feature) |
| Out | [**1º Cloud Native Floripa**](https://community.cncf.io/events/details/cncf-cloud-native-floripa-presents-1o-cloud-native-floripa/) |
| Set | [**Tech Connection Florianópolis – TalkFloripa**](https://talkfloripa.com.br/tech-connection-fln) |
| Ago | [**Platform Engineer Immersive Experience – LINUXtips**](https://www.linuxtips.io/platform-engineer-immersive-experience) |
| Ago | [**AWS Summit São Paulo**](https://aws.amazon.com/pt/events/summits/sao-paulo/) |
| Jun | [**TDC 2023 – Trilha Cloud**](https://thedevconf.com/tdc/2023/innovation/trilha-cloud) |
| Jun | [**TDC 2023 – Trilha DevOps & SRE**](https://thedevconf.com/tdc/2023/innovation/trilha-cloud) |
### Eventos anteriores
| Data | Evento |
|------|--------|
| 2019/04 | [**FLISoL Bauru**](https://flisol.info/FLISOL2019/Brasil/Bauru) |
| 2018/05 | [**VIII Jornada de Informática – USC**](https://unisagrado.edu.br/8jor-info) |
| 2018/02 | [**Hackathon DevTalks**](https://fibbauru.br/site/conteudo/462-hackathon-evento-inedito-em-bauru-comeca-hoje-.html) |
| 2017/10 | [**Circuito Finchers – Liderança & Gestão**](https://stoblobcertificados011.blob.core.windows.net/certificados/2017-10-Palestra.sobre.Liderança.Gestão.de.Pessoas-Finch.pdf) |
---
Esses eventos foram fundamentais para meu desenvolvimento profissional, permitindo-me aprender novas habilidades, fazer networking com profissionais da área e me manter atualizado sobre as últimas tendências tecnológicas. Espero que essa lista inspire outros a participar de eventos de tecnologia e aproveitar as oportunidades que eles oferecem.
Se você tem alguma dúvida ou quer compartilhar suas próprias experiências em eventos de tecnologia, deixe um comentário abaixo. Vamos continuar aprendendo e crescendo juntos!
**#Eventos #Tecnologia #DesenvolvimentoProfissional #Networking**
---
# Participações em Lives
URL: https://www.orafaelferreira.com/artigos/participacoes
Publicado: 2023-10-28
Categoria: Colaborações Externas
Tags: Carreira
Tempo de leitura: 2 min de leitura
> Minhas participações em lives e podcasts sobre Green IT, IaC com Terraform e OpenTofu, segurança em nuvem Microsoft, certificações e carreira em DevOps.
Olá, pessoal!
Estou empolgado para compartilhar com vocês um novo post onde destaco minhas participações em diversas lives na plataforma YouTube. Espero que este post seja informativo e inspire outros a buscar desenvolvimento profissional contínuo. Vamos lá!
### Minhas Participações
#### Green IT - O Futuro da Sustentabilidade na Nuvem
[**Green IT - O Futuro da Sustentabilidade na Nuvem**](https://jovemnerd.com.br/podcasts/nerd-na-cloud/green-it-o-futuro-da-sustentabilidade-na-nuvem)
#### IaC com Terraform & OpenTofu
[](https://www.youtube.com/watch?v=eBGb7TukdSs)
#### Tech Floripa Cast (PythonFloripa) #010 - Rafael Ferreira
[](https://www.youtube.com/watch?v=yt6X_3M1Vi4)
#### Segurança em Nuvem Microsoft: Estratégias e Melhores Práticas
[](https://www.youtube.com/watch?v=C7tKgg5uD9w)
#### Mesa Redonda: Protegendo dado na era das Inteligência Artificial
[](https://www.youtube.com/watch?v=56Jm6uPWV1w)
#### Desvendando Certificações: O Caminho Real ou Mito?
[](https://www.youtube.com/watch?v=YF6yT04eR_s&ab_channel=CloudnaQuebrada%E2%98%81%EF%B8%8F)
#### LIVE001: Magalu Cloud - A 1ª Cloud Pública do Brasil
[](https://www.youtube.com/watch?v=Eg_Y3fa-Mv4&ab_channel=UnicastCloudLab)
#### Como você pode alavancar a sua carreira com DevOps
[](https://www.youtube.com/watch?v=eo2rHuanZiM&ab_channel=FabricioVeronez)
#### Live23 Ressaca TDC Innovation 2023
[](https://www.youtube.com/watch?v=jfZIjuze6nU&t=3s&ab_channel=Osert%C3%A3oser%C3%A1Cloud)
### Agradecimento Especial
Gostaria de expressar minha gratidão a todos os anfitriões das lives em que participei e a todos que acompanharam e interagiram. Cada experiência foi extremamente enriquecedora, e estou ansioso para continuar explorando novas oportunidades de compartilhar conhecimento e aprender com vocês.
Espero que tenham gostado deste post e que ele tenha inspirado vocês de alguma forma. Se tiverem alguma pergunta ou quiserem saber mais sobre minhas participações em lives, fiquem à vontade para entrar em contato. Vamos continuar crescendo juntos!
---
**#Participações #Lives #DesenvolvimentoProfissional #DevOps #Certificações #Tecnologia**
---
# Alertmanager no Prometheus: Simplificando o Gerenciamento de Alertas
URL: https://www.orafaelferreira.com/artigos/artigo-prometheus
Publicado: 2023-08-14
Categoria: Artigos
Tempo de leitura: 2 min de leitura
> Entenda o Alertmanager do Prometheus: o que é, funcionalidades como agrupamento, silenciamento e roteamento de alertas, e por que usá-lo na observabilidade.
Em um mundo onde o monitoramento e a observabilidade tornaram-se cruciais para a operação eficiente de infraestruturas de TI, as ferramentas de alerta são mais importantes do que nunca. Uma dessas ferramentas que se destaca é o Alertmanager do Prometheus. Aqui está uma rápida visão geral de suas funcionalidades e benefícios.
### O Que é o Alertmanager?
O Alertmanager é uma ferramenta especializada, integrada ao ecossistema do Prometheus, responsável por gerenciar os alertas. Quando o Prometheus detecta uma situação que atende a um critério de alerta predefinido, ele envia esses alertas para o Alertmanager. Em seguida, cabe ao Alertmanager decidir o que fazer com eles.
### Funcionalidades Principais
1. Agrupamento: O Alertmanager agrupa alertas semelhantes, reduzindo o ruído e facilitando a gestão e a resolução de incidentes.
2. Inibição: Alertas relacionados podem ser suprimidos com base em critérios definidos, evitando uma avalanche de notificações.
3. Silenciamento: Se você já está ciente de um problema e está trabalhando nele, o Alertmanager permite que você silencie alertas específicos.
4. Roteamento: Dependendo da gravidade ou do tipo do alerta, ele pode ser roteado para diferentes equipes ou canais, como email, Slack ou PagerDuty.
### Por Que Usar o Alertmanager?
Em resumo, o Alertmanager ajuda as equipes a focarem nos alertas que realmente importam. Ao reduzir o ruído e fornecer ferramentas para gerenciar alertas de forma eficaz, as equipes podem responder mais rapidamente a incidentes críticos, melhorando a confiabilidade e a disponibilidade do sistema.
Para aqueles que buscam uma solução robusta de gerenciamento de alertas que integre perfeitamente ao Prometheus, o Alertmanager é, sem dúvida, uma escolha acertada.
Aqui vai o link da documentação caso você queira ler um pouco mais: [ALERTMANAGER](https://prometheus.io/docs/alerting/latest/alertmanager/)
E se quiser saber mais sobre o treinamento que estou fazendo, da uma olhada no livro aberto a toda comunidade DescomplicandoPrometheus: [DescomplicandoPrometheus](https://github.com/badtuxx/DescomplicandoPrometheus/tree/main)
---
# Kubernetes: Aproveitando o ACR como Repositório de Imagem Docker para Implementação de API
URL: https://www.orafaelferreira.com/artigos/artigo-aks-acr
Publicado: 2023-02-05
Categoria: Artigos
Tempo de leitura: 2 min de leitura
> Como usar o Azure Container Registry como repositório de imagens Docker para implantar uma API no Kubernetes, do build da imagem ao deploy no cluster.
O Kubernetes é uma das tecnologias mais populares para gerenciamento de contêineres na nuvem. Ele permite a implantação, escalabilidade e gestão de aplicativos em contêineres de forma altamente automatizada e confiável. Além disso, o Kubernetes oferece recursos avançados de orquestração de contêineres, como balanceamento de carga, escalabilidade horizontal e garantia de disponibilidade.
Para maximizar a eficiência e o desempenho do Kubernetes, é importante que as imagens docker utilizadas nas implantações sejam armazenadas em um repositório centralizado, como o Azure Container Registry (ACR). O ACR é uma solução de repositório de imagem docker nativa do Azure, que oferece armazenamento seguro, escalável e de alta disponibilidade para as suas imagens docker. Além disso, o ACR oferece recursos adicionais, como garantia de integridade de imagem, controle de acesso baseado em roles e integração direta com o Kubernetes.
Neste artigo, vamos explorar como usar o ACR como repositório de imagem docker para implementar uma API. O objetivo é mostrar como aproveitar ao máximo as vantagens do Kubernetes e do ACR para implementar e gerenciar aplicativos em contêineres de forma eficiente e confiável.
Começamos criando uma nova API em uma linguagem de programação de sua escolha, como Node.js ou Python. Em seguida, criamos uma imagem docker da API, utilizando as diretrizes de Dockerfile e as ferramentas de build da plataforma. Em seguida, enviaremos a imagem docker para o ACR usando o comando "docker push".
Com a imagem docker armazenada no ACR, podemos prosseguir com a implantação da API no Kubernetes. Para isso, criamos um arquivo de descrição do deploy, que especifica as configurações de implantação, como número de réplicas, requisitos de recursos, etc. Em seguida, usamos o comando "kubectl apply" para aplicar as configurações de deploy no cluster do Kubernetes.
A partir daí, o Kubernetes se encarregará de gerenciar as réplicas
---
# A importância do Persistent Volume no Kubernetes AKS: garantindo dados seguros e acessíveis
URL: https://www.orafaelferreira.com/artigos/artigo-aks-volume
Publicado: 2023-02-05
Categoria: Artigos
Tempo de leitura: 3 min de leitura
> Por que Persistent Volume e Persistent Volume Claim são essenciais no Kubernetes AKS: persistência de dados, manifestos YAML e Azure Disk e Azure File.
Olá, a todos!
Quando se trata de aplicações em containers, o uso de persistência de dados é fundamental para garantir a continuidade dos serviços. É por isso que o Persistent Volume (PV) e o Persistent Volume Claim (PVC) são recursos importantes do Kubernetes. E, no contexto do Azure Kubernetes Services (AKS), o uso de PV e PVC se torna ainda mais relevante.
No AKS, o Persistent Volume permite aos usuários armazenar dados de forma permanente, mesmo após a recriação de pods ou reinicialização de nós. Isto significa que, independentemente do status da aplicação, os dados serão preservados e disponíveis para uso quando necessário. Isso é extremamente importante para aplicações críticas, como banco de dados, que precisam garantir a disponibilidade e integridade dos dados em todos os momentos.
O Persistent Volume Claim, por sua vez, é um recurso que permite que os usuários solicitem espaço de armazenamento de forma simples e rápida. O PVC permite aos desenvolvedores especificar a quantidade de espaço de armazenamento necessária para suas aplicações, sem se preocupar com detalhes técnicos da infraestrutura. A partir daí, o Kubernetes se encarrega de alocar o espaço de armazenamento apropriado automaticamente.
Além do uso de Persistent Volumes no Kubernetes AKS, outro aspecto importante para garantir a disponibilidade de dados é o uso de Manifestos YAML. Manifestos YAML são arquivos que descrevem as configurações e recursos que um usuário deseja criar e gerenciar no cluster Kubernetes. Eles podem ser usados para declarar Persistent Volumes, Persistent Volume Claims, Deployments, Services e outros recursos importantes.
A vantagem do uso de Manifestos YAML é que ele permite a criação de recursos no cluster Kubernetes de forma programática e repetível, o que torna o processo de provisionamento muito mais eficiente e automatizado. Além disso, é possível versionar e controlar as mudanças realizadas nos Manifestos YAML, o que ajuda a manter o histórico e a rastreabilidade das configurações do cluster.
O AKS permite a integração de PV com serviços de armazenamento da Azure, como o Azure Disk e o Azure File. Isso significa que, além de garantir a persistência de dados, os usuários também podem desfrutar de alta disponibilidade e escalabilidade dos serviços de armazenamento da Azure.
Em resumo, o uso de Persistent Volumes e Manifestos YAML são duas práticas importantes no desenvolvimento de aplicações no Kubernetes AKS, que ajudam a garantir a disponibilidade e persistência de dados, além de permitir a automatização e gestão eficiente da infraestrutura.
---
# Pipelines CI/CD
URL: https://www.orafaelferreira.com/artigos/artigo-pipelines-ci-cd
Publicado: 2023-02-05
Categoria: Artigos
Tempo de leitura: 3 min de leitura
> As metodologias ágeis têm mudado a forma como as empresas desenvolvem software, e o desenvolvimento contínuo é uma parte importante dessa mudança.
As metodologias ágeis têm mudado a forma como as empresas desenvolvem software, e o desenvolvimento contínuo é uma parte importante dessa mudança. As pipelines CI/CD (Integração Contínua e Entrega Contínua) são uma forma de automatizar o processo de entrega de software, permitindo que as empresas desenvolvam e entreguem software de forma rápida e eficiente.Cada vez mais, empresas de todos os tamanhos estão adotando práticas DevOps para agilizar seus processos de desenvolvimento e entrega de software. E um dos principais pilares dessa abordagem é a automação de pipelines de CI/CD.
Existem diversas ferramentas disponíveis para ajudar a criar pipelines de CI/CD. Algumas das mais populares incluem o Jenkins, o GitHub Actions e o Azure DevOps.
O Jenkins é uma ferramenta de automação de código aberto que é amplamente utilizada em pipelines de CI/CD. Ele permite criar pipelines complexos que podem ser executados em ambientes diversos, desde servidores locais até ambientes na nuvem.
Já o GitHub Actions é um serviço de integração contínua e entrega contínua fornecido pelo GitHub. Ele permite criar pipelines de CI/CD diretamente no repositório de código, o que facilita bastante o processo.
O Azure DevOps é uma plataforma de colaboração e gerenciamento de projetos que também possui recursos para pipelines de CI/CD. Ele oferece ferramentas para gerenciamento de código, testes automatizados, implementação e monitoramento, permitindo a criação de pipelines completos. Ele é altamente integrado com outras ferramentas da Microsoft, como o Visual Studio, e oferece suporte para várias plataformas e linguagens de programação.
Independentemente da ferramenta escolhida, a automação de pipelines de CI/CD é uma etapa crucial para acelerar a entrega de software e garantir a qualidade do código. Além disso, permite que as equipes se concentrem em tarefas mais importantes e estratégicas em vez de gastar tempo em atividades manuais repetitivas.
Independentemente da ferramenta escolhida, é importante lembrar que a criação de um pipeline CI/CD não é um processo único. É um processo contínuo que requer monitoramento e ajustes constantes. No entanto, investir tempo e esforço na criação de um pipeline CI/CD bem projetado pode levar a uma entrega de software mais rápida, de maior qualidade e com menos riscos.
Se você ainda não adotou práticas de CI/CD na sua empresa, vale a pena explorar as diversas ferramentas disponíveis e ver qual se encaixa melhor nas suas necessidades. O importante é não deixar de lado a automação de pipelines e buscar sempre melhorias contínuas no processo de desenvolvimento e entrega de software.
---
---
# Como Configurar um WSL de Respeito
URL: https://www.orafaelferreira.com/artigos/zsh
Publicado: 2024-09-12
Categoria: Artigos
Tempo de leitura: 3 min de leitura
> Aprenda a montar um WSL de respeito para DevOps e SRE: Zsh com tema e plugins, ferramentas essenciais de linha de comando e aliases poderosos para o dia a dia.
### Introdução
Neste artigo, você vai aprender a montar um WSL de respeito, ambiente que todo DevOps, SRE ou engenheiro de plataforma deveria ter na manga. Vamos configurar o WSL com Zsh, tema e plugins, instalar ferramentas essenciais como `kubectx` e `kubens`, e configurar atalhos poderosos como o alias `k` para `kubectl`.
Ideal para quem vive no terminal e quer performance, praticidade.
### Parte 1 – Shell Zsh com estilo e produtividade
#### Passo 1: Verificar se o Zsh já está instalado
```bash
zsh --version
```
#### Passo 2: Instalar o Zsh
```bash
sudo apt install zsh -y
```
#### Passo 3: Mudar o shell padrão para Zsh
```bash
chsh -s /bin/zsh
```
#### Passo 3: Reiniciar o terminal
Feche e reabra seu terminal.
#### Passo 4: Instalar Oh My Zsh
```bash
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
```
#### Passo 5: Clonar o tema Dracula para Zsh
```bash
git clone https://github.com/dracula/zsh.git
```
#### Passo 6: Criar um link simbólico para o tema
Após clonar o repositório, crie um link simbólico para o tema na pasta de temas do Oh My Zsh:
```bash
ln -s $PWD/zsh/dracula.zsh-theme ~/.oh-my-zsh/themes/dracula.zsh-theme
```
#### Passo 7: Configurar o tema no Zsh
Edite o arquivo de configuração do Zsh:
```bash
vim ~/.zshrc
```
Altere a linha que começa com ZSH_THEME= para:
```bash
ZSH_THEME="dracula"
```
#### Passo 8: Instalar Plugins
Instale os plugins úteis com os seguintes comandos:
a) zsh-autosuggestions
```bash
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
```
b) zsh-syntax-highlighting
```bash
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
```
#### Passo 9: Adicionar os plugins ao Zsh
Abra o arquivo ~/.zshrc novamente:
```bash
vim ~/.zshrc
```
Adicione os plugins que você instalou na linha plugins=(...):
```bash
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)
```
#### Passo 10: Aplicar as mudanças
Após fazer as alterações, salve e feche o editor. Aplique as mudanças com:
```bash
source ~/.zshrc
```
#### Passo 11: Verificar se tudo está funcionando
Reinicie o terminal e verifique se o tema Dracula e os plugins estão funcionando corretamente.
### Parte 2 – Kubernetes com classe: kubectx, kubens e alias `k`
#### Instalar `kubectx` e `kubens`
```bash
mkdir -p ~/.local/bin
git clone https://github.com/ahmetb/kubectx.git ~/.local/bin/kubectx
sudo ln -sf ~/.local/bin/kubectx/kubectx /usr/local/bin/kubectx
sudo ln -sf ~/.local/bin/kubectx/kubens /usr/local/bin/kubens
```
Autocomplete para kubectx e kubens no Zsh
```bash
mkdir -p ~/.oh-my-zsh/completions
cp ~/.local/bin/kubectx/completion/_kubectx.zsh ~/.oh-my-zsh/completions/_kubectx
cp ~/.local/bin/kubectx/completion/_kubens.zsh ~/.oh-my-zsh/completions/_kubens
```
Edite e adicione no final do arquivo ~/.zshrc:
```bash
fpath+=("$HOME/.oh-my-zsh/completions")
autoload -Uz compinit
compinit
```
Recarregar o Zsh
```bash
exec zsh
```
Criar o alias k para kubectl com autocomplete
Adicione no ~/.zshrc:
```bash
alias k="kubectl"
```
E recarregue:
```bash
source ~/.zshrc
```
Pronto! Com autocomplete e velocidade. O terminal nunca mais será o mesmo.