Como funciona tecnicamente a Mandaê?

Backend, frontend, dados, nuvem e mais...

Standing on the Shoulder of Giants

Esse texto não poderia começar sem antes eu reconhecer e prestar minha imensa admiração pelo trabalho dos que construíram byte by byte a Mandaê de hoje. Algumas dessas pessoas ainda estão lá e nós carinhosamente as chamamos de "bruxos'' pelos motivos certos. Essas pessoas materializaram grande parte dos desafios e sonhos que o nosso CEO teve e principalmente, não "trincaram" quando passaram por momentos difíceis. Apesar de ter muito a reconhecer, sempre parecerá pouco. Como Stephen King diz: as coisas mais importantes são as mais difíceis de expressar

Talk is cheap

Ok, mas antes, quem sou eu na fila do pão, certo? As credenciais e a sopa de letrinhas técnica estão no Linkedin. Vou tentar contar o que não está lá. Como CTO, eu sempre acreditei que relacionamento e comunicação são pilares tão importantes quanto conhecimento técnico nessa posição. Para entregar os resultados, não posso só focar no técnico. Apesar de ser técnico (formado e certificado) considero que desenvolver uma cultura é de fato, o grande diferencial para atrair e reter grandes talentos na área de TI. 

Quando falamos em talentos (não só em TI) temos que considerar que gente talentosa, precisa de um ambiente propício, com pessoas que elas também consideram talentosas e aprendem mutuamente. Tudo isso apoiado em valores pessoais alinhados aos valores que a empresa acredita e que as mantêm motivadas nos desafios do dia-a-dia. Assim, elas consideram que estão fazendo a coisa certa, no lugar certo e cercada de pessoas igualmente talentosas. Sim mas não exclusivamente, também sendo bem recompensadas por isso. Isso é o que eu considero o principal diferencial da Mandaê como líder. É impossível vender para pessoas inteligentes uma empresa que fala uma coisa e faz outra. Muito cedo ou cedo essas pessoas vão perceber que estão no lugar errado e a oferta e demanda vão fazer o seu trabalho. É por isso que insisto, é muito raro achar uma empresa que "walk the talk", ou seja, que fala e faz. E a Mandaê é um desses lugares.

Quando um problema acontece, considero que posso atuar como consultor do time técnico e ajudar a guiá-los como um gerente de engenharia ou um arquiteto faria. Mas o meu foco sempre será na estratégia. Costumo fazer a metáfora de um capitão em uma grande embarcação: não é porque ele sabe amarrar cordas ou fazer manutenção nas máquinas que ele tem que fazer isso. Não porque é um trabalho mais ou menos nobre. Mas é que se ele fizer isso, quem está fazendo as atividades do capitão?

O que e a quem?

Esse texto foi pensado e endereçado a tech guys. Nós sempre estamos curiosos com a mesma pergunta depois de ouvir sobre a história/operação de uma empresa: "certo, mas como funciona por de trás das cortinas?". É exatamente essa resposta que irei buscar entregar a vocês durante o texto. E sim, eu organizei esse texto em subtópicos porque acredito que é a maneira mais fácil de lidar com o nosso attention span cotidiano.

Long story short / TL;DR

Acho justo também como tech guy, oferecer uma versão do texto direto ao ponto. A Mandaê tem suas aplicações hospedadas na AWS (nascemos cloud native). Nossa stack é basicamente Java com Spring Boot e no frontend usamos Angular. Recentemente, despublicamos nosso app de rastreamento pois ele não fazia mais sentido na nossa estratégia. Ou seja, como não somos customer-facing, nosso front hoje (early 2021) é significativamente menor que a nossa estrutura backend. O que não significa que não temos melhorias e mudanças de interface e ligação com o backend já no roadmap. Nós temos, e muitas.

Do ponto de vista de banco de dados temos duas bases PostgreSQL. Nosso código,CI/CD está no Bitbucket e conseguimos fazer deploys e rollbacks de uma forma transparente.

Em dois minutos e dez mil pés de altura, é isso.

First things first

Antes de entrar no detalhe, é preciso dar um passo atrás para lembrar o que é a Mandaê. Somos uma plataforma que conecta e-commerces com as melhores soluções logística do Brasil. Fazemos isso através de integrações com transportadoras e plataformas de e-commerces. Apesar de as integrações serem super importantes, ela não é o nosso core. Tecnicamente brincando, não somos um grande API gateway que recebe chamadas de um lado, transforma e agrega mais informações de outro. Nosso core é precificação dinâmica. Ou seja, temos uma base de dados com informações sobre diversas transportadoras e acordos comerciais que nos permitem oferecer um preço menor para o lado do e-commerces e garantir uma previsibilidade maior para o lado da transportadora. É um modelo de negócios em que todos saem ganhando.

Backend

Nossos serviços estão grande parte Java 8 e Spring boot 2. Mas isso não significa que eles vão ficar assim para sempre. Por trabalharmos com micro serviços, temos a oportunidade única de absorver o melhor de cada linguagem. Significa que vamos mudar tudo para Python e Kotlin nesse quarter? Não. Significa que estamos super abertos a avaliar os trade offs e acreditamos que construir/migrar um serviço em uma nova linguagem é inevitável a médio e longo prazo. By the way, estamos ansiosos para ter esse tipo de conversa.

Integrações

Aqui podemos pensar em dois grandes grupos: transportadoras e e-commerces. Do lado das transportadoras, basicamente trabalhamos com EDI. Apesar das minhas críticas pessoais a esse modelo, ele tem sim suas vantagens e muitos irão dizer "sempre funcionou assim" no mundo das transportadoras. Mas eu acredito que aqui podemos implementar uma estratégia que vai nos permitir mudar dar um passo significativo a uma melhor precificação dinâmica e, certamente, nos colocar em um outro estágio.

Do lado da integração com os e-commerces isso pode ser feito via plataformas que concentram esses e-commerces (como VTEX, Tray, Nuvemshop e Shopify) ou diretamente com eles via API (mais raro). Aqui o desafio técnico é sempre pensar em escala e pontos únicos de falha para garantir a entrega dos valores de frete em cenários de grande demanda ou em falha em algum ponto onde mesmo assim conseguimos manter a consistência.

Tá bom, mas como vamos mudar o jogo com as transportadoras e os tais arquivos? 

Na minha visão, uma solução como um leilão em tempo real (real-time bidding) pode ser uma saída. Se tivermos todas as pontas conectadas em tempo real, conseguimos preços ainda mais baixos. As transportadoras conectadas com arquivos que começarem a perder volume por novas transportadoras já conectadas via API e vão se sentir pressionadas a seguir o modelo. Boom a precificação dinâmica acontece. E como falei anteriormente, é um ganha-ganha para todos os lados. Uma coisa é fato, quanto mais crescemos, melhor fica o nosso preço.

Frontend

Conectamos tudo com Angular 7. Como não temos (pelo menos nada no roadmap a curto prazo) planos para atender o consumidor final (o cliente desses e-commerces), nossos problemas com interfaces e versões de browser aqui e limpa o cache ali são bem reduzidos. E isso é uma coisa boa. Conseguimos focar tempo e energia no nosso maior desafio.

Serviços

Nossos principais serviços (pedidos, coletas e rastreamento) usam a abordagem DDD. Tudo isso usando um login com Spring Security. E todas as APIs no padrão REST.

Se lembra do Postgres? Eles não são 100% das nossas tecnologias de banco de dados. Também usamos para cenários muito específicos MongoDB e Dynamo.

ElastiCache tem nos ajudado a não só cachear (duhh) mas fazer alguns semáforos interessantes. Para mensageria Aws SQS  e Apache Kafka .

O SNS da AWS tem nos suprido para o serviço de notificações.

Servidor de orquestração com Apache Airflow rodando pipelines em Python e scripts em R para transformação de dados.

Cloud = AWS 

Temos nos dado muito bem com Kubernetes para orquestração de serviços. E para isso tudo foi migrado para EKS.

Para agregação de informações a combinação Grafana, Prometheus e Loki funcionam bem para a nossa necessidade.

Acreditamos muito no Infra as a code. Até por isso as diretivas do Kubernets estão no proprio repositorio Bitbucket o que nos permite fazer deploys sem impacto. Mas blue/green é possibilidade que queremos explorar.

QA

Tive péssimas experiências como gerente de engenharia misturando QAs com engenheiros de software no cenário de QAs testarem código em ambiente de homologação. Em linhas gerais, esse cenário (na minha amostra) gerou engenheiros preguiçosos que nem testavam o seu código no ambiente de homologação para passar no caminho feliz. Do outro lado, QAs frustrados sendo reduzidos a testers. Eles estavam fazendo um trabalho que não é qualidade e sim um trabalho que qualquer pessoa poderia fazer. Para mudar isso, na Mandaê investi no conceito de líder de qualidade. Essa função permeia nossos squads e é envolvida quando a história nasce. Assim ela mapeia caminho feliz e fluxo de exceção. Já busca e disponibiliza algum dado específico necessário para realizar os testes, quando necessário. Valida se é um cenário que precisa passar por um teste de carga ou se tem alguma informação pessoal que precisa passar pelo processo de LGPD. Planeja os testes, e vai ajudar o próximo time. Os testes escritos (texto mesmo) podem ser executados por qualquer pessoa (o engenheiro que fez o código, o engenheiro que fez code-review ou o product manager).

Próximos passos nesse tema, automatização de testes. Mas primeiro criar conhecimento e cultura no time sobre o tema é necessário.

Organização de times

Acreditamos muito na autonomia dos squads. O time de engenharia e produtos é uma unidade. Eles decidem como prefere trabalhar. Normalmente varia entre sprints e kanban. O que fizer mais sentido para o momento.

Mudanças

Não existe CAB ou GMUD. Você está trabalhando em algo? Três passos para o deploy:

1 - Alinhe o impacto e a data com o seu product manager. Ele provavelmente vai validar essa data e o horário com o time de operações e possíveis áreas impactadas. Não impactar operações é uma premissa.

2 - Consiga um cúmplice para fazer peer review e saber fazer rollback caso haja alguma emergência e você não esteja disponível. 

3 - Publique no canal de mudanças no Slack, comunicando o quê, quem, quando e onde.

É isso. Até agora tivemos zero problema com esse cenário de comunicar ao invés de pedir autorização. Queremos nos manter assim.

A wide-open road ahead

Então é só alegria e céu azul? Bem, não é o objetivo desse texto vender a Mandaê para um cliente e fazer um pitch de investimento. Nossa missão é devolver ao comércio eletrônico o controle e a liberdade através da melhor logística do Brasil. Nobre, mas não fácil. A realidade é que os players envolvidos são grandes marketplaces e grandes transportadoras e esses gigantes não estão de brincadeira. No entanto, para cada movimento deles, nós fazemos cinco movimentos mais rápidos. Os fatos é que estamos usando essa velocidade para nos adaptar rapidamente e dobrar de tamanho a cada ano. Estamos em um cenário de estabilidade financeira e sem perder a velocidade conforme crescemos. Isso significa que a nossa velocidade para entregar inovação é real.

Em termos de desafios técnicos, imagine o que estaremos fazendo em nossa precificação dinâmica usando machine ou como estará nosso ecossistema de aplicações e base de dados em dois ou quatro anos? Estamos trabalhando para adaptar a escalabilidade das nossas aplicações, fazer melhores slices dos nossos dados constantemente. Na Mandaê você tem oportunidade de impactar diretamente problemas do mundo real. Tecnicamente não faltam desafios e oportunidades de protagonismo para fazer mais e melhor.