Uma das maiores vantagens da computação em nuvem também pode se tornar um desafio: a quantidade de opções disponíveis.
Atualmente, praticamente qualquer necessidade possui uma ferramenta ou serviço especializado para atender aquele cenário.
Precisamos de análise de dados? Existem diversas plataformas disponíveis.
Precisamos de integração? Existem serviços específicos para isso.
Precisamos de monitoramento, automação ou processamento? A nuvem oferece diferentes alternativas.
Essa variedade é uma das grandes forças dos ambientes cloud.
Porém, ela também traz uma responsabilidade importante para quem trabalha com arquitetura de soluções.
Antes de pensar em qual novo serviço podemos adicionar, existe uma pergunta que deveria fazer parte do processo de decisão:
Será que já possuímos alguma capacidade dentro da plataforma que utilizamos hoje?
Essa pergunta representa uma mudança de mentalidade.
Administrar uma plataforma é saber utilizar seus recursos.
Arquitetar uma solução é entender o problema, avaliar possibilidades e escolher conscientemente o caminho mais adequado.
Nem sempre a melhor arquitetura é aquela que adiciona novos componentes.
Em alguns cenários, a melhor decisão pode ser explorar melhor aquilo que já existe.
Foi exatamente essa reflexão que guiou uma decisão envolvendo Azure DevOps e a necessidade de disponibilizar dashboards para acompanhamento de informações.
A solução mais conhecida estava disponível.
Mas, 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.
Resumo
Neste artigo você verá:
- Como 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.
O objetivo era permitir uma visão mais clara dos dados e facilitar o acompanhamento das informações necessárias para tomada de decisão.
Nesse momento, uma ferramenta especializada naturalmente apareceu como uma alternativa.
E essa escolha faria sentido.
O Power BI é uma plataforma consolidada, com recursos avançados de visualização, análise de dados e criação de dashboards.
Não existia uma dúvida sobre a capacidade técnica da ferramenta.
A questão era outra.
O problema não era:
Essa ferramenta consegue resolver a necessidade?
A resposta era sim.
A pergunta correta era:
Essa é a solução mais adequada considerando todo o contexto da arquitetura?
Essa diferença é fundamental.
Em arquitetura de soluções, uma decisão raramente deve considerar apenas se uma tecnologia consegue executar determinada função.
Também precisamos avaliar os impactos que essa escolha adiciona ao ambiente.
A adoção de uma nova ferramenta envolveria novos pontos de análise:
- modelo 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.
O desafio era encontrar uma solução equilibrada.
O 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.
Sempre que surge uma nova necessidade, a primeira reação costuma ser procurar um novo serviço.
E isso é compreensível.
A nuvem foi construída justamente para oferecer soluções especializadas.
Porém, existe um risco quando essa passa a ser sempre a primeira resposta.
Cada novo componente inserido em uma arquitetura também adiciona novas responsabilidades.
Um novo serviço significa:
- novos 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.
Foi exatamente essa reflexão que fizemos.
O Power BI resolveria o problema.
Mas a decisão não deveria ser baseada apenas na capacidade da ferramenta.
Precisávamos avaliar se a introdução de uma nova solução realmente traria benefícios proporcionais à complexidade adicionada.
A 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.
A decisão não foi simplesmente evitar custo.
Esse ponto é importante.
A escolha não aconteceu porque uma alternativa era mais barata.
O objetivo era encontrar uma solução que equilibrasse:
- simplicidade;
- 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.
Esses recursos são extremamente importantes e fazem parte do uso cotidiano da plataforma.
Porém, uma plataforma como Azure DevOps possui outras capacidades que muitas vezes não exploramos completamente.
Esse foi um dos principais aprendizados dessa experiência.
Muitas vezes, conhecemos uma ferramenta apenas pelos recursos que utilizamos diariamente.
Quando uma nova necessidade aparece, procuramos imediatamente uma nova solução, sem antes avaliar se aquilo que já temos disponível pode resolver o problema.
Nesse 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.
A ideia aqui não é mostrar uma configuração específica ou criar um tutorial sobre WebHooks.
O ponto principal é outro:
Conhecer melhor uma plataforma muda a forma como pensamos soluções.
Um profissional que pensa apenas em ferramentas tende a perguntar:
Qual serviço resolve esse problema?
Um arquiteto procura fazer perguntas anteriores:
Esse problema realmente exige um novo serviço?
Existe alguma capacidade que já possuímos e ainda não exploramos?
Estamos adicionando complexidade sem necessidade?
Essa mudança de perspectiva é uma das diferenças entre utilizar tecnologia e arquitetar soluções.
A 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.
Mais serviços.
Mais integrações.
Mais ferramentas.
Mas complexidade não significa maturidade.
Uma arquitetura madura é aquela em que cada componente possui uma razão clara para existir.
Antes 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.
Foi esse pensamento que orientou nossa decisão.
Ao aproveitar recursos que já faziam parte do Azure DevOps, conseguimos atender a necessidade sem introduzir uma nova camada desnecessária na arquitetura.
A solução permaneceu dentro do ecossistema que o time já utilizava.
Isso trouxe benefícios importantes:
- menor 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.
Simplicidade não significa falta de capacidade.
Muitas vezes, simplicidade é resultado de boas decisões.
Autonomia também faz parte da arquitetura #
Durante essa análise, um ponto se mostrou tão importante quanto a escolha tecnológica:
a autonomia do time.
Esse foi um dos fatores que fortaleceram a decisão.
Uma solução pode funcionar tecnicamente muito bem, mas ainda assim criar dependências desnecessárias para sua evolução.
Quando pequenas alterações dependem de múltiplas equipes, naturalmente surgem novos fluxos:
- solicitações;
- aprovações;
- filas;
- dependências externas.
Governança é fundamental em ambientes corporativos.
Segurança e controle continuam sendo prioridades.
Mas uma arquitetura eficiente também precisa permitir que as equipes consigam evoluir suas soluções.
Ao 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.
A decisão deixou de ser apenas técnica.
Ela passou a considerar também a forma como as pessoas trabalham.
Uma 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.
Esse é um aspecto que muitas vezes não aparece nas discussões tradicionais de arquitetura.
Falamos bastante sobre custo, performance, disponibilidade e segurança.
Todos esses fatores são essenciais.
Mas a capacidade de uma equipe evoluir uma solução com independência também faz parte da arquitetura.
Uma boa arquitetura não deve apenas funcionar.
Ela deve permitir evolução.
O aprendizado: arquitetura começa antes da escolha da tecnologia #
Essa experiência reforçou uma mensagem que considero cada vez mais importante:
Conhecer uma plataforma vai muito além de saber provisionar recursos.
Um profissional pode conhecer diversos serviços de nuvem, criar ambientes complexos e dominar ferramentas específicas.
Mas arquitetura exige algo além do conhecimento técnico.
Exige capacidade de analisar cenários.
Exige entender o problema antes de escolher a solução.
Exige questionar se a primeira resposta encontrada realmente é a melhor.
Em ambientes cloud, onde novos serviços surgem constantemente, essa habilidade se torna ainda mais importante.
Criar um novo recurso ficou simples.
O desafio agora é saber quando realmente precisamos fazer isso.
Essa é uma reflexão que procuro levar para os times com os quais trabalho:
Antes de pensar em criar um novo recurso, conheça melhor aqueles que já fazem parte da plataforma.
Muitas vezes, a solução não está em adicionar mais um serviço.
Ela está em explorar melhor aquilo que utilizamos todos os dias.
Conclusão #
Essa decisão envolvendo Azure DevOps não foi sobre substituir uma ferramenta por outra.
Também não foi sobre simplesmente reduzir custos.
Foi sobre entender o contexto, avaliar alternativas e escolher uma solução que equilibrasse tecnologia, governança, simplicidade e autonomia.
O Azure DevOps já fazia parte da arquitetura.
Antes de adicionar uma nova peça, decidimos olhar melhor para aquilo que já existia.
Essa 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.
No final, esse é um dos aprendizados que continuo levando para os projetos e para os times com os quais trabalho.
Conhecer uma plataforma não significa apenas saber criar novos recursos.
Significa saber reconhecer quando novos recursos realmente são necessários.
Antes de adicionar qualquer novo componente à arquitetura, talvez a pergunta mais importante seja:
Nós realmente precisamos criar um novo serviço?
