Você não pode tornar uma infraestrutura imutável sem uma arquitetura por aplicação

Em 2013, fomos apresentados ao conceito de um 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. O motivo pelo qual isso é desejável, principalmente em ambientes de nuvem e locais altamente automatizados, é que simplifica a configuração e melhora a confiabilidade dos sistemas de automação que impulsionam as implantações.

Esse conceito funciona bem em ambientes de nuvem e contêineres, mesmo para serviços de rede e aplicativos, mas não tão bem em arquiteturas de infraestrutura compartilhadas tradicionais.

Isso ocorre porque a definição de infraestrutura compartilhada implica múltiplos serviços em execução. Com base nos dados do F5 iHealth , múltiplos podem significar uma média de 123 configurações individuais (servidores virtuais). Não é prático nem sugerido que você tente parar 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 junto com seus sistemas de automação e infraestrutura como código (IaC) é migrar para uma arquitetura por aplicativo.

Por que infraestrutura imutável?

Por que você empreenderia uma mudança tão significativa na arquitetura de rede corporativa? Deixe-me citar a mim mesmo , porque não consigo pensar em uma maneira melhor de reformular o dia de hoje:

Porque, entropia.

A Lei da Entropia de Software é descrita por Ivar Jacobson et al. em " Engenharia de Software Orientada a Objetos: Uma abordagem orientada por 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 aumentada. Uma medida dessa desordem é a entropia . Essa lei também parece plausível para sistemas de software ; à medida que um sistema é modificado, sua desordem, ou entropia, sempre aumenta. Isso é conhecido como entropia de software.

Esta lei também se aplica a sistemas para os quais atualizações de firmware ou de nível de sistema devem ser aplicadas. Para os quais são implantados hot fixes e patches. Para quais ajustes de emergência na configuração, 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) está tentando resolver é que quanto mais mudanças você introduz em um sistema, mais desorganizado e instável ele parece se tornar. Desordem. Caos. Entropia.

Não se trata apenas de alterações na configuração do serviço de um aplicativo ou de implantar patches virtuais de emergência para alguma vulnerabilidade descoberta recentemente. Essas são boas razões para alterar a configuração de um serviço de aplicativo, mas não são as únicas. Hot fixes, patches e dependências de versão também são bons motivos pelos quais você pode precisar alterar uma das 123 configurações em execução na infraestrutura compartilhada.

Ao mudar para uma arquitetura por aplicativo, você elimina o potencial de interrupção de uma, duas ou até dez dessas instâncias em relação às outras cem em execução na infraestrutura compartilhada. Dar a cada aplicativo seu próprio caminho de dados, essencialmente, prepara o cenário para dar suporte a uma abordagem de infraestrutura imutável que dará melhor suporte à mudança em direção a uma prática de implantação automatizada e baseada em infraestrutura como código.

Isso significa um pipeline de serviços de aplicativos totalmente baseado em software – com serviços de aplicativos implantados no que é muito mais uma arquitetura de “micro-serviços de aplicativos”, semelhante a como os microsserviços são implantados em contêineres. 

Julian Dunn , do Chef, explicou bem em seu blog - Immutable Infrastructure: Prático ou não?

Infraestrutura imutável é geralmente definida como uma pilha que você cria uma vez (seja uma imagem de máquina virtual, imagem de contêiner ou outra coisa), executa uma ou muitas instâncias e nunca mais muda. O modelo de implantação é encerrar a instância/contêiner e começar do zero a partir da etapa um: criar uma nova imagem e descartar as instâncias antigas.

Então, se aplicarmos isso aos serviços de aplicativos que são mais fortemente acoplados (afins) a um determinado aplicativo, você acaba com uma arquitetura de rede de duas camadas que compreende serviços compartilhados comuns e essenciais (como DDoS de rede e acesso por meio de firewalls tradicionais baseados em portas) que alimentam uma "pilha" por aplicativo que é tratada como imutável e implantada/gerenciada usando conceitos de infraestrutura como código.

Mas você realmente não pode fazer algo imutável sem uma infraestrutura por aplicativo, porque você precisa primeiro desacoplar os serviços de aplicativo relevantes de suas plataformas compartilhadas. Se você puder usar a mesma plataforma — apenas em um formato de software — esse processo se tornará ainda mais fácil porque você já terá muito do conhecimento e dos conjuntos de ferramentas necessários para avançar a todo vapor em direção a um modelo imutável por aplicativo.

Mesmo que você não esteja considerando uma infraestrutura verdadeiramente imutável, a capacidade de aproveitá-la quando fizer mais sentido (nova versão da infraestrutura, hot fixes, patches, etc.) tornará a vida mais fácil para você e para os proprietários de DevOps do aplicativo que a infraestrutura está suportando.