Docker já faz parte de muitos projetos que tenho assistido e participado, e está cada vez mais no dia-a-dia de mais gente. Uma vez superada a curva de aprendizado, você rapidamente se vê com super poderes, compondo suas aplicações com os mais variados serviços, e eliminando assim a necessidade de construção e setup extenso de diversos desses serviços. Esse empoderamento lhe permite fazer muito mais, de forma muito mais profissional com menor custo¹.Então vemos um fenômeno curioso, o breakeven dos projetos Docker, onde meus orçamentos saem mais caros quando não uso docker, do que usando docker. É sobre isso que vou abordar hoje.

Desenvolvimento

Em termos práticos, subir um similar a um Amazon S3, ou mesmo SQL Server, Oracle, PostgreSQL, RabbitMQ, ELK Stack e milhares de outros recursos vira algo trivial. Com um script de inicialização, você tem um ambiente funcional, recriável, testável, durante os primeiros dias de desenvolvimento. Compartilhado? Não, espelhado em cada máquina, ao custo de executar um docker-compose up, ou no caso dos projetos com o Visual Studio, da mesma forma como você rodava seu projeto antes, com um F5. Embora o bootstrap seja um pouco maior na primeira vez, isso se torna imperceptível quando você sobre uma infraestrutura complexa, com todos os recursos necessários para rodar sua aplicação.

Em termos práticos, se você desenvolve com docker desde o início do projeto, e está familiarizado com a plataforma, você enriquece suas aplicações de forma a entregar muito mais resultado em um espaço de tempo muito menor. Isso acontece pois seus impedimentos a respeito de recursos ou problemas a respeito de recursos compartilhados deixam de existir. Todos os desenvolvedores possuem uma cópia do ambiente em suas máquinas, 100% funcional. Todo esse poder lhe permite chegar mais longe, com menos quebras, permite trabalhar de forma mais assertiva.

Implantação

Se você em desenvolvimento consegue utilizar uma infraestrutura declarativa, imagina o que é possível fazer quando se precisa implantar o projeto em qualquer lugar? Basta usar os mesmos artefatos, com ligeiras modificações. Onde está o ganho? No processo que antes poderia depender de outros times, uma documentação extensa, agora passa a ser formalizado via um script. AS-IS! Deixe de passar dias escrevendo um documento de implantação que simplesmente não funciona.

E se não usar docker?

Esse é o ponto que me chamou a atenção na última semana quando me pediram para realizar uma implantação sem docker em um projeto dockenizado. É simplesmente voltar no tempo e precisar alocar gente para perder tempo apertando botões.

Na prática eu preciso disponibilizar alguém que gere os pacotes, faça publish da aplicação, drop o banco e recrie a todo deploy, aplicando scripts de DDL e DML. O resultado é que custa mais caro. O que era automático e reproduzível, agora depende de conhecimento específico e precisa ser feito manualmente, gerando não somente os riscos básicos da execução manual de processos relativamente extensos.

Mas como pode custar mais caro?

O que antes era automático, agora depende do meu time. Embora não seja o caso pelo qual estou passando, poderia depender de um time de Ops para executar tarefas. Enfim, problemas do dia-a-dia de desenvolvimento que me remetem a um passado torpe e mais complicado.

O custo aumenta pois enquanto estou gerando um deploy, fazendo troubleshooting de algo que só acontece no ambiente de testes ou homologação, eu não estou produzindo. Quando estou abrindo chamados e produzindo documentação de implantação, não estou produzindo. Quando estou em reuniões explicando como faço e para que faço o que faço, não estou produzindo. E nesse ponto, estou falando de custo de pessoal, homem/hora. Mas há outros aspectos.

O tradoff de não ter automação é o custo de iteração com outros times. Seja para aguardar a disponibilização de um recursos, ou um conjunto de recursos. A dinâmica de ter de pré-provisionar recursos, de forma estática. 

Perder a automação significa perder tempo, interagir mais, demandar mais  de outras equipes e naturalmente ter mais dor de cabeça para entregar as mesmas coisas. Por isso não usar docker sai mais caro, pois eu perco a flexibilidade e a garantia de automação, na medida que preciso executar passos manuais. Automaticamente o escopo aumenta, consequentemente o custo por funcionalidade aumenta. Assim, minha capacidade produtiva é reduzida e posso perfeitamente cobrar mais caro por isso.

Conclusão

Há algum tempo atrás, usar docker era inimaginável, em outro momento um sonho distante, aos poucos foi se tornando algo mais palatável. Já faz algum tempo que considero um requisito para muitos projetos. Mas hoje constato que não usá-lo representa jogar dinheiro fora. É tão curioso quanto engraçado como as coisas mudam e como o jogo muda em pouquíssimo tempo. 

1) Se você desenvolve sob o Windows, entregar no mínimo um I5 com 8GB de RAM e SSD é o único requisito para ter um ambiente favorável para toda essas mudanças. Eu uso em viagem um I7 2ª Geração com 12 GB de RAM e SSD e consigo fazer coisas muito legais.