Sobre DevOps e Snowflakes

Mal se consegue dar um passo na TI hoje em dia sem ouvir pessoas falando sobre DevOps. DevOps é o novo tema quente da indústria, assumindo o lugar de onde a conversa sobre cloud parou, e ao ouvir as pessoas falarem sobre isso poderíamos acreditar que a administração de sistemas tradicional já está morta e enterrada.

Primeiro, precisamos falar sobre o que queremos dizer com DevOps. Isso pode ser confuso porque, assim como com cloud, um termo mais antigo é frequentemente sequestrado para significar algo diferente ou, na melhor das hipóteses, relacionado a algo que já existia. O DevOps tradicional era a fusão dos papéis de desenvolvedor e de operações. Da década de 1960 até a de 1990, essa era a forma padrão de operar sistemas. Nesse mundo, as pessoas que escreviam o software eram geralmente as mesmas que o implantavam e o mantinham. Daí a fusão de “desenvolvedor” e “operações”, sendo operações um termo semipadronizado para o papel de administrador de sistemas. Esses papéis não eram comumente separados até o surgimento do “Departamento de TI” nas décadas de 1990 e 2000. Desde então, o retorno à fusão dos dois papéis começou a ganhar popularidade novamente, principalmente por causa da maneira como os dois podem operar juntos, com grande valor, em muitas situações modernas de aplicações web hospedadas.

O DevOps de que se fala hoje frequentemente não é uma fusão estrita dos desenvolvedores e da equipe de operações, mas uma modificação da equipe de operações, com um foco muito maior em programação, não na aplicação em si, mas na definição de infraestruturas de aplicação como código, como uma extensão natural das arquiteturas de cloud. Isso pode ser bastante confuso a princípio. O que é importante notar é que o DevOps tradicional não é o que ocorre comumente hoje, mas sim um novo DevOps “falso”, no qual os desenvolvedores continuam sendo desenvolvedores e as operações continuam sendo operações, mas as operações evoluíram para um novo papel “pesado em código” que continua focado em gerenciar servidores que executam código fornecido pelos desenvolvedores.

O que é significativo hoje é que o papel do administrador de sistemas começou a se dividir em dois papéis relacionados, mas significativamente diferentes, sendo que um deles é chamado impropriamente de DevOps pela maior parte da indústria atualmente (sendo a maior parte da indústria jovem demais para se lembrar de quando o DevOps era a norma, não a exceção, e certamente não algo novo e inovador.) Refiro-me a esses dois aspectos do papel do administrador de sistemas aqui como as abordagens DevOps e Snowflake.

Uso o termo Snowflake para me referir a arquiteturas tradicionais de sistemas, porque cada servidor individual pode ser visto como um “Snowflake único” (floco de neve único.) Todos são diferentes, pelo menos na medida em que não são gerenciados de alguma forma que os mantenha idênticos. Isso não significa que eles tenham que ser todos únicos, apenas que retêm o potencial de sê-lo. Em ambientes tradicionais, um administrador de sistemas fará login em cada servidor individualmente para trabalhar neles. É comum certo grau de scripting para facilitar as tarefas de administração, mas, em sua essência, o papel envolve muito tempo trabalhando em sistemas individuais.

Facilitar a administração de arquiteturas Snowflake muitas vezes envolvia tentativas de minimizar as diferenças entre os sistemas de maneiras razoáveis. Isso geralmente começa com coisas como a escolha de um único sistema operacional e versão padrão (Windows 2012 R2 ou Red Hat Enterprise Linux 7), em vez de permitir que cada instalação de servidor tenha um SO ou versão diferente. Essa padronização pode parecer básica, mas muitos ambientes carecem dela ainda hoje.

Um próximo passo é, comumente, criar uma metodologia de implantação padrão ou uma imagem golden master que é usada para criar todos os sistemas, de modo que o sistema operacional base e todos os pacotes base, frequentemente incluindo customização do sistema, pacotes de monitoramento, pacotes de segurança, configuração de autenticação e modificações semelhantes, sejam padronizados e implantados de forma uniforme. Isso fornece um ponto de partida comum para todos os sistemas, a fim de minimizar a divergência. Mas, tecnicamente, eles apenas garantem um ponto de partida padrão, e, ao longo do tempo, a divergência na configuração deve ser prevista.

Além desses passos, os ambientes Snowflake normalmente usam scripts de administração personalizados e sob medida ou ferramentas de gerenciamento para manter certa padronização entre os sistemas ao longo do tempo. Quanto mais semelhanças existirem entre os sistemas, mais fácil é mantê-los e solucionar seus problemas, e menos conhecimento é necessário por parte da equipe de administração. Mais padronização significa menos surpresas, menos incógnitas e capacidades de teste muito melhores.

Em um ambiente com um único administrador de sistemas, com boas práticas e ferramentas, os ambientes Snowflake podem assumir um alto grau de padronização. Mas em ambientes com muitos administradores de sistemas, especialmente aqueles com suporte 24 horas por dia a partir de muitas regiões, e com um grande número de sistemas, a padronização, mesmo com práticas muito diligentes, pode se tornar muito difícil. E isso antes mesmo de enfrentarmos as questões óbvias em torno do fato de que pacotes diferentes, e possivelmente versões de pacotes diferentes, são necessários em sistemas que desempenham papéis diferentes.

A abordagem DevOps cresce organicamente a partir do modelo de arquitetura de cloud. A arquitetura de cloud é projetada em torno de sistemas amplamente idênticos (pelo menos em grupos), criados e destruídos automaticamente, que são controlados por meio de uma interface programática ou API. Esse modelo se presta, de forma bastante óbvia, a ser controlado centralmente por meio de um sistema de gerenciamento, em vez de pelos esforços manuais de um administrador de sistemas. A administração manual é efetivamente impossível e completamente impraticável sob esse modelo. Os sistemas individuais não são únicos como no modelo Snowflake, e qualquer divergência criará problemas sérios.

A ideia que emergiu do mundo da arquitetura de cloud é a de que a arquitetura de sistemas deveria ser definida centralmente “em código”, em vez de nos próprios servidores. Isso parece confuso a princípio, mas faz muito sentido quando o examinamos mais a fundo. A fim de suportar esse modelo, começou a surgir um novo tipo de ferramenta de gerenciamento de sistemas que ainda não adotou um nome realmente padrão, mas que é frequentemente chamada de ferramenta de automação de sistemas, framework DevOps, ferramenta de automação de TI ou simplesmente ferramenta de “infraestrutura como código”. Conjuntos de ferramentas comuns nesse campo incluem Puppet, Chef, CFEngine e SaltStack.

A ideia por trás desses conjuntos de ferramentas de automação é que um serviço central é usado para gerenciar e controlar todos os sistemas. Essa autoridade central gerencia servidores individuais por meio de descrições baseadas em código de como o sistema deve se parecer e se comportar. No mundo do Chef, essas descrições são chamadas de “recipes” (receitas), de forma divertida, mas a analogia funciona bem. O código de cada sistema pode incluir informações como uma lista de quais pacotes e versões de pacotes devem ser instalados, quais configurações do sistema devem ser modificadas e arquivos a serem copiados para a máquina. Em muitos casos, as decisões sobre essas implantações ou modificações são tratadas por meio de uma lógica potencialmente complexa, daí a necessidade de código de verdade, em vez de algo mais simplista, como markup ou templates. Os sistemas são então agrupados por papel e gerenciados em grupos. O papel de “servidor web” pode dizer a um conjunto de sistemas para instalar Apache e PHP e configurar a memória para fazer pouco swap. O papel de “SQL Server” pode instalar o MS SQL Server e ferramentas de backup especiais usadas apenas para essa aplicação e configurar a memória para ser ajustada conforme desejado para um pool de máquinas SQL Server. Esses são apenas exemplos. Tipicamente, uma organização teria um grande número de papéis, alguns podendo ser genéricos, como “servidor web”, e outros muito mais específicos para suportar aplicações muito específicas. Os papéis geralmente podem ser combinados em camadas, de modo que um sistema possa ser tanto um “servidor web” quanto um “servidor java”, atendendo às necessidades combinadas de ambos.

Essas definições padronizadas significam que os sistemas, uma vez designados como pertencentes a um papel ou outro, podem “construir a si mesmos” automaticamente. Um novo sistema pode ser criado por um administrador que solicita um sistema, ou um sistema de monitoramento de capacidade pode decidir que capacidade adicional é necessária para um papel e gerar novas instâncias de servidor automaticamente, sem qualquer intervenção humana. No momento em que o sistema é solicitado, por um humano ou automaticamente, o papel é designado, e o sistema, por meio do framework de automação, se transformará em um “nó” totalmente configurado e atualizado. Nenhuma intervenção humana de administração de sistemas é necessária. O processo é rápido, simples e, mais importante, completamente repetível.

Definir sistemas em código tem algumas consequências não óbvias. Uma é que os backups de sistemas completos já não são necessários. Por que fazer backup de um sistema que você pode recriar, com esforço mínimo, quase instantaneamente? Os dados locais de sistemas de banco de dados precisariam ter backup, mas apenas os dados do banco de dados, não o sistema inteiro. Isso pode reduzir muito a carga sobre as infraestruturas de backup e tornar os processos de restauração mais rápidos e mais confiáveis.

A quantidade de documentação necessária para sistemas já definidos em código é muito mínima. Em ambientes Snowflake, o administrador de sistemas precisa manter documentação específica de cada host e mantê-la manualmente. Isso consome muito tempo e é propenso a erros. Sistemas definidos por meio de código central precisam de pouca ou nenhuma documentação, e a documentação pode ser tratada em nível de grupo, não em nível de nó individual.

Testar sistemas que são definidos em código também é fácil de fazer. Você pode criar um sistema via código, testá-lo e saber que, quando você mover essa definição para produção, o sistema de produção será criado de forma repetível, exatamente como foi criado nos testes. Em ambientes Snowflake, é muito comum ter práticas de teste que tentam fazer isso, mas o fazem por meio de esforços manuais e são propensas a serem desleixadas e não exatamente repetíveis, e muito frequentemente a política ditará que é mais rápido simular a repetibilidade do que realmente buscá-la. Sistemas definidos em código contornam esses problemas, tornando os testes muito mais valiosos.

Fora a necessidade de definir um número de nós para existir dentro de cada papel, o sistema pode reprovisionar uma arquitetura inteira, do zero, automaticamente. A reconstrução após um desastre ou a ativação de um site secundário pode ser feita de forma muito rápida e fácil. Além disso, mover-se entre sistemas hospedados localmente e sistemas hospedados remotamente, incluindo os de empresas como Amazon, Microsoft, IBM, Rackspace e outras, é extremamente fácil.

É claro que, no mundo DevOps, há um grande valor em usar arquiteturas de cloud para habilitar o nível mais extremo de automação, mas usar arquiteturas de cloud é desnecessário para alavancar esses tipos de ferramentas. E, é claro, ter uma arquitetura definida em código poderia ser usado parcialmente, enquanto a administração manual também poderia ser implementada, para uma abordagem híbrida, mas isso raramente é recomendado em sistemas individuais. Geralmente é muito melhor ter dois ambientes, um que é gerenciado como Snowflakes e outro que é gerenciado como DevOps, quando as duas abordagens são exigidas. Isso resulta em uma hibridização muito melhor. Já vi isso funcionar extremamente bem em um ambiente corporativo com mais de várias dezenas de milhares de servidores “Snowflake”, cada um muito único, mas com um ambiente dedicado de dezenas de milhares de nós que era gerenciado de maneira DevOps, porque todos os nós deveriam ser idênticos e intercambiáveis usando uma de duas configurações possíveis. A hibridização foi muito eficaz.

A abordagem DevOps, no entanto, vem com ressalvas importantes também. Os conjuntos de habilidades necessários para gerenciar um sistema dessa maneira são muito maiores do que os necessários para a administração de sistemas tradicional, pois, no mínimo, todo o conhecimento de administração de sistemas tradicional ainda é necessário, além de um sólido conhecimento de programação, tipicamente de linguagens modernas como Python e Ruby, e conhecimento dos frameworks específicos em questão também. Esse requisito de base de conhecimento ampliada significa que os praticantes de DevOps não são apenas raros, mas também caros. Significa também que a educação universitária, que já está muito aquém de preparar administradores de sistemas ou desenvolvedores para o mundo profissional, está agora ainda mais distante de preparar os graduados para trabalhar sob um modelo DevOps.

Os administradores de sistemas que trabalham em cada um desses dois campos têm a tendência de ver todos os sistemas como se precisassem se encaixar em seu próprio molde. Os novos praticantes de DevOps muitas vezes acreditam que os sistemas Snowflake são legados e precisam ser atualizados. Os administradores Snowflake (tradicionais) tendem a ver o movimento de “infraestrutura como código” como bobo, cheio de overhead desnecessário, excessivamente complicado e muito de nicho.

A realidade é que ambas as abordagens têm uma quantidade enorme de mérito e ambas permanecerão extremamente viáveis. Ambas fazem sentido para cargas de trabalho muito diferentes, e suspeito que as grandes organizações comumente verão ambas em uso por meio de alguma forma de hibridização. No mercado SMB, onde normalmente há apenas um número minúsculo de servidores, nenhuma alavancagem de escala para justificar arquiteturas de cloud e uma grande disparidade entre os sistemas, suspeito que o DevOps permanecerá quase indefinidamente fora da norma, pois o overhead e as habilidades adicionais necessárias para fazê-lo funcionar são impraticáveis ou até impossíveis de adquirir. As organizações maiores precisam analisar suas cargas de trabalho. Muitas cargas de trabalho tradicionais e grande parte do software tradicional não são bem adequados à abordagem DevOps, especialmente à automação de cloud, e exigirão hibridização ou um nível de programação impraticavelmente alto por sistema, tornando o modelo DevOps impossível de justificar. Mas as cargas de trabalho construídas sobre arquiteturas web ou que escalam horizontalmente extremamente bem se beneficiarão fortemente do modelo DevOps em escala. Isso poderia se aplicar a grandes empresas corporativas ou a empresas menores que provavelmente produzem aplicações hospedadas para consumo externo.

Essa diferença de abordagem significa que, nos Estados Unidos, por exemplo, a maior parte do país é composta por empresas que permanecerão focadas no modelo de gerenciamento Snowflake, enquanto algumas empresas da costa leste poderiam avaliar o modelo DevOps de forma eficaz e começar a se mover nessa direção. Mas na costa oeste, onde arquiteturas mais modernas e um foco muito maior em aplicações hospedadas e aplicações para consumo externo são os fatores econômicos motrizes, o DevOps já está deixando de ser novidade para se tornar uma normalidade madura e estabelecida. As abordagens DevOps e Snowflake provavelmente permanecerão fortemente segregadas por regiões dessa forma, assim como a TI, em geral, vê diferentes conjuntos de habilidades migrarem para diferentes regiões. Não seria surpreendente ver o DevOps começar a se firmar em mercados como Austin, onde a TI tradicional teve um desempenho bastante fraco.

Nenhuma das abordagens é melhor ou pior; são duas abordagens diferentes que atendem a duas maneiras muito diferentes de provisionar sistemas e a duas necessidades fundamentais distintas desses sistemas. Com a ascensão das arquiteturas de cloud e do modelo DevOps, no entanto, é de importância crítica que os administradores de sistemas existentes entendam o que significa o modelo DevOps e quando ele se aplica, para que possam avaliar corretamente suas próprias cargas de trabalho e necessidades únicas. Uma grande parcela do mundo tradicional de administração de sistemas Snowflake migrará, ao longo do tempo, para o modelo DevOps. Estamos muito longe de alcançar um estado estável na indústria quanto ao equilíbrio entre esses dois modelos.

Publicado originalmente no StorageCraft Blog.