Microsserviços em Python: comunicação, testes e resiliência

Fundamentos de sistemas distribuídos - Introdução

Apresentando o instrutor e o curso

Olá! Meu nome é Stéfano Henrique Batista e atualmente sou Staff Engineer em uma empresa de meios de pagamento.

Audiodescrição: Stéfano é um homem branco, com cabelo curto castanho e barba. Ele veste uma camisa azul e está em um ambiente de escritório com uma parede clara ao fundo.

Tenho 20 anos de experiência em desenvolvimento e, nesse período, já trabalhei para diversas empresas relacionadas a diferentes negócios. Hoje, tenho o orgulho de apresentar o curso de microserviços.

Introduzindo o conteúdo do curso

Neste curso, vamos aprender o que são sistemas distribuídos, como desenvolver um microsserviço, as boas práticas e também os maiores erros que ocorrem durante o desenvolvimento. Vamos criar um sistema do zero: um sistema de checkout de e-commerce que se conecta ao meio de pagamento, a pedidos e ao estoque. Durante esse desenvolvimento, compartilharemos nossa experiência e como desenvolver esse microsserviço. Venha participar!

Fundamentos de sistemas distribuídos - Entendendo os sistemas distribuidos

Introduzindo a discussão sobre sistemas distribuídos

Olá, hoje vamos discutir sobre sistemas distribuídos e por que, muitas vezes, o correto é falarmos sobre sistemas distribuídos em vez de microserviços. Vamos explicar como as coisas funcionavam há 20 anos, quando começamos no desenvolvimento de software. É importante entender como, ao longo dessas duas décadas, o desenvolvimento de software evoluiu, para compreender por que algumas práticas foram adotadas e por que muitas empresas mudaram.

Descrevendo o desenvolvimento de software há 20 anos

Há 20 anos, quando começamos a desenvolver software, tínhamos uma aplicação monolítica, mas diferente do que conhecemos hoje. Esse monolito era diferente porque, dentro dele, não havia apenas o código, mas também o HTML. Isso é o que chamamos de server-side (lado do servidor), ou seja, o código era processado junto com o HTML e já era entregue pronto na máquina do usuário. Diferente de hoje, onde tudo é processado localmente, falando da parte do usuário e do design. A manutenção era muito difícil, pois era necessário ter conhecimento em CSS, HTML, JavaScript e no código em si. Além disso, o banco de dados estava integrado. Era fácil ocorrerem erros, pois tudo estava misturado, exigindo um conhecimento profundo do que estava sendo feito.

Naquela época, criávamos novas funcionalidades e as implementávamos uma vez por mês ou a cada duas semanas, todas juntas no servidor de produção. Fazíamos o deploy de forma manual, copiando e colando arquivos na pasta do servidor, e assim o sistema web estava funcionando. Era um processo complicado.

Evoluindo com o surgimento de novas tecnologias

Depois, as coisas melhoraram, principalmente com o surgimento do jQuery, entre 2006 e 2008. Começaram a surgir aplicações front-end, separando o código front-end do back-end. Assim, tínhamos o back-end e o banco de dados separados. Para nós, isso já foi uma grande melhoria, pois podíamos focar no que gostávamos, que era o back-end. Houve também uma divisão de papéis, especialmente após o lançamento do AngularJS, entre 2011 e 2012, diferenciando quem trabalhava com front-end, back-end e banco de dados. Isso trouxe uma boa melhoria, mas ainda havia um problema: construíamos toda a aplicação e o negócio da empresa dentro de uma única aplicação.

Enfrentando desafios com monolitos tradicionais

Manter a manutenção desse tipo de código ainda era complicado. Apesar de ter facilitado, não havia mais o HTML ou o CSS para mexer, mas ainda assim era complexo, pois o codebase era muito grande, com milhares de linhas de código. Normalmente, ao modificar uma parte, outra era afetada negativamente, o que ficou conhecido como um monolito tradicional, onde o código está todo junto e misturado, sem uma clara delimitação de início e fim, resultando em diversos bugs.

Propondo a transformação para múltiplos serviços

Alguém então pensou: e se transformássemos esse código, esse back-end, em vários back-ends? Ou seja, teríamos o código 1 como um serviço, o código 2 como outro serviço, e o código 3 como mais um serviço. Cada um desses sistemas teria seu próprio banco de dados. Assim, teríamos um banco de dados para cada serviço.

Comparando complexidade e independência em grandes empresas

Muitas vezes, pensamos que agora o desenvolvimento de código está mais complexo do que antes. De certa forma, concordamos com essa visão. No entanto, imagine uma empresa muito grande, como a Netflix, que possui diversos negócios internos. Não é apenas o serviço de streaming de vídeo, mas também o pagamento, a busca por filmes e séries, a funcionalidade de dar like, entre outros. Existe uma grande quantidade de funcionalidades de negócios dentro da Netflix. Poderíamos usar a Amazon.com como exemplo também, onde não é viável esperar um deploy para cada nova funcionalidade.

Imagine a Netflix com tudo em um único back-end, em um único monolito. Como seria isso? Ao criar vários serviços, estamos criando independência. Cada serviço pode ser modificado a qualquer momento sem problemas. Esse é o benefício do microserviço. O microserviço é um código semelhante ao monolito, mas com complexidade muito menor. Em vez de ter três códigos ou serviços, como faturamento, stream de vídeo e catálogo, dentro de um único back-end, temos esses três serviços de forma separada.

Explicando a origem e a prática dos sistemas distribuídos

É importante entender que a ideia de microserviço é, na verdade, a de um sistema distribuído. Essa ideia existe desde muito antes da década de 1990. Quando desenvolvemos uma aplicação e temos um banco de dados, já estamos utilizando a prática de sistemas distribuídos. O que é um sistema distribuído? É ter dois serviços em servidores separados que se comunicam. Isso começou na década de 1970 e foi muito utilizado durante a Guerra Fria, quando os Estados Unidos precisavam proteger seus dados, distribuindo-os em vários estados e computadores diferentes. Foi a partir daí que a rede, a internet como conhecemos hoje, começou.

Concluindo com a continuidade das práticas de sistemas distribuídos

A ideia aqui é mostrar que não há nada de novo. O microserviço traz alguns padrões e práticas que aprenderemos neste curso, mas está apenas utilizando práticas de sistemas distribuídos que a ciência da computação já conhece há muito tempo. Ao longo desta aula, vamos explicar como funciona o microserviço e quais são as diferenças em relação a outros tipos de arquitetura.

Fundamentos de sistemas distribuídos - Monolito vs microsserviços

Discutindo as diferenças entre monolito e micro-serviço

Vamos discutir as diferenças entre o monolito tradicional e o micro-serviço. Quando não temos muita experiência, sabemos que, dentro do monolito, uma das complexidades é a presença de várias regras de negócio. Por exemplo, podemos ter a funcionalidade de usuário, pedidos, produto e estoque. Essas funcionalidades estão frequentemente espalhadas e, muitas vezes, muito interligadas, o que pode causar problemas no código. Quando alteramos uma parte, podemos acabar afetando outra, devido à mistura excessiva.

Por outro lado, no micro-serviço, há uma divisão mais clara. Podemos ter a funcionalidade de usuário separada de pedidos, produto e estoque. Esses serviços se comunicam entre si, como o produto se comunicando com o pedido, que se comunica com o estoque. Muitas vezes, quem não tem muita experiência pode afirmar que o monolito é uma má arquitetura e que tudo deve ser feito em micro-serviços. No entanto, qualquer tipo de arquitetura pode ser ineficaz se mal implementada. Uma implementação ruim de micro-serviços pode resultar em um produto insatisfatório, assim como no monolito.

Explorando a escolha entre monolito e micro-serviço

É importante reforçar que não existe uma arquitetura superior à outra. Não há uma solução única que resolva todos os problemas. Se isso fosse verdade, grandes empresas como Shopify e Amazon não estariam retornando ao monolito. Muitas vezes, precisamos resolver questões com micro-serviços, mas isso traz uma complexidade maior, algo que pessoas menos experientes no desenvolvimento de software podem não compreender.

Vamos explorar as diferenças entre essas duas arquiteturas e quando utilizar cada uma. O monolito é mais simples para começar. Em uma startup ou negócio pequeno, iniciar com micro-serviços pode não ser uma boa prática, a menos que tenhamos uma ideia clara do que precisamos desenvolver e que isso não mudará, o que é raro no desenvolvimento de software. Mudanças são parte do processo, e é por isso que precisamos de muitos desenvolvedores.

Comparando a complexidade e a escalabilidade

O monolito é mais fácil de começar e tem menos complexidade. Em um cenário monolítico, temos um único banco de dados e o que chamamos de atomicidade. Quando salvamos dados, todas as funcionalidades são atualizadas ao mesmo tempo. Se houver uma mudança em pedido, produto, estoque e usuário, um único commit faz todas as alterações. No micro-serviço, isso não acontece. Podemos criar um pedido e depois atualizar o estoque, resultando em dados momentaneamente desatualizados. Embora existam filas para atualizar, essa complexidade está presente.

Depurar erros é mais fácil no monolito, pois temos toda a pilha de erros, mensagens e logs em um só lugar. No micro-serviço, analisar o que aconteceu é mais complexo, embora ferramentas modernas como Datadog e New Relic ajudem bastante. No entanto, o monolito não oferece benefícios em todos os aspectos. No micro-serviço, se quisermos escalar, podemos aumentar a capacidade de um serviço específico, como pedidos, sem afetar os demais. No monolito, seria necessário escalar todo o código, incluindo todas as funcionalidades.

Considerando a eficiência e a independência das equipes

No final, vamos considerar que temos, de forma concorrente, três pods rodando no Kubernetes ou três serviços web rodando no Azure, ou em qualquer outro lugar. Se quisermos aumentar para 10, será necessário subir todos os 10, o que pode ser mais custoso, pois estamos subindo todos os serviços. No entanto, em outra abordagem, subimos apenas um serviço, o que é mais eficiente.

Além disso, cada serviço de um microserviço possui seu próprio banco de dados. Isso não significa que sempre teremos, mas há uma facilidade em obter requisições mais rápidas, pois cada banco está em uma instância separada. Quando fazemos uma requisição em pedidos, estamos acessando um banco de dados que contém apenas dados de pedidos, sem os dados de todo o monolito. Nesse caso, os serviços tendem a ser mais rápidos, retornando informações de maneira mais ágil.

Avaliando a comunicação e a gestão de equipes

Obviamente, existe outra complexidade. Dentro do monolito, quando um pedido faz uma chamada em produto, essa chamada é feita via memória local. No caso dos microserviços, a chamada é feita via rede, o que é mais lento do que uma chamada via memória. Portanto, o monolito oferece vários benefícios, mas é necessário ponderar se esses benefícios realmente compensam. Se o monolito fosse apenas vantajoso, empresas como Netflix e Google utilizariam essa abordagem, mas não é o que acontece.

A razão para isso é que, além de ser escalável, cada serviço pode ser gerido de forma independente, permitindo que cada equipe cuide de um serviço específico. É desafiador ter 50 equipes mantendo um único monolito. Com microserviços, os serviços são divididos entre equipes. Por exemplo, existe uma equipe responsável por usuários, que tem independência para modificar qualquer funcionalidade do serviço de usuário, e outra equipe para pedidos, com a mesma independência. Esse é o maior benefício dos microserviços. Embora muitos destaquem aspectos tecnológicos como benefícios, a independência das equipes é o principal.

Concluindo sobre a escolha de arquitetura

Podemos encontrar essa conclusão em diversos livros sobre sistemas distribuídos e microserviços. O maior benefício é a independência que cada equipe tem para trabalhar sem depender de outras. Assim, temos a diferença entre monolito e microserviço. No microserviço, há outros benefícios, como a possibilidade de cada equipe escolher a melhor linguagem para resolver um problema específico. No monolito, há apenas uma linguagem. Com microserviços, podemos usar C#, Python, Go para desempenho, ou JavaScript, conforme o background da equipe.

Cada equipe pode escolher a linguagem que melhor se adapta ao seu conhecimento e ao problema a ser resolvido. Nas grandes empresas, é comum encontrar um mix de linguagens, com equipes de JavaScript, Go, C# e Java. Esse mix de linguagens pode ser visto como um problema por algumas pessoas, mas não é necessariamente ruim. Cada linguagem tem seus pontos fortes e fracos, e podemos utilizá-las para atacar problemas específicos da empresa.

Por exemplo, Python é excelente para ciência de dados. Não faz sentido usar Java apenas porque é o padrão da empresa. Devemos utilizar a melhor linguagem para cada problema. Além disso, podemos criar e testar serviços rapidamente com microserviços, algo mais complicado em um monolito. Apresentamos aqui os prós e contras de ambas as abordagens para que possamos decidir quando usar uma ou outra.

Neste curso, abordaremos tudo sobre microserviços, mas é importante deixar claro que não existe uma arquitetura ideal para todos os problemas. Não há uma solução única. Devemos pensar cuidadosamente sobre qual arquitetura adotar, considerando o problema e o contexto. Não afirmaremos que uma é melhor que a outra. Cabe a nós e à nossa equipe discutir e decidir o que é melhor para o nosso problema.

Sobre o curso Microsserviços em Python: comunicação, testes e resiliência

O curso Microsserviços em Python: comunicação, testes e resiliência possui 257 minutos de vídeos, em um total de 68 atividades. Gostou? Conheça nossos outros cursos de Python em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• capitulo