O que é infraestrutura como código para NetOps?

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

À medida que as abordagens de DevOps avançam para as operações de rede, elas trazem consigo uma nova terminologia. Esses termos coloquiais podem confundir as equipes de NetOps que ainda não os conhecem e deixar perplexos os executivos de TI que estão sendo pressionados a adotar essa metodologia.

Entre eles está o conceito de infraestrutura como código. No mundo dos desenvolvedores, a infraestrutura consiste principalmente nas plataformas, nos servidores e nos sistemas de contêineres nos quais os aplicativos são implantados e dimensionados. A infraestrutura é, sobretudo, computação.

Do outro lado do muro, há um conjunto de infraestrutura mais amplo e robusto, que abrange armazenamento, segurança e redes, além de computação. Afinal, são quatro áreas de operações, e todas precisam funcionar em sincronia para viabilizar a implantação contínua e permitir o tipo de otimização que os líderes de TI e de negócios esperam obter com a transformação digital. Isso significa que, em produção, a infraestrutura como código inclui uma variedade muito maior de sistemas, dispositivos e serviços do que no desenvolvimento. Em geral, a implantação de um aplicativo afeta, de alguma forma, a infraestrutura de cada uma das quatro áreas de operações. Isso torna a infraestrutura como código em produção um pouco mais complexa, mas também amplia seu impacto sobre a eficiência e a velocidade.

Isso acontece porque a automação pode eliminar os tempos de espera entre as transferências de tarefas, que muitas vezes são a causa de ineficiências nas implantações, especialmente quando os processos manuais são prejudicados por férias, licenças médicas e horários de almoço.

É UMA COMPARAÇÃO

Infraestrutura como código é uma comparação; isso significa que, na verdade (pelo menos por enquanto), não queremos transformar nossos sistemas de rede e de serviços de aplicações em código para depois compilá-lo e implantá-lo. Isso seria uma loucura para a maioria das organizações empresariais e comprometeria a estabilidade e a confiabilidade da rede corporativa. No entanto, queremos aproveitar os benefícios de um sistema que desvincula as configurações e os perfis dos sistemas nos quais são executados.

Isso significa separar as configurações, políticas e perfis do hardware ou software em que são implantados.

É esse conjunto que passa a ser considerado como “artefatos de implantação” e pode ser tratado da mesma forma que o código. Isso significa que esses artefatos podem ser armazenados e gerenciados em repositórios, versionados e revisados. Eles podem ser obtidos, clonados e submetidos da mesma forma que um desenvolvedor obtém, clona e submete código de e para um repositório (como o Github).

Também devemos incluir os “artefatos de automação”. Eles são os scripts e arquivos associados que descrevem as tarefas de automação usadas com o kit de ferramentas de automação de sua preferência. No Ansible, são os playbooks. No Chef, é uma receita. No Puppet, um manifesto. Ou pode ser simplesmente um bom e velho script em Python.

Para o BIG-IP e um número cada vez maior de sistemas hospedados em rede, isso também inclui modelos (iApp) que podem descrever com mais detalhes configurações mais complexas ou padronizadas. O uso de um modelo pode ser vantajoso nesse caso, pois ele pode oferecer suporte a opções e serviços de aplicativos que talvez ainda não sejam compatíveis com o conjunto principal de ferramentas.

Juntamente com os artefatos de implantação, os artefatos de automação formam o conjunto que chamamos de “infraestrutura como código”. Pressupõe-se que seja possível provisionar um sistema e, posteriormente, executar nele um processo de automação para configurá-lo conforme desejado.

Quando combinada a uma abordagem por aplicativo para serviços de rede e de aplicativos, a abordagem de infraestrutura como código pode reduzir drasticamente o risco associado a implantações frequentes. Ao isolar as configurações e restringir seu impacto a um único sistema, o impacto de uma implantação malsucedida é praticamente eliminado. Isso, por sua vez, incentiva cronogramas específicos para cada aplicativo, mais alinhados às necessidades da empresa e às demandas dos usuários.

Para organizações voltadas para a nuvem, adotar uma abordagem de infraestrutura como código pode reduzir as dificuldades envolvidas na migração de um data center para a nuvem ou de uma nuvem para outra. Como a configuração é desacoplada do sistema, ela pode, em princípio, ser implantada em um sistema semelhante em outro ambiente.

Há muitos bons motivos para adotar uma abordagem de infraestrutura como código e pouquíssimos para não fazê-lo. A infraestrutura como código é uma das formas mais vantajosas de implementar a rede ágil de que as organizações precisam para prosperar em uma economia digital multicloud e orientada por aplicações.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie