Passo 2: Organize suas equipes da maneira certa

Até agora, podia parecer que a construção de microsserviços é um assunto mais técnico. Você precisa dividir uma base de código em vários serviços, implementar os padrões certos para falha normal e recuperação de problemas de rede, lidar com a consistência dos dados, monitorar a carga de serviço etc. Vai haver vários novos conceitos para entender. Mas, sem dúvida, a coisa mais importante que não deve ser ignorada é que você vai precisar reestruturar a maneira como suas equipes são organizadas.

A Lei de Conway é real e pode ser observada em todos os tipos de equipes. Se uma equipe de software for organizada com uma equipe de back-end, uma de front-end e uma de operações separadas, elas vão acabar entregando monólitos de front-end e back-end separados que vão ser jogados para a equipe de operações, que vai passar para a produção. Esse tipo de estrutura de equipe não é adequado para microsserviços, pois cada serviço deve ser visto como seu próprio produto que precisa de lançamento independente dos outros.

Em vez disso, você deve criar equipes DevOps menores que tenham todas as competências necessárias para desenvolver e manter os serviços pelos quais elas estão encarregadas. Há grandes benefícios em organizar suas equipes dessa maneira. Em primeiro lugar, seus desenvolvedores têm uma compreensão melhor do impacto do código na produção, o que ajuda a produzir versões melhores e reduzir o risco de ver problemas lançados aos seus clientes. Em segundo lugar, as implementações se tornam naturais para cada equipe, pois elas trabalham juntas em melhorias no código, bem como na automação do pipeline de implementação.

Passo 3: Divida o monólito para construir uma arquitetura de microsserviços

Quando você tiver identificado os limites dos serviços e descoberto como reestruturar as equipes, vai poder começar a dividir o monólito para criar microsserviços. A seguir estão os pontos-chave a serem considerados nesse momento.

Mantenha a comunicação entre serviços simples com uma API RESTful

Se você ainda não está usando uma API RESTful, agora seria um bom momento para começar a usar em seu sistema. Como Martin Fowler explica, você quer ter "pontos de extremidade inteligentes e pipes burros". Ou seja, o protocolo de comunicação entre seus serviços deve ser o mais simples possível, apenas responsável pela transmissão (e não pela transformação) de dados. Toda a magia vai acontecer nos próprios pontos de extremidade — eles recebem uma solicitação, processam e emitem uma resposta em troca.

As arquiteturas de microsserviços se esforçam para manter as coisas o mais simples possível para evitar o acoplamento apertado dos componentes. Em alguns casos, você pode estar usando uma arquitetura voltada a eventos com comunicações assíncronas baseadas em mensagens. Porém, mais uma vez, você deve olhar para serviços básicos de fila de mensagens, como RabbitMQ, e evitar adicionar complexidade às mensagens transmitidas pela rede.

Divida os dados em contextos limitados ou domínios de dados

Os aplicativos monolíticos usam um único banco de dados para todas os funções de negócios do aplicativo. Como um monólito é dividido em microsserviços, esse banco de dados único pode não fazer mais sentido. Um banco de dados central pode se tornar um gargalo para o dimensionamento do tráfego. Se um determinado serviço acessar o banco de dados com alta carga, ele pode interromper o acesso ao banco de dados de outros serviços. Além disso, um banco de dados único pode ser um gargalo de colaboração para várias equipes que tentam modificar o esquema ao mesmo tempo. Essa situação pode exigir a divisão do banco de dados ou a adição de ferramentas extras de armazenamento de dados para dar suporte às necessidades de dados de microsserviço.

Refatorar um esquema de banco de dados monolítico pode ser uma operação delicada. É importante identificar com clareza de quais conjuntos de dados cada serviço precisa e de quaisquer sobreposições. Esse planejamento de esquema pode ser feito usando contextos limitados, que são um padrão do Domain-Driven Design. Um contexto limitado define um sistema independente, incluindo o que pode entrar e sair desse sistema.

Nesse sistema, quando um usuário acessa um pedido, você pode visualizar as informações do cliente na tabela, que também podem ser usadas para preencher a fatura gerenciada pelo sistema de faturamento. Pode parecer lógico e simples, mas, com microsserviços, os serviços devem ser dissociados para que as faturas possam ser acessadas mesmo se o sistema de pedidos estiver inativo. Além disso, permite otimizar ou evoluir a tabela de faturas independentemente de outras. Cada serviço pode acabar tendo seu próprio armazenamento de dados para acessar os dados de que precisa.

Assim você vai enfrentar novos problemas, pois alguns dados vão ser duplicados em bancos de dados diferentes. Contextos limitados podem identificar a melhor estratégia para lidar com dados compartilhados ou duplicados. Você pode adotar uma arquitetura voltada a eventos para ajudar a sincronizar dados em vários serviços. Por exemplo, seus serviços de rastreamento de faturamento e entrega podem estar ouvindo eventos emitidos pelo serviço de conta quando os clientes atualizam suas informações pessoais. Após a recepção do evento, esses serviços vão atualizar seu armazenamento de dados de acordo. Essa arquitetura voltada a eventos permite que a lógica do serviço de conta seja mantida simples, pois não precisa conhecer todos os outros serviços dependentes. Ele simplesmente diz ao sistema o que ele fez e outros serviços ouvem e agem de acordo.

Você também pode optar por manter todas as informações do cliente no serviço de conta e manter apenas uma referência de chave estrangeira em seu serviço de faturamento e entrega. Em seguida, esses serviços interagem com o serviço de conta para obter dados relevantes do cliente, em vez de duplicar os registros existentes. Como não existe uma solução universal para esses problemas, você vai precisar examinar cada caso específico para determinar a melhor abordagem.

Crie sua arquitetura de microsserviços para falhas

Vimos como os microsserviços podem lhe proporcionar grandes benefícios em relação a uma arquitetura monolítica. Eles são menores em tamanho e especializados, o que os torna fáceis de entender. Eles são dissociados, o que significa que você pode refatorar um serviço sem temer quebrar os outros componentes do sistema, ou retardar o desenvolvimento das outras equipes. Eles também oferecem mais flexibilidade a seus desenvolvedores, pois eles podem escolher tecnologias diferentes, se necessário, sem serem limitados pelas necessidades de outros serviços.

Em suma, ter uma arquitetura de microsserviços facilita o desenvolvimento e a manutenção de cada capacidade de negócios. Mas as coisas se tornam mais complicadas quando você olha para todos os serviços juntos e como eles precisam interagir para concluir ações. Seu sistema agora está distribuído com vários pontos de falha e você precisa lidar com essa situação. Você precisa levar em conta não apenas os casos em que um serviço não está respondendo, mas também ser capaz de lidar com respostas de rede mais lentas. A recuperação de uma falha também pode ser complicada às vezes, pois você precisa ter certeza de que os serviços que voltam a ficar on-line não sejam inundados por mensagens pendentes.

À medida que você começa a extrair recursos de seus sistemas monolíticos, faça com que seus projetos sejam criados para falhas desde o início.

Enfatize o monitoramento para facilitar o teste de microsserviços

O teste é outra desvantagem dos microsserviços em comparação com um sistema monolítico. Um aplicativo criado como uma única base de código não precisa de muito para ter um ambiente de teste em execução. Na maioria dos casos, você vai ter que iniciar um servidor de back-end junto com um banco de dados para poder executar seu conjunto de testes.

No mundo dos microsserviços, as coisas não são tão fáceis. Em relação aos testes unitários, ainda vai ser bastante semelhante ao monólito, e você não deveria ter mais problemas nesse nível. No entanto, quando se trata de integração e testes de sistema, as coisas vão ser muito mais difíceis. Você pode precisar iniciar vários serviços juntos e ter diferentes armazenamentos de dados em funcionamento, e a configuração pode precisar incluir filas de mensagens que não seriam necessárias com o monólito. Nesta situação, fica muito mais caro executar testes funcionais, e o número crescente de elementos dinâmicos torna muito difícil prever os diferentes tipos de falhas que podem acontecer.

O monitoramento pode identificar problemas com antecedência e permitir que você reaja de acordo. Você precisa entender os padrões de diferentes serviços e reagir não apenas quando eles ficam inativos, mas também quando apresentam comportamento inesperado. Uma vantagem de adotar uma arquitetura de microsserviço é que seu sistema deve ser resistente a falhas parciais. Portanto, se você começar a ver anomalias no serviço de rastreamento de entrega do aplicativo Pizzup, não vai ser tão ruim como se fosse um sistema monolítico. O aplicativo deve ser projetado para que todos os outros serviços apresentem as respostas adequadas e permitam que os clientes encomendem pizzas enquanto a gente restaura o rastreamento em tempo real.

Adote a entrega contínua para reduzir o atrito da implementação

O lançamento manual de um sistema monolítico para produção é um esforço tedioso e arriscado, mas possível. É claro que a gente não recomenda essa abordagem e incentiva todas as equipes de software a adotar a entrega contínua para todos os tipos de desenvolvimento; porém, no início de um projeto, você mesmo pode fazer suas primeiras implementações através da linha de comando.

Essa abordagem não é sustentável quando você tem um número crescente de serviços que precisam ser implementados várias vezes ao dia. Assim, como parte de sua transição para microsserviços, é fundamental que você adote a entrega contínua para reduzir os riscos de falha de lançamento, além de garantir que sua equipe esteja focada na criação e execução do aplicativo, em vez de ficar preso na implementação dele. Praticar a entrega contínua também significa que seu serviço passou nos testes de aceitação antes de ir para a produção. É claro que os bugs vão ocorrer, mas, ao longo do tempo, você vai construir um conjunto de testes robusto que deve aumentar a confiança de sua equipe na qualidade das versões.