Desafio
Em 2016, a Booking.com migrou para uma plataforma OpenShift, que deu aos desenvolvedores de produto acesso mais rápido à infraestrutura. Mas como o Kubernetes estava abstraído dos desenvolvedores, a equipe de infraestrutura se tornou um "gargalo de conhecimento" quando surgiam desafios. Tentar escalonar esse suporte não era sustentável.
Solução
Após um ano operando o OpenShift, a equipe de plataforma decidiu construir sua própria plataforma Kubernetes vanilla—e pedir aos desenvolvedores que aprendessem um pouco de Kubernetes para usá-la. "Esta não é uma plataforma mágica", diz Ben Tyler, Desenvolvedor Principal, B Platform Track. "Não estamos afirmando que você pode usá-la de olhos fechados. Os desenvolvedores precisam aprender um pouco, e vamos fazer tudo o que pudermos para garantir que eles tenham acesso a esse conhecimento."
Impacto
Apesar da curva de aprendizado, houve um grande aumento na adoção da nova plataforma Kubernetes. Antes dos contêineres, criar um novo serviço podia levar alguns dias se os desenvolvedores entendessem de Puppet, ou semanas se não entendessem. Na nova plataforma, pode levar apenas 10 minutos. Cerca de 500 novos serviços foram construídos na plataforma nos primeiros 8 meses.
Impressionada com o que a tecnologia oferecia, mas precisando de funcionalidades empresariais em sua escala—o site processa mais de 1,5 milhão de reservas de quarto-noite por dia em média—a equipe decidiu adotar uma plataforma OpenShift.
Esta plataforma, que foi envolvida em uma interface CLI de alto nível no estilo Heroku, "definitivamente foi popular entre nossos desenvolvedores de produto", diz Ben Tyler, Desenvolvedor Principal, B Platform Track. "Demos a eles acesso mais rápido à infraestrutura."
Mas, ele acrescenta, "sempre que algo saía um pouco dos trilhos, os desenvolvedores não tinham nenhum dos conhecimentos necessários para se sustentarem."
E após um ano operando essa plataforma, a equipe de infraestrutura descobriu que havia se tornado "um gargalo de conhecimento", diz ele. "A maioria dos desenvolvedores que a usavam não sabia que era Kubernetes por baixo. Uma falha de aplicação e uma falha de plataforma pareciam ambas falhas daquela ferramenta no estilo Heroku."
Escalonar o suporte necessário não parecia viável ou sustentável, então a equipe de plataforma precisava de uma nova solução. O entendimento de Kubernetes que eles haviam adquirido operando a plataforma OpenShift deu-lhes confiança para construir uma plataforma Kubernetes vanilla própria e personalizá-la para atender às necessidades da empresa.
"Para entrar no cenário, o OpenShift foi definitivamente muito útil", diz Eduard Iacoboaia, Administrador de Sistema Sênior, B Platform Track. "Ele mostra o que a tecnologia pode fazer e facilita seu uso. Depois de passarmos algum tempo nele, percebemos que precisávamos aprender melhor o Kubernetes para utilizar todo o seu potencial. Naquele momento, fizemos a mudança para construir nossa própria plataforma Kubernetes. Definitivamente nos beneficiamos a longo prazo por darmos esse passo e investirmos o tempo em adquirir esse conhecimento."
A equipe de Iacoboaia havia personalizado muitas ferramentas do OpenShift para fazê-las funcionar na Booking.com, e "esses pontos de integração eram meio frágeis", diz ele. "Passamos muito mais tempo entendendo todos os componentes do Kubernetes, como eles funcionam, como interagem entre si." Essa pesquisa levou a equipe a mudar dos playbooks Ansible embutidos do OpenShift para implantações com Puppet, que são usadas para o resto da infraestrutura da Booking. A camada de gerenciamento também foi movida de dentro do cluster para servidores dedicados, já que a empresa opera dezenas de milhares de servidores dedicados e uma grande infraestrutura para executar aplicações em servidores dedicados. (A Booking executa Kubernetes em múltiplos clusters em múltiplos data centers nas várias regiões onde tem computação.) "Decidimos mantê-lo o mais simples possível e também usar as ferramentas que conhecemos melhor", diz Iacoboaia.
A outra grande mudança foi que os engenheiros de produto teriam que aprender Kubernetes para fazer o onboarding. "Esta não é uma plataforma mágica", diz Tyler. "Não estamos afirmando que você pode usá-la de olhos fechados. Os desenvolvedores precisam aprender um pouco, e vamos fazer tudo o que pudermos para garantir que eles tenham acesso a esse conhecimento." Isso inclui treinamentos, posts de blog, vídeos e cursos da Udemy.
Apesar da curva de aprendizado, houve um grande aumento na adoção da nova plataforma Kubernetes. "Acho que a razão pela qual conseguimos fechar esse acordo com sucesso é que não estamos pedindo a eles para aprender um sistema de aplicação proprietário", diz Tyler. "Estamos pedindo a eles que aprendam algo que é código aberto, onde o conhecimento é transferível. Eles estão investindo em suas próprias carreiras ao aprender Kubernetes."
Um sinal claro de que essa estratégia foi um sucesso é que no canal de suporte, quando os usuários têm dúvidas, outros engenheiros de produto estão entrando para responder. "Eu não tinha visto esse tipo de engajamento de comunidade em torno de um produto de plataforma específico internamente antes", diz Tyler. "Ajuda muito que seja visivelmente um padrão do ecossistema fora da empresa, então as pessoas sentem valor em investir nesse conhecimento e compartilhá-lo com outros, o que é realmente, realmente poderoso."
Há outras evidências quantificáveis também: Antes dos contêineres, criar um novo serviço podia levar alguns dias se os desenvolvedores entendessem de Puppet, ou semanas se não entendessem. Na nova plataforma, leva 10 minutos. "Temos um tutorial. Você segue o tutorial. Seu código está rodando. Então, é hora da lógica de negócio", diz Tyler. "O tempo para obter acesso aos recursos é reduzido enormemente." Cerca de 500 novos serviços foram construídos nos primeiros 8 meses na plataforma, com centenas de releases por dia.
A plataforma oferece diferentes "camadas de contratos, por assim dizer", diz Tyler. "Na base, é apenas Kubernetes. Se você é um usuário avançado de Kubernetes, aqui está uma API Kubernetes, exatamente como você obtém do GKE ou AKS. Estamos tentando ser um provedor nesse mesmo nível. Mas todo o nosso trabalho dentro da empresa é ser um valor agregado maior do que apenas infraestrutura vanilla, então fornecemos um conjunto de imagens base para nossas principais stacks, Perl e Java."
E "à medida que nossos usuários aprendem Kubernetes e se tornam usuários mais sofisticados de Kubernetes, eles nos pressionam para fornecer uma experiência Kubernetes melhor e mais nativa, o que é ótimo", diz Tyler. "É uma dinâmica super saudável."
A plataforma também inclui outras tecnologias da CNCF, como Envoy, Helm e Prometheus. A maior parte do tráfego de serviço crítico da Booking.com é roteada através do Envoy, e o Prometheus é usado principalmente para monitorar componentes de infraestrutura. O Helm é consumido como um padrão de empacotamento. A equipe também desenvolveu e tornou código aberto o Shipper, uma extensão para Kubernetes para adicionar estratégias de implantação mais complexas e orquestração multi-cluster.
Para ter certeza, houve discussões internas sobre a sabedoria de construir uma plataforma Kubernetes do zero. "Esta não é realmente nossa competência principal—Kubernetes e viagens, eles estão meio distantes, certo?" diz Tyler. "Mas fizemos algumas apostas em componentes da CNCF que funcionaram muito bem para nós. Envoy e Kubernetes, em particular, têm sido realmente benéficos para nossa organização. Conseguimos personalizá-los, seja porque podíamos olhar o código-fonte ou porque eles tinham pontos de extensão, e conseguimos obter valor deles muito rapidamente sem precisar mudar nenhum paradigma internamente."