Voltar
Entrevista com Thiago Gambarra, desenvolvedor na Mundipagg há 10 anos. Nesse bate papo, falaremos da importância dos microsserviços.
Hoje falaremos com o Thiago Gambarra sobre pagamentos de e-commerce utilizando microsserviços.
Conheci o Thiago no Vale do Silício e tenho certeza que a experiência dele ajudará todos a entenderem o mundo de serviços.
Wesley – O Thiago trabalha na área há mais de dez anos e atualmente trabalha na Mundipagg. A Mundipagg é uma plataforma de pagamentos que possui 40% do market share do e-commerce brasileiro. O Thiago compartilhará como utiliza microsserviços no mundo de pagamentos.
Thiago – “Esse é um ambiente que requer muita segurança, rapidez e tem que ser escalável, pois nunca se sabe quando será necessário aumentar o parque no sistema para processar os eventos.
A maioria das transações online são feitas pela Mundipagg. Quando você faz uma compra, a Mundipagg é a intermediária entre você, o banco e a empresa.
Possivelmente, vocês já compraram em uma dessas lojas.
Quando você compra de uma dessas lojas, a Mundipagg está executando seu trabalho de intermediador. Temos um volume muito grande de transações e com isso temos desafios.”
“Entregar a melhor solução de pagamentos do mercado, com a melhor performance e mantendo o SLA acima de 99,5%.”
“Partimos para o modelo de aplicações distribuídas, como:
Para manter a performance elevada estamos adotando uma estratégia de microsserviços usando o conceito de CQRS e Event Sourcing. Com isso, conseguimos ter velocidade na leitura dos dados e não interfere no fluxo dos dados.
Para Banco de Dados, trabalhamos com SQL, NoSQL, Elastic, MongoDB, Influxdb. Utilizamos todas as linguagens que possam agregar valor para o cliente.
Quando trabalhamos com microsserviços, precisamos nos preocupar com o Monitoramento e Logs. Algumas pessoas não dão a devida importância ao assunto, mas é fundamental para o sucesso do negócio.
Essas são algumas ferramentas que utilizamos para monitoramento e log:
New Relic, Splunk, Monits, Zabbix”
Thiago, você falou em CQRS e Event Sourcing para aumentar a performance. Por favor, fale um pouco mais sobre essas ferramentas para o pessoal entender a sua utilidade.
“CQRS é um tema bem complexo, precisaríamos de um dia só pra falar sobre esse assunto. Falarei, resumidamente, como o adotamos aqui.
Nossa base de escrita é no SQL Server, utilizando comandos que é a base do CQRS. Toda vez que um comando é criado ou atualiza alguma entidade, um evento é disparado e vai para um event bus que propagará esse evento para algumas exchanges e alguns consumidores pegam esses eventos propagados para o service bus e popula, algumas vezes no nosso MongoDB, outras vezes no ElasticSource. De acordo com o tipo de evento, mineramos esse evento e, ou persiste ou exibe esse evento.
No final do ano passado lançamos plataforma multi pagamento que fornece informações em tempo real para o logista. No momento que está chegando uma transação no Mundipagg, em tempo real, o logista consegue visualizar o volume que está passando. Disponibilizamos um dashboard para os clientes em que ele consegue visualizar, em tempo real, todo o volume transacional. Isso é possível porque uma vez que chega um comando, é propagado o evento, os consumidores pegam esse evento e propagam para diversos bancos de dados, os mais usados são o MongoDB e Elastic.”
Agora, o Thiago fará um overview do processo quando estão trabalhando com serviços, desde o início quando estão desenvolvendo, incluindo o controle de versão, o processo de integração contínua, os testes, o processo que faz o deploy e o monitoramento. Ele dará uma visão mais detalhada e mostrará como funciona na empresa.
“Iniciamos com a chegada da demanda, que pode ser através de um backlog ou uma tarefa.
Se for um serviço novo, criamos um repositório no Github. Utilizamos o Git como versionador e o Github como repositório. Trabalhamos com o conceito do gitflow para a entrega do software.
Quando a demanda chega, mapeamos, desenvolvemos, é aberto um processo de PR, que é muito importante, que é uma revisão do código. Todo código quando sai do desenvolvedor é revisado pelo time. Há uma etapa junto a PR que, só abre uma revisão se houver evidências que aquele código que está subindo está sendo testado: através da criação de testes unitários, através da criação de testes de integração ou através de evidências de testes.
Atualmente, só permitimos subir se houver testes de integração e unitários junto a PR.
Para os testes de integração usamos o Postman com o auxílio do Newman. Ele roda os testes coletando as informações do Postman, roda os testes e a aplicação só sobe para produção depois que os testes foram aprovados, senão o deploy é abortado e a aplicação não é entregue.
Todo o processo passa por CI, testes de integração e unitários.
Depois que sobe para produção, qualquer fluxo tem que ter Log. Logamos mais de uma ferramenta e, dependendo da complexidade do serviço, podemos atingir até 3 níveis de Log.
Após o software ser entregue, ele é monitorado pelo New Relic. Dessa forma conseguimos saber quanto recurso está sendo utilizado (CPU, memória). Se for container, utilizamos o Prometheus para saber o consumo e a saúde do container. O Monitis também faz o monitoramento e qualquer alerta, nos informa.”
Agora vamos tentar desmembrar o assunto. Gostaria que você dissesse como funciona o processo de revisão, como uma equipe revisa o próprio código? Vocês têm algumas guidelines para ajudar nesse processo?
“Seguimos o padrão, onde temos que descrever no pull request o que foi desenvolvido e porque foi desenvolvido. Temos um checklist que marcarmos os itens para abrir um PR, tais como: foi testado, atende as necessidades do cliente, foi revisado e é a demanda solicitada pelo cliente. Esses são alguns itens. Depois de checados todos os itens, verificamos se atendeu todo o checklist e então começamos a detalhar o PR. Verificamos os guidelines para saber se está sendo respeitado os guidelines do projeto, está seguindo a nomenclatura de métodos. Revisamos também, além de verificar se o código não tem nenhum erro, se o desenvolvedor tentou implementar da melhor forma possível, se ele não deixou nenhuma sujeira no código, tentamos não deixar nenhum comentário no código, somente se for extremamente necessário.
Esse é o processo de review, precisa ter dois aprovadores, no mínimo, para um PR ser fechado e ser mediado pra master ou pra onde for o PR. Não há PR que o desenvolvedor abre, commita e master.
Resumindo, todo processo que passa por um PR tem que ter dois aprovadores, no mínimo, dizer que está condizente, respeitar o checklist, respeitar as etapas de criação de testes e respeitar as etapas de criação de testes de integração.”
Para projetos menores, é necessário seguir esse padrão com esse nível de rigidez ou depende de cada projeto? Como vocês fazem com a entrega, uma vez que vocês precisam entregar rápido e de forma segura. Como fazem pra nivelar isso?
“Seguimos o pensamento que não existe uma tarefa de uma única pessoa e sim a tarefa é do time. Se é pra subir com qualidade e não tiver retrabalho no futuro, optamos em perder um tempo pra subir do que entregar rápido e depois de algum tempo ter que mexer porque apresentou algum problema.
Parece burocracia, mas vale a pena, num primeiro momento, perder esse tempo e evitar retrabalho no futuro, pois um bug pode custar muito mais do que a demora da primeira entrega. Sempre que desenvolvemos uma feature, ela é orientada a testes. Com os testes há o ganho de deixar as coisas mais enxutas, com maior qualidade, mais simples e há o amadurecimento como time, adotando essas práticas.”
O que é CI, como é o processo de CI e como ele ajuda no dia a dia?
“CI significa Continuous Integration, que é a etapa de entrega do código. Quando o código é colocado em master, o CI faz o papel de empacotar esse código convertendo para binário ou criando uma imagem e disponibilizando-a, para depois haver o processo de deploy que irá jogar nos devidos servidores. Resumindo, é o processo de empacotamento e transformação do código em binário ou imagem para disponibilizar nos servidores.
Nosso processo é automático. Temos uma trilha no github que compila e roda todos os testes unitários e dá o covered do projeto. Estamos iniciando a utilização do SonarQube, que é uma ferramenta de análise de código que verifica uma série de itens, como: métricas do código, grau de complexidade, quantidade de possíveis bugs e se está dentro do guideline do projeto, entre outros.
Atualmente, passamos pelo processo de CI, com a etapa de testes e depois pela análise de código. Se alguma dessas etapas falha, o código volta e nem vai para a etapa de deploy. Definimos como meta 70% de covered, mas queremos chegar em 95%. Se o código não atinge a meta, o processo de CI não é concluído para ir para a fase de produção.
A próxima fase é a code analise, onde verificamos se o código está respeitando guidelines, se há algum code smell (código potencialmente ruim).
Com todas as etapas concluídas , empacotamos, se for container, criamos uma imagem e disponibilizamos no hub de imagens para que o processo de CI possa disponibilizar nos servidores.”
Como vocês rodam os testes no processo de CI? No mundo de Serviços, utilizamos APis para tudo. Como vocês testam as APis?
“Usamos o Visual Studio on line e uma das tasks do processo de CI é dar todos os checks unitários. Temos todos os testes unitários rodando no processo de CI, que executa os testes unitários e de integração e calcula o covered. Algumas partes dos testes de integração ainda são feitas no processo CD, mas antes de chegar no servidor. A maior parte estamos migrando pra o processo de CI em que subimos direto o web host na própria máquina, no container, executa os testes, traz as amostragens e continua o processo de build.”
No caso de vocês, há milhares de transações envolvendo muito dinheiro. O que vocês já conseguiram trabalhar e tratar em relação a performance para garantir que esses serviços funcionem corretamente?
“Recentemente tivemos que nos preparar para um evento onde houveram em torno de 180 transações por segundo. Para se ter uma ideia, na última black friday, a Mundipagg operou 50% do volume de transações de e-commerce, que chegaram a 52 transações por segundo. Trabalhando com microsserviços temos essa vantagem de escalar rapidamente e de forma muito fácil. Para esse evento tínhamos essa necessidade, subimos mais containers para fornecer essa disponibilidade e com isso crescemos nosso parque de forma muito rápida.
Um erro que ocorre muito quando se trabalha com microsserviços, devido a facilidade de subir um novo container, é em relação a qualidade do código, verificar se ele está performático. As pessoas acabam se esquecendo de fazer esse monitoramento. Ficar subindo container acaba elevando o custo. É necessário saber que nem tudo é resolvido com hardware, pois no final, o projeto pode não se pagar.
Para esse projeto específico, fizemos uma curadoria no nosso código, verificamos todos os detalhes, diminuímos algumas etapas, para melhorar o tempo de resposta e aumentar o número de transações por segundo. Trabalhar com microsserviços tem a facilidade de escalar, mas tem um custo. Deve-se ter um equilíbrio entre desenvolver um código com qualidade e escalável e escalar. Há a necessidade de sempre pensar em fazer um código performático, com possibilidade de ser escalável.”
Falando no mundo de microsserviços, acho que os desenvolvedores estão visando mais o software, como será desenvolvido e não se preocupando com o valor que será entregue para o cliente.
Sabemos que esse valor está baseado em serviços que conseguimos entregar. Atualmente, com o grande número de transações, estamos tendo que quebrar esses serviços para que, em sistemas maiores e distribuídos, esse processo fique mais simples e de forma escalável, diminuindo o potencial de erro.
Como você vê, hoje, a parte de microsserviços? Como está a adoção dessa prática por vocês e com a comunidade que você tem contato?
“A discussão sobre microsserviços é em torno da sua utilização. Quando devemos usá-lo.
Microsserviços é excelente quando você tem um time maduro, que desenvolva com qualidade, que foque em performance, métricas, entrega contínua. Quando trabalhamos com o conceito de microsserviços, esses pontos são fundamentais. Não adianta ter vários serviços e realizar o deploy manualmente. Não adianta fazer um serviço bacana e não ter um processo de entrega contínua, de testes automatizados, de monitoramento.
Todo ecossistema por trás do microsserviço é importante. Por exemplo, temos diversos serviços aqui: assinatura, pagamentos, etc. Na black friday não precisamos escalar assinatura pois não serão processados nesse evento, mas os pagamentos serão processados. O microsserviço auxilia escalar somente o que é necessário, dando essa flexibilidade. Por isso é importante ter as métricas, os logs, pois se houver um erro, por exemplo no processo de compra, rapidamente é possível identificar onde ele ocorreu, se foi no serviço de compra, na autenticação do usuário, no serviço de proxy que se comunica com o serviço externo. Se estiver bem parametrizado, com os logs em funcionamento, facilmente será rastreado o erro, caso contrário terá que testar todos os serviços e isso poderá levar muito tempo.
Reforçando, é importante ter esse trace completo. Atingindo esse nível, trabalhar com microsserviços é excelente.”
Falando em microsserviços e escalabilidade, você comentou sobre a maturidade do desenvolvedor. Atualmente, vejo desenvolvedores muito bons tecnicamente, que programam muito bem, com boas ideias, mas não têm experiência em criar um pull request, não sabem como funciona a parte de CI e CD, não têm muita noção de infra estrutura. Hoje em dia não tem mais isso do cara programar e a parte de infra estrutura deixar que o pessoal de infra estrutura cuide.
Como você vê isso e qual seria a sua dica para essas pessoas que sabem programar, mas não sabem trabalhar, que são duas coisas diferentes, pois é necessário ter um fluxo de trabalho com a equipe.
“Primeiro, o básico de tudo é estudar. Na área de tecnologia é fundamental o estudo para saber o que está acontecendo ao redor.
Não é necessário ser um especialista, eu não sei tudo de configuração de servidor, não sei tudo de Docker, mas é necessário ter o conhecimento básico de tudo. Quem trabalha na área de tecnologia tem dois objetivos: ser gestor ou arquiteto.
Não dá pra ser um arquiteto se não tiver conhecimento sobre serviços, arquitetura, DevOps, segurança. Até mesmo para ser gestor, é necessário ter um conhecimento básico de arquitetura, DDD, Microsserviços, Docker, kubernets. Não é necessário ter conhecimento profundo, mas o básico é necessário. Precisa saber como funciona uma fila, qual a vantagem de adotar uma fila, qual o ganho em usar uma fila.
Na minha visão, todo sistema complexo deve utilizar microsserviços. Não vejo a Mundipagg de outra forma. Se fosse um sistema monolítico e um programador cometesse um erro, todo o sistema de pagamentos desapareceria. No nosso caso seria inviável.
Em sistemas complexos, altamente escaláveis, que processam muitas informações diferentes, que tem muitos bounded context diferentes, vale a pena adotar microsserviços.
Em sistemas menores não há essa necessidade de utilizar microsserviços, é possível usar o sistema monolítico , desde que bem codificado e bem testado.
Resumindo, estudar e estar antenado no que está acontecendo no mercado é muito importante.”
Com tudo que você expôs, chegamos em um dilema: o cara que trabalha em empresa pequena não conseguirá adquirir experiência em microsserviços, pois não há demanda para isso. Por outro lado, as empresas grandes exigem um mínimo de experiência na área.
Qual a sua sugestão para essas pessoas, para que elas possam passar em uma entrevista? Você acha viável a montagem de um laboratório para que elas possam treinar? O mercado de TI brasileiro está em alta em busca de bons profissionais e as contratações estão cada vez mais difíceis.
“Aqui na Mundipagg temos uma premissa de contratar pessoas melhores dos que as pessoas que estão aqui ou com potencial para serem melhores. Nunca contratamos pessoas piores, por mais que estejamos precisando.
Uma dica importante, é sobre uma experiência pessoal onde trabalhei por seis anos em uma empresa que era basicamente windows form, estava confortável, com um bom salário, mas não estava agregando mais nada. O mundo estava voltado todo para web, decidi mudar e ir pra uma empresa trabalhar com web sem ter experiência prática. Montei um laboratório em casa e pensava como empreendedor e dessa forma uni as duas coisas, conseguia aprender desenvolvendo e empreendendo, tentando lançar um produto no mercado. Um exemplo, desenvolva um sistema de gestão de padaria utilizando microsserviços. Pense em todas as etapas do planejamento, como desenvolveria todos os módulos, desde a gestão de estoque até a de funcionários. A ideia é estudar e treinar.
No Brasil o salário da área de tecnologia é bem alto. É necessário entender que é o desenvolvedor que traz o conhecimento para a empresa e não o contrário. Reforçando que nessa área o mais importante é sempre estudar e ficar atento às novas tecnologias.”
Como você vem reforçando, a grande questão é o estudo. Diferenciar um programador básico de um intermediário é bem fácil perceber. Fazer isso entre um intermediário e um avançado, já é mais difícil, pois são detalhes que os diferenciam e que garantem que esse desenvolver vá agregar valor para a empresa. Venho alertando os desenvolvedores que, atualmente, não adianta só programar, ter conhecimento somente de linguagem, de sintaxe. Precisa ir além, ter conhecimento em CI, CD, DevOps, revisão de código. É um processo contínuo de estudos, onde todos precisam tornar isso uma rotina. Dessa forma, esses desenvolvedores terão todas as linguagens disponíveis e a capacidade de decidir o que é melhor naquele momento para utilizar.
Para finalizar, gostaria que você desse três dicas para o pessoal que está programando, não está contente com o trabalho, não tem contato com o mundo de serviços, só trabalhou com monolítico e está querendo conhecer essas novas tecnologias.
Quais são as dicas pontuais de estudo que você pode dar para esse pessoal?
“Primeiro é se inscrever nos cursos da School of Net, lá tem cursos muito bons de microsserviços.
A segunda dica é participar de comunidades, elas agregam muito valor. Mesmo que não seja ativo, é possível ver o que a comunidade está fazendo, está usando e com isso é possível visualizar a tendência do momento. Há comunidades muito boas de arquitetura, de linguagem. Sempre tem um pessoal bem sério compartilhando conhecimento. Participar dessas comunidades é importante para absorver o conhecimento, tirar dúvidas, participar de eventos.
Por último, colocar a mão na massa, investir nos estudos para sair da teoria e ir para a prática, sem a prática não irá adquirir experiência.”
Tenho certeza que esse conteúdo ajudou bastante a comunidade a entender um pouco mais sobre microsserviços nas plataformas de pagamento. Um agradecimento especial ao Thiago Gambarra que se dispôs a compartilhar seu conhecimento e ajudar o pessoal que está começando e os que já têm experiência em microsserviços.
Como ele disse, estudar continuamente é necessário para se manter atualizado e entre os melhores da área.
Então, se você quer aprender mais sobre pagamentos online usando microsserviços, solicite contato clicando aqui e nós te ajudamos.
Um abraço e até a próxima.