Image for post
Image for post
Tiago Souza Silva | Expert Architect | everis Brasil

Infraestrutura como Código: da obsolescência ao novo

A maioria das organizações estão adotando ferramentas de automação de infraestrutura de TI e plataformas dinâmicas de infraestrutura, como nuvens privadas e/ou públicas. No entanto, a tecnologia por si não basta para ajudar a TI a responder de forma rápida e confiável às mudanças. No pior cenário, elas podem levar a uma situação constrangedora, onde a capacidade de aprovisionar uma nova infraestrutura expande sistemas não otimizados/preparados e até com falhas conceituais em sua arquitetura.

Para resolver este tipo de desafio surgiu a Infraestrutura como Código (IaC — Infrastructure as Code). Uma abordagem que permite gerenciar infraestrutura e viabilizar a utilização de práticas de engenharia de software, a fim de entregar a infraestrutura como código. Empresas como Netflix e Spotify foram pioneiras em uma nova geração de princípios e práticas para o gerenciamento de mudanças e os times de TI que adotaram essas práticas, passaram a ter maior tração em suas entregas, aumentando não somente a quantidade, mas também a frequência, contribuindo significativamente no aumento da confiabilidade, segurança e qualidade de seus serviços de TI.

A virtualização e a nuvem (IaaS, Infraestrutura como serviço) escancararam a necessidade de se criar automatizações para ganhar agilidade no setup de ambientes. O crescimento da infraestrutura era limitado pelo ciclo de compras de hardware, que poderia levar dias ou até mesmo semanas para chegar, sem falar na ineficiência ao instalar o Sistema Operacional e seguir com as demais configurações, em sua grande maioria, de forma completamente manual.

A necessidade de aprovisionar novas máquinas virtuais (VMs) cada vez mais rápido, exigiu melhorias na automação desse processo. Por conta disto, templates de imagem dos servidores e práticas de clonagem chegaram para melhorar a eficiência, mas também a complexidade. Pois, uma vez que é possível implementar novas VMs sem muito esforço, os parques de servidores tendem a ficar cada vez maiores. Consequentemente, aumenta-se a necessidade de manter um número de servidores em constante crescimento, garantir que as atualizações ocorram sem falhas, evitar o que chamamos de “configuration drift”, etc.

Estes novos desafios para lidar com o crescimento exponencial da infraestrutura possibilitou o surgimento de novas ferramentas.

Chef, CFengine e Puppet se consolidaram e elevaram o nível da categoria de ferramentas para automação de infraestrutura e por conta disso, foram brevemente adotadas por organizações ágeis que estavam aproveitando ao máximo a nuvem IaaS à medida que ela emergia. Essas organizações, cuja TI foi tipicamente construída em torno da cultura Agile e Lean, desenvolveram práticas de “Infraestrutura como código” para gerenciar sua infraestrutura.

É importante destacar que a essência da Infraestrutura como Código é tratar a configuração dos sistemas da mesma forma que o código de software é tratado. Os sistemas de gerenciamento de código-fonte, o Desenvolvimento Orientado por Testes (TDD), a Integração Contínua (CI), refatoração e outras práticas XP são especialmente úteis para garantir que as mudanças na infraestrutura sejam completamente testadas, repetíveis e transparentes.

À medida que as organizações mais tradicionais adotaram a virtualização — geralmente em infraestrutura on-premises em vez de nuvens públicas, eles sentiram a mesma necessidade de automação para gerenciar seus sistemas. Embora alguns tenham explorado os conjuntos de ferramentas usados pelos “Early Adopters”, muitos recorreram aos fornecedores tradicionais, dos chamados ‘conjuntos de ferramentas de gestão corporativa’, que mudaram para adaptar e reformular seu software, a fim de surfar a onda “DevOps”.

O problema é que destes conjuntos de ferramentas, somente alguns foram projetados para suportar Infraestrutura como Código. Sim, eles oferecem certo grau de automatização e permitem criar um template do servidor com instâncias idênticas. Entretanto, quando é necessário fazer ajustes no template, não há registro rastreável que possa ser facilmente compreendido. Logo, não é possível executar testes automáticos de cada alteração usando ferramentas de validação de vários fornecedores, projetos de código aberto e times internos.

Ou seja, ao invés de usar um gerenciamento de mudanças contínuo e obrigatório, acaba-se criando um cenário de lock in, onde o gerenciamento de mudanças acaba voltando ao modelo tradicional (manual), exatamente como era antes do surgimento de qualquer tipo de automação.

A automação de infraestrutura possibilita a realização de ações repetidas em um grande número de nós. A infraestrutura como código usa técnicas, práticas e ferramentas de desenvolvimento de software para garantir que essas ações sejam exaustivamente testadas antes de serem aplicadas em ambiente produtivo, evitando falhas, períodos de downtime e impactos na experiência do usuário final ao mesmo tempo que possibilita reduzir o tempo de lançamento de novos releases.

Existem algumas variáveis a se considerar ao escolher as ferramentas que serão utilizadas para gerenciamento de configuração e que suportam infraestrutura como código. No entanto, destacam-se duas:

· As definições usadas para criar e atualizar as configurações do sistema devem ser externalizáveis em um formato que possa ser armazenado e versionado em um SCM (Git). Isso permite a adoção de uma ampla variedade de ferramentas para gerenciar, validar e testar o código. Dessa forma será possível obter o histórico de cada mudança implementada, juntamente com o tracking de quem fez, o porquê, a capacidade de reverter e a facilidade para criar documentações;

· Deve ser possível validar definições em vários níveis de granularidade para seja possível aplicar uma variação da pirâmide de testes, validações rápidas de sintaxe e estilo de código, testes unitários de configuração, seguidas pela instanciação de VMs que possam ser validadas, etc. Isso oferece os benefícios de “fail fast” e a correção rápida de mudanças, que é a base para a integração contínua e a construção de um pipeline de entrega contínua.

Sem a capacidade de garantir que cada mudança seja testada com facilidade e agilidade não é possível ter visibilidade e código aberto das mudanças de configuração, ocorrendo assim o vendor lock in em ferramentas de um único fornecedor, privando-se de um grande ecossistema de ferramentas para gerenciamento mudanças de software.

A principal característica do movimento do obsoleto ao moderno é que a infraestrutura agora pode ser tratada como software. Quando se aplicam práticas eficazes de desenvolvimento de software e uso intenso do crescente ecossistema de ferramentas projetadas para apoiar esta mudança, as organizações se tornam verdadeiramente ágeis.
Portanto, aproveitar ao máximo essa mudança é essencial para o futuro das organizações.

Exponential intelligence for exponential companies

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store