Aplicativos com estado e sem estado: como eles afetam o DevOps

Stateful e Stateless são dois tipos diferentes de arquitetura de computação que definem como um aplicativo gerencia processos de longa duração. Alguns sistemas são inerentemente sem estado, enquanto outros tendem a ser modelados com estado. Qualquer que seja a abordagem escolhida, afetará como as equipes de design e operações constroem e mantêm a solução.

Neste artigo, você aprenderá sobre as diferenças entre aplicativos com e sem estado e quando você pode usar cada um. Você também verá como os dois modelos afetam os requisitos de uma implementação de DevOps.

O que é um estado?

O “estado” de um serviço é uma informação persistente que é registrada durante uma transação ou evento e então chamada durante outra. Um dos exemplos mais simples de estado é um servidor de banco de dados: ele gerencia dados armazenados que precisam ser armazenados com segurança. Um registro salvo em uma sessão deve estar disponível para a próxima sessão.

O estado precisa ser cuidadosamente gerenciado para que possa ser usado no futuro. Os sistemas externos não precisam fornecer muitas informações para se referir a um evento anterior. Um identificador simples, como um número de transação de pagamento, permite que o serviço recupere outros dados associados à ação, como o valor do pagamento e o endereço de entrega.

O que são aplicativos sem estado?

Nem todo aplicativo tem um estado. Alguns sistemas não funcionam com dados de longa duração ou os armazenam em cache apenas para melhorar o desempenho. Eles ainda funcionarão se os dados salvos anteriormente forem perdidos.

Os aplicativos sem estado lidam com cada evento isoladamente. Os eventos não estão cientes uns dos outros ou do contexto maior no qual o aplicativo está sendo executado. Essa qualidade simplifica a consideração de sistemas sem estado. Não há risco de que a atividade anterior afete a operação atual.

Meu aplicativo é com estado ou sem estado?

Alguns aplicativos confundem as linhas entre modelos com e sem estado. O mesmo sistema pode ser visto com ou sem estado, dependendo do ponto de vista do qual você o aborda.

Os aplicativos da Web do lado do cliente geralmente são vistos como sem estado do ponto de vista do operador de serviço. Eles podem ser hospedados em um servidor web estático independente de quaisquer outros componentes. O aplicativo ainda pode acumular estado durante o uso, como configurações salvas no dispositivo do usuário e histórico de páginas recentes. Essa forma de estado não é relevante para equipes de DevOps porque não afeta a implantação do aplicativo.

Você pode determinar se um aplicativo precisa de um modelo de implantação com ou sem estado observando como ele armazena dados. Não há estado se não houver persistência ou se os dados forem armazenados apenas no dispositivo do usuário ou em um provedor de armazenamento não relacionado, como o Amazon S3. Um aplicativo persistirá no estado se alterar diretamente seu ambiente por meio de gravações do sistema de arquivos e outras alterações e, em seguida, exigir que essas alterações persistam indefinidamente.

Estado com contêineres e nuvem

Os aplicativos modernos geralmente são implantados na nuvem como contêineres. Os contêineres são projetados como unidades efêmeras de funcionalidade que podem ser substituídas sem efeitos colaterais. Isso significa que eles são predominantemente componentes computacionais sem estado.

No entanto, os contêineres podem ser usados ​​para encapsular sistemas com estado. Volumes persistentes fornecem um meio de montar armazenamento durável que dura mais que instâncias de contêiner individuais. Em comparação com VMs tradicionais e implantações bare metal, a diferença se resume à intencionalidade interna de gerenciar o estado do contêiner.

A conteinerização de um sistema com estado requer que você antecipe onde o estado ocorre e como ele é armazenado. Você não pode escrever ingenuamente caminhos arbitrários do sistema de arquivos porque eles não serão mapeados para um volume. Sem um volume, os dados serão perdidos se o contêiner parar ou for substituído. Um período de refatoração pode ser necessário para garantir que seu aplicativo grave consistentemente o caminho para o volume montado, portanto, você precisa determinar seus requisitos de armazenamento de dados com antecedência.

Como o status afeta o DevOps

Os processos de DevOps precisam ser ajustados dependendo se você usa serviços com ou sem estado. Os modelos de implantação sem estado oferecem muito mais margem de manobra. Você pode facilmente iniciar novos contêineres e escalá-los em vários nós distribuídos sem se preocupar com o acesso constante ao estado.

Um serviço com estado requer uma abordagem mais cuidadosa ao gerenciamento. Cada instância do aplicativo precisa ter acesso ao estado compartilhado. Isso pode impor restrições de escala. Poucas distribuições do Kubernetes permitem , por exemplo, que vários nós montem um volume com acesso de gravação ao mesmo tempo.

Ambos os tipos de aplicativos exigem monitoramento proativo para que você esteja ciente dos problemas antes que eles ocorram. Isso é mais importante para soluções com estado porque você precisa estar à frente dos requisitos de armazenamento e determinar quando a montagem do volume afeta as opções de agendamento de contêiner. As implantações com estado também devem ser suportadas por uma estratégia de backup normal.

O estado também complica o processo de DevOps, dificultando a reprodução precisa dos ambientes. Torna-se possível que o problema exista na produção, permanecendo indescritível na máquina do desenvolvedor. Esses problemas podem ser difíceis de diagnosticar. Você pode torná-los mais gerenciáveis ​​fornecendo mecanismos para os desenvolvedores clonarem ambientes para que possam reproduzir problemas em um sandbox.

O estado sempre adiciona complexidade e sobrecarga. Você precisa configurar e fornecer soluções de gerenciamento de estado, como volumes e bancos de dados, o que torna os pipelines de integração contínua mais complexos e difíceis de manter. O estado é inevitável na maioria dos aplicativos principais, portanto, tentar muito manter os sistemas sem estado pode ser um arenque vermelho fútil. É melhor usar ferramentas e treinamento para integrar perfeitamente aplicativos com estado em suas rotinas de DevOps, mesmo que isso signifique mais trabalho pela frente.

Resumo

A distinção entre aplicativos com estado e sem estado é importante para o sucesso do DevOps. Do ponto de vista do DevOps, um aplicativo com estado será mais difícil de implantar e manter porque você precisa dar a cada instância acesso a um armazenamento de dados persistente.

Os aplicativos sem estado são completamente separados de seu ambiente, o que normalmente os torna mais fáceis de conteinerizar e dimensionar na nuvem. No entanto, os verdadeiros sistemas sem estado são relativamente raros, portanto, geralmente são combinados com armazenamentos de dados com estado. Refatorar para componentes sem estado sempre que possível enquanto cria ferramentas para oferecer suporte a implantações com estado geralmente é a maneira mais eficaz de equilibrar o DevOps otimizado com os requisitos funcionais do seu sistema.