Há tempos, a forma dominante de manter nossas aplicações “rodando” tem sido através de infraestruturas “mutáveis”. Ou seja, compostas por servidores projetados para continuar funcionando por tempo indeterminado, recebendo atualizações na medida em que estas ficam disponíveis. Entretanto, esse “jeito de funcionar”, parece estar com os dias contados!

[tweet]Manter os servidores, em produção, devidamente atualizados e saudáveis é um desafio crescente.[/tweet] A menos que passemos a fazer as coisas de uma forma diferente da que fazemos hoje, nossos obstáculos só vão aumentar.

O “jeito mutável”, tem feito com que frequentemente, rotinas administrativas, mesmo as aparentemente inocentes, originem falhas notáveis em produção. Nem mesmo a adoção de ótimas ferramentas, como Puppet, Chef, Ansible e Octopus, tem sido suficientes para impedir que coisas assim aconteçam.

A raiz das dificuldades relacionadas as infraestruturas “mutáveis”, acreditamos, é a “complexidade” crescente e manifesta em suas quatro origens comuns:

1. dimensionalidade alta, tanto nos diversos fluxos independentes de atualização quanto na heterogeneidade resultante nas diversas instâncias de servidores;
2. interdependência crescente dos componentes, expressa na falta evidente de resiliência das arquiteturas;
3. grande influência de fatores externos, sobretudo em atualizações que não tem qualquer relação com as demandas da aplicação operando em um servidor e que, mesmo assim, são instaladas e geram impactos negativos;
4. baixíssima reversibilidade, assinalada na dificuldade de reverter “impactos colaterais” causados por rotinas de atualização que gostaríamos que fossem desfeitas.

As soluções para estas origens de complexidade, presentes nas infraestruturas “mutáveis”, passam pelo rompimento definitivo com o paradigma.

A recomendação tem sido para que, inspirados pelos contêineres, deixemos de utilizar servidores, incrementalmente atualizados, projetados para operar por tempo indeterminado. No lugar deles, que adotemos métodos ágeis para “levantar” e “derrubar” servidores, rapidamente, a partir de scripts de configuração. Esses servidores não seriam atualizados em produção, permanecendo “imutáveis”, sendo substituídos por novas instâncias sempre que necessário.

A “infraestrutura imutável”, combinada com o conceito de “infraestrutura como código”, possibilita, inclusive, com ferramentas como a Packer, da HashiCorp, que apliquemos as mesmas estratégias de CI/CD que já aplicamos com sucesso no desenvolvimento de aplicações. Dessa forma, temos:

1. redução na dimensionalidade, uma vez que concentramos os fluxos de atualização sempre na atualização do script que gera a imagem dos servidores e que as instâncias passam a ter homogeneidade garantida pela utilização da mesma imagem;
2. redução da interdependência, visto que o deploy da aplicação fica combinado com o da infraestrutura;
3. menor influência do ambiente, uma vez que as imagens são projetadas em isolamento e podem ser testadas também em isolamento;
4. aumento da reversibilidade, uma vez que, por serem imutáveis, os servidores não armazenam estado e podem ser gerados, rapidamente, por versões anteriores de seus scripts de configuração.

Em termos simples, infraestruturas “imutáveis” atacam as origens comuns da complexidade e, por isso, invariavelmente, são mais simples, eficientes e mais baratas.

Finalmente, mas não menos importante, infraestruturas “imutáveis” são plenamente alinhadas com os princípios da computação em nuvem. Afinal, a geração de novas instâncias, simplificada a partir de scripts, melhora a descartabilidade dos servidores e habilita a utilização de features como auto-scaling e self-healing.