O que são microsserviços?

É provável que os microsserviços sejam pelo menos tão populares entre executivos e líderes de projeto quanto entre desenvolvedores. Essa é uma das características mais incomuns dos microsserviços, pois o entusiasmo com a arquitetura normalmente é reservado às equipes de desenvolvimento de software. A razão para isso é que os microsserviços refletem melhor a maneira como muitos líderes de negócios desejam estruturar e administrar suas equipes e processos de desenvolvimento.

Em outras palavras, os microsserviços são um modelo de arquitetura que facilita melhor um modelo operacional desejado. Em uma pesquisa da IBM de 2021 com mais de 1.200 desenvolvedores e executivos de TI, 87% dos usuários de microsserviços concordaram que a adoção de microsserviços vale a despesa e o esforço. 

Aqui estão apenas alguns dos benefícios corporativos dos microsserviços:

Implementável de forma independente

Talvez a característica mais importante dos microsserviços seja que, como os serviços são menores e implementáveis de forma independente, não é mais necessário um ato do congresso para alterar uma linha de código ou adicionar um novo recurso na aplicação.

Os microsserviços prometem às organizações um antídoto para as frustrações viscerais associadas a pequenas mudanças que levam muito tempo. Não é necessário um Ph.D. em ciência da computação para ver ou entender o valor de uma abordagem que facilita melhor a velocidade e a agilidade.

Mas a velocidade não é o único valor de projetar serviços dessa maneira. Um modelo organizacional emergente comum é a reunião de equipes multifuncionais em torno de um problema de negócios, serviço ou produto. O modelo de microsserviços se encaixa perfeitamente nessa tendência porque possibilita que uma organização crie equipes pequenas e multifuncionais em torno de um serviço ou uma coleção de serviços e faça com que operem de forma ágil.

O acoplamento frouxo dos microsserviços também cria um grau de isolamento de falhas e melhor resiliência nas aplicações. E o tamanho reduzido dos serviços, combinado com seus limites e padrões de comunicação claros, facilita que os novos membros da equipe entendam a base de código e contribuam com ela rapidamente, um claro benefício em termos de velocidade e moral dos funcionários.

Ferramenta certa para o trabalho

Nos padrões tradicionais de arquitetura de n camadas, uma aplicação normalmente compartilha uma pilha comum, com um grande banco de dados relacional que oferece suporte a todo a aplicação.

Essa abordagem tem várias desvantagens óbvias, a mais significativa delas é que todos os componentes de uma aplicação devem compartilhar uma pilha, um modelo de dados e um banco de dados comuns, mesmo que haja uma ferramenta clara e melhor para o trabalho para determinados elementos. Isso contribui para uma arquitetura ruim e é frustrante para os desenvolvedores que estão constantemente cientes de que há uma maneira melhor e mais eficiente de construir esses componentes.

Por outro lado, em um modelo de microsserviços, os componentes são implantados de forma independente e se comunicam por meio de uma combinação de REST, streaming de eventos e agentes de mensagens, portanto é possível que a pilha de cada serviço individual seja otimizada para esse serviço. A tecnologia muda o tempo todo, e uma aplicação composto por vários serviços menores é muito mais fácil e menos dispendioso de evoluir com uma tecnologia mais desejável à medida que ela se torna disponível.

Dimensionamento preciso

Com microsserviços, serviços individuais podem ser implantados individualmente, mas também podem ser dimensionados individualmente. O benefício resultante é óbvio: feitos corretamente, os microsserviços exigem menos infraestrutura do que aplicações monolíticas porque permitem o dimensionamento preciso somente dos componentes que exigem isso, em vez de toda a aplicação no caso de aplicações monolíticas.

Desafios dos microsserviços

Os benefícios significativos dos microsserviços vêm com desafios significativos.

Passar do monólito para os microsserviços significa muito mais complexidade de gerenciamento - muito mais serviços, criados por muito mais equipes, implantados em muito mais lugares. Problemas em um serviço podem causar ou ser cautilizados por problemas em outros serviços.

Os dados de log (utilizados para monitoramento e resolução de problemas) são mais volumosos e podem ser inconsistentes entre os serviços. Novas versões podem causar problemas de compatibilidade com versões anteriores. As aplicações envolvem mais conexões de rede, o que significa mais oportunidades para problemas de latência e conectividade.

Uma abordagem de DevOps pode resolver muitos desses problemas, mas a adoção do DevOps tem seus próprios desafios.

No entanto, esses desafios não impedem que os não adotantes adotem microsserviços, nem que os adotantes aprofundem seus compromissos com microsserviços. Os dados da pesquisa da IBM acima mencionados revelam que 56% dos não usuários atuais provavelmente ou muito provavelmente adotarão microsserviços nos dois anos seguintes e 78% dos usuários atuais de microsserviços provavelmente aumentarão o tempo, o dinheiro e o esforço que investiram em microsserviços.

A arquitetura de microsserviços é frequentemente descrita como otimizada para DevOps e integração contínua ou entrega contínua e, no contexto de pequenos serviços que podem ser implementados com frequência, é fácil entender o porquê.

Mas outra maneira de analisar a relação entre microsserviços e DevOps é que as arquiteturas de microsserviços realmente exigem DevOps para serem bem-sucedidas.

Embora as aplicações monolíticas tenham uma série de desvantagens que foram discutidas anteriormente neste artigo, eles têm a vantagem de não serem um sistema distribuído complexo com várias partes móveis e pilhas de tecnologia independentes. Por outro lado, dado o enorme aumento na complexidade, nas partes móveis e nas dependências que acompanham os microsserviços, não seria sensato abordar os microsserviços sem investimentos significativos em implantação, monitoramento e automação do ciclo de vida.

Rosalind Radcliffe apresenta um mergulho mais profundo no DevOps no vídeo:

Os microsserviços não são necessariamente relevantes exclusivamente para a computação em nuvem, mas há algumas razões importantes pelas quais eles frequentemente andam juntos, razões que vão além dos microsserviços serem um estilo de arquitetura popular para novas aplicações e da nuvem ser um destino de hospedagem popular para novas aplicações.

Entre as principais vantagens da arquitetura de microsserviços estão os benefícios de utilização e custo associados à implantação e ao dimensionamento de componentes individualmente. Embora esses benefícios ainda estejam presentes, até certo ponto, na infraestrutura local, a combinação de componentes pequenos e independentemente dimensionáveis com a infraestrutura sob demanda e paga por uso é onde as otimizações reais de custo podem ser encontradas.

Em segundo lugar, e talvez mais importante, outro benefício principal dos microsserviços é que cada componente individual pode adotar a pilha mais adequada ao seu trabalho específico. A proliferação da pilha pode levar a sérias complexidades e despesas gerais quando você a gerencia, mas consumir a pilha de suporte como serviços de nuvem pode minimizar drasticamente os desafios de gerenciamento. Dito de outra forma, embora não seja impossível implementar sua própria infraestrutura de microsserviços, não é aconselhável, especialmente quando você está somente começando.

Nas arquiteturas de microsserviços, há muitos padrões comuns e úteis de design, comunicação e integração que ajudam a enfrentar alguns dos desafios e oportunidades mais comuns, incluindo os seguintes:

Padrão backend-for-frontend (BFF)

Esse padrão insere uma camada entre a experiência do usuário e os recursos que a experiência utiliza. Por exemplo, um aplicativo utilizado em um desktop terá tamanho de tela, exibição e limites de desempenho diferentes de um dispositivo móvel.

O padrão BFF possibilita que os desenvolvedores criem e ofereçam suporte a um tipo de backend por interface de usuário utilizando as melhores opções para essa interface, em vez de tentar oferecer suporte a um backend genérico que funciona com qualquer interface, mas pode impactar negativamente o desempenho do frontend.

Padrões de entidade e agregados

Uma entidade é um objeto que se distingue por sua identidade. Por exemplo, em um site de comércio eletrônico, um objeto de produto pode ser diferenciado pelo nome, tipo e preço do produto.

Um agregado é uma coleção de entidades relacionadas que devem ser tratadas como uma unidade. Portanto, para o site de comércio eletrônico, um pedido seria uma coleção (agregada) de produtos (entidades) encomendados por um comprador. Esses padrões são utilizados para classificar dados de maneiras significativas.

Padrões de descoberta de serviços

Isso ajuda aplicações e serviços a se encontrarem. Em uma arquitetura de microsserviços, as instâncias de serviço mudam dinamicamente devido a dimensionamento, atualizações, falhas de serviço e até mesmo encerramento de serviço. Esses padrões oferecem mecanismos de descoberta para lidar com essa transitoriedade. O balanceamento de carga pode utilizar padrões de descoberta de serviço utilizando verificações de funcionamento e falhas de serviço como gatilhos para reequilibrar o tráfego.

Padrões de microsserviços de adaptadores

Pense nos padrões de adaptadores da mesma forma que você pensa nos adaptadores de plugue que você utiliza quando viaja para outro país. O objetivo dos padrões de adaptador é ajudar a traduzir relacionamentos entre classes ou objetos que, de outra forma, seriam incompatíveis. Uma aplicação que depende de APIs de terceiros pode precisar utilizar um padrão de adaptador para garantir que a aplicação e as APIs possam se comunicar.

Padrão de aplicação Strangler

Esses padrões ajudam a gerenciar a refatoração de uma aplicação monolítico em aplicações de microsserviços. O nome colorido se refere à forma como uma videira (microsserviços) lentamente e ao longo do tempo ultrapassa e estrangula uma árvore (uma aplicação monolítica).

Embora existam muitos padrões para fazer bem os microsserviços, há um número igualmente significativo de padrões que podem rapidamente colocar qualquer equipe de desenvolvimento em apuros.

Algumas delas, reformuladas como "nãos" de microsserviços, são as seguintes:

Não crie microsserviços

Dito de forma mais precisa, não comece com microsserviços.

Os microsserviços são uma maneira de gerenciar a complexidade quando as aplicações se tornam muito grandes e pesados para serem atualizados e mantidos facilmente. Somente quando você sentir que a dor e a complexidade do monólito começam a surgir é que vale a pena considerar como você pode refatorar essa aplicação em serviços menores. Até sentir essa dor, você nem mesmo tem um monólito que precise de refatoração.

Não faça microsserviços sem DevOps ou serviços de nuvem

Desenvolver microsserviços significa desenvolver sistemas distribuídos, e sistemas distribuídos são difíceis, e são especialmente difíceis se você fizer escolhas que tornam ainda mais difícil.

Tentar fazer microsserviços sem a automação adequada de implementação e monitoramento, ou serviços de nuvem gerenciados para dar suporte à sua infraestrutura agora extensa e heterogênea, é ficar sujeito a muitos problemas desnecessários. Evite esse trabalho para passar o tempo se preocupando com o estado. 

Não crie muitos microsserviços tornando-os muito pequenos

Se você exagerar no “micro” de microsserviços, poderá facilmente acabar com sobrecarga e complexidade que superam os ganhos gerais de uma arquitetura de microsserviços. É melhor buscar serviços maiores e separá-los somente quando começarem a desenvolver características que os microsserviços resolvem, como quando está ficando difícil e lento implantar mudanças, quando um modelo de dados comum está se tornando muito complexo ou quando diferentes partes do serviço têm diferentes requisitos de carga/escala.

Não transforme microsserviços em SOA

Geralmente, microsserviços e SOA são confundidos entre si, já que no nível mais básico ambos estão interessados na criação de componentes individuais reutilizáveis que possam ser consumidos por outras aplicações.

A diferença entre microsserviços e SOA é que os projetos de microsserviços geralmente envolvem a refatoração de uma aplicação para ser mais fácil de gerenciar, enquanto o SOA se preocupa em alterar a maneira com que os serviços de TI funcionam em toda a empresa. Um projeto de microsserviços que se transforma em um projeto de SOA provavelmente falhará sob seu próprio peso.

Não tente ser a Netflix

A Netflix foi uma das pioneiras da arquitetura de microsserviços ao construir e gerenciar uma aplicação que representava um terço de todo o tráfego da Internet, uma espécie de tempestade perfeita que exigiu que eles criassem muitos códigos personalizados e serviços desnecessários para a aplicação comum.

É muito melhor começar com um ritmo possível de controlar, evitando a complexidade e utilizando o máximo possível de ferramentas prontas.

Se você está pronto para saber mais sobre como utilizar microsserviços ou se precisar aprimorar suas habilidades em microsserviços, experimente um destes tutoriais:

• Introdução aos microsserviços
• Laboratório rápido: crie microsserviços de aplicações web altamente escaláveis com Node.js
• Comece a utilizar microsserviços Java utilizando Spring Boot e Cloudant
• Crie, execute e implante microsserviços Spring em cinco minutos
• Microsserviços, SOA e APIs: amigos ou inimigos?