Ao revisar antigos e-mails para preparar este artigo, encontrei uma conversa de 2017 com Alexis Richardson, na época CEO da Weaveworks. Ambos tínhamos papéis na Cloud Native Computing Foundation: Richardson era o presidente do Comitê de Supervisão Técnica, enquanto eu ocupava a posição de presidente de marketing. Naquela ocasião, estávamos revisando uma apresentação que mais tarde introduziria o conceito de GitOps ao mundo — uma reconciliação entre um estado desejado em repositórios Git e o estado real em clusters Kubernetes.
A equipe da Weaveworks desenvolveu o GitOps para lidar com a complexidade da gestão de clusters Kubernetes. A ideia nasceu do trabalho fundamental que a empresa realizava no ecossistema de contêineres desde antes do termo "cloud native" ser amplamente utilizado, e foi impulsionada por um momento crítico quando um engenheiro accidentalmente excluiu o ambiente de produção. O conceito era inteligente e bem timingado, mas não era exatamente novo.
Loops de reconciliação — sistemas que comparam continuamente um estado desejado com o estado real e reconciliam as diferenças — existem há muito tempo. Sistemas de regulação física utilizam esse princípio desde o regulador centrífugo de Watt, em 1788. Ferramentas de gestão de configuração como CFEngine, nos anos 90, já implementavam essa ideia. Puppet, Chef, Ansible e Terraform todas desenvolveram versões do mesmo conceito: defina o que você quer, deixe a ferramenta descobrir como chegar lá e continue verificando se você permanece nesse estado.
Nos dias de hoje, passo a maior parte do tempo interagindo com pessoas que projetam e constroem data centers massivos em velocidade acelerada para servir armies de GPUs a usuários famintos por inteligência artificial. No mundo cloud native, tendemos a assumir que a infraestrutura física subjacente e como ela nos é disponibilizada são responsabilidade de outros. No meu papel atual, essa é a problemática central, e também existem loops de reconciliação em ação, embora com desafios únicos.
A escala de infraestrutura sendo implantada em data centers de IA está explodindo, os cronogramas de implantação esperados estão encolhendo e os requisitos de resiliência não param de aumentar. Equipes de infraestrutura geralmente abordam o projeto dessas restrições em dois níveis:
Designs de alto nível mapeiam a topologia geral, incluindo quantidade de racks, quais dispositivos de rede, computação e armazenamento serão utilizados, planos de cabeamento, aparência do fabric de rede, limites e restrições de endereçamento IP e muito mais.
Designs de baixo nível são o que um design de alto nível se torna quando realmente implantado — localização exata dos racks, variantes específicas de dispositivos e suas posições nos racks, versões específicas de sistema operacional e firmware, conexões específicas de interface, cada cabo, cada atribuição de IP e número de sistema autônomo, configuração de roteamento, circuitos e mais.
Não faz muito tempo que, para a maioria do mercado, as práticas usadas para capturar e expressar designs de alto e baixo nível pareceriam decididamente antiquadas para a maioria dos profissionais de cloud native e engenheiros de software. Designs de alto nível eram frequentemente expressos em ferramentas como LucidChart, e designs de baixo nível eram frequentemente expressos em planilhas eletrônicas. Essas ferramentas já não são mais suficientes.
O primeiro loop de reconciliação ocorre entre designs de alto nível e designs de baixo nível. Empresas que precisam se mover rapidamente estão adotando, em massa, novas formas de modelar designs de alto nível. Geralmente são arquivos YAML que são declarativos, versionados, composáveis e customizáveis em tempo real, permitindo que arquitetos de infraestrutura criem designs de alto nível comprovadamente bons que podem ser analisados programaticamente e reutilizados para implementar novos blocos de construção de infraestrutura. Esses designs variam em escopo, desde uma única variante de dispositivo com seus módulos associados, até um rack completo de equipamentos com cabeamento e IPs de gestão, até um pod de racks, ou frequentemente nos dias de hoje, um "superpod" contendo até 80 racks.
Uma vez que os arquitetos criaram seus designs de alto nível, que capturam o "o quê", a ferramenta de reconciliação assume e fornece o "como". Designs de alto nível são combinados com variáveis de tempo de implantação, renderizados e aplicados idempotentemente ao design de baixo nível, que na maioria das vezes é um sistema de Fonte de Verdade, que então serve como referência para operadores de infraestrutura, centros de operações de rede, engenheiros de data center e qualquer outra pessoa na empresa que deseja saber "o que achamos que realmente temos rodando em nosso data center?"
Como é comum em sistemas de loop de reconciliação, o valor não para aí. Mover-se para uma abordagem declarativa para designs de alto nível também permite que essas empresas façam perguntas como "A realidade diária no design de baixo nível driftou da minha intenção de design de alto nível?" Em escala, a automação é essencial, e a automação se beneficia da homogeneidade da infraestrutura. Ser capaz de identificar rapidamente quando o design de baixo nível está driftando ajuda a prevenir snowflakes.
O segundo loop de reconciliação envolve procurement e instalação. Claro, projetar infraestrutura não magicamente faz seu equipamento — servidores, switches, roteadores, racks, cabos, etc. — aparecer magicamente no data center.
A segunda vantagem de adotar designs de alto nível programáticos é que eles podem ser usados para racionalizar e acelerar os processos de procurement e instalação, o que é especialmente importante no mercado atual onde prazos de entrega de equipamentos frequentemente são o fator limitante mais longo. Um design de alto nível programático pode ser usado para criar uma Lista de Materiais, depois um ou mais Pedidos de Compra, que levam a múltiplas remessas de equipamentos, que podem então ser rackeados e empilhados no data center.
A reconciliação automática do ciclo completo ainda é difícil (embora pessoas já estejam olhando para automatizar tarefas de data center com robôs), mas começar com um design de alto nível consultável permite que todos esses processos sejam conectados com maior facilidade, economizando semanas valiosas nos prazos de implantação.
O terceiro loop de reconciliação é a configuração do equipamento. Uma vez que usamos o design de alto nível tanto para popularizar o design de baixo nível na Fonte de Verdade para uso diário quanto para impulsionar os processos de procurement que instalam o equipamento, há um passo restante: configurar o equipamento.
Nesta etapa, pegamos as especificidades da infraestrutura, armazenadas na Fonte de Verdade como o design de baixo nível, e comunicamos com o equipamento na infraestrutura para garantir que ele esteja pronto para uso. Este deve ser um conceito familiar para a maioria dos leitores, pois é análogo a exatamente como você usaria Terraform ou OpenTofu para aplicar mudanças na nuvem. A Fonte de Verdade serve como entrada para o processo, e ferramentas como Ansible, Terraform ou outros executores de workflow agem para aplicar idempotentemente as mudanças aos ativos na rede.
O mundo da infraestrutura física está no meio de uma mudança semelhante ao movimento DevOps que vimos nos anos 2010. Em muitos aspectos, as abordagens sendo tomadas são idênticas: a automação é primordial, a homogeneidade é um requisito para escala. Existem, no entanto, desafios únicos no espaço de infraestrutura física que gerações anteriores de automatizadores conseguiram evitar em grande parte. Um grande número de pessoas inteligentes está trabalhando no problema, e parece que a Automação Orientada por Design é um dos padrões líderes sobre os quais vamos ouvir falar muito mais.
Fonte: DCD
