Não é possível implementar uma infraestrutura imutável sem uma arquitetura por aplicativo

F5

Em 2013, fomos apresentados ao conceito de servidor imutável. Um servidor imutável é, como o termo imutável sugere, estático. Sua configuração é fixa e não pode (ou, pelo menos, não deve) ser alterada. Se forem necessárias alterações, um novo servidor com a nova configuração substituirá o servidor em execução. Isso é desejável, especialmente em ambientes de nuvem e ambientes locais altamente automatizados, porque simplifica a configuração e aumenta a confiabilidade dos sistemas de automação responsáveis pelas implantações.

Esse conceito funciona bem em ambientes de nuvem e conteinerizados, até mesmo para serviços de rede e de aplicações, mas não tão bem em arquiteturas tradicionais de infraestrutura compartilhada.

Isso ocorre porque a definição de infraestrutura compartilhada pressupõe vários serviços em execução. Com base nos dados do F5 iHealth , isso pode representar, em média, 123 configurações individuais (servidores virtuais). Não é prático nem recomendável tentar interromper e reimplantar 122 desses servidores virtuais para fazer uma única alteração em um servidor virtual.

Mas isso não torna o conceito impraticável nem indesejável. A chave para adotar uma infraestrutura imutável em conjunto com seus sistemas de automação e de infraestrutura como código (IaC) é migrar para uma arquitetura por aplicativo.

Por que usar uma infraestrutura imutável?

Por que você faria uma mudança tão significativa na arquitetura da rede corporativa? Permita-me citar a mim mesmo, pois não consigo pensar em uma forma melhor de reformular isso hoje:

Por causa da entropia.

A Lei da Entropia de Software é descrita por Ivar Jacobson et al. em "Engenharia de Software Orientada a Objetos: Uma Abordagem Baseada em Casos de Uso":

A segunda lei da termodinâmica, em princípio, afirma que a desordem de um sistema fechado não pode ser reduzida; ela só pode permanecer inalterada ou aumentar. Uma medida dessa desordem é a entropia. Essa lei também parece se aplicar a sistemas de software; à medida que um sistema é modificado, sua desordem, ou entropia, sempre aumenta. Isso é conhecido como entropia de software.

Essa lei também se aplica a sistemas que exigem atualizações de firmware ou em nível de sistema, nos quais são implantadas correções emergenciais e patches e são feitos ajustes urgentes de configuração que, em um mundo perfeito, só deveriam ser alterados por meio de um processo de gerenciamento de mudanças rigorosamente seguido. O problema que a infraestrutura imutável (descartável) busca resolver é que, quanto mais mudanças são introduzidas em um sistema, mais remendado e instável ele parece se tornar. Desordem. Caos. Entropia.

Não se trata apenas de alterações na configuração para atender a um aplicativo ou implantar patches virtuais emergenciais para alguma vulnerabilidade descoberta recentemente. Esses são bons motivos para alterar a configuração de um serviço de aplicação, mas não são os únicos. Correções emergenciais, patches e dependências de versão também são bons motivos pelos quais talvez seja necessário alterar uma das 123 configurações em execução na infraestrutura compartilhada.

Ao adotar uma arquitetura por aplicativo, você elimina o risco de que uma, duas ou até dez dessas instâncias causem interrupções nas outras cem executadas em uma infraestrutura compartilhada. Em essência, atribuir a cada aplicativo seu próprio caminho de dados cria as condições necessárias para uma abordagem de infraestrutura imutável, que dará maior suporte à transição para uma prática de implantação automatizada e baseada em infraestrutura como código.

Isso significa um pipeline de serviços de aplicação totalmente baseado em software, com os serviços de aplicação implantados em uma arquitetura que pode ser considerada de “microsserviços de aplicação”, semelhante à forma como os microsserviços são implantados em contêineres.

Julian Dunn da Chef explicou isso muito bem em seu blog — Infraestrutura imutável: prática ou não?

A infraestrutura imutável é geralmente definida como uma pilha que você cria uma única vez (seja uma imagem de máquina virtual, uma imagem de contêiner ou qualquer outra coisa), executa uma ou várias instâncias dela e nunca mais a altera. O modelo de implantação consiste em encerrar a instância ou o contêiner e recomeçar desde a primeira etapa: criar uma nova imagem e descartar as instâncias antigas.

Portanto, se aplicarmos isso aos serviços de aplicação mais estreitamente vinculados (afins) a uma determinada aplicação, teremos uma arquitetura de rede em duas camadas, composta por serviços centrais comuns e compartilhados (como proteção de rede contra DDoS e controle de acesso por meio de firewalls tradicionais baseados em portas), que alimentam uma “pilha” específica para cada aplicação, tratada como imutável e implantada/gerenciada com base nos conceitos de infraestrutura como código.

Mas você realmente não consegue adotar a imutabilidade sem uma infraestrutura por aplicativo, pois precisa desacoplar os serviços relevantes da aplicação das plataformas compartilhadas primeiro. Se puder usar a mesma plataforma — apenas em formato de software —, esse processo se torna ainda mais fácil, pois você já dispõe de grande parte do conhecimento e das ferramentas necessárias para avançar a todo vapor rumo a um modelo imutável e específico para cada aplicativo.

Mesmo que você não esteja considerando uma infraestrutura verdadeiramente imutável, a possibilidade de adotá-la quando fizer mais sentido (nova versão da infraestrutura, correções emergenciais, patches etc.) facilitará a vida tanto para você quanto para os responsáveis por DevOps do aplicativo ao qual a infraestrutura dá suporte.

Sobre o autor

F5

Mais publicações de F5