O que são microsservicos?

Microsserviços são uma abordagem de arquitetura para a criação de aplicações. Como um framework de arquitetura, microsserviços são distribuídos e levemente acoplados para que as mudanças feitas por uma equipe não corrompam toda a aplicação. A vantagem de usar microsserviços é que as equipes de desenvolvimento conseguem criar rapidamente novos componentes de app para atender às dinâmicas necessidades empresariais.

O que diferencia a arquitetura de microsserviços das abordagens monolíticas mais tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é chamada de serviço e pode ser criada e implantada de maneira independente. Em outras palavras, cada serviço individual pode funcionar ou falhar sem comprometer os demais. Isso ajuda você a adotar o lado tecnológico do DevOps e tornar a iteração e a entrega constantes (CI/CD) mais otimizadas e viáveis.

Pense na última vez em que você visitou uma loja online.  Provavelmente, você usou a barra de pesquisa do site para procurar produtos. Essa pesquisa representa um serviço. Talvez você também tenha visto recomendações de produtos relacionados, extraídas de um banco de dados das preferências de clientes. Isso também é um serviço. Você adicionou algum item ao carrinho de compras? Isso mesmo, esse é mais um serviço.

Portanto, um microsserviço é como uma função essencial de uma aplicação sendo executado independentemente dos outros serviços. No entanto, a arquitetura de microsserviços é mais complexa do que o mero acoplamento flexível das funções essenciais de uma app. Trata-se da restruturação das equipes de desenvolvimento e da comunicação entre serviços de modo a preparar a aplicação para falhas inevitáveis, escalabilidade futura e integração de funcionalidades novas.

Como isso é possível? Com a adaptação dos fundamentos da arquitetura orientada a serviços (SOA) para a implantação de microsserviços.

O método de decomposição de apps em funções essenciais para evitar os problemas provocados pelas abordagens monolíticas soa familiar? É porque o estilo de arquitetura de microsserviços é semelhante ao da arquitetura orientada a serviço (SOA), já consagrado no desenvolvimento de software.

Nos primórdios do desenvolvimento de apps, até mesmo as alterações mais insignificantes em uma aplicação pronta exigiam uma atualização da versão universal, com um ciclo próprio de garantia da qualidade (QA). Isso provavelmente atrasava o trabalho de muitas subequipes. Muitas vezes, essa abordagem era chamada de "monolítica" porque o código-fonte da app toda era incorporado em uma única unidade de implantação, como .war ou .ear. Se a atualização de alguma parte causasse erros, seria necessário desativar a aplicação inteira, reverter a escala e corrigir o problema. Embora essa abordagem ainda seja viável para aplicações menores, as empresas em ampla expansão não podem se dar ao luxo de sofrer com downtime.

A arquitetura orientada a serviço serve para resolver essa questão, pois estrutura as apps em serviços distintos e reutilizáveis que se comunicam por meio de um ESB (Enterprise Service Bus). Nessa arquitetura, os serviços individuais, cada um deles organizado em torno de um processo de negócios específico, aderem a um protocolo de comunicação (como SOAP, ActiveMQ ou Apache Thrift) para que sejam compartilhados por meio do ESB. Quando reunidos em um pacote integrado por meio de um ESB, esses serviços formam uma aplicação.

Por um lado, isso permite criar, testar e ajustar os serviços de maneira simultânea, eliminando os ciclos de desenvolvimento monolíticos. Por outro, o ESB representa um ponto único de falha no sistema inteiro. Portanto, todo o esforço empregado para eliminar uma abordagem monolítica, de certo modo, serviu apenas para criar outra: o ESB, que pode congestionar toda a organização.

Qual é a diferença? Os microsserviços podem se comunicar entre si, normalmente de maneira stateless. Dessa forma, as apps assim criadas podem ser mais tolerantes a falhas e depender menos de um único ESB. Além disso, as equipes de desenvolvimento podem escolher as ferramentas que desejarem, pois os microsserviços conseguem se comunicar usando APIs independentes de linguagem.

Levando em consideração a história da SOA, os microsserviços não são uma ideia completamente nova. Porém, eles se tornaram mais viáveis graças aos avanços nas tecnologias de conteinerização. Com os containers Linux, agora é possível executar várias partes de uma app de maneira independente no mesmo hardware e com um controle muito maior sobre os componentes individuais e ciclos de vida. Com as APIs e as equipes de DevOps, os microsserviços em containers são os pilares das aplicações nativas em nuvem.

Com os microsserviços, você pode aumentar a eficiência das suas equipes e tarefas rotineiras com o desenvolvimento distribuído. Além disso, é possível desenvolver vários microsserviços ao mesmo tempo. Isso significa mais desenvolvedores trabalhando simultaneamente na mesma app, reduzindo o tempo gasto com desenvolvimento.

Se a sua organização pretende migrar para a arquitetura de microsserviços, tenha em mente que serão necessárias mudanças não só nas apps, mas também no modo como as pessoas trabalham. As mudanças organizacionais e culturais podem ser, em parte, consideradas desafios. Isso porque cada equipe terá um ritmo próprio de implantação e será responsável por um serviço exclusivo, com um conjunto próprio de clientes. Elas podem não ser preocupações típicas do desenvolvimento, mas serão essenciais para o sucesso da arquitetura de microsserviços.

Além das mudanças na cultura e nos processos, a complexidade e a eficiência são outros dois grandes desafios da arquitetura baseada em microsserviços. John Frizelle, responsável pela arquitetura de plataformas do Red Hat Mobile, definiu as oito categorias de desafios a seguir em sua palestra no Red Hat Summit de 2017:

1. Compilação: reserve um tempo para identificar as dependências entre os serviços. Observe que concluir uma compilação pode gerar muitas outras devido a essas dependências. Também é necessário levar em consideração como os microsserviços afetam os dados.
2. Testes: os testes de integração, assim como os testes de ponta a ponta, podem se tornar mais difíceis, e mais importantes do que nunca. Saiba que uma falha em uma parte da arquitetura pode provocar outra mais adiante, dependendo de como os serviços foram projetados para oferecer suporte uns aos outros.
3. Controle de versão: ao atualizar para versões novas, lembre-se de que isso pode afetar a compatibilidade com versões anteriores. Para resolver esse problema, é possível usar a lógica condicional. Porém, isso logo pode se tornar outra complicação. Como alternativa, você pode lançar várias versões ativas para clientes diferentes, mas essa solução é mais complexa em termos de manutenção e gerenciamento.
4. Implantação: sim, isso também é um desafio, pelo menos na configuração inicial. Para facilitar a implantação, primeiro é necessário investir bastante na automação, pois os microsserviços são complexos demais para implementar manualmente. Pense sobre o modo e a ordem de implementação dos serviços.
5. Geração de logs: com os sistemas distribuídos, são necessários logs centralizados para unificar tudo. Caso contrário, é impossível gerenciar a escala.
6. Monitoramento: é crítico ter uma visualização centralizada do sistema para identificar as origens dos problemas.
7. Depuração: a depuração remota pelo seu ambiente de desenvolvimento integrado (IDE) local não é uma opção e não funciona com dezenas ou centenas de serviços. Infelizmente, no momento não há uma única resposta sobre como realizar depurações.
8. Conectividade: considere a detecção de serviços, seja de maneira centralizada ou integrada.