Como os containers estão revolucionando o desenvolvimento de aplicativos

O atual momento no desenvolvimento de aplicativos deve muito ao crescimento do conceito DevOps e das ferramentas de automação viabilizadas por ele. Em vez de apenas escrever código, os desenvolvedores agora precisam pensar em termos das ferramentas que estão usando – e como elas se encaixam em um fluxo desde a ideia inicial para o “go live” do aplicativo.

O container é uma das mais importantes novas ferramentas neste novo fluxo de trabalho. Tecnologias como o Docker nos permitem capturar serviços essenciais e os abstrair da camada de infraestrutura subjacente. É uma abordagem que nos permite repensar como podemos fazer o deploy de aplicativos e ao mesmo tempo tirar proveito das infraestruturas de nuvem.

Pacote completo

docker1Em um evento recente da Amazon Web Services em Londres, um usuário do serviço de nuvem descreveu como sua equipe tratava as atualizações de aplicativos ao não operar uma única alteração, mas transformando a saída de um processo em construção em uma infraestrutura completa.

Somente quando essa infraestrutura fosse implementada e testada ele alteraria o DNS para torná-la um sistema “live”. Entre outras coisas, essa abordagem permite tratar a antiga infraestrutura virtual como um backup durante os primeiros dias de operação antes de ser excluída.

A ideia de pensar a infraestrutura à parte no desenvolvimento pode parecer estranha à primeira vista, mas quando consideramos a implementação e sobretudo a economia da nuvem, não é muito mais oneroso do que fazer deploys de atualizações. Isso também significa que estamos fazendo o deploy de um estado conhecido, e não a atualização de servidores e serviços que podem ter sido operados por algum tempo, e que podem ter tido o sistema operacional ou software atualizados automaticamente.

Não há necessidade de investir em hardware. Podemos usar a mesma plataforma em nuvem para desenvolvimento, teste e produção: tudo o que precisamos é de redes virtuais separadas para cada ambiente, juntamente com o controle apropriado de acesso. Somos até mesmo capazes de trabalhar com produção de dados na fase de desenvolvimento, simplesmente clonando armazenamento quando precisamos de dados “limpos”.

Containers abrangentes

A “containerização” de aplicativos no Docker facilita a abstração de elementos-chave da aplicação na infraestrutura. Enquanto faz muito sentido às boas práticas DevOps tratar o software dessa forma, também tornamos mais fácil escalar serviços de acordo com a evolução das demandas. Envolver uma implementação Node.js/Seneca de microserviço em um container torna possível implementar rapidamente novas instâncias, seja no mesmo host ou em novas máquinas virtuais, conforme a necessidade.

Essa abordagem tem conduzido a um modelo DevOps interessante: a do container idempotente. Em vez de tornar um aplicativo ou serviço o endpoint de uma compilação, é possível compilar containers que envolvem aplicativos, serviços e todas as suas dependências. Toda vez que uma alteração for feita, um novo container é compilado; e é possível testar e fazer o deploy do container como um todo, não como um elemento individual. É uma abordagem que faz muito sentido, eliminando inclusive algum risco no processo de desenvolvimento. Em um modelo de compilação tradicional, é fácil pegar um atalho e apenas testar as alterações, mas não o todo.

Uma vez que um container tenha sido compilado e implementado, ele não deve mudar até que um novo passe pelo deploy. Como um container é uma sandbox, a única maneira de interagir com seu conteúdo é através de APIs ou (para um usuário final) através de qualquer interface oferecida. Isso o torna uma abstração ideal para um microserviço, onde APIs de serviços são os únicos pontos de contato. Com definições de APIs melhor pensadas como um contrato entre equipes DevOps, containers em execução em menores instâncias de servidor, como CoreOS ou o novo Nano Server da Microsoft, tornam-se um bloco padrão de infraestrutura.

Seguindo o fluxo

Então não é nenhuma surpresa observar que o Jenkins construiu um pipeline de ferramentas adicionando suporte ao Docker. Jenkins tornou-se uma ferramenta de construção padrão em muitos processos de compilação. Sua arquitetura modular customizável facilita o ajuste para seu fluxo de trabalho específico, e integra com ferramentas de controle de origem e com plataformas de desenvolvimento e testes.

De acordo com o criador do projeto Jenkins, Kohsuke Kawaguchi, adicionar suporte Docker faz muito sentido: “induz a demanda pelo Jenkins, tratando o Docker como um formato de pacote executável. Você pode compilar e empacotar em um sistema binário, executá-lo e descartá-lo quando não for mais necessário”.

Enquanto o formato de arquivo do Docker é a língua franca atual no mundo dos containers, é bom saber do patrocínio de desenvolvimento por parte da Linux Foundation a um container open source de formato comum. Esta iniciativa aproximou muitos desenvolvedores de container e seus fornecedores, incluindo empresas como a Microsoft. Com um formato de container comum com o apoio de toda a indústria, será possível entregar containers para vários provedores de nuvem (privadas e públicas) a partir do mesmo processo de criação.

Um container de formato comum não irá resolver todos os problemas associados ao gerenciamento de diferentes definições de infraestrutura de nuvem. Mas irá certamente abrir caminho para facilitar o transporte de serviços entre, digamos, Azure e AWS ou entre OpenStack e Google Cloud. Da mesma forma, com a infraestrutura descrita pelo Puppet ou Chef e gerida em repositórios Git, também será possível desenvolver uma camada de tradução que leva uma VM genérica e uma descrição de rede para uma aplicação, e entrega uma orquestração apropriada a qualquer fornecedor de nuvem que o usuário possua.

A ideia de que tudo é código não é nova, mas tem se tornado uma realidade mais plausível com o argumento DevOps. Com ferramentas como o Docker e Jenkins trabalhando juntas, começamos a ver como podem funcionar na prática.

 

Fonte: DZone

21