O que é a infraestrutura como código para o NetOps?

À medida que as abordagens do DevOps avançam para as operações de rede, elas trazem consigo uma nova terminologia. Esses coloquialismos podem ser confusos para NetOps que nunca os encontraram antes e podem confundir executivos de TI que estão sendo pressionados a adotar a metodologia.

Entre elas está a noção de infraestrutura como código. No mundo dos desenvolvedores, a infraestrutura é basicamente as plataformas, os servidores e os sistemas de contêineres nos quais os aplicativos são implantados e dimensionados. Infraestrutura é principalmente computação.

Do outro lado do muro existe um conjunto de infraestrutura mais amplo e robusto que abrange armazenamento, segurança e rede, além de computação. Afinal, existem quatro operações, e todas devem operar em sincronia para atingir a implantação contínua e permitir o tipo de otimização que os líderes de TI e negócios buscam na transformação digital. Isso significa que a infraestrutura como código inclui uma gama muito mais ampla de sistemas, dispositivos e serviços em produção do que em desenvolvimento. Uma implantação de aplicativo geralmente significa que a infraestrutura em cada uma das quatro operações será afetada de alguma forma. Isso torna a infraestrutura como código na produção um pouco mais complicada, mas também tem um impacto maior na eficiência e na velocidade.

Isso ocorre porque a automação pode eliminar os tempos de espera entre as transferências, que muitas vezes são a fonte de ineficiências nas implantações, principalmente quando os processos manuais entram em conflito com férias, dias de doença e horários de almoço.

É UMA SEMELHANÇA

Infraestrutura como código é uma comparação; o que significa que não queremos realmente (pelo menos não agora) transformar nossos sistemas de serviços de rede e aplicativos em código que construímos e depois implantamos. Isso seria uma loucura para a maioria das organizações empresariais e prejudicaria a estabilidade e a confiabilidade da rede corporativa. Mas queremos aproveitar os benefícios de um sistema que desvincula a configuração e os perfis dos sistemas nos quais eles estão sendo executados.

Isso significa separar configurações, políticas e perfis do hardware ou software no qual eles são implantados.

É essa coleção que é então considerada “artefatos de implantação” e pode ser tratada como código. Isso significa que eles podem ser armazenados e gerenciados em repositórios, versionados e revisados. Eles podem ser extraídos, clonados e confirmados da mesma forma que um desenvolvedor extrai, clona e confirma o código de e para um repositório (como o Github).

Também deveríamos incluir “artefatos de automação”. Esses são os scripts e arquivos associados que descrevem tarefas de automação que acompanham o kit de ferramentas de automação de sua escolha. Se isso é Ansible, então são playbooks. Se é Chef, é uma receita. Para Puppet, um manifesto. Ou pode ser apenas um script Python antigo.

Para BIG-IP e um número crescente de sistemas hospedados em rede, isso também inclui modelos (iApp) que podem descrever melhor configurações mais complexas ou padronizadas. Usar um modelo pode ser vantajoso aqui porque ele pode oferecer suporte a opções e serviços de aplicativos que talvez ainda não sejam suportados pelo conjunto de ferramentas principal.

Junto com os artefatos de implantação, os artefatos de automação formam a coleção que chamamos de “infraestrutura como código”. Supõe-se que você possa provisionar um sistema e posteriormente executar um processo de automação nele para configurá-lo conforme desejado.

Quando combinada com uma abordagem por aplicativo para serviços de rede e aplicativo, uma abordagem de infraestrutura como código pode reduzir drasticamente o risco de implantações frequentes. Ao isolar configurações e limitar seu impacto a um único sistema, o impacto de uma implantação que deu errado é praticamente eliminado. Isso, por sua vez, incentiva cronogramas por aplicativo que se alinham melhor às necessidades do negócio e às demandas dos usuários.

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

Há muitos bons motivos para empreender o esforço de migrar para uma abordagem de infraestrutura como código, e muito poucos bons motivos para não fazê-lo. A infraestrutura como código é uma das maneiras mais vantajosas de concretizar a rede ágil que as organizações precisam para ter sucesso em uma economia digital multinuvem e orientada por aplicativos.