Docker aos 10 anos – 3 coisas que acertamos, 3 coisas que erramos

Docker celebrou recentemente seu aniversário de 10 anos. Estou muito orgulhoso de tudo o que realizamos no Docker e das coisas incríveis que a equipe continua a alcançar hoje. Muito do que vemos ao nosso redor não existiria — arquiteturas baseadas em microsserviços, Kubernetes e muito mais — se os contêineres não se tornassem a nova unidade de consumo de computação. No entanto, tenho certeza de que quando você olha para trás, para as principais jornadas de transformação em sua vida, você vê tanto as coisas que acertou quanto as que não acertou. Isto é certamente verdade para mim. Então, sem mais delongas, vamos dar uma olhada em alguns.

3 coisas que acertamos

Containers Transformaria o mundo

Quando me juntei à Solomon Hykes para construir o DotCloud (mais tarde renomeado Docker) em 2010, rapidamente ficou claro que nunca seríamos capazes de concretizar nossa visão se apenas usássemos as ferramentas que existiam na época. DotCloud foi a primeira plataforma como serviço (PaaS) a oferecer suporte a qualquer idioma, enquanto Heroku e outros ainda estavam limitados a executar uma única pilha de idiomas. Uma limitação que enfrentamos imediatamente ao construir o DotCloud foi a falta de alternativas às máquinas virtuais (VMs) como o principal alicerce da infraestrutura. Embora as máquinas virtuais tenham representado um grande avanço em relação aos servidores bare-metal para o mundo da infraestrutura, elas não conseguiram oferecer a agilidade que precisávamos para migrar para a era nativa da nuvem. Precisávamos de algo leve o suficiente para isolar cada cliente em seu próprio namespace (computação, rede, armazenamento) e, ao mesmo tempo, agrupar centenas de aplicativos de desenvolvedor em uma única máquina. Foi o início do padrão de microsserviços. As VMs ainda eram o que há de mais moderno em termos de repetibilidade de infraestrutura, e os contêineres ainda eram uma tecnologia obscura restrita a alguns criadores (lembra quando o LXC exigiu um patch de kernel para anexar aos contêineres em execução?). Outros pensaram que a solução era colocar o VM em uma dieta sem carboidratos (lembra do JeOS?). Ficou claro para nós que, apesar de todos os desafios, valeu a pena o esforço para construir tudo em torno de contentores. Eventualmente, provamos que estávamos certos. Alguns anos depois, extraímos um componente central da plataforma DotCloud: o tempo de execução do contêiner. Nós o reescrevemos e abrimos o código-fonte. Foi a primeira versão do Docker. O objetivo inicial era que o Docker fosse o primeiro de muitos componentes abertos extraídos do DotCloud. O orquestrador de contêineres, a camada de rede, viria logo depois. Mas dada a atenção imediata que o Docker teve em seus primeiros dias, o cronograma mudou bastante.

Desenvolvedores, Desenvolvedores, Desenvolvedores

Steve Ballmer estava certo. Embora a VMware se concentrasse principalmente na solução de problemas de TI, percebemos desde o início que a maneira de mudar o mundo era focar nos desenvolvedores de software do mundo todo. Era preciso mudar a maneira como o software era construído, e não apenas operado, e isso significava começar primeiro pelas necessidades dos desenvolvedores. Como alguém que gerenciou milhares de desenvolvedores, estou perfeitamente ciente dos desafios que os desenvolvedores de software enfrentam todos os dias. Pode ser um dos trabalhos mais incríveis do mundo, cheio de problemas desafiadores e da satisfação de criar algo maravilhoso, mas também pode ser tedioso, frustrante e, às vezes, irritante. A infraestrutura e as ferramentas progrediram enormemente, mas o padrão também subiu. Nossa estrela norte no Docker era reduzir distrações e despesas gerais e permitir que os desenvolvedores fossem produtivos e colaborassem de maneira eficaz. Uma das primeiras aquisições (e integrações de produtos bem-sucedidas) foi um produto chamado “Fig”, que mais tarde se tornou Docker Compose, inicialmente desenvolvido por Ben Firshman, que agora é o fundador da Replicate, e Anand Prasad. Curiosamente, o modelo YAML implementado pela Fig (compose.yml) foi diretamente inspirado na primeira composição de serviço DotCloud (dotcloud.yml) que construímos anos antes. Embora tenhamos feito grandes progressos, ainda há muito a ser feito aqui, em particular indo além dos contêineres como a única unidade e orquestrando pipelines de contêineres. Essa é uma das razões pelas quais iniciamos o Dagger, um mecanismo de CI/CD programável que executa seus pipelines em contêineres, em 2018.

Investindo na construção de uma comunidade vibrante

Nós nos concentramos em construir uma grande comunidade primeiro. Acreditamos desde o primeiro dia que não conseguiríamos alcançar o que queríamos alcançar sozinhos. Foi necessário conquistar os corações e as mentes de um grande número de pessoas, e a chave para conseguir isso foi abrir mão da propriedade de tantas coisas. A DockerCon tornou-se o ponto de encontro para muitos dos melhores e mais brilhantes do nosso setor, um lugar onde se reuniam pessoas que compartilhavam uma visão comum de como as coisas poderiam evoluir e estavam dispostas a arregaçar as mangas e contribuir para construí-la. Nos primeiros dias do Docker, quando consideramos construir nós mesmos uma conferência de desenvolvedores, inicialmente parecia um sonho inalcançável. Algo que seja para grandes corporações ou para uma comunidade de desenvolvedores muito mais madura, como a PyCon. Mas quando organizamos a primeira DockerCon em São Francisco, em junho de 2014, e conseguimos reunir alguns desenvolvedores talentosos no mesmo lugar, ficou óbvio que era o início de algo muito maior que transformaria toda a empresa e a indústria. Esse legado permanece forte hoje nas dezenas (ou serão centenas agora?) de projetos e comunidades de código aberto que vemos em nosso setor. A Cloud Native Computing Foundation serve hoje como anfitriã de muitos deles, e muitos mais continuam a surgir a cada dia.

3 coisas que erramos

Adoção vs. Monetização

O outro lado de “comunidade em primeiro lugar” é que demorou muito para construirmos um negócio sustentável. Nossa tendência era fazer tudo abertamente, ouvir atentamente as necessidades da comunidade e tentar ao máximo atendê-las. A base inicial desta estratégia era que projetos de código aberto e soluções comerciais proprietárias poderiam coabitar perfeitamente e fazer parte da mesma jornada do cliente. Ainda acredito neste modelo hoje, mas é um equilíbrio complicado. Primeiro, você precisa aceitar que alguns colaboradores e usuários de código aberto nunca serão clientes. E está tudo bem, visto que eles participam da construção de uma comunidade forte, de uma marca forte, que depois contribui para o crescimento do funil comercial. Em segundo lugar, a arquitetura do produto deve permitir a construção de recursos de nível empresarial em uma base central de código aberto. Isso geralmente vem com um processo complexo de suporte e liberação. Definitivamente poderíamos ter sido um pouco mais estratégicos na forma como criamos o caminho para a construção de um negócio sólido. Eventualmente, chegamos lá, mas demorou muito e muitas vezes parecia assustador.

Cultura da equipe

Não definimos a cultura da equipe e os valores fundamentais desde o início. Foi definido posteriormente, seja pela comunidade, seja pelas pessoas que ingressaram na empresa posteriormente. Isso fez com que a cultura da nossa equipe mudasse drasticamente desde o início, sem que isso fosse óbvio a princípio. Nossa cultura acabou refletindo os estilos e valores de quem faz parte da comunidade e não o contrário. Um exemplo específico do que erramos foi ter dois grupos separados de pessoas em nossa empresa – um focado no código aberto e na comunidade, e o outro nos negócios. Este é um dos meus maiores arrependimentos. Tornou-se uma divisão cerebral em ferramentas internas, gerenciamento de produtos e projetos e, o mais importante, na própria cultura da equipe. É difícil equilibrar esses interesses conflitantes para qualquer pessoa, mas quando você divide os papéis, acaba com batalhas internas, inconsistências e debates abertos que nunca poderão ser resolvidos (todos estão certos do seu ponto de vista). Muitos dos melhores e mais brilhantes queriam trabalhar no lado comunitário, e muitas vezes havia um julgamento subtil (ou não tão subtil) do outro lado que surgia através de muitas das nossas colaborações. Às vezes parecia que tínhamos o “povo religioso do OSS” contra os “fabricantes de dinheiro empresarial”. Simplesmente não foi produtivo. Ter uma comunidade vibrante e um negócio sustentável requer equipas integradas onde todos lutam com as tensões inerentes que o nosso modelo cria naturalmente. Também cria uma cultura de equipe melhor. Não importa em que parte da empresa você esteja trabalhando, há apenas um conjunto de objetivos com os quais você deve se preocupar.

Recipientes como centro do universo

Ao dar um passo para trás, percebi que estávamos excessivamente apegados ao contêiner. Começamos a ver os contêineres como a solução central para a maioria dos problemas. Isso nos deixou cegos para todas as outras necessidades da cadeia de suprimentos de desenvolvimento. O Docker ganhou vida porque vimos que os contêineres iriam desbloquear todo um conjunto de mudanças necessárias em nossa indústria, mas à medida que as coisas progrediam, não nos concentramos nas necessidades subsequentes. Ao deixar tantas necessidades sem solução, criamos muito espaço para que outros intervenham e construam essas áreas. Por um lado, isso deixou uma grande oportunidade, mas também significou uma fragmentação da comunidade. Um exemplo de um dos desafios que não enfrentamos na Docker foi a automação geral da cadeia de fornecimento de software. Liberamos muito valor no final dessa cadeia de suprimentos, mas não atendemos adequadamente às necessidades dos desenvolvedores enquanto eles codificavam e colaboravam, e hoje o CI/CD continua uma bagunça. Mas é uma bagunça solucionável. Como muitos outros daquela época, enquanto Solomon Hykes, Andrea Luzzardi e eu refletimos sobre o nosso tempo na Docker, percebemos que a nossa revolução continua incompleta e, assim, encontrámos a nossa missão para a próxima década.

Junte-se a nós na KubeCon + CloudNativeCon North America em novembro. 6-9 em Chicago para saber mais sobre Kubernetes e o ecossistema nativo da nuvem.

A postagem Docker às 10 — 3 coisas que acertamos, 3 coisas que acertamos apareceu pela primeira vez em The New Stack.