[{"content":"","date":"26 de julho de 2026","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"Uma das maiores vantagens da computação em nuvem também pode se tornar um desafio: a quantidade de opções disponíveis.\nAtualmente, praticamente qualquer necessidade possui uma ferramenta ou serviço especializado para atender aquele cenário.\nPrecisamos de análise de dados? Existem diversas plataformas disponíveis.\nPrecisamos de integração? Existem serviços específicos para isso.\nPrecisamos de monitoramento, automação ou processamento? A nuvem oferece diferentes alternativas.\nEssa variedade é uma das grandes forças dos ambientes cloud.\nPorém, ela também traz uma responsabilidade importante para quem trabalha com arquitetura de soluções.\nAntes de pensar em qual novo serviço podemos adicionar, existe uma pergunta que deveria fazer parte do processo de decisão:\nSerá que já possuímos alguma capacidade dentro da plataforma que utilizamos hoje?\nEssa pergunta representa uma mudança de mentalidade.\nAdministrar uma plataforma é saber utilizar seus recursos.\nArquitetar uma solução é entender o problema, avaliar possibilidades e escolher conscientemente o caminho mais adequado.\nNem sempre a melhor arquitetura é aquela que adiciona novos componentes.\nEm alguns cenários, a melhor decisão pode ser explorar melhor aquilo que já existe.\nFoi exatamente essa reflexão que guiou uma decisão envolvendo Azure DevOps e a necessidade de disponibilizar dashboards para acompanhamento de informações.\nA solução mais conhecida estava disponível.\nMas, antes de criar uma nova ferramenta dentro da arquitetura, decidimos avaliar se a própria plataforma que já fazia parte do nosso ecossistema poderia atender essa necessidade.\nResumo\nNeste artigo você verá:\nComo uma nova necessidade levou à análise dos recursos já disponíveis no Azure DevOps. Por que a decisão não foi baseada apenas em custo, mas em simplicidade, governança e autonomia. Como recursos existentes da plataforma ajudaram a evitar a criação de um novo serviço. Por que conhecer melhor uma plataforma é fundamental antes de adicionar novos componentes à arquitetura. O problema: quando uma nova necessidade aparece # Durante a evolução de uma solução, percebemos que algumas informações importantes precisavam estar disponíveis de uma forma mais visual para acompanhamento das equipes.\nO objetivo era permitir uma visão mais clara dos dados e facilitar o acompanhamento das informações necessárias para tomada de decisão.\nNesse momento, uma ferramenta especializada naturalmente apareceu como uma alternativa.\nE essa escolha faria sentido.\nO Power BI é uma plataforma consolidada, com recursos avançados de visualização, análise de dados e criação de dashboards.\nNão existia uma dúvida sobre a capacidade técnica da ferramenta.\nA questão era outra.\nO problema não era:\nEssa ferramenta consegue resolver a necessidade?\nA resposta era sim.\nA pergunta correta era:\nEssa é a solução mais adequada considerando todo o contexto da arquitetura?\nEssa diferença é fundamental.\nEm arquitetura de soluções, uma decisão raramente deve considerar apenas se uma tecnologia consegue executar determinada função.\nTambém precisamos avaliar os impactos que essa escolha adiciona ao ambiente.\nA adoção de uma nova ferramenta envolveria novos pontos de análise:\nmodelo de licenciamento; governança; administração da solução; controle de acesso; responsabilidades entre equipes; evolução futura. O desafio não era encontrar uma ferramenta capaz.\nO desafio era encontrar uma solução equilibrada.\nO conflito arquitetural: criar um novo serviço ou aproveitar melhor o que já existe? # Existe uma tendência muito comum quando trabalhamos com ambientes cloud.\nSempre que surge uma nova necessidade, a primeira reação costuma ser procurar um novo serviço.\nE isso é compreensível.\nA nuvem foi construída justamente para oferecer soluções especializadas.\nPorém, existe um risco quando essa passa a ser sempre a primeira resposta.\nCada novo componente inserido em uma arquitetura também adiciona novas responsabilidades.\nUm novo serviço significa:\nnovos acessos para administrar; novos controles de segurança; novos processos de governança; novos pontos de monitoramento; mais elementos para manter ao longo do tempo. Uma arquitetura pode se tornar complexa não porque uma decisão específica estava errada, mas porque diversas pequenas decisões foram adicionando componentes sem uma análise completa do cenário.\nFoi exatamente essa reflexão que fizemos.\nO Power BI resolveria o problema.\nMas a decisão não deveria ser baseada apenas na capacidade da ferramenta.\nPrecisávamos avaliar se a introdução de uma nova solução realmente traria benefícios proporcionais à complexidade adicionada.\nA análise mostrou que existiam capacidades dentro do próprio Azure DevOps que poderiam atender aquela necessidade utilizando uma plataforma que o time já conhecia e utilizava.\nA decisão não foi simplesmente evitar custo.\nEsse ponto é importante.\nA escolha não aconteceu porque uma alternativa era mais barata.\nO objetivo era encontrar uma solução que equilibrasse:\nsimplicidade; governança; manutenção; autonomia das equipes. Azure DevOps além do CI/CD: conhecer melhor a plataforma antes de criar algo novo # Quando falamos em Azure DevOps, normalmente a primeira associação está relacionada a pipelines, automação de entregas e integração contínua.\nEsses recursos são extremamente importantes e fazem parte do uso cotidiano da plataforma.\nPorém, uma plataforma como Azure DevOps possui outras capacidades que muitas vezes não exploramos completamente.\nEsse foi um dos principais aprendizados dessa experiência.\nMuitas vezes, conhecemos uma ferramenta apenas pelos recursos que utilizamos diariamente.\nQuando uma nova necessidade aparece, procuramos imediatamente uma nova solução, sem antes avaliar se aquilo que já temos disponível pode resolver o problema.\nNesse cenário, utilizamos WebHooks do Azure DevOps para disponibilizar as informações necessárias para o dashboard, aproveitando uma capacidade que já fazia parte da plataforma utilizada pelo time.\nA ideia aqui não é mostrar uma configuração específica ou criar um tutorial sobre WebHooks.\nO ponto principal é outro:\nConhecer melhor uma plataforma muda a forma como pensamos soluções.\nUm profissional que pensa apenas em ferramentas tende a perguntar:\nQual serviço resolve esse problema?\nUm arquiteto procura fazer perguntas anteriores:\nEsse problema realmente exige um novo serviço?\nExiste alguma capacidade que já possuímos e ainda não exploramos?\nEstamos adicionando complexidade sem necessidade?\nEssa mudança de perspectiva é uma das diferenças entre utilizar tecnologia e arquitetar soluções.\nA melhor arquitetura nem sempre adiciona novas peças # Existe uma percepção comum de que uma arquitetura mais evoluída é aquela que possui mais componentes.\nMais serviços.\nMais integrações.\nMais ferramentas.\nMas complexidade não significa maturidade.\nUma arquitetura madura é aquela em que cada componente possui uma razão clara para existir.\nAntes de introduzir uma nova ferramenta para resolver uma necessidade específica, precisamos entender se o ganho proporcionado realmente compensa toda a estrutura adicional que virá junto.\nFoi esse pensamento que orientou nossa decisão.\nAo aproveitar recursos que já faziam parte do Azure DevOps, conseguimos atender a necessidade sem introduzir uma nova camada desnecessária na arquitetura.\nA solução permaneceu dentro do ecossistema que o time já utilizava.\nIsso trouxe benefícios importantes:\nmenor complexidade operacional; menos pontos de governança; menor dependência de novas ferramentas; maior proximidade entre desenvolvimento e solução. Existe uma diferença importante entre uma arquitetura simples e uma arquitetura limitada.\nSimplicidade não significa falta de capacidade.\nMuitas vezes, simplicidade é resultado de boas decisões.\nAutonomia também faz parte da arquitetura # Durante essa análise, um ponto se mostrou tão importante quanto a escolha tecnológica:\na autonomia do time.\nEsse foi um dos fatores que fortaleceram a decisão.\nUma solução pode funcionar tecnicamente muito bem, mas ainda assim criar dependências desnecessárias para sua evolução.\nQuando pequenas alterações dependem de múltiplas equipes, naturalmente surgem novos fluxos:\nsolicitações; aprovações; filas; dependências externas. Governança é fundamental em ambientes corporativos.\nSegurança e controle continuam sendo prioridades.\nMas uma arquitetura eficiente também precisa permitir que as equipes consigam evoluir suas soluções.\nAo utilizar capacidades que já faziam parte do Azure DevOps, o próprio time de desenvolvimento passou a ter mais liberdade para ajustar os dashboards conforme novas necessidades surgissem.\nA decisão deixou de ser apenas técnica.\nEla passou a considerar também a forma como as pessoas trabalham.\nUma decisão arquitetural impacta não apenas a tecnologia utilizada, mas também a velocidade com que as equipes conseguem transformar uma necessidade em uma solução.\nEsse é um aspecto que muitas vezes não aparece nas discussões tradicionais de arquitetura.\nFalamos bastante sobre custo, performance, disponibilidade e segurança.\nTodos esses fatores são essenciais.\nMas a capacidade de uma equipe evoluir uma solução com independência também faz parte da arquitetura.\nUma boa arquitetura não deve apenas funcionar.\nEla deve permitir evolução.\nO aprendizado: arquitetura começa antes da escolha da tecnologia # Essa experiência reforçou uma mensagem que considero cada vez mais importante:\nConhecer uma plataforma vai muito além de saber provisionar recursos.\nUm profissional pode conhecer diversos serviços de nuvem, criar ambientes complexos e dominar ferramentas específicas.\nMas arquitetura exige algo além do conhecimento técnico.\nExige capacidade de analisar cenários.\nExige entender o problema antes de escolher a solução.\nExige questionar se a primeira resposta encontrada realmente é a melhor.\nEm ambientes cloud, onde novos serviços surgem constantemente, essa habilidade se torna ainda mais importante.\nCriar um novo recurso ficou simples.\nO desafio agora é saber quando realmente precisamos fazer isso.\nEssa é uma reflexão que procuro levar para os times com os quais trabalho:\nAntes de pensar em criar um novo recurso, conheça melhor aqueles que já fazem parte da plataforma.\nMuitas vezes, a solução não está em adicionar mais um serviço.\nEla está em explorar melhor aquilo que utilizamos todos os dias.\nConclusão # Essa decisão envolvendo Azure DevOps não foi sobre substituir uma ferramenta por outra.\nTambém não foi sobre simplesmente reduzir custos.\nFoi sobre entender o contexto, avaliar alternativas e escolher uma solução que equilibrasse tecnologia, governança, simplicidade e autonomia.\nO Azure DevOps já fazia parte da arquitetura.\nAntes de adicionar uma nova peça, decidimos olhar melhor para aquilo que já existia.\nEssa mesma linha de raciocínio aparece em outras decisões arquiteturais que compartilhei aqui no blog, como no artigo sobre Azure Event Hubs Premium e crescimento de plataforma, onde a escolha também não foi simplesmente adicionar recursos, mas encontrar o equilíbrio adequado entre capacidade, custo e evolução da solução.\nNo final, esse é um dos aprendizados que continuo levando para os projetos e para os times com os quais trabalho.\nConhecer uma plataforma não significa apenas saber criar novos recursos.\nSignifica saber reconhecer quando novos recursos realmente são necessários.\nAntes de adicionar qualquer novo componente à arquitetura, talvez a pergunta mais importante seja:\nNós realmente precisamos criar um novo serviço?\n","date":"26 de julho de 2026","externalUrl":null,"permalink":"/posts/azure-devops-reutilizar-recursos-existentes/","section":"Posts","summary":"Uma das maiores vantagens da computação em nuvem também pode se tornar um desafio: a quantidade de opções disponíveis.\nAtualmente, praticamente qualquer necessidade possui uma ferramenta ou serviço especializado para atender aquele cenário.\nPrecisamos de análise de dados? Existem diversas plataformas disponíveis.\nPrecisamos de integração? Existem serviços específicos para isso.\nPrecisamos de monitoramento, automação ou processamento? A nuvem oferece diferentes alternativas.\nEssa variedade é uma das grandes forças dos ambientes cloud.\n","title":"Azure DevOps: quando reutilizar recursos existentes fez mais sentido do que criar novos serviços","type":"posts"},{"content":"","date":"26 de julho de 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"Existem problemas que aparecem porque algo foi mal planejado.\nMas existem outros que aparecem justamente porque a arquitetura evoluiu.\nDurante bastante tempo, o Azure Event Hubs Standard atendeu perfeitamente às necessidades dos projetos que utilizavam nossa plataforma.\nA escolha fazia sentido.\nO serviço entregava o que precisávamos, os projetos conseguiam evoluir e não existia nenhum motivo para pensar em uma mudança de arquitetura.\nAté que a plataforma começou a crescer.\nNovos projetos foram chegando, novas integrações passaram a utilizar eventos e um recurso que antes parecia simples começou a exigir uma análise mais profunda.\nO curioso é que o problema não apareceu porque o Azure Event Hubs deixou de funcionar.\nEle apareceu porque a arquitetura que atendia um cenário menor precisava acompanhar uma realidade maior.\nNeste artigo, vou compartilhar como avaliamos a evolução do Azure Event Hubs Standard para Premium e quais fatores influenciaram essa decisão arquitetural.\nResumo\nNeste artigo você verá:\nComo o crescimento da plataforma impactou uma arquitetura baseada em Azure Event Hubs Standard. Quais alternativas foram avaliadas antes da migração. Como governança e FinOps influenciaram a decisão. Por que o Azure Event Hubs Premium passou a fazer sentido para o novo cenário. O problema não estava no funcionamento do serviço # Quando pensamos em migrar um serviço para uma camada Premium, normalmente associamos essa decisão a problemas de desempenho.\nPensamos em:\naumento de processamento; problemas de latência; necessidade de maior throughput; limitações técnicas. Mas esse não era o nosso caso.\nAs aplicações continuavam funcionando.\nOs produtores continuavam enviando eventos.\nOs consumidores continuavam processando as mensagens.\nO ambiente estava saudável.\nO problema apareceu em um momento muito mais simples.\nUm novo projeto precisava utilizar o Azure Event Hubs.\nComo já acontecia normalmente, o caminho esperado era criar mais um recurso para atender essa necessidade.\nSó que dessa vez encontramos uma limitação.\nChegamos ao ponto em que a camada Standard deixou de atender a evolução da arquitetura que estávamos construindo.\nE esse foi o momento em que percebemos que não estávamos diante de um problema pontual.\nEstávamos diante de uma decisão arquitetural.\nQuando a plataforma cresce, a arquitetura precisa acompanhar # Uma coisa que acontece naturalmente em ambientes corporativos é que as decisões tomadas no início precisam ser revisitadas conforme o cenário muda.\nUma arquitetura que funciona muito bem com poucos projetos pode não ser a mesma arquitetura necessária quando a plataforma cresce.\nFoi exatamente essa reflexão que começamos a fazer.\nCom o crescimento da quantidade de projetos, a infraestrutura deixou de ser vista apenas como recursos individuais criados para atender necessidades específicas.\nPassamos a trabalhar com uma visão de recursos estruturantes.\nA ideia era criar uma base mais organizada, com maior previsibilidade operacional e melhor governança.\nIsso envolve diversos fatores:\ncontrole de recursos; organização dos ambientes; permissões; monitoramento; custos; operação. Nesse cenário, o Azure Event Hubs deixou de ser apenas um serviço utilizado por uma aplicação.\nEle passou a fazer parte de uma camada importante da plataforma.\nE uma decisão tomada apenas para resolver uma limitação imediata poderia gerar impacto no futuro.\nAs alternativas avaliadas antes da migração # A migração para o Azure Event Hubs Premium não foi a primeira opção.\nAntes de tomar essa decisão, avaliamos outros caminhos.\nComo acontece em decisões de arquitetura, o objetivo não era simplesmente encontrar uma solução rápida.\nEra encontrar uma solução que continuasse fazendo sentido conforme a plataforma continuasse crescendo.\nCriar novos namespaces # A primeira alternativa avaliada foi criar novos namespaces.\nTecnicamente, essa solução resolveria o problema.\nNovos projetos poderiam utilizar novos namespaces e seguir seu ciclo normalmente.\nPorém, quando analisamos o impacto dessa decisão, percebemos que ela criaria uma nova complexidade.\nNossa estratégia estava caminhando para uma infraestrutura mais estruturada.\nCriar vários namespaces para contornar uma limitação aumentaria a quantidade de recursos que precisariam ser administrados.\nIsso significaria mais pontos de configuração, mais permissões, mais monitoramento e mais itens para controlar operacionalmente.\nA solução resolveria a necessidade daquele momento, mas poderia criar um problema maior conforme novos projetos fossem surgindo.\nEra uma decisão que precisava ser analisada além do curto prazo.\nAumentar a capacidade do namespace # A segunda alternativa foi aumentar a capacidade existente.\nDo ponto de vista técnico, também era uma opção válida.\nPorém, novamente, a discussão não era apenas técnica.\nPrecisávamos avaliar como esse crescimento impactaria a plataforma.\nAumentar capacidade significa também avaliar o impacto financeiro dessa decisão, principalmente quando pensamos no crescimento contínuo da plataforma.\nE essa análise precisava considerar não somente a necessidade atual, mas também o crescimento esperado dos próximos projetos.\nFoi nesse momento que FinOps entrou naturalmente na discussão.\nA pergunta deixou de ser:\n\u0026ldquo;Como resolvemos a limitação que apareceu agora?\u0026rdquo;\nE passou a ser:\n\u0026ldquo;Qual decisão faz mais sentido para uma plataforma que continuará crescendo?\u0026rdquo;\nEsse foi um ponto importante.\nNão queríamos apenas eliminar uma limitação.\nQueríamos evitar que a mesma discussão voltasse a acontecer novamente em pouco tempo.\nPor que escolhemos Azure Event Hubs Premium # Depois de avaliar as alternativas, chegamos à conclusão de que o Azure Event Hubs Premium fazia mais sentido para o cenário que estávamos construindo.\nE existe um ponto importante nessa decisão.\nA migração não aconteceu porque o Azure Event Hubs Standard era ruim.\nDurante muito tempo ele atendeu perfeitamente.\nTambém não aconteceu porque existia um problema de performance.\nA decisão aconteceu porque o contexto havia mudado.\nA plataforma cresceu.\nA quantidade de projetos aumentou.\nA infraestrutura passou a precisar de uma abordagem mais estruturada.\nO Azure Event Hubs Premium deixou de ser apenas uma mudança de camada.\nEle passou a representar uma evolução da arquitetura.\nEm uma análise superficial, uma camada Premium pode parecer simplesmente um aumento de custo.\nMas arquitetura precisa considerar o cenário completo.\nExiste o custo direto de um recurso.\nMas também existe o custo operacional de administrar uma plataforma cada vez mais fragmentada.\nÀs vezes, investir mais em uma camada do serviço reduz complexidade em outras áreas.\nE essa também é uma conta que precisa ser feita.\nO que aprendemos com essa decisão # Essa experiência trouxe uma reflexão importante.\nNem toda mudança de arquitetura acontece porque algo está quebrado.\nAlgumas mudanças acontecem porque aquilo que funcionava antes deixou de representar o melhor caminho para o futuro.\nAlguns aprendizados desse cenário:\nNem sempre criar mais recursos é a melhor solução para uma limitação. Crescimento da plataforma exige revisitar decisões arquiteturais. FinOps precisa participar das decisões técnicas desde o início. Governança e operação fazem parte da arquitetura. Recursos estruturantes ajudam a preparar a plataforma para novos projetos. Esse tipo de decisão aparece em outros componentes de nuvem também.\nEm outro artigo, explorei como decisões arquiteturais em AKS em Produção impactam a escalabilidade de clusters Kubernetes e como escolhas feitas no início podem influenciar a evolução futura da plataforma.\nConclusão # Existe uma tendência de associar uma migração para uma camada Premium apenas ao aumento de desempenho.\nNossa experiência mostrou uma situação diferente.\nNão migramos porque o Azure Event Hubs Standard era ruim.\nNão migramos porque a plataforma estava com problemas.\nMigramos porque a arquitetura precisava acompanhar o crescimento da plataforma.\nUma decisão arquitetural raramente envolve apenas tecnologia.\nEla envolve operação, governança, custos e a capacidade de continuar evoluindo.\nA arquitetura que resolveu os problemas de ontem nem sempre será a mesma que sustentará os projetos de amanhã.\nEvoluir também significa reconhecer o momento certo de mudar.\nPerguntas frequentes # Quando utilizar Azure Event Hubs Premium? # O Azure Event Hubs Premium pode fazer sentido em ambientes que precisam evoluir sua arquitetura considerando maior governança, previsibilidade e crescimento da plataforma.\nAzure Event Hubs Premium é utilizado apenas para melhorar desempenho? # Não. A escolha de uma camada Premium pode envolver diversos fatores, como arquitetura, operação, governança e estratégia de crescimento.\nCriar vários namespaces no Azure Event Hubs é sempre uma boa solução? # Depende do cenário. Embora possa resolver uma necessidade imediata, muitos namespaces podem aumentar a complexidade operacional.\nQual a importância do FinOps em decisões de arquitetura Azure? # FinOps ajuda a avaliar não apenas o custo direto dos recursos, mas também o impacto financeiro e operacional das decisões tomadas pela arquitetura. ","date":"19 de julho de 2026","externalUrl":null,"permalink":"/posts/content/posts/azure-event-hubs-premium-crescimento-plataforma/","section":"Posts","summary":"Existem problemas que aparecem porque algo foi mal planejado.\nMas existem outros que aparecem justamente porque a arquitetura evoluiu.\nDurante bastante tempo, o Azure Event Hubs Standard atendeu perfeitamente às necessidades dos projetos que utilizavam nossa plataforma.\nA escolha fazia sentido.\nO serviço entregava o que precisávamos, os projetos conseguiam evoluir e não existia nenhum motivo para pensar em uma mudança de arquitetura.\nAté que a plataforma começou a crescer.\n","title":"Azure Event Hubs Premium: quando o Standard deixou de acompanhar o crescimento da plataforma","type":"posts"},{"content":" Resumo # Projetar um ambiente Azure Kubernetes Service (AKS) vai muito além da criação de um cluster funcional. Em ambientes corporativos, decisões como escolha de máquinas virtuais, organização de Node Pools, estratégia de escalabilidade, alta disponibilidade e observabilidade determinam diretamente a eficiência, o custo e a capacidade de evolução da plataforma.\nNeste artigo, exploramos os principais pontos arquiteturais que influenciam o comportamento de um cluster em produção, utilizando um cenário corporativo realista para demonstrar como decisões tomadas no início do projeto impactam todo o ciclo de vida da plataforma.\nIntrodução # O cluster parecia saudável.\nCPU disponível, memória dentro do esperado, nenhuma indicação imediata de problema. À primeira vista, tudo funcionava como deveria.\nMesmo assim, algo chamava atenção. À medida que novas aplicações eram implantadas, os custos aumentavam, a complexidade crescia e a solução recorrente para qualquer necessidade de capacidade era sempre a mesma: adicionar mais nós ao cluster.\nCom o tempo, ficou claro que o problema não estava na infraestrutura em si, mas na forma como ela havia sido pensada.\nEm ambientes de produção, o crescimento de uma plataforma raramente é um problema isolado de capacidade. Ele é, na maioria das vezes, consequência direta de decisões arquiteturais tomadas no início da jornada.\nO cluster não começa com az aks create # Existe uma ideia bastante difundida de que a implantação de um ambiente Kubernetes começa com a criação do cluster. Na prática, essa é apenas uma das últimas etapas do planejamento.\nAntes disso, é necessário compreender como as aplicações se comportam, quais restrições corporativas existem, quais padrões de infraestrutura são permitidos e como a plataforma deverá evoluir ao longo do tempo.\nEm ambientes corporativos, é comum que parte dessas decisões já esteja condicionada por políticas internas. Famílias de máquinas virtuais homologadas, padrões de rede, requisitos de segurança e diretrizes de governança fazem parte da realidade de muitas organizações.\nProjetar um ambiente AKS não consiste em escolher livremente todas as opções disponíveis na plataforma, mas em encontrar a melhor arquitetura possível dentro das restrições existentes.\nConheça o comportamento das suas aplicações # Uma das decisões mais importantes do projeto acontece antes da infraestrutura: entender como as aplicações consomem recursos.\nCada workload possui um comportamento diferente. Alguns consomem CPU de forma intensa e intermitente. Outros mantêm consumo constante de memória. Outros ainda apresentam padrões híbridos.\nSem essa visibilidade, qualquer decisão de infraestrutura se torna uma suposição.\nEm muitos ambientes corporativos, observa-se predominância de consumo de memória em aplicações internas, especialmente APIs e serviços de integração.\nEsse tipo de comportamento impacta diretamente o dimensionamento da infraestrutura e a organização dos recursos do cluster.\nEscolhendo a infraestrutura: quando a melhor opção nem sempre está disponível # Depois de compreender o comportamento das aplicações, o próximo passo é a escolha da infraestrutura.\nEm ambientes corporativos, essa escolha raramente é totalmente livre. Catálogos de produtos homologados, requisitos de segurança, governança e disponibilidade regional influenciam diretamente quais máquinas virtuais podem ser utilizadas.\nAlém disso, diferentes famílias de máquinas virtuais atendem perfis distintos de carga. Algumas são otimizadas para memória, outras para processamento, outras para armazenamento ou cenários especializados.\nA escolha da infraestrutura deve equilibrar comportamento das aplicações e restrições organizacionais.\nNode Pools: organizando a plataforma para crescer # Separar workloads em Node Pools não é apenas uma decisão técnica. É uma forma de organizar a evolução da plataforma.\nAmbientes que utilizam um único pool tendem a misturar aplicações com perfis diferentes de consumo, dificultando escalabilidade, manutenção e previsibilidade.\nAo separar Node Pools por tipo de workload, a plataforma passa a refletir melhor a realidade das aplicações, permitindo maior controle sobre crescimento, custos e operação.\nEscalabilidade: adicionar nós ou adicionar inteligência? # Escalar um cluster não significa apenas adicionar recursos.\nSignifica garantir que o crescimento ocorra de forma controlada, previsível e adequada ao comportamento das aplicações.\nEm muitos ambientes, a escalabilidade acontece de forma reativa: novos nós são adicionados sempre que há pressão de carga.\nEssa abordagem resolve sintomas, mas não necessariamente a causa do problema.\nUma estratégia eficiente de escalabilidade começa antes do Cluster Autoscaler, com definição correta de requests, organização dos Node Pools e análise contínua de consumo.\nAlta disponibilidade: projetando para falhas inevitáveis # Ambientes de produção devem assumir que falhas acontecerão.\nNós podem ser reiniciados, atualizações podem ocorrer e zonas podem sofrer indisponibilidades.\nA pergunta não é como evitar falhas, mas como o sistema se comporta quando elas acontecem.\nAlta disponibilidade depende de múltiplos fatores: distribuição de réplicas, uso de zonas de disponibilidade, políticas de agendamento e capacidade de manter o serviço durante atualizações.\nNão é uma configuração isolada, mas o resultado de decisões arquiteturais combinadas.\nObservabilidade: decisões precisam de evidências # Toda decisão arquitetural é, inicialmente, uma hipótese.\nSem observabilidade, não há como validar se essas hipóteses continuam válidas ao longo do tempo.\nMétricas, logs e traces permitem entender o comportamento real da plataforma, identificar gargalos e ajustar decisões antes que elas se tornem problemas.\nUma arquitetura madura evolui com base em dados, não em suposições.\n# Eficiência: quando boas decisões reduzem custos naturalmente # Eficiência não significa reduzir recursos indiscriminadamente.\nSignifica utilizar os recursos de forma adequada ao comportamento das aplicações.\nDecisões como escolha de infraestrutura, organização de Node Pools, definição de requests e estratégia de escalabilidade impactam diretamente a utilização do cluster.\nCustos elevados geralmente são consequência de decisões arquiteturais tomadas sem visibilidade adequada do comportamento dos workloads.\nAplicando os conceitos: um cenário corporativo # Imagine uma organização iniciando a modernização de suas aplicações internas com AKS.\nO ambiente deverá suportar dezenas de aplicações distribuídas entre APIs, serviços de integração e sistemas de negócio.\nAlgumas características são identificadas:\nconsumo predominante de memória; catálogo de máquinas virtuais homologadas; múltiplas equipes utilizando a plataforma; requisitos de alta disponibilidade; crescimento contínuo esperado. Nesse cenário, a primeira decisão não seria criar o cluster, mas compreender o comportamento das aplicações e as restrições existentes.\nA partir disso, a arquitetura seria construída progressivamente, refletindo essas decisões em infraestrutura, Node Pools, escalabilidade e observabilidade.\nConclusão # O cluster parecia saudável.\nMeses depois, aquele mesmo cluster continuava saudável.\nNão porque nunca precisou crescer, mas porque sua arquitetura cresceu junto com ele.\nEm ambientes de produção, não é o cluster que define a arquitetura. É a arquitetura que determina se o cluster continuará fazendo sentido ao longo do tempo.\n","date":"28 de junho de 2026","externalUrl":null,"permalink":"/posts/aks-producao-decisoes-arquiteturais-escalabilidade-cluster/","section":"Posts","summary":"Resumo # Projetar um ambiente Azure Kubernetes Service (AKS) vai muito além da criação de um cluster funcional. Em ambientes corporativos, decisões como escolha de máquinas virtuais, organização de Node Pools, estratégia de escalabilidade, alta disponibilidade e observabilidade determinam diretamente a eficiência, o custo e a capacidade de evolução da plataforma.\nNeste artigo, exploramos os principais pontos arquiteturais que influenciam o comportamento de um cluster em produção, utilizando um cenário corporativo realista para demonstrar como decisões tomadas no início do projeto impactam todo o ciclo de vida da plataforma.\n","title":"AKS em Produção: decisões arquiteturais que determinam a escalabilidade do cluster","type":"posts"},{"content":"Transferência de arquivos continua sendo uma necessidade comum dentro de ambientes corporativos.\nMesmo em arquiteturas modernas, ainda existem integrações que dependem de troca de arquivos entre:\naplicações parceiros sistemas legados ambientes híbridos fornecedores externos O problema normalmente não está na transferência em si.\nEstá na forma como a solução é construída ao longo do tempo.\nEm muitos ambientes, a necessidade de troca de arquivos acaba crescendo junto com a operação.\nCom o tempo, surgem novos fluxos, integrações e requisitos de retenção de dados.\nIsso normalmente aumenta a complexidade da solução e exige maior atenção para pontos como:\nsegurança governança rastreabilidade automação escalabilidade Em cloud, utilizar serviços gerenciados permite simplificar parte dessa operação e reduzir esforço administrativo ao longo do tempo.\nO desafio da transferência corporativa # Transferência corporativa de arquivos não envolve apenas envio e recebimento de dados.\nCom o crescimento da operação, surgem novos fluxos, integrações e requisitos de retenção.\nO desafio passa a ser construir uma arquitetura que permaneça simples de administrar e sustentável ao longo do tempo.\nUma abordagem utilizando serviços nativos do Azure # A proposta da arquitetura foi utilizar serviços gerenciados do Azure para criar uma solução mais integrada e simples de administrar.\nA solução foi desenhada utilizando:\nAzure Blob Storage com SFTP Azure Data Factory Azure Key Vault RBAC Private Endpoint monitoramento nativo do Azure O objetivo era criar uma estrutura:\nsegura escalável desacoplada simples de administrar preparada para crescimento futuro Arquitetura proposta # A arquitetura foi organizada da seguinte forma:\nO fluxo foi desenhado para permitir integração entre ambientes distintos utilizando serviços nativos do Azure.\nOs arquivos podem ser recebidos ou disponibilizados por diferentes origens, incluindo ambientes on-premises, parceiros externos ou aplicações internas.\nO Azure Data Factory atua como camada de orquestração e integração, permitindo movimentação controlada dos arquivos entre os ambientes.\nJá o Blob Storage funciona como camada desacoplada de armazenamento e retenção dos dados.\nAlém disso:\no acesso aos arquivos pode ocorrer utilizando SFTP nativo do Blob Storage credenciais e segredos permanecem centralizados no Key Vault permissões são controladas utilizando RBAC a comunicação pode ser restringida utilizando rede privada e Private Endpoint Essa separação reduz acoplamento entre os componentes e facilita evolução da arquitetura ao longo do tempo.\nBlob Storage com SFTP # O Azure Blob Storage com suporte nativo a SFTP estabelece o storage como ponto central de ingestão de dados na arquitetura, eliminando a necessidade de componentes intermediários para transferência de arquivos.\nEssa abordagem posiciona o Blob Storage como uma camada desacoplada de armazenamento, responsável pela persistência e organização dos dados ao longo do ciclo de vida.\nO serviço incorpora mecanismos nativos de governança e gestão de dados, incluindo:\ndesacoplamento entre ingestão e processamento integração direta com serviços do ecossistema Azure controle de ciclo de vida dos dados por meio de Lifecycle Management As políticas de Lifecycle Management permitem a evolução automática dos dados entre camadas de armazenamento:\nHot para dados em uso ativo Cool para dados de acesso eventual Archive para retenção de longo prazo Esse modelo suporta requisitos de governança e auditoria ao longo do tempo, mantendo os dados acessíveis conforme seu padrão de uso e retenção.\nO Blob Storage também suporta versionamento de objetos, garantindo rastreabilidade e preservação do histórico dos dados.\nO papel do Azure Data Factory # O Azure Data Factory foi utilizado como camada de orquestração da arquitetura, responsável pela integração e coordenação dos fluxos de dados entre diferentes sistemas.\nSua escolha se baseia na capacidade de centralizar a movimentação de dados entre ambientes heterogêneos, incluindo fontes on-premises, serviços Azure e endpoints externos, utilizando Integration Runtime quando necessário.\nNesse contexto, o ADF atua como mecanismo de controle de fluxo, permitindo:\nmovimentação de arquivos entre sistemas automação de pipelines de dados integração entre diferentes ambientes controle de execução e agendamento de processos rastreabilidade das execuções Essa abordagem reduz a necessidade de soluções customizadas para automação de transferência de arquivos, concentrando a lógica de integração em um serviço gerenciado e padronizado.\nAlém disso, a integração nativa com o ecossistema Azure simplifica a conexão com serviços como Blob Storage, Key Vault e mecanismos de processamento de dados.\nSegurança e governança # A segurança da solução não está restrita ao protocolo de transferência, sendo aplicada de forma transversal em toda a arquitetura.\nO desenho prioriza a redução de exposição pública dos serviços e o controle centralizado de acesso e credenciais.\nNesse contexto, a arquitetura adota:\nsegregação de acesso entre componentes e funções criptografia em trânsito e em repouso autenticação centralizada e controlada isolamento de rede para redução de superfície de ataque controle granular de permissões minimização de exposição de endpoints públicos O uso de Private Endpoint garante que os serviços permaneçam acessíveis apenas por redes autorizadas, eliminando exposição direta à internet.\nO RBAC permite separar funções administrativas e operacionais, reduzindo o risco de permissões excessivas e acessos não intencionais.\nJá o Azure Key Vault centraliza o gerenciamento de segredos e credenciais, evitando o armazenamento de informações sensíveis em aplicações, scripts ou configurações distribuídas.\nEsse conjunto estabelece uma base de segurança orientada a controle de acesso, isolamento e redução de superfície de ataque, alinhada a ambientes corporativos e cenários de integração entre múltiplos sistemas.\nCriptografia e ciclo de vida dos dados # Além da transferência segura dos arquivos, a arquitetura também considera proteção e retenção dos dados ao longo do tempo.\nO Azure Storage já oferece criptografia em repouso nativa utilizando chaves gerenciadas pela própria plataforma ou chaves controladas pelo cliente.\nDurante a transferência, o uso de SFTP garante criptografia dos dados em trânsito, reduzindo exposição durante envio e recebimento dos arquivos.\nOutro ponto importante foi a definição de políticas de ciclo de vida para o armazenamento.\nNem todos os arquivos precisam permanecer permanentemente em camadas de acesso de alta performance.\nA arquitetura pode utilizar políticas automáticas para movimentação entre níveis de armazenamento conforme o tempo de retenção.\nNesse modelo, os dados podem evoluir entre camadas de armazenamento conforme o tempo de retenção:\narquivos recentes permanecem em Hot Tier após 6 meses podem ser movidos para Cool Tier retenções de longo prazo podem utilizar Cold ou Archive Tier Isso reduz custo operacional sem perder capacidade de retenção dos dados.\nEm cenários corporativos, esse tipo de política normalmente é importante para:\ncompliance auditoria retenção regulatória redução de custos governança de dados Além disso, automatizar esse processo evita movimentações manuais e reduz risco operacional.\nO ganho operacional da arquitetura # O principal ganho da solução não está apenas na transferência de arquivos, mas na mudança do modelo operacional da integração de dados.\nAo adotar serviços gerenciados e uma arquitetura desacoplada, a solução reduz a necessidade de componentes dedicados para movimentação, manutenção e orquestração manual de fluxos.\nNa prática, isso elimina atividades recorrentes como:\nmanutenção de infraestrutura para transferência de arquivos gerenciamento manual de fluxos de integração ajustes operacionais em processos de ingestão dependência de componentes customizados para automação Com isso, a operação passa a se concentrar na configuração e evolução dos fluxos, e não na sustentação da infraestrutura.\nOs ganhos observados estão relacionados a:\nredução de esforço operacional contínuo menor dependência de intervenções manuais simplificação da arquitetura de integração maior previsibilidade dos fluxos de dados facilidade de evolução da solução ao longo do tempo Em termos práticos, a arquitetura reduz o custo de manutenção da solução ao longo do ciclo de vida, ao mesmo tempo em que aumenta a capacidade de adaptação a novos cenários de integração.\nEm cloud, o valor não está na adição de componentes, mas na redução da complexidade necessária para atingir o mesmo resultado.\nO que foi anonimizado # As imagens e fluxos apresentados neste artigo foram adaptados para preservar informações internas.\nForam removidos ou alterados:\nnomes de aplicações padrões corporativos nomenclaturas internas informações de conectividade identificações de ambiente O objetivo foi manter o contexto técnico da arquitetura sem expor informações sensíveis.\nConclusão # Transferência corporativa de arquivos continua sendo um requisito importante em muitos ambientes.\nO problema não está na necessidade em si, mas na complexidade operacional criada ao redor dela.\nA adoção de serviços gerenciados reduz a dependência de infraestrutura tradicional e simplifica a sustentação do ambiente.\nCloud-native não significa apenas mover workloads para a nuvem.\nSignifica utilizar serviços capazes de reduzir operação, desacoplar componentes e construir arquiteturas mais sustentáveis ao longo do tempo.\n","date":"17 de maio de 2026","externalUrl":null,"permalink":"/posts/transferencia-segura-arquivos-azure/","section":"Posts","summary":"Transferência de arquivos continua sendo uma necessidade comum dentro de ambientes corporativos.\nMesmo em arquiteturas modernas, ainda existem integrações que dependem de troca de arquivos entre:\naplicações parceiros sistemas legados ambientes híbridos fornecedores externos O problema normalmente não está na transferência em si.\nEstá na forma como a solução é construída ao longo do tempo.\nEm muitos ambientes, a necessidade de troca de arquivos acaba crescendo junto com a operação.\n","title":"Transferência segura de arquivos no Azure com Blob Storage e Data Factory","type":"posts"},{"content":"Participei de um novo projeto que tinha um objetivo relativamente comum em empresas que cresceram rápido:\nmodernizar uma aplicação que já não acompanhava mais a necessidade operacional.\nO cenário original era simples.\nToda a aplicação estava concentrada em um único servidor:\nfront-end back-end banco de dados servidor de arquivos transferência de arquivos Tudo coexistindo na mesma máquina.\nDurante muito tempo isso funcionou.\nO problema é que esse tipo de arquitetura normalmente cresce sem separação clara de responsabilidades.\nCom o aumento da demanda, começam os problemas:\ndificuldade de escalabilidade dependência excessiva de uma única VM risco operacional elevado manutenção complexa baixa flexibilidade para evolução dificuldade de padronização entre ambientes O pedido era claro:\ncriar uma nova arquitetura em Azure utilizando serviços homologados internamente e alinhados às boas práticas da empresa.\nO cenário original # Além do risco técnico, qualquer atualização da aplicação exigia maior cuidado operacional porque todos os componentes dependiam da mesma estrutura.\nUma única estrutura centralizava toda a operação.\nIsso criava alguns problemas importantes:\nqualquer indisponibilidade afetava o ambiente inteiro atualização da aplicação exigia maior janela de manutenção crescimento horizontal praticamente inexistente componentes fortemente acoplados dificuldade de segregação entre desenvolvimento, homologação e produção Além disso, existia um ponto importante:\na aplicação precisava continuar suportando arquivos estáticos, upload de conteúdo e persistência de dados sem alterar completamente o funcionamento esperado pelos usuários.\nOu seja:\nnão era apenas uma migração.\nEra uma modernização controlada, sem interromper completamente a operação existente.\nO objetivo da nova arquitetura # A proposta da nova solução precisava atender alguns pilares:\nseparação clara de responsabilidades ambientes independentes escalabilidade maior segurança serviços gerenciados redução de dependência operacional padronização de deployment Além disso, a arquitetura precisava seguir padrões internos de rede, segurança e conectividade corporativa.\nArquitetura proposta # A solução foi desenhada utilizando serviços nativos do Azure com foco em desacoplamento da aplicação.\nOs ambientes passaram a ser separados em:\ndesenvolvimento homologação produção Cada ambiente possuindo sua própria segmentação lógica.\nAmbiente de desenvolvimento # Ambiente de homologação # Ambiente de produção # Componentes principais da solução # Azure Kubernetes Service (AKS) # O AKS foi utilizado como base principal para execução da aplicação.\nO AKS também permitiu criar uma estrutura mais preparada para crescimento futuro da aplicação, mantendo padronização entre ambientes e melhor controle operacional.\nA escolha aconteceu por alguns motivos importantes:\npadronização de deployment escalabilidade horizontal separação por namespaces melhor gerenciamento de workloads aderência às práticas modernas de aplicação A aplicação foi segmentada dentro do cluster utilizando namespaces dedicados.\nIsso permitiu isolar componentes e organizar melhor os deployments.\nBlob Storage para conteúdo estático # Parte do front-end e arquivos estáticos foram movidos para Azure Blob Storage.\nSeparar arquivos estáticos da aplicação principal reduziu acoplamento entre os componentes e simplificou futuras atualizações da plataforma.\nIsso resolveu alguns problemas importantes:\nredução de dependência da aplicação principal distribuição simplificada de arquivos menor consumo do ambiente computacional armazenamento desacoplado Além disso, o uso de Static Website Hosting facilitou a publicação dos arquivos HTML, CSS e mídia.\nAzure Database for PostgreSQL # O banco de dados deixou de existir dentro da mesma VM da aplicação.\nA utilização do PostgreSQL gerenciado trouxe vantagens importantes:\nbackups automatizados maior resiliência redução de administração operacional gerenciamento simplificado integração nativa com serviços Azure Esse é um dos pontos que normalmente gera maior ganho operacional em modernizações.\nAzure Key Vault # Credenciais e segredos passaram a ser armazenados de forma centralizada.\nIsso eliminou o uso de informações sensíveis diretamente na aplicação ou em arquivos locais.\nNa prática:\nmelhora segurança reduz exposição de credenciais facilita rotação de segredos melhora governança File Share # O ambiente também precisava manter compatibilidade com compartilhamento de arquivos.\nPara isso foi utilizado Azure File Share.\nEsse ponto foi importante porque permitiu modernizar a aplicação sem exigir mudança completa do comportamento operacional existente.\nSegurança e conectividade # A nova arquitetura também criou uma base mais preparada para integração futura com monitoramento centralizado, observabilidade e análise operacional da aplicação.\nO ambiente de produção foi desenhado considerando:\nVPN corporativa acesso privado Azure Firewall segmentação de rede controle de tráfego interno Além disso, os ambientes foram organizados em VNets e subnets específicas.\nIsso permitiu maior controle de comunicação entre os componentes.\nO ganho real da modernização # O principal ganho não foi apenas tecnológico.\nFoi operacional.\nAntes da modernização:\nexistia alta dependência de servidor único baixa flexibilidade de crescimento manutenção mais complexa maior risco operacional Depois da modernização:\nworkloads desacoplados serviços gerenciados melhor organização dos ambientes maior capacidade de escalabilidade segurança centralizada arquitetura preparada para evolução O que foi anonimizado # As imagens utilizadas neste artigo foram adaptadas para preservar informações internas.\nForam removidos ou alterados:\nnomes de aplicações nomenclaturas internas nomes de subscriptions padrões corporativos de identificação informações específicas de infraestrutura O objetivo foi manter o contexto técnico da solução sem expor dados internos da empresa.\nConclusão # Modernização de aplicação não significa apenas mover workloads para cloud.\nNa prática, o desafio está em:\nseparar responsabilidades reduzir acoplamento melhorar operação criar capacidade de evolução aumentar resiliência Em muitos cenários, o maior problema não é a tecnologia.\nÉ a arquitetura que cresceu sem planejamento ao longo do tempo.\nQuando a modernização é feita da forma correta, o ambiente deixa de ser apenas funcional.\nEle passa a ser sustentável.\nEm muitos cenários, modernizar uma aplicação não significa reconstruir tudo do zero.\nO principal objetivo normalmente é reduzir dependências, separar responsabilidades e preparar o ambiente para evolução contínua.\n","date":"10 de maio de 2026","externalUrl":null,"permalink":"/posts/modernizacao-aplicacao-legada-azure/","section":"Posts","summary":"Participei de um novo projeto que tinha um objetivo relativamente comum em empresas que cresceram rápido:\nmodernizar uma aplicação que já não acompanhava mais a necessidade operacional.\nO cenário original era simples.\nToda a aplicação estava concentrada em um único servidor:\nfront-end back-end banco de dados servidor de arquivos transferência de arquivos Tudo coexistindo na mesma máquina.\nDurante muito tempo isso funcionou.\nO problema é que esse tipo de arquitetura normalmente cresce sem separação clara de responsabilidades.\n","title":"Modernização de aplicação legada no Azure com AKS e serviços gerenciados","type":"posts"},{"content":"Quando se fala em cloud, muita gente pensa primeiro em rede, máquina virtual ou custo.\nNa prática, nada disso vem antes da identidade.\nSe o controle de acesso estiver errado, todo o resto perde valor.\nNão importa o quão bem estruturada está a rede ou o quão otimizado está o custo.\nIdentidade mal configurada transforma qualquer ambiente em um risco.\nE esse é um problema mais comum do que parece.\nO cenário que mais se repete # Em ambientes pequenos e médios, é muito comum encontrar algo assim:\nNa prática:\nusuários com acesso administrativo sem necessidade permissões atribuídas diretamente a pessoas ausência total de MFA nenhum padrão de governança Isso normalmente nasce de uma decisão simples:\nfazer funcionar rápido.\nO problema é que esse tipo de decisão acumula.\nQuando o ambiente cresce, o controle se perde.\nE quando acontece um incidente, ninguém sabe exatamente quem tinha acesso a quê.\nO papel do Entra ID # No Azure, tudo passa pelo Microsoft Entra ID.\nEle não é apenas um diretório de usuários.\nEle é o ponto central de autenticação e autorização.\nTudo que acessa o ambiente depende dele:\nusuários grupos aplicações serviços Na prática, ele funciona como a camada que define quem pode entrar e o que pode fazer.\nUma forma simples de visualizar:\nSe essa base não estiver bem estruturada, qualquer tentativa de organização depois vira retrabalho.\nOnde começa o problema de verdade # O maior erro não está na ferramenta.\nEstá na forma como o acesso é distribuído.\nUm padrão muito comum é o crescimento desorganizado do acesso ao longo do tempo:\nUsuário → recebe permissão direto → ambiente cresce → controle se perde\nIsso até funciona no início.\nMas rapidamente vira um cenário onde:\nninguém sabe quem tem acesso administrativo remover acesso vira risco operacional auditoria se torna inviável Esse é o ponto onde o ambiente deixa de ser gerenciável.\nRBAC como decisão, não como configuração # O modelo de RBAC resolve esse problema.\nMas não por existir.\nEle resolve quando é usado corretamente.\nA estrutura ideal não é:\nUsuário → Permissão\nÉ:\nUsuário → Grupo → Permissão → Recurso\nModelo correto de controle de acesso com RBAC:\nEssa simples mudança define se o ambiente escala ou quebra.\nDecisão prática # Em vez de pensar:\n\u0026ldquo;quem precisa de acesso?\u0026rdquo;\nO correto é pensar:\n\u0026ldquo;qual grupo precisa desse tipo de acesso?\u0026rdquo;\nExemplo real:\nGrupo: DevOps Permissão: Contributor Escopo: Resource Group específico Agora, qualquer pessoa que entrar ou sair do time não exige reconfiguração do ambiente.\nVocê ajusta o grupo, não o ambiente.\nO risco invisível: permissões altas # Outro ponto crítico é o uso excessivo de permissões elevadas.\nPrincipalmente a role Owner.\nEla resolve rápido.\nMas cria três problemas sérios:\naumenta a superfície de ataque dificulta auditoria elimina controle fino Na prática, muitos ambientes usam Owner como padrão.\nIsso não é necessidade.\nÉ comodidade.\nE essa comodidade custa caro quando algo dá errado.\nMFA não é opcional # Se RBAC define quem pode acessar, o MFA define se esse acesso é seguro.\nAmbientes sem MFA são os primeiros a serem comprometidos quando há vazamento de credenciais.\nNão é uma hipótese.\nÉ o padrão.\nCom MFA, mesmo que a senha seja exposta, o acesso não acontece sozinho.\nEsse é o tipo de controle que muda completamente o nível de segurança sem aumentar complexidade.\nO que realmente funciona no dia a dia # Depois de estruturar e corrigir ambientes reais, alguns padrões ficam claros.\nEles não são avançados.\nNa prática, alguns padrões simples fazem toda a diferença:\nevitar uso de conta administrativa no dia a dia usar grupos para controlar acesso aplicar menor privilégio possível revisar permissões periodicamente ativar MFA para contas críticas Nada disso é complexo.\nMas ignorar qualquer um desses pontos cria fragilidade.\nO que muda quando isso é bem feito # Quando identidade é bem estruturada:\no ambiente escala sem perder controle auditoria se torna possível incidentes são mais fáceis de conter acesso deixa de ser improvisado E principalmente:\ndecisões deixam de ser reativas e passam a ser planejadas.\nConclusão # A maioria dos problemas em cloud não vem de falhas técnicas complexas.\nVem de decisões simples tomadas sem estrutura.\nIdentidade é uma dessas decisões.\nQuando bem feita, quase ninguém percebe.\nQuando mal feita, vira incidente.\nSe você acerta identidade, o resto do ambiente passa a fazer sentido.\n","date":"29 de abril de 2026","externalUrl":null,"permalink":"/posts/identidade-azure-entra-id-rbac-mfa/","section":"Posts","summary":"Quando se fala em cloud, muita gente pensa primeiro em rede, máquina virtual ou custo.\nNa prática, nada disso vem antes da identidade.\nSe o controle de acesso estiver errado, todo o resto perde valor.\nNão importa o quão bem estruturada está a rede ou o quão otimizado está o custo.\nIdentidade mal configurada transforma qualquer ambiente em um risco.\nE esse é um problema mais comum do que parece.\n","title":"Identidade no Azure na prática: controle de acesso com Entra ID, RBAC e MFA","type":"posts"},{"content":"Este documento descreve a arquitetura atual do blog e seus principais componentes de infraestrutura.\nO objetivo desta página é registrar de forma clara como o sistema está estruturado em ambiente cloud, servindo como referência técnica.\n1. Hosting # O blog está hospedado no Azure Static Web Apps.\nCaracterísticas: # Deploy automático Integração nativa com repositório Git Entrega global via CDN Ambiente gerenciado sem necessidade de servidor 2. CI/CD Pipeline # O processo de deploy é totalmente automatizado através de GitHub Actions.\nFluxo: # Commit no repositório\n→ GitHub Actions\n→ Build automático\n→ Deploy no Azure Static Web Apps\n3. DNS \u0026amp; Routing # O gerenciamento de DNS é feito através do Cloudflare.\n4. Fluxo Geral da Arquitetura # Usuário\n↓\nDNS (Cloudflare)\n↓\nAzure Static Web Apps\n5. Observabilidade (em evolução) # Web Analytics do Cloudflare ativado Métricas de tráfego em inicialização Status # Sistema em produção ativo e estável.\n","date":"12 de abril de 2026","externalUrl":null,"permalink":"/architecture/","section":"","summary":"Este documento descreve a arquitetura atual do blog e seus principais componentes de infraestrutura.\nO objetivo desta página é registrar de forma clara como o sistema está estruturado em ambiente cloud, servindo como referência técnica.\n1. Hosting # O blog está hospedado no Azure Static Web Apps.\nCaracterísticas: # Deploy automático Integração nativa com repositório Git Entrega global via CDN Ambiente gerenciado sem necessidade de servidor 2. CI/CD Pipeline # O processo de deploy é totalmente automatizado através de GitHub Actions.\n","title":"Architecture Overview","type":"page"},{"content":" Contexto # Se o Active Directory parar e não houver backup válido, a operação da empresa para — simples assim.\nO Active Directory Domain Services (AD DS) continua sendo o diretório mestre em muitas organizações, responsável por autenticação, autorização e políticas de acesso.\nSem um plano de backup e recuperação, o AD DS torna-se um ponto único de falha capaz de paralisar toda a organização em minutos.\nPequenas e médias empresas, sem budget para soluções premium, precisam de alternativas simples, eficazes e viáveis financeiramente.\nArquitetura de Backup Híbrido # A proposta é usar recursos já disponíveis, com custo praticamente irrelevante:\nSystem State Backup (Windows Server): captura dados críticos do AD DS Blob Storage no Microsoft Azure: destino do backup, com volumetria reduzida (raramente ultrapassa 3 GB) Automação com Task Scheduler + AzCopy: execução automática com baixo esforço operacional Redundância nativa do Azure: elimina dependência de hardware físico Fluxo da solução # Administrador agenda o backup do System State Arquivo é gerado e armazenado localmente Script com AzCopy envia o backup para o Blob Storage Em caso de falha, restauração é realizada via Windows Server Recovery Segurança e Controle de Acesso # Armazenar o backup na nuvem não significa que ele está seguro.\nSem controles adequados, um erro administrativo ou ataque pode simplesmente apagar todos os backups.\nPara mitigar esse risco:\nControle de acesso (RBAC) # Conta de backup: apenas escrita (Storage Blob Data Contributor) Conta de recuperação: apenas leitura (Storage Blob Data Reader) Evitar uso de chaves compartilhadas Identidade # Uso de Managed Identity Elimina credenciais fixas em scripts Reduz risco de vazamento Criptografia # Dados já são criptografados no Azure Blob Storage Recomendado adicionar criptografia antes do envio (AES-256) Proteção contra ransomware # Ativar imutabilidade (WORM) no container Impede exclusão ou alteração durante o período de retenção Sem essas medidas, o backup pode ser comprometido junto com o ambiente.\nCaso Prático # Uma empresa de 80 usuários, com AD DS rodando em um único servidor físico:\nSituação inicial: ausência total de backup Risco: perda completa do ambiente em caso de falha Implementação # Backup semanal do System State (~1 GB por backup) Upload automático para Azure Blob Storage Resultado # Recuperação possível em menos de 2 horas Eliminação da dependência de HD externo Redução significativa do risco operacional Redução de risco superior a 80% Estratégia de Recuperação (Restore) # O maior erro em projetos de backup não está na cópia dos dados, mas na recuperação.\nTipos de restore no Active Directory # Non-Authoritative Restore\nRecupera um Domain Controller que volta a sincronizar com os demais\nAuthoritative Restore\nRecupera objetos específicos e força replicação\nForest Recovery (cenário crítico)\nNecessário em falhas graves, corrupção ou ransomware\nProcesso essencial em cenários críticos # Isolar o ambiente (evitar replicação de corrupção) Restaurar um único Domain Controller em modo DSRM Validar integridade do AD Resetar credenciais críticas (ex: KRBTGT) Recriar os demais Domain Controllers Risco crítico # Um restore executado de forma incorreta pode propagar corrupção para todo o ambiente via replicação.\nO processo de recuperação deve ser tratado com o mesmo nível de criticidade que o backup.\nRegra de ouro # Backup que nunca foi testado é, na prática, um backup inexistente.\nRecomendações:\nTestes periódicos (mensais ou trimesais) Ambiente isolado para validação Procedimento documentado Quando essa solução NÃO é suficiente # Esta abordagem é ideal para pequenas e médias empresas, mas pode não atender cenários como:\nAmbientes com múltiplos sites e replicação complexa Requisitos de RPO/RTO muito baixos Ambientes com alta criticidade e necessidade de backup contínuo Infraestruturas com múltiplos Domain Controllers distribuídos Nesses casos, soluções dedicadas como Azure Backup ou ferramentas especializadas podem ser mais adequadas.\nVolumetria e custo # O tamanho do backup do AD DS depende da quantidade de objetos e do conteúdo do SYSVOL.\nReferência prática # NTDS.dit: 200 MB a 2 GB System State completo: até ~3 GB Este valor é uma estimativa baseada em ambientes reais de pequeno e médio porte.\nO cálculo exato deve considerar NTDS.dit + SYSVOL.\nCusto no Azure Blob Storage # LRS (Hot tier): ~US$ 0,0184 por GB/mês 3 GB → ~US$ 0,055/mês (~R$ 0,30) GRS → ~US$ 0,11/mês (~R$ 0,60) Menos de R$ 1,00 por mês para proteger o Active Directory\nValores aproximados, podendo variar conforme região e câmbio.\nBenefícios # Custo extremamente baixo Continuidade operacional Independência de hardware físico Resiliência em nuvem Acesso remoto ao backup Base para evolução futura (Azure Backup, Veeam, etc.) Trade-offs e Mitigações # Dependência de internet\nMitigação: manter cópia local Tempo de restauração via download\nMitigação: último backup em disco Configuração inicial manual\nMitigação: script padronizado Risco de exclusão ou ataque ao backup\nMitigação: RBAC + imutabilidade + criptografia Conclusão # Ter um plano de backup para o Active Directory não é opcional — é um requisito básico de sobrevivência operacional.\nA combinação de System State Backup + Azure Blob Storage permite construir uma solução:\nSimples Econômica Resiliente Quando combinada com segurança (RBAC, criptografia e imutabilidade) e um processo de recuperação testado, essa abordagem se torna uma estratégia sólida de continuidade de negócio.\nSe você possui um Active Directory em operação hoje, verifique agora se existe um backup válido e testado.\nNão espere o problema acontecer — implemente o backup, valide a recuperação e elimine o AD DS como ponto único de falha.\n","date":"12 de abril de 2026","externalUrl":null,"permalink":"/posts/backup-active-directory-azure-blob/","section":"Posts","summary":"Contexto # Se o Active Directory parar e não houver backup válido, a operação da empresa para — simples assim.\nO Active Directory Domain Services (AD DS) continua sendo o diretório mestre em muitas organizações, responsável por autenticação, autorização e políticas de acesso.\nSem um plano de backup e recuperação, o AD DS torna-se um ponto único de falha capaz de paralisar toda a organização em minutos.\n","title":"Backup de Active Directory com Azure Blob: solução de baixo custo para pequenas e médias empresas","type":"posts"},{"content":" Contexto # Organizações que mantêm Active Directory Domain Services (AD DS) como diretório mestre enfrentam um desafio recorrente: consumir serviços modernos como Microsoft 365 e aplicações SaaS sem investir em licenças premium ou infraestrutura adicional.\nEsse cenário é comum em empresas de médio porte, órgãos públicos e ambientes corporativos que ainda dependem fortemente de infraestrutura local. O risco de não resolver essa integração corretamente é alto:\nDuplicação de contas: usuários precisam manter logins separados para nuvem e on-premises. Perda de governança: administradores não conseguem aplicar políticas consistentes. Complexidade operacional: aumenta o esforço de suporte e a chance de falhas de autenticação. Sem resolver esse problema, a organização limita sua capacidade de modernizar processos e compromete a produtividade.\nA arquitetura de referência apresentada aqui responde a esse contexto, oferecendo uma solução prática e sem custo adicional, baseada em tecnologias já disponíveis no ambiente.\nArquitetura # A proposta é simples, mas robusta:\nAD DS On-Premises: continua sendo a fonte primária de identidades, responsável por autenticação interna e políticas de domínio. Microsoft Entra Connect (Azure AD Connect): instalado em servidor local já existente, atua como ponte de sincronização entre o AD DS e o Entra ID. Entra ID Free: recebe os objetos sincronizados e provê autenticação básica para aplicações SaaS e Microsoft 365. Fluxo híbrido:\nUsuários internos → autenticam no AD local via Kerberos/NTLM. Usuários externos e SaaS → autenticam no Entra ID Free. A sincronização garante identidade única, sem duplicação de contas. Limitações técnicas já presentes: sem Conditional Access, sem Identity Protection, sem políticas avançadas de segurança.\nDiagrama de Referência # Figura: Diagrama de referência da arquitetura de sincronização de usuários entre AD DS e Entra ID.\nEsse desenho evidencia que o Entra ID atua como extensão do AD DS, garantindo continuidade de políticas locais e evitando duplicação de identidades.\nFluxo de Autenticação # Usuário interno → login no AD local. Entra Connect → sincroniza objetos para a nuvem. Usuário externo/SaaS → login direto no Entra ID Free. Resultado → identidade única, sem duplicação. Pontos de controle:\nAutenticação local via Kerberos/NTLM. Sincronização periódica pelo Entra Connect. Autenticação SaaS via Entra ID Free. Possíveis falhas: indisponibilidade do AD local ou atraso na sincronização. Caso Prático # Uma empresa de médio porte com 100 usuários decide migrar para Microsoft 365:\nSituação inicial: AD DS local gerencia todas as contas. Necessidade: usar Exchange Online, Teams e SharePoint. Decisão: instalar Entra Connect em servidor local já existente. Resultado: Usuários internos continuam autenticando no AD local. Usuários acessando Teams/Outlook online usam Entra ID Free. Nenhum custo adicional. Governança mínima, mas suficiente para operação. Impacto prático:\nRedução de chamados de suporte em até 30%. Provisionamento de usuários simplificado (tempo médio reduzido de horas para minutos). Adoção de SaaS sem barreiras financeiras. Benefícios # Zero custo adicional. Consistência de identidade. Base evolutiva para P1/P2. Adaptável em DEV, TEST e PROD. Reduz barreiras para adoção de SaaS. Mantém governança mínima sem investimento. Trade-offs e Mitigações # Recursos limitados: sem Conditional Access. Mitigação: senha forte e MFA gratuito em contas críticas. Manutenção manual: Entra Connect precisa de atualização. Mitigação: alertas e revisão periódica de logs. Dependência do AD local: se o AD falhar, sincronização para. Mitigação: backup e plano de recuperação simples. Sem Conditional Access, o risco de acesso indevido aumenta significativamente em ambientes externos.\nConclusão # A arquitetura de referência para sincronização de usuários sem budget demonstra que é possível entregar consistência de identidade entre ambientes locais e nuvem sem custos adicionais. O Active Directory local continua sendo o diretório mestre, enquanto o Entra Connect garante a ponte de sincronização para o Entra ID Free, que por sua vez habilita acesso a Microsoft 365 e aplicações SaaS.\nO diagrama mostra a simplicidade da solução, mas é o texto que revela sua força:\nGovernança mínima, mas suficiente para ambientes que não podem investir em licenciamento premium. Mitigações práticas para lidar com limitações (senhas fortes, MFA gratuito, monitoramento do Entra Connect). Evolução futura clara: quando houver budget, a arquitetura pode crescer para P1/P2 e habilitar Conditional Access, MFA avançado e políticas de segurança mais granulares. Essa referência não é apenas uma solução técnica, mas um guia estratégico:\nSe você tem AD DS local e precisa consumir nuvem sem gastar, este é o caminho seguro e replicável.\nEla entrega consistência, simplicidade e prepara o terreno para evoluções futuras, sem cair na armadilha de improvisar identidades “no feeling” e depois pagar em complexidade e falta de governança.\nEsse deve ser o primeiro passo de qualquer organização que queira consumir nuvem sem budget, garantindo identidade única e preparando a base para evoluções futuras.\n","date":"11 de abril de 2026","externalUrl":null,"permalink":"/posts/sincronizar-usuarios-adds-entra-id/","section":"Posts","summary":"Contexto # Organizações que mantêm Active Directory Domain Services (AD DS) como diretório mestre enfrentam um desafio recorrente: consumir serviços modernos como Microsoft 365 e aplicações SaaS sem investir em licenças premium ou infraestrutura adicional.\nEsse cenário é comum em empresas de médio porte, órgãos públicos e ambientes corporativos que ainda dependem fortemente de infraestrutura local. O risco de não resolver essa integração corretamente é alto:\n","title":"Sincronização de Usuários sem Budget – Arquitetura de Referência","type":"posts"},{"content":"Muitas empresas acreditam que podem desligar seus file servers e migrar tudo para OneDrive ou SharePoint. Essa ideia parece simples, mas não funciona em cenários corporativos que exigem retenção de longo prazo, compliance e escala.\nOneDrive e SharePoint são ferramentas de colaboração. Ótimas para equipes, mas limitadas para guarda de documentos por 10, 15 ou 20 anos. O espaço de 25 TB não atende áreas como financeiro ou jurídico. A performance não suporta aplicações que dependem de acesso direto a arquivos. E as políticas de retenção não se comparam às de um file server corporativo.\nA solução correta é uma arquitetura híbrida que combina o legado on-premises com a nuvem corporativa do Azure:\nFile Servers on-premises continuam existindo, garantindo compatibilidade e acesso local. Azure File Sync conecta esses servidores ao Azure, sincronizando dados e permitindo tiering automático. Azure File Share recebe os dados sincronizados e mantém a integração com o ambiente local. Azure Data Factory (ADF) é responsável por migrar os arquivos do File Share para o Blob Storage, já que o Blob não consegue ingerir SMB/NFS diretamente. Azure Blob Storage é o destino final, com camadas Hot, Cool e Archive. Dentro dele, o Lifecycle Management aplica regras automáticas de retenção e movimentação entre camadas, reduzindo custos e garantindo compliance. Figura – Arquitetura da solução File Server Híbrido\nEssa arquitetura é modular, escalável e suportada oficialmente pela Microsoft. Ela resolve o problema de retenção de documentos por décadas, reduz custos com automação e mantém a performance necessária. É a resposta corporativa real para quem precisa evoluir além do file server tradicional sem perder controle, segurança ou conformidade.\n","date":"10 de abril de 2026","externalUrl":null,"permalink":"/posts/file-server-hibrido-azure/","section":"Posts","summary":"Muitas empresas acreditam que podem desligar seus file servers e migrar tudo para OneDrive ou SharePoint. Essa ideia parece simples, mas não funciona em cenários corporativos que exigem retenção de longo prazo, compliance e escala.\nOneDrive e SharePoint são ferramentas de colaboração. Ótimas para equipes, mas limitadas para guarda de documentos por 10, 15 ou 20 anos. O espaço de 25 TB não atende áreas como financeiro ou jurídico. A performance não suporta aplicações que dependem de acesso direto a arquivos. E as políticas de retenção não se comparam às de um file server corporativo.\n","title":"File Server Híbrido com Azure","type":"posts"},{"content":" Introdução # Encontrei uma solução para quem precisa da sua identidade visual na internet sem gastar nada.\nO serviço se chama Azure Static Web Apps e oferece hospedagem gratuita para aplicações estáticas, com integração nativa ao GitHub Actions e suporte a autenticação via Entra ID.\nO que é o Azure Static Web Apps # O Azure Static Web Apps é um serviço da Microsoft que conecta seu repositório no GitHub diretamente ao Azure.\nPrincipais vantagens:\nCI/CD automatizado: cada push no repositório dispara build e deploy. Autenticação integrada: suporte nativo ao Entra ID para segurança. Escalabilidade global: combinado com Cloudflare, garante performance e proteção. Plano gratuito: ideal para quem está começando ou quer validar uma ideia sem custo. Como criei a solução # No meu caso, o fluxo funciona assim:\nVS Code → escrevo e testo o código do blog. GitHub Actions (CI/CD) → automatiza build e deploy com pipelines YAML. Entra ID (Auth) → autenticação de usuários, conectada ao Static Web Apps. Azure Static Web Apps (Resource Group) → hospeda o blog e organiza recursos no Azure. Cloudflare (DNS/CDN) → garante performance e segurança. Leitores → o público final que acessa o conteúdo. Esse pipeline está representado no diagrama que montei, mostrando cada etapa da jornada do código até chegar aos leitores.\nFigura – Arquitetura da solução Azure Static Web\nConclusão # O Azure Static Web Apps free é uma ótima porta de entrada para quem quer colocar sua identidade digital no ar sem custo inicial.\nEle combina simplicidade, automação e segurança, permitindo que qualquer pessoa crie e publique um blog moderno.\nMais do que uma solução técnica, é uma forma prática de aprender sobre arquitetura de aplicações e dar os primeiros passos na nuvem.\n","date":"9 de abril de 2026","externalUrl":null,"permalink":"/posts/criando-blog-azure-static-web/","section":"Posts","summary":"Introdução # Encontrei uma solução para quem precisa da sua identidade visual na internet sem gastar nada.\nO serviço se chama Azure Static Web Apps e oferece hospedagem gratuita para aplicações estáticas, com integração nativa ao GitHub Actions e suporte a autenticação via Entra ID.\nO que é o Azure Static Web Apps # O Azure Static Web Apps é um serviço da Microsoft que conecta seu repositório no GitHub diretamente ao Azure.\n","title":"Criando um Blog com Azure Static Web Apps Free","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":" \u0026ldquo;Soluções simples, engenhosas e confiáveis.\u0026rdquo; # — Marcel Bich\nArquiteto de Soluções | Azure \u0026amp; Oracle Cloud | Gestão de Infraestrutura e Projetos\nArquiteto de Soluções especializado em infraestrutura e cloud híbrida (Microsoft Azure e Oracle Cloud, certificações AZ-900 e OCI Foundations). Atuei em projetos estratégicos de modernização e automação, como CALCULUS e HUB de Pagamentos, conduzindo desenho de soluções e governança de TI.\nReconhecido pela liderança servidora e mentoria de equipes, conecto tecnologia e estratégia para gerar eficiência, inovação e resultados sustentáveis.\nCertificações # ","externalUrl":null,"permalink":"/authors/egly/","section":"Authors","summary":"“Soluções simples, engenhosas e confiáveis.” # — Marcel Bich\nArquiteto de Soluções | Azure \u0026 Oracle Cloud | Gestão de Infraestrutura e Projetos\nArquiteto de Soluções especializado em infraestrutura e cloud híbrida (Microsoft Azure e Oracle Cloud, certificações AZ-900 e OCI Foundations). Atuei em projetos estratégicos de modernização e automação, como CALCULUS e HUB de Pagamentos, conduzindo desenho de soluções e governança de TI.\n","title":"Sobre Mim","type":"authors"}]