Como evoluímos de IaC para ambientes como código

Nos anos que passei construindo nossa plataforma — e trabalhando com outros DevOps e engenheiros de plataforma que nosso produto suporta — vi em primeira mão como a evolução da infraestrutura de aplicativos está quebrando a automação que deveria fornecer.

As ferramentas de infraestrutura como código (IaC) são inestimáveis ​​para definir e automatizar a entrega de serviços em nuvem. Quando as necessidades de uma equipe de desenvolvimento vão além desse escopo, a automação geralmente falha.

Isso acontece por dois motivos:

• As ferramentas IaC foram projetadas para velocidade e automação, não como fonte de verdade para ambientes. Grandes equipes podem ter dificuldade para aproveitar a infraestrutura em escala e entender como as alterações no código podem atrapalhar o desempenho dos aplicativos.
• As ferramentas IaC não funcionam bem juntas. As aplicações dependem cada vez mais de infraestruturas complexas definidas em diversas tecnologias, necessitando de orquestração manual para conciliar as nuances das ferramentas.

Os desenvolvedores enfrentam uma lacuna entre os recursos de automação da infraestrutura e a realidade das necessidades de um aplicativo. O resultado é a diminuição da velocidade e o aumento do risco de infraestrutura não gerenciada ou mal configurada.

Perguntamos o que poderíamos fazer para preencher essa lacuna e isso nos levou a uma pergunta simples:

E se você pudesse simplesmente lançar todos os ambientes como código, independentemente do escopo da infraestrutura ou das ferramentas IaC usadas para defini-la?

Definindo Ambientes como Código no Git

Para definir ambientes como código, primeiro precisamos definir tudo o que um desenvolvedor precisa para lançar um ambiente, em um formato que seja simultaneamente fácil de entender para DevOps e legível por máquina para automação.

Usando nossa plataforma Torque, nos conectamos a um repositório Git, descobrimos os módulos IaC definidos nele e agrupamos as configurações de recursos em um novo YAML que foi gerado automaticamente pela plataforma.

A partir daí, poderíamos modificar qualquer código YAML para incluir os componentes de infraestrutura, parâmetros, dependências, metadados, autenticação e saídas que o ambiente irá gerar no lançamento.

Este trecho YAML é um exemplo:



Contém uma definição única de todos os metadados essenciais para um ambiente em um formato estruturado.

Simplificando, aproveitamos nosso código de infraestrutura existente para definir um ambiente como código.

Usando GitOps para lançar ambientes de aplicativos

Para responder às necessidades dos nossos clientes, precisávamos operacionalizar esta definição.

Nossa resposta inicial foi contar com nosso portal de autoatendimento. Quando os administradores em nossa plataforma criam um desses arquivos YAML, que chamamos de “modelo” para um ambiente, eles podem optar por “publicá-lo”. Isso adiciona o ambiente a um catálogo de autoatendimento na plataforma, onde aqueles com permissões de usuário final podem iniciar o ambiente sob demanda. Para aqueles que integram ambientes em ferramentas de desenvolvedor, CI/CD ou portais internos de desenvolvedor, a publicação de um novo blueprint também o torna acessível por meio dessas ferramentas.

Para apoiar as equipes que adotam o GitOps, precisávamos integrar os blueprints publicados ao fluxo de trabalho diário.

Ao armazenar este novo arquivo YAML no repositório original onde descobrimos os módulos IaC, tornamos a definição do ambiente acessível em um movimento GitOps. Na verdade, “publicamos” a definição do ambiente para os usuários com acesso a esse repositório.

Agora os desenvolvedores podem iniciar o ambiente completo com um único comando.

Essa abordagem oferece diversas vantagens adicionais:

• Controle de versão: assim como o código do aplicativo, os ambientes podem ter controle de versão, garantindo que cada alteração seja rastreada e possa ser revertida, se necessário.
• Consistência: aproveitar essa definição sempre fornece ambientes consistentes, eliminando o problema de “funciona na minha máquina”.
• Velocidade: os desenvolvedores podem provisionar ambientes simplesmente comprometendo o código — um movimento com o qual estão familiarizados — para que possam responder às necessidades de desenvolvimento, teste ou produção rapidamente e sem precisar da ajuda de outras equipes.
• Colaboração e governança: a criação de uma definição compartilhada de um ambiente estabelece uma base para colaboração que não é tão fácil apenas com IaC.
• Eficiência operacional: Automatizar o processo de provisionamento significa menos trabalho manual redundante (e desgaste) para os engenheiros de DevOps e mais capacidade para realizar tarefas mais valiosas.

Na engenharia de plataformas, cada segundo conta e cada recurso é importante. À medida que a infraestrutura se torna mais complexa, o gerenciamento de ambientes como código é o próximo passo na maturidade das organizações modernas de DevOps.

A postagem Como evoluímos de IaC para ambientes como código apareceu pela primeira vez em The New Stack.