Risco x Recompensa: um guia para entender os contêineres de software

Aqueles de nós que têm idade suficiente podem se lembrar de um dia em que o software foi entregue principalmente pela mídia física. A disseminação da internet de banda larga e dos smartphones nos levou à era do serviço da web – software hospedado na nuvem acessado por clientes de usuários, como navegadores e aplicativos.

Não muito tempo atrás, os aplicativos da Web eram executados diretamente em máquinas físicas em data centers privados. Para facilitar o gerenciamento, esses aplicativos geralmente eram monolíticos - um único servidor grande conteria todo o código de back-end e o banco de dados. Agora, serviços de hospedagem na web como a Amazon e a disseminação da tecnologia de hipervisor mudaram tudo isso. Graças ao Amazon Web Services (AWS) e ferramentas como o VirtualBox, ficou fácil empacotar um sistema operacional inteiro em um único arquivo.

Usando serviços como o EC2, tornou-se fácil empacotar imagens de máquina e encadear conjuntos de servidores virtuais. Junto veio o paradigma de microsserviços – uma abordagem para arquitetura de software em que grandes aplicativos monolíticos são divididos em serviços menores focados que fazem uma coisa bem. Em geral, essa abordagem permite dimensionamento e desenvolvimento de recursos mais fáceis, pois os gargalos são mais rápidos de encontrar e as alterações do sistema mais fáceis de isolar.

Animais de estimação para gado

Tornei-me engenheiro de infraestrutura bem no auge dessa tendência. Lembro-me de construir meu primeiro ambiente de produção na Amazon usando uma série de scripts bash. Os servidores eram como animais de estimação para mim. Eu dei a cada um deles nomes fofos. Eu os monitorei cuidadosamente. Respondi aos alertas rapidamente e os mantive saudáveis. Tratei esses casos com amor e carinho porque era doloroso tentar substituí-los — como um animal de estimação amado.

Junto veio o Chef, uma ferramenta de gerenciamento de configuração, e quase imediatamente minha vida ficou mais fácil. Com ferramentas como Chef e Puppet, você pode eliminar a maior parte da dor manual associada ao gerenciamento de um sistema em nuvem. Você pode usar sua construção de “ambientes” para separar os servidores de desenvolvimento, preparação e produção. Você pode usar suas “bolsas de dados” e “funções” para definir parâmetros de configuração e enviar conjuntos de alterações. Agora, todos os meus servidores “de estimação” se formaram na escola de obediência.

Então, em 2013, veio o Docker, e uma nova era começou: a era do software como gado (desculpas a qualquer vegano na platéia). O paradigma do contêiner é de orquestração, não de gerenciamento de configuração. Ferramentas como Kubernetes, Docker Compose e Marathon se concentram em mover imagens predefinidas em vez de ajustar valores de configuração em instâncias em execução. A infraestrutura é imutável; quando um contêiner estraga, não tentamos consertá-lo — atiramos na cabeça dele e o substituímos. Nós nos preocupamos mais com a saúde do rebanho do que com os animais individualmente. Não damos mais nomes fofos aos nossos servidores.

As recompensas

Os contêineres facilitam muitas coisas. Eles permitem que as empresas se concentrem mais em seu próprio molho especial. As equipes de tecnologia podem se preocupar menos com o gerenciamento de infraestrutura e configuração e se preocupar principalmente com o código do aplicativo. As empresas podem dar um passo adiante e usar serviços gerenciados para coisas como MySQL, Cassandra, Kafka ou Redis para não ter que lidar com a camada de dados. Existem várias startups que oferecem serviços de aprendizado de máquina “plug and play”, bem como para permitir que as empresas façam análises sofisticadas sem se preocupar com a infraestrutura. Essas tendências culminaram no modelo sem servidor – uma abordagem de arquitetura de software que permite que as equipes lancem software sem gerenciar uma única VM ou contêiner. Serviços da AWS como S3, Lambda, Kinesis e Dynamo tornam isso possível. Então, para estender a analogia, passamos de animais de estimação para gado para algum tipo de serviço de animais sob demanda.

Tudo isso é muito legal. É uma loucura vivermos em uma época em que uma criança de doze anos pode criar um sistema de software sofisticado com apenas alguns cliques. Devemos lembrar que, não muito tempo atrás, isso era impossível. Apenas alguns presidentes dos EUA atrás, a mídia física era o padrão e apenas as grandes empresas tinham os meios para fabricar e distribuir software. Correções de bugs eram um luxo. Agora, aquele garoto de doze anos pode criar uma conta da AWS e disponibilizar seu software para o mundo inteiro. Se houver um bug, alguém o bugará no Slack e, em alguns minutos, uma correção será lançada para todos os usuários.

Os riscos

Muito, muito legal, mas não sem seu preço – a dependência de provedores de nuvem como a Amazon significa dependência de grandes corporações e tecnologias proprietárias. Se Richard Stallman e Edward Snowden não fizeram você se preocupar com essas coisas, o recente desastre com o Facebook certamente deveria ter feito.

Uma maior abstração do hardware também traz o risco de menos transparência e controle. Quando algo quebra em um sistema executando centenas de contêineres, temos que esperar que a falha borbulhe em algum lugar que possamos detectar. Se o problema for com o sistema operacional do host ou hardware subjacente, pode ser difícil determinar. Uma interrupção que poderia ter sido resolvida em 20 minutos usando VMs pode levar horas ou dias para ser resolvida com contêineres se você não tiver a instrumentação correta.

Não é apenas com as falhas que precisamos nos preocupar quando se trata de coisas como o Docker. Há também o problema da segurança. Seja qual for a plataforma de contêiner que usamos, temos que confiar que não há backdoors ou vulnerabilidades de segurança não reveladas. O uso de plataformas de código aberto também não é garantia de segurança. Se dependermos de imagens de contêiner de terceiros para partes de nosso sistema, podemos ficar vulneráveis.

Embrulhar

O paradigma da pecuária é atraente por várias razões, mas também tem suas desvantagens. Antes de correr para contentorizar toda a pilha, as equipes de tecnologia precisam pensar se é ou não a escolha certa e garantir que possam mitigar os efeitos negativos.

Pessoalmente, adoro trabalhar com contêineres. Estou animado para ver onde as coisas vão nos próximos dez anos à medida que surgem novas plataformas e paradigmas. No entanto, como ex-consultor de segurança, sou cauteloso o suficiente para saber que tudo tem um preço. Cabe aos engenheiros permanecerem vigilantes para garantir que não abrimos mão de nossa autonomia como usuários e desenvolvedores. Mesmo o fluxo de trabalho de CD/CI mais fácil do mundo não valeria o custo.