Este artigo devia inicialmente concentrar-se apenas no repo do Airbnb. Sua história, entretanto, continha traços de Quality Engineering.

Decidi então ter um prisma mais amplo na análise da evolução de seu repositório. A história deles é interessante pela forte ligação de sua engenharia em suporte e capacitador do negócio. A dimensão alcançada pela empresa torna-a útil para tirar aprendizagens.

A escolha de um mono ou multirepo é um assunto estruturante. Para uma start-up, a escolha do monorepo parece ser o padrão. Por outro lado, como a arquitetura do nosso repositório, código e de deployment deve mudar para apoiar o crescimento da empresa?

Então, vamos dar uma olhada na evolução do Airbnb do ponto de vista do Quality Engineering.

Segue a QE Unit para aceder a mais conteudo exclusivo de Quality Engineering.

Tudo começou com um monólito em monorepo, o Monorail

A Airbnb começou sua aventura com as primeiras linhas de código. A construção do seu produto focou em uma arquitetura monolítica armazenada em um monorepo. Pouco legacy deveria ser considerado para uma empresa que estava iniciando sua atividade.

A escolha da linguagem foi focada principalmente em Ruby on Rails, dando também nome ao seu repo, Monorail. Seu front-end começou no BackBone, mudando para React e Redux a partir de 2015. A base de código ainda era complementada por alguns serviços Java e mecanismos assíncronos no Resque.

Podemos notar um modelo centralizado por meio de um monólito em monorepo, e uma mudança mais rápida de tecnologias no front-end. Seus componentes tiveram que evoluir rapidamente para suportar os ciclos de iteração do negócio. A pipeline de suporte ao processo de desenvolvimento e de deploy era, portanto, estruturante.

Um pipeline que integra qualidade desde o inicio

As cadeias de integração de software são compostas de estágios relativamente padrão. Porém, seu desempenho depende da escolha e da qualidade das implementações realizadas.

A Airbnb garantiu seu processo de desenvolvimento aplicando práticas exigentes desde o início. Um mecanismo de pre-review semelhante ao pre-submit da Google garante uma revisão por um colega responsável pelo projeto. Uma vez que a mudança é validada, o build pode começar incluindo a execução dos testes do projeto.

O repositório principal encontra-se integrando as várias mudanças que passaram pelas primeiras etapas de validação. Em uma arquitetura monorepo monolítica, todo o sistema de Integração Contínua (CI) é acionado.

A implantação em diferentes ambientes pode ser seguida, acompanhada por testes manuais e automáticos. Esta é a oportunidade de executar testes exclusivamente relevantes em um ambiente integrado, como de performance ou de ponta a ponta.

Observe que a frase “All of CI is ran again” envolve uma construção completa, sem split-repo ou modelo de seleção de projeto para instalar. Com o tempo, a base de código cresce e se torna mais complexa, aumentando o tempo de construção. Veremos mais tarde que este é um assunto que a Airbnb teve que abordar.

Uma cultura de engenharia integrando as operações

A sensibilização ao risco é fundamental para equipas de engenharia, em particular desenvolvedores que podem facilmente se distanciar dela. Criar uma cultura de engenharia compartilhada é fundamental para o desempenho da organização.

A Airbnb desde cedo promoveu uma cultura transversal de entrega e de deployment. As equipas de infraestrutura fornecem aos desenvolvedores as ferramentas para ir ativar os serviços até a produção. Cada deploy é da responsabilidade do desenvolvedor em questão garantindo o acompanhamento, coordenação e possíveis ajustes. 

A Airbnb estimulou a iniciativa e a colaboração entre suas equipes. O suporte fora de hroas é, por exemplo, fornecida numa base voluntária. A coordenação das releases é realizada entre engenheiros, sem contar com uma equipe em silo de release management. Por defeito, as entregas são em horário laboral, podendo haver exceções acordadas.

Essas práticas estão a serviço de uma experiência de qualidade do cliente, exigindo operações robustas. Os mecanismos de ativação progressiva, feature flags e de reversão automática são essenciais para garantir a capacidade de resposta. Essas práticas, mesmo que simples em seu conceito, requerem uma verdadeira integração de ponta a ponta, mais complexa a realizar.

A divisão do monólito torna-se necessária para a empresa

Essas várias iterações e melhorias apoiaram o crescimento da Airbnb. Esse crescimento resultou em uma expansão de sua base de código, criando um problema a ser resolvido: a desaceleração de seus ciclos de iteração.

A crescente base de código retarda o pipeline de entrega em uma arquitetura monolítica, em monorepo, com um “All of CI is ran again”. Em última análise, foi a capacidade da Airbnb de melhorar a experiência do utilizador que foi afetada e, portanto, sua sobrevivência.

Havia então um bom motivo para adaptar seu sistema de desenvolvimento. Este é um ponto importante a ser observado porque esclarece o “Porquê”. Um porquê muitas vezes esquecido, fazendo com que as equipes de engenharia percam de vista os objetivos do negócio.

Em 2019, a Airbnb, portanto, revisou seu sistema geral de software, incluindo a arquitetura, o código e os processos de depoyment. A prioridade deles era ser capaz de apoiar o crescimento do Airbnb por meio de uma melhor experiência dos utilizadores na web e móvel, enquanto expandia a gama de serviços oferecidos.

A Airbnb, portanto, abordou cada problématica em seu contexto ao serviço da empresa e dos seus clientes. A sua transformação manteve os objetivos do negócio com a frase “não podemos impactar o crescimento da empresa”. 

Os contextos front-end e back-end foram isolados respectivamente no Hyperloop e Treehouse. Notará que os nomes escolhidos explicam as intenções de velocidade e robustez almejadas por cada um deles. Foi um primeiro nível de separação que permitiu evoluir posteriormente para uma divisão baseada em serviços na abordagem SOA. 

O front deve responder aos desafios da aceleração

O front-end se encontra em sintonia com seus desafios de aceleração, seus frameworks e equipas voltadas para a melhoria da experiência do utilizador. A Airbnb capitalizou sua cultura de compartilhamento e práticas de engenharia para essa transformação.

O objetivo do front-end era oferecer suporte a “loops mais rápidos, controlados e com valor”.

As chaves para as respostas estão no equilíbrio. Uma arquitetura MVC é escolhida para isolar cada um desses contextos. A comunicação na front-end é garantida por APIs padrão em JSON. Por fim, a organização e o código são organizados em Business Unit, para permitir deploys independentes.

O back deve ficar robusto e expandir em serviços

O back-office está evoluindo para dar suporte à espinha dorsal da empresa, que deve se expandir em oferta e serviços. A palavra “Treehouse” reflete claramente a floresta de serviços que a Airbnb queria construir. Java é a linguagem escolhida com ferramentas que facilitam a replicabilidade das aplicações a serem entregues, expostas principalmente em REST.

A comunicação entre os diferentes serviços foi estruturada pela distribuição do seu sistema. Os modelos de comunicação síncrona e assíncrona são definidos para atender aos diferentes casos de uso. Thrift é mantido para fornecer validação dos schemas, com um protocolo padrão e open source. Este tijolo permite-lhes garantir consistência de dados e trocas abstratas das escolhas tecnológicas.

O modelo assíncrono promove o desacoplamento e escalabilidade individual. Os componentes seguem uma abordagem orientada a eventos. A implementação da plataforma de eventos via Kafka integra um ecossistema de wrappers standards suportam o Thrift.

O desempenho do pipeline de desenvolvimento da Airbnb continuou a ser o foco principal. Daí a importância dado Developer Experience, ou DevEx.

Uma abordagem de plataforma ao suporte da DevEx

Acelerar a entrega de software requer uma otimização do processo de desenvolvimento. Os ciclos de iterações devem ser encurtados, em particular aqueles de produção de código, daí a importância da experiência de desenvolvimento.

Para isso, o uso de uma abordagem de plataforma permite industrializar os serviços valorizados pelos atores do sistema. No nosso caso, os desenvolvedores precisam ser capazes de navegar facilmente entre a criação do projeto, código, construção, teste e implantação.

A Airbnb investiu em vários etapas principais de seu processo:

• Um gerador de serviço fornecendo um projeto padrão com bibliotecas de infraestrutura, registrando e testando em segundos
• Externalização e automatização da configuração de projetos, deixando os desenvolvedores focados no código e menos na integração
• Pipelines de deployment standards atualizadas para suas várias stacks tecnológicas

A implementação desse ecosistema requer uma maturidade de engenheira de processos.  As equipes devem ser capazes de explicar sequências complexas para automatizá-las e industrializá-las.

Uma abordagem equilibrada para um Quality Engineering

A evolução do repositório é interessante em vista das outras evoluções implementadas na Airbnb. A escolha do repo é um dos elementos a considerar para construir um sistema de software poderoso, inserido num sistema maior.

A abordagem iterativa e orientada para os negócios da Airbnb permite assegurar a criação de valor com gestão dos riscos. Com base no exemplo da arquitetura, o monólito evoluiu gradualmente em face dos problemas reais de escalabilidade do negócio. Também encontramos o foco do negócio neste principle da equipa “Não podemos impactar o crescimento do negócio”. 

A Airbnb fez um investimento importante desde o início: sua cultura de engenharia. Uma cultura na qual eles se concentraram primeiramente nas operações e no cliente, ao mesmo tempo em que capacitaram as equipas. Essa base permitiu que desenvolvessem sua capacidade de obter ciclos de desenvolvimento acelerados.

Os resultados alcançados em automação, experiência de desenvolvimento e pipelines não são por acaso. Eles são o resultado de investimentos contínuos em seu sistema de engenharia, desde a organização até as operações.

Poucos atalhos são possíveis para desenvolver verdadeiras capacidades de Quality Engineering.

Referências

From Monorail to Monorepo: Airbnb’s journey into microservices – GitHub Universe 2018 https://www.youtube.com/watch?v=47VOcGGm6aU