Ah, anos 90! Falar em deploy era sinônimo de arrepio para os sysadmins (neste grupo podemos colocar os administradores de rede, administradores de sistemas, administradores de banco de dados, analistas de infra e suporte, entre outros).

Mudanças na aplicação implicavam em mudanças na infra, e todos sabiam que esta era a maior causa de instabilidade nos sistemas. Sempre tinha um desenvolvedor que aplicava aquele patch com um novo recurso em plena sexta-feira, às 17 horas, pouco antes de desligar o celular e partir para o litoral. Foi assim que começou a guerra épica dos anos 90 e 2000, infra versus dev.

Nos anos 2010, entretanto, a guerra chegou ao fim: o devops veio para juntar os dois mundos, trazendo paz às equipes. Infra e dev unidos por uma causa nobre, o bem-estar da aplicação.

Mas o que de fato mudou de lá para cá? Vamos pensar no processo:

Deploy nos anos 90

Era inevitável: o pobre do responsável pela infra tinha que carregar servidores pesados (que possuíam menos poder que o smartphone que está no seu bolso) por meio do datacenter. Era uma dura jornada:

• receber,
• desempacotar,
• conferir os itens,
• montar,
• atualizar o firmware,
• particionar,
• instalar o SO,
• atualizar,
• e instalar a aplicação.

A instalação da aplicação também não era simples. Era necessário baixar um zip ou tarball usando uma internet lenta e cheia de restrições de segurança. Quando a instalação começava, você descobria que a aplicação tinha uma dependência, e o processo começava novamente.

Deploy nos anos 2000

Esta foi uma década importante: a virtualização ganhou força e tomou as empresas e datacenters. A VMware ganhou uma enorme fatia do mercado e foi seguida pela Citrix, RedHat, Microsoft e por produtos da comunidade open source. O trabalho ficou assim: todos os passos dos anos 90 eram realizados da primeira vez. Entretanto, a camada de virtualização era instalada antes da aplicação, e todos os aplicativos subsequentes eram instalados em máquinas virtuais dentro do mesmo grande servidor físico.

Outro ponto importante foi a popularização dos repositórios de código-fonte. O Sourceforge.net foi um dos mais conhecidos nesta época, e o software era baixado diretamente na máquina virtual. Aliás, a internet melhorou muito nesta década.

Deploy hoje

No começo da década atual, um movimento de automatização, simplificação e boas práticas inundou o mercado, junto com a difusão das práticas ágeis. Palavras como repositórios distribuídos, integração contínua, entrega contínua, aplicativos para dispositivos móveis, computação em nuvem e automatização de infraestrutura se tornaram parte do bê-a-bá dos administradores de sistemas. Estes, por sua vez, passaram a olhar para o aplicativo e para a operação ao mesmo tempo, tentando manter tudo funcionando da melhor forma possível. Surge o movimento devops, que traz uma nova cultura organizacional.

O processo de deploy fica assim:

• O devops cria o código que gera a infra. Este código é salvo em um repositório, no qual  ele é versionado.
• Ele utiliza uma ferramenta de automatização, como Ansible, Chef, Puppet, entre outras, para iniciar esta infra.
• O desenvolvedor utiliza um repositório para versionar seus programas.
• As alterações na aplicação são automaticamente detectadas por um servidor de integração contínua.
• Este servidor baixa a aplicação e executa diversos tipos de testes (funcionais, unitários, de segurança, etc.), salvando os relatórios.
• Se a aplicação passa nos testes, o servidor faz seu deploy no servidor de aplicação automaticamente.
• A qualidade e a performance são medidas em todos os passos do ciclo, e os erros são detectados e resolvidos rapidamente.

Claro que este processo não é uma regra rígida, uma forma universal, mas demonstra o processo de deploy de um aplicativo típico.

Novidades quentes

Vimos algumas tecnologias de infra crescendo muito em 2014 e agora em 2015. Algumas são reinvenções (melhorias) de soluções existentes, e outras são adaptações de coisas que não havia em infra.

Servidor de integração contínua criando infra

Os maiores serviços de cloud fornecem uma API para controlar seus recursos. Um bom exemplo é a API da AWS: ela está disponível em várias linguagens, é amplamente documentada e permite fazer tudo que é feito pela página de gerenciamento. Uma API tão poderosa permitiu desenvolver um pipeline de desenvolvimento no qual o servidor responsável pelos testes tem autonomia para criar uma ou mais instâncias de servidores em nuvem, instalar a aplicação em questão nestes servidores e testá-la. Assim que os testes acabam, os servidores são terminados. Como o pagamento em nuvem é calculado por horas de uso, os custos com ambiente de testes são reduzidos a frações do custo de manter um ambiente com máquinas físicas e instalação manual.

Aplicação em containers imutáveis e descartáveis

Para aumentar a segurança de um servidor, uma das táticas mais eficientes é não permitir que ele mude. A técnica de criar servidores imutáveis reduz significativamente os riscos de alteração da aplicação por ataques. Funciona muito bem em um paradigma de infra descartável:

• Uma imagem padrão do servidor virtual é criada.
• A aplicação é instalada em um container (docker, LXC, cgroups).
• O container é embutido no servidor em modo read-only.
• O servidor passa por um processo de hardening que visa manter a integridade desta imagem.
• Após a execução da aplicação, o servidor é deletado.

Este processo deve ter uma infra em nuvem porque depende fortemente de uma API para criar servidores a partir de um modelo e descartar toda a VM após o uso.

Códigos de automatização de infra com BDD

Partindo do princípio que temos que automatizar a infra e que nossa infra é transformada em código, como todo código de qualidade, ela deve ser testada e versionada. Para testar a infra, usamos Behavior Driven Development, ou Desenvolvimento Guiado por Comportamento. Para cada funcionalidade que queremos implementar descrevemos vários cenários, sempre atrelados às regras de negócio e às histórias do projeto.

Minha ferramenta preferida para esta tarefa é o Cucumber. Ele facilita muito o processo de testes do código da infra, e no final o relatório serve como documentação.. É uma real entrega de valor para o projeto de codificação da infra.

Vejamos alguns exemplos de códigos features:

Quando executamos o Cucumber, podemos ver os relatórios diretamente no console:

Há ainda outra maneira de fazer os testes: podemos deixar o Jenkins CI executá-los, gerando os relatórios em uma página HTML:

O que pensar de tudo isso?

Eu particularmente acho muito positivo reaproveitar tecnologias em outras áreas. Por que não usar em infra algo que foi feito para dev? Por que não usar em dev algo que foi feito para biologia? Vejo que o futuro do conhecimento é tornar-se cada vez mais multidisciplinar.

E você, o que acha? Quais tecnologias novas está usando em infra?

Conta pra gente aqui nos comentários!