O estado da tecnologia na Olist

Desde janeiro deste ano assumi o desafio de cuidar do setor de tecnologia da Olist e pretendo usar este artigo para contar sobre os problemas que enfrentamos, as dificuldades do dia-a-dia e os projetos incríveis que estamos desenvolvendo para o futuro.

O objetivo é mostrar que estamos cientes das insatisfações e dos problemas que nossos clientes enfrentam todos os dias com nossa plataforma e dizer que estamos fazendo muitas coisas para resolver tudo isso.

Estamos contratando!
Gostaria de fazer parte da equipe de desenvolvimento Olist? Participe do nosso processo seletivo.

Um pouco de história pessoal

Até dezembro de 2015 eu trabalhava como líder técnico de uma empresa de tecnologia que tinha uma das melhores equipes técnicas que vi ao longo dos meus (quase) 30 anos na área de TI. Todos os programadores da minha equipe e vários programadores de outras equipes eram extremamente qualificados e apaixonados pelo trabalho.

Ter pessoas assim é essencial para se ter sucesso em um empreendimento, mas ter indivíduos incríveis não é o suficiente. A coisa só funcionava bem porque a empresa conseguiu criar times com essas pessoas e implantou um bons processos de trabalho que permitiam a todos trabalhar com tranquilidade.

Em uma nota lateral é importante dizer que na minha equipe o trabalho remoto era a regra e criamos uma equipe distribuída que funcionava tão bem (melhor?) quanto as equipes que trabalhavam no escritório de São Paulo. Eu mesmo trabalhava todos os dias na minha casa em Curitiba. Saia eventualmente para um co-working apenas para não ficar completamente isolado das pessoas.

Por questões alheias à tecnologia e à essas equipes a empresa começou a ter problemas financeiros graves e a perda dessas pessoas foi inevitável.

Bem nessa época um amigo me chamou no Facebook:

Flaaa meu guri (sic)
Posso te apresentar para o Tiago Dalvi da Olist?
Ele tá procurando um dev senior com experiência em ecommerce. Com certeza vc poderia indicar alguém (se a vaga não lhe interessar tb)
O Tiago é simplesmente sensacional.
Recomento (sic) sem nenhum tipo de restrição.
Conheço ele desde a faculdade e até hoje é um dos meus mentores, quem vou sempre bater um papo quando preciso tomar alguma decisão importante.

Eu sempre tento ajudar empresários que estão começando as suas startups porque acredito que isso faz muito bem para o mercado como um todo. Então fui lá conversar com o Tiago.

Para conversar com esses empresários sempre faço uma pesquisa preliminar sobre a empresa, o produto, o mercado, etc. Faço isso para poder entender melhor o negócio e poder contribuir de forma mais efetiva.

Confesso que quando li sobre a Olist pensei: “Que idéia f*da! Porque eu não tive ela antes?”. E, modéstia à parte, quando eu penso “porque não tive essa idéia antes?” é porque a coisa é boa mesmo.

Então fui lá para o bate-papo munido com várias sugestões e com algumas indicações de profissionais para sugerir para ele. Apesar das dificuldades da empresa onde eu estava, o emprego era bom, o trabalho era ótimo, a equipe onde eu estava era perfeita e o trabalho era em casa! Não pretendia sair.

Conversa vai, conversa vem, e eu percebi que a Olist era ainda melhor do que eu tinha lido e que o Tiago era ainda mais legal do que o meu amigo havia comentado. Mas ele tinha um problema sério pra resolver na área de tecnologia. E que problema…

Empresa de tecnologia “sem tecnologia”

A Olist “entrou no ar” como Olist em meados de fevereiro de 2015. A empresa toda tinha cerca de 7 pessoas sendo que 2 delas eram desenvolvedores de software.

Esses programadores começaram a desenvolver o sistema da Olist em novembro de 2014. A primeira versão do sistema da Olist foi desenvolvida em apenas 4 meses! Com apenas 2 desenvolvedores! E o mais impressionante: 2 desenvolvedores com pouca experiência profissional!

Analisando as circunstâncias onde o sistema da Olist foi desenvonvolvido é impressionante ver que ele funciona! Funciona “aos trancos e barrancos” mas funciona.

A empresa começou a operar e começou a crescer… e crescer… e crescer… até chegar na Black Friday em outubro/novembro de 2015 quando recordes inimagináveis de vendas foram batidos.

Nesse momento o sistema, que foi desenvolvido sem testes automatizados, sem processos, sem boas práticas de engenharia de software e por programadores inexperientes começou a apresentar fadiga. Os problemas proliferaram e a coisa toda começou a sair um pouco do controle. Era o momento de estruturar a tecnologia da Olist.

Nessa etapa da vida da empresa as medidas necessárias para fazer essa reestruturação começaram a ser adotadas. Mais desenvolvedores foram contratados, um gestor foi colocado para organizar mais os processos, a empresa tomou mais conhecimento sobre o funcionamento do negócio, etc.

Mas alguma coisa acabou não funcionando e aos poucos (e por razões diversas) a equipe de tecnologia foi se desfazendo. As pessoas foram saindo e só um programador ficou para “passar o bastão” para a próxima equipe.

Foi nesse momento que a minha conversa com o Tiago aconteceu e ele então me convidou para assumir esse desafio. Confesso que tive muitas dúvidas, mas acabei topando.

Em janeiro de 2016 eu iniciava a minha jornada na Olist com um objetivo: fazer a Olist se tornar referência em tecnologia.

O plano de ação

Nos poucos dias em que me despedia do antigo trabalho e já ia pro escritório da Olist eu comecei a desenhar um plano (bem óbvio) de ação que consistia em:

• Compreender o sistema (aproveitando a presença do programador remanescente) e compreender as regras do negócio
• Levantar os problemas e dificuldades
• Montar um plano para evoluir o produto
• Montar uma equipe e definir processos de trabalho

Depois de uma análise rápida desses itens eu cheguei à conclusão que quase todas as “dores do crescimento” que a empresa estava sofrendo eram causados por um sistema (software) que já não suportava mais o tamanho do negócio. Resolver esse problema era a prioridade máxima.

Para resolver problemas de software, geralmente, temos 2 alternativas: evoluir o sistema atual ou reescreve-lo. Ambas possuem prós e contras.

Evolução

A opção que escolhi inicialmente era a de evoluir o sistema e corrigir os seus problemas. Essa abordagem costuma ser a mais segura pois mantem o sistema em funcionamento (sem parar o negócio) e conserva todo o aprendizado prévio (na forma de regras de negócio e problemas resolvidos).

O problema que encontramos nessa abordagem foi que todas as mudanças que a gente fazia no sentido de corrigir problemas ou de implementar novas funcionalidades geravam transtornos intermináveis para nossos clientes (chamamos eles de Sellers) e afetavam toda a nossa operação.

O sistema caia, o nosso monitoramento era fraco, a plataforma ficava impossível de usar, os Sellers não conseguiam enviar seus pedidos, as entregas atrasavam, os repasses e pagamentos atrasavam… enfim, uma escalada sem fim de problemas.

O número de problemas que tivemos foi tão grande que nos forçou a reavaliar a situação e partir para uma reescrita.

Reescrita

Antes de optar por uma reescrita eu elaborei uma análise com prós e contras de cada uma das abordagens (evolução/reescrita) e apresentei ao Tiago e para outras pessoas chave na Olist.

Nesse documento eu enumerei as vantagens da reescrita e também os riscos envolvidos. Também adicionei um plano de contingência que previa manter o sistema atual com pequenas evoluções até que o novo sistema fosse concluído.

O resultado dessa discussão foi: deveríamos escrever um novo sistema, do zero, enquanto faríamos manutenções no sistema atual. O prazo? Segundo semestre de 2016. Antes da Black Friday (com uma boa margem de segurança).

Ok! Go!

Eu já havia feito algumas contratações para montar a equipe que daria manutenção do sistema atual. Mas com a decisão de reescrever o sistema precisaria montar uma equipe bem maior.

Alguns processos precisariam ser criados e outros modificados. Tecnologias precisariam ser substituídas. Arquitetura do sistema precisava ser redefinida. E para isso funcionar tracei algumas diretrizes para guiar os trabalhos:

1. Todo o desenvolvimento será feito visando qualidade e as boas práticas de programação. O sistema atual foi desenvolvido “sob demanda” sem muitos cuidados com qualidade.
2. Devemos ter um processo claro e bem definido para trabalhar. O sistema atual foi desenvolvido sem nenhum processo. Era simplesmente um “demanda chega, demanda sai” sem ordem, critério ou planejamento.
3. O novo sistema deve ser simples. A brincadeira que faço com a equipe é que o novo sistema precisa ser extremamente “arroz com feijão”. Vai ser um delicioso arroz com feijão, mas só isso. O atual é desnecessariamente complexo em algumas partes e demasiadamente simplista (que é diferente de simples) em outras.
4. O novo sistema precisa ser robusto (ter capacidade de “aguentar o tranco”). O sistema atual tem limitações que impedem ou dificultam a operação na escala que estamos operando.
5. O novo sistema precisa ser resiliente (capacidade de continuar funcionando mesmo na adversidade). O sistema atual fica todo comprometido quando algum parceiro fica fora do ar (ex. Correios).
6. O novo sistema precisa ser modular (cada parte do sistema tem uma responsabilidade clara e bem definida). O sistema atual é um emaranhado de responsabilidades (ex. mudanças no código de produtos pode afetar o cálculo de frete).
7. Devemos usar ferramentas e tecnologias testadas e comprovadamente robustas. O sistema atual parece um flyer de congresso de tecnologia. Usaram várias ferramentas, tecnologias e arquitetura sem necessidade.
8. Devemos priorizar ferramentas e tecnologias prontas e administrada por terceiros mesmo que elas tenham um custo maior. A equipe é pequena e temos muito trabalho a fazer num curto espaço de tempo.

Com a abordagem escolhida, diretrizes descritas e a equipe montada iniciamos a aventura.

Esse é o cenário que temos hoje: um sistema com vários problemas e instabilidades que geram alguns transtornos para nossos Sellers mas que, independente disso, ainda ajudam eles a vender mais. E um outro sistema novo, sendo criado do zero, que eliminará grande parte dessas dificuldades.

Versão 1 (ou V1)

Agora que a situação da tecnologia da Olist foi contextualizada vou fazer um detalhamento mais técnico para aqueles que tiverem um interesse maior no que estamos fazendo e para reforçar um dos nossos valores que é a transparência.

O sistema atual da Olist é conhecido internamente como V1 (vê um) porque é a primeira versão do nosso software. Durante um tempo chamamos ela de legacy (legada) mas paramos de chamá-la assim porque não era justo com o sistema que manteve (e ainda mantém) a Olist funcionando e ainda desmotivava a equipe que ainda a manteria até o nascimento do novo sistema.

A V1 foi desenvolvida em PHP usando o framework Symfony2. Ela guarda os seus dados em um banco de dados relacional (MySQL) e alguns dados relacionados à moderação de produtos são gravados em um banco de dados de documentos (MongoDB).

A aplicação é monolítica (uma base de código PHP/Symfony2 única) e implementa uma API (REST-like) acessadas via navegador por uma aplicação cliente escrita com AngularJS. Essa mesma aplicação também implementa alguns comandos que são executados por um “job runner” (implementado em Python) que busca mensagens de várias filas SQS da Amazon Web Service para executar processos.

Esse sistema foi desenvolvido com poucos testes automatizados e a cobertura é bem baixa (<4%) e, por esse motivo, fizeram muito poucas refatorações. Sem testes não há um modo de garantir que alguma melhoria não se transforme em uma grande dor de cabeça.

A modelagem dos dados no banco de dados é bem “relaxada” e, por isso, um bug no sistema pode sujar totalmente os dados e acrescentar diversas inconsistências na nossa base de dados.

O sistema também foi desenvolvido de um modo onde os dados novos sobrescrevem os dados antigos e quase nenhum histórico disso é gerado. Graças à essa abordagem é praticamente impossível rastrear e auditar problemas.

Monitoramento e métricas do sistema eram praticamente inexistentes. Hoje temos algumas mas ainda é muito pouco perto do ideal.

Processo e organização no trabalho era inexistente. Hoje praticamos Kanban e priorizamos as demandas em um quadro virtual. A equipe da V1 trabalha no escritório da Olist e é composta de 3 integrantes (atualmente com 2 porque migramos um integrante para a V2 e abriremos uma vaga).

Versão 2 (ou V2)

O desenvolvimento da V2 foi iniciado em fevereiro desse ano. Recebeu esse nome porque é a segunda versão do sistema da Olist. Chamamos ela de Olist-NG (New Generation) por um tempo mas decidimos mudar para V2 porque não sabemos se algum dia precisaremos de uma V3. Tomara que não. 🙂

A V2 é desenvolvida em Python e Django. Essa linguagem e framework foram escolhidos porque são as ferramentas com as quais eu tenho mais familiaridade e contatos profissionais. Isso facilitaria o meu trabalho para montar uma boa equipe. Lembram do “Arroz com Feijão”? Essa seria a escolha “Arroz com Feijão”.

A arquitetura da V2 é orientada à serviços (SOA — Service Oriented Architecture) com comunicação baseada em mensagens e APIs. Escolhemos essa arquitetura para termos uma plataforma mais robusta, resiliente e modular (conforme definido nas diretrizes). Atualmente as pessoas também chamam esse tipo de arquitetura de “Microserviços”.

Nessa arquitetura temos 3 tipos de componentes:

1. APIs: endpoints RESTful para gerenciamento síncrono de recursos.
2. Services: ficam em funcionamento constante processando informações.
3. Jobs: executam em intervalos de tempos regulares ou sob demanda.

Todos esses componentes conversam entre si através de mensagens publicadas em tópicos globais. Esses tópicos são assinados por filas específicas de algum serviço que queira receber essas notificações e agirem sobre elas.

As ferramentas escolhidas para esse trabalho foram os serviços SNS (pubsub) e SQS (queue) da Amazon Web Service (AWS). Esses serviços foram escolhidos por serem mantidos por terceiros (a Amazon garante o funcionamento deles) e isso libera a minha equipe do trabalho de manter uma infra similar (com RabbitMQ, Kafka e afins). Essa escolha foi feita para atender à 8ª diretriz.

Os componentes que precisam guardar dados usam um banco de dados relacional (arroz com feijão, lembram?). Optamos pelo PostgreSQL por ser mais estrito no seguimento das regras de modelagem (constraints), por disponibilizar um leque maior de funcionalidades e por ser disponibilizado por nosso fornecedor de plataforma. Eventualmente usaremos DynamoDB para armazenamento dos eventos para fins de auditoria e BI.

Escolhemos o Heroku como plataforma para hospedar nosso sistema. É um serviço de plataforma (PaaS — Platform as a Service) que facilita absurdamente o deployment desses sistemas. É um serviço caro mas realmente libera minha equipe dos trabalhos “mundanos” de DevOp.

Temos mais alguns serviços complementares: Github (gerenciamento de código e revisão de código), CircleCI (integração contínua), Sentry (monitoramento de erro), Hosted Graphite (métricas), etc.

No trabalho da equipe utilizamos diversas práticas e processos que visam melhorar a qualidade do código e uniformizar o conhecimento do sistema pela equipe:

• Testes automatizados: todo código precisa ter testes automatizados que garantam o seu funcionamento.
• Code Review (revisão de código): todo código precisa ser revisado por outros integrantes da equipe e não pode ser colocado no código “oficial” pelo autor original.
• Kanban/Scrum: as histórias são priorizadas e implementadas conforme cronograma de entregas.

Gestão de Produto

Esse tópico não é exatamente da área de tecnologia mas nasceu de uma demanda nossa.

Durante a estruturação da V2 não queríamos repetir os mesmos erros da V1 que foi criada sem nenhum planejamento. Não queríamos criar a V2 “sob demanda” igual a V1 foi criada.

Hoje a Olist tem uma área só para lidar com o nosso produto e planejar a sua criação e evolução.

O futuro

A migração do sistema atual (V1) para o novo (V2) será feita de uma única vez quando a V2 ficar pronta. Essa migração será bem difícil e deve trazer alguns transtornos. Por isso teremos bastante cuidado para minimizar esses problemas ao máximo.

Obviamente a equipe de tecnologia e produto vai conversar bastante com nossos Sellers antes, durante e depois dessa migração.

Com a entrega da V2 nós teremos condições de disponibilizar um serviço imbatível para os nossos Sellers permitindo que eles batam recordes de vendas e agilizando a operação deles. O objetivo é garantir que o sofrimento que eles sentem hoje acabe.

A Olist é uma empresa muito nova e ainda está em processo de crescimento. Isso causa problemas e dores. Mas o legal é saber que as pessoas que estão ao meu lado nessa empreitada são fantásticas e estão se doando ao máximo para que nossos Sellers e, consequentemente, a Olist sejam um sucesso.