4 anos de tsuru

Tudo começou há mais de 4 anos atrás, quando a globo.com formou uma equipe com o objetivo de criar uma ferramenta para diminuir o tempo que uma aplicação leva para entrar em produção.

O problema

Naquela época, a maior parte das equipes fazia um deploy a cada duas semanas, não havia uma forma padronizada para deploy e provisionamento das máquinas das aplicações. Isso atrapalhava o cronograma e adicionava um custo no desenvolvimento dos projetos.

Cavalos mais rápidos

Eu acreditava que não era necessário fazer uma ferramenta para permitir que o deploy fosse feito a qualquer momento de forma fácil e simples.

Eu pensava que padronizar os scripts de deploy seria o suficiente e achava também que não conseguiríamos convencer as pessoas a mudarem a forma de fazer release de aplicações. E que fazer isso não valia a pena.

Eu estava errado…

Naquela época cada time tinha uma aplicação em produção, elas eram monolíticas e um dos motivos disso era o deploy ser custoso. Quando o deploy tornou-se algo rápido e simples foi natural as equipes criarem projetos menores. Apenas com “scripts mais rápidos” seria insano controlar a quantidade de aplicações que temos hoje em produção (~800 apps).

Premissas

Em março de 2012 começamos usando um PaaS que existia na época, mas ele não suportava várias linguagens de programação que usávamos e tinha vários problemas com performance. Enviamos vários “pull requests” para esse projeto adicionando suporte a mais linguagens de programação e adicionando integração com CloudStack mas nenhum “pull request” foi aceito. Esse PaaS tinha parceiros comerciais e as mudanças enviadas não faziam parte do objetivo do projeto. O código era aberto, mas o projeto não.

Resolvemos então criar uma ferramenta com algumas premissas como alicerce:

  • open source
  • extensível
  • escalável
  • simplicidade
  • multi linguagem
  • alta disponibilidade

A ferramenta

Usamos as idéias boas do PaaS que estávamos usando, como a simplicidade da command line interface, e começamos a fazer os componentes internos.

O tsuru do início era bem diferente do que existe hoje.

Para conseguir ter o mínimo funcionando no menor tempo possível, começamos utilizando o Juju. Usando as fórmulas genéricas do Juju (charms) foi simples provisionar aplicações de diferentes plataformas.

Mas com o Juju cada unidade de processamento rodava em uma máquina virtual. A cada deploy as dependências e configurações das unidades eram alteradas uma a uma, e para adicionar uma unidade nova era necessário criar uma máquina virtual nova e replicar as configurações das unidades equivalentes. Os deploys não eram “reproduzíveis” e adicionar unidades era uma operação lenta.

Devido a esses problemas começamos a pensar em uma forma mais rápida e consistente de provisionar as aplicações. Existiam algumas alternativas e entre elas usar linux containers foi a melhor opção, o lxc possibilita o isolamento lógico entre as aplicações, mas compartilha o mesmo kernel, tornando o “boot” de uma aplicação bem rápido. Mas para ir por esse caminho teríamos que resolver vários problemas, como gerenciamento de redes e de disco dos containers. Felizmente nessa época nasceu o Docker.

O Docker trouxe um ecossistema que simplificou o uso de containers, permitindo a criação de containers baseado em imagens e um repositório para armazenar e distribuir essas imagens. Como o Docker resolvia todos os problemas foi natural a escolha dele como ferramenta para provisionar as aplicações.

E assim nasceu o tsuru da forma como ele existe hoje, tornando possível colocar uma aplicação em produção em minutos:

A cultura

Uma das coisas que mais gosto do tsuru é a forma como a equipe do projeto trabalha. Ela tem como prioridade o produto/cliente e as pessoas que trabalham para fazer o projeto ter sucesso.

Com isso a equipe sempre manteve os usuários do tsuru próximos, conseguindo organizar e priorizar as features para resolver o que era mais importante para o cliente, criando assim um projeto que as pessoas gostassem de usar.

Colocar as primeiras aplicações em produção com tsuru foi difícil, a maioria não estavam preparadas para um ambiente baseado em cloud computing. Antes do tsuru eram utilizadas máquinas físicas com uma quantidade de memória e processadores grande, escrever aplicações para rodar em muitas máquinas não era algo comum. Mostrar como desenvolver uma aplicação para ter mais de 100 unidades dessas aplicações rodando foi um dos maiores desafios quando as equipes começaram a usar o tsuru.

Realizamos vários workshops mostrando como cada equipe poderia usar o tsuru, falando sobre 12 factor e sobre as vantagens de ter uma arquitetura escalável.

Outro desafio foi operar as aplicações. Criamos várias features para facilitar a visualização do que está acontecendo com a aplicação como dashboard com métricas, agregação de logs e automatizamos alguns procedimentos de recuperação das aplicações. No tsuru quando uma unidade fica indisponível outra é criada automaticamente para substituir a que está com problemas.

Em produção e o lançamento do 1.0

No último trimestre de 2013 entrou o primeiro projeto em produção e hoje vários projetos como o cartola, globoplay e globosat play usam tsuru.

Com mais de 3 anos em produção na globo.com o tsuru possibilita mais de 300 deploys por dia, desde aplicaçōes internas até aplicaçōes com picos de 300k de acessos simultâneos.

Há alguns meses lançamos a versão 1.0.0, com ela versionamos, estabilizamos e padronizamos a HTTP API do tsuru.

Foi uma longa jornada. Mas após anos em produção, com aplicações com mais de 300k de usuários simultâneos, já era hora de estabilizar a API. dando a segurança que a API 1.0 não mudará e as mudanças serão lançadas em novas versões da API.

O futuro

Quando começamos a usar Docker não existia nenhum orquestrador de containers e hoje existem vários softwares open source que resolvem muito bem esse problema como o Mesos/Marathon, Kubernetes e Docker Swarm. Começar a usar esses orquestradores em vez de manter um orquestrador próprio é o próximo objetivo e após isso o próximo passo é ter suporte a filesystem persistente e roteamento tcp, com isso tornando possível o deploy de aplicações como Spark, Tensorflow e etc.

Mas, na minha opinião o maior desafio do tsuru é tornar a sua instalação e atualização tão simples quanto subir uma aplicação no tsuru.

Isso já está á caminho.

Se você curtiu conhecer a história do tsuru e quiser saber mais sobre o projeto ou contribuir com o projeto, você pode olhar nosso repositório no github ou conversar com a gente no gitter.