Embora qualquer ferramenta ou linguagem moderna possa ser usada em uma arquitetura de microsserviços, há um variedade de ferramentas importantes que se tornaram essenciais e praticamente definitivas para os microsserviços:

Contêineres, Docker e Kubernetes

Uma das principais características de um microsserviço é que geralmente é bem pequeno. Não existe um volume específico de código que determine se algo é ou não um microsserviço, mas "micro" está lá no nome.

Quando oDocker iniciou a era do contêiner moderno em 2013, também introduziu um modelo de computação que se tornaria muito associado aos microsserviços. Como os  contêineres  individuais não têm a sobrecarga do próprio sistema operacional, são menores e mais leves do que as  máquinas virtuais  tradicionais e podem girar para cima e para baixo mais rapidamente, são ideais para os serviços menores e mais leves encontrados nas arquiteturas de microsserviços.

Com a proliferação de serviços e contêineres, orquestrar e gerenciar grandes grupos de contêineres rapidamente tornou-se um dos maiores desafios. O Kubernetes, uma plataforma de software livre  para a orquestração de contêineres,  surgiu como uma das soluções de orquestração mais populares porque é muito eficaz.

Gateways de API

Os microsserviços muitas vezes se comunicam por meio de APIs, especialmente para estabelecer o estado inicial. Embora os clientes e serviços possam se comunicar diretamente, os gateways de API consistem muitas vezes em uma camada intermediária útil, especialmente à medida que o número de serviços em um aplicativo cresce ao longo do tempo. Um gateway de API atua como um proxy reverso para os clientes, roteando as solicitações e as distribuindo entre diversos serviços para fornecer segurança e autenticação adicionais.

Há diversas tecnologias para a implementação de gateways de API, incluindo plataformas de gerenciamento de API, mas quando a arquitetura de microsserviços está sendo implementada com contêineres e com o Kubernetes, o gateway é normalmente implementado com o Ingress ou, mais recentemente, com o  Istio.

Sistema de mensagens e fluxos de eventos

Embora a melhor prática seja desenvolver serviços sem estado, o estado ainda existe e os serviços precisam estar atentos a ele. E embora uma chamada de API seja muitas vezes eficaz para estabelecer inicialmente o estado de um determinado serviço, ela não é particularmente eficaz para manter-se atualizado sobre ele. Uma pergunta constante, a abordagem "já chegamos aonde gostaríamos?" para manter os serviços atual simplesmente não é prática.

Em vez disso, é preciso acoplar chamadas de API de estabelecimento de estado com sistemas de mensagens ou fluxos de eventos para que os serviços possam transmitir as mudanças de estado e outras partes interessadas possam ouvir essas mudanças e fazer os ajustes necessários. Esta tarefa pode ser mais bem executada por um broker de mensagens de propósito geral, mas há casos nos quais uma plataforma de fluxos de eventos, como o Apache Kafka, é mais adequada. Ao combinar os microsserviços com a  arquitetura orientada a eventos,  os desenvolvedores  podem criar sistemas distribuídos, altamente escaláveis, tolerantes a falhas e extensíveis que são capazes de consumir e processar quantidades enormes de eventos ou informações em tempo real.

Serverless

As arquiteturas serverless utilizam alguns dos padrões de cloud e de microsserviços em sua conclusão lógica. Nesse caso, a unidade de execução não é só um pequeno serviço, mas uma função, que muitas vezes pode ter poucas linhas de código. As diferenças entre uma função serverless e um microsserviço não são muito claras, mas as funções são consideradas ainda menores do que um microsserviço.

Tanto as arquiteturas serverless e as plataformas de  função como serviço (FaaS)  quanto os microsserviços tem como objetivo criar unidades menores de implementação e ajustar precisamente a escala de acordo com a demanda.

Não é necessariamente só a área de cloud computing que vê relevância nos microsserviços, mas há algumas razões importantes que justificam esse interesse e que vão além da popularidade do estilo de arquitetura dos microsserviços e da cloud como destino de hospedagem para novos aplicativos.

Entre os principais benefícios da arquitetura de microsserviços estão a utilização e o custo associados à implementação e ao ajuste de escala de cada componente. Embora isso, de certa forma, também seja um benefício da infraestrutura local, só é possível obter uma otimização de custo real ao combinar componentes pequenos e que podem ter sua escala ajustada de maneira independente com uma infraestrutura sob demanda e com pagamento por uso.

Além disso, outro grande benefício dos microsserviços, talvez até mesmo o mais importante, é que cada componente individual pode adotar a stack mais adequada à sua tarefa específica. Enquanto a proliferação de stacks pode gerar grande complexidade e sobrecarga quando gerenciada por conta própria, consumir a stack de suporte na forma de serviços de cloud pode minimizar drasticamente os desafios de gerenciamento. Embora não seja impossível implementar sua própria infraestrutura de microsserviços, isso não é recomendado, especialmente quando você está apenas começando.

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

Padrão back-end para front-end (BFF). Esse padrão insere uma camada entre a experiência do usuário e os recursos usados por ela. Por exemplo, um aplicativo usado em uma área de trabalho terá um tamanho de tela, uma exibição e limites de desempenho diferentes daqueles em um dispositivo móvel. O padrão BFF permite que desenvolvedores criem e suportem um tipo de back-end por interface com o usuário usando as melhores opções para essa interface, em vez de tentar suportar um back-end genérico que funciona com qualquer interface, mas que pode impactar negativamente o desempenho do front-end.

Padrões de entidades e agregados. Uma entidade é um objeto diferenciado por sua identidade. Por exemplo, em um site de e-commerce, um objeto de produto pode ser distinguido por nome, tipo e preço. Um agregado é uma coleção de entidades relacionadas que deve ser tratada como uma unidade. Portanto, para o site de e-commerce, um pedido seria uma coleção (agregado) de produtos (entidades) solicitada por um comprador. Esses padrões são usados para classificar dados de maneiras significativas.

Padrões de descoberta de serviço. Esses aplicativos e serviços de ajuda são combinados. Em uma arquitetura de microsserviços, as instâncias de serviço mudam dinamicamente devido ao ajuste de escala, aos upgrades, às falhas de serviço e até mesmo à rescisão de serviço. Esses padrões fornecem mecanismos de descoberta para lidar com essa transitoriedade. O balanceamento de carga pode adotar estes padrões de descoberta de serviço usando verificações de funcionamento e falhas de serviço como acionadores para reequilibrar o tráfego.

Padrões de adaptadores de microsserviços. Os padrões de adaptadores são similares aos adaptadores de tomada usados em viagens para outros países. A finalidade dos padrões de adaptador é ajudar a traduzir os relacionamentos entre classes ou objetos que seriam incompatíveis. Um aplicativo que usa APIs de terceiros pode precisar de um padrão de adaptador para garantir a comunicação entre o aplicativo e as APIs.

Padrão de aplicação Strangler. Estes padrões ajudam a gerenciar a refatoração de um aplicativo monolítico em aplicativos de microsserviços. O nome criativo se refere a como uma videira (microsserviços) lentamente toma conta e estrangula uma árvore (um aplicativo monolítico).

Você pode saber mais sobre esses padrões em "Como usar padrões de desenvolvimento com microsserviços (parte 4)". O IBM Developer também oferece um lote de informações caso você deseje descobrir sobre outros padrões de código de microsserviços.

Embora existam muitos padrões úteis para os microsserviços, há um número igualmente significativo de padrões que podem causar problemas para qualquer equipe de desenvolvimento. Veja a seguir alguns deles, considerados ruins para os microsserviços:

A primeira regra dos microsserviços é não criar microsserviços. Mais precisamente, não comece a partir dos microsserviços. Os microsserviços são uma forma de gerenciar a complexidade de aplicativos que ficaram grandes demais para serem atualizados e mantidos com facilidade. Ao notar as dificuldades e a complexidade do aplicativo monolítico, vale a pena considerar como refatorá-lo em serviços menores. Até lá, não se preocupe com isso. Não haverá um monólito que precisa de refatoração.

Não faça microsserviços sem DevOps ou serviços de cloud. Desenvolver microsserviços significa desenvolver sistemas distribuídos, ou seja, haverá complexidade (especialmente se você tomar as decisões erradas). Você terá muitos problemas ao tentar usar microsserviços sem a) implementação e automação de monitoramento adequadas ou b) serviços de cloud gerenciados para suportar sua nova infraestrutura extensa e heterogênea. Em vez disso, economize tempo e concentre-se apenas no estado. 

Não crie muitos microsserviços tornando-os muito pequenos. Ao fazer isso, pode haver sobrecarga e complexidade superiores aos ganhos gerais da arquitetura de microsserviços. É melhor usar serviços maiores e separá-los apenas quando eles começarem a desenvolver características que podem ser resolvidas pelos microsserviços, ou seja, quando a implementação de mudanças é difícil e lenta, um modelo de dados comum está se tornando muito complexo ou diferentes partes do serviço têm diferentes requisitos de carga/escala.

Não transforme os microsserviços em SOA. Os microsserviços e a arquitetura orientada a serviços (SOA) são frequentemente assimilados como a mesma coisa, dado que em seu nível mais básico, ambos estão interessados em desenvolver componentes individuais reutilizáveis que possam ser consumidos por outros aplicativos. A diferença entre eles é que os projetos de microsserviços geralmente envolvem a refatoração de um aplicativo para facilitar o gerenciamento, enquanto a SOA se preocupa em mudar a forma como os serviços de TI funcionam em toda a empresa. Um projeto de microsserviços que se transforma em um projeto de SOA provavelmente apresentará problemas.

Não tente ser igual a Netflix. A Netflix foi um dos pioneiros da arquitetura de microsserviços ao desenvolver e gerenciar um aplicativo que representava um terço de todo o tráfego da Internet, o que exigiu muitos serviços e código customizados que eram desnecessários para o aplicativo de forma geral. É muito melhor começar aos poucos, evitando a complexidade e usando o maior número de ferramentas prontas para uso possível.

Para saber mais sobre como usar microsserviços ou desenvolver habilidades relacionadas a eles, experiente um destes tutoriais:

• Introdução aos microsserviços
  
  
• Quick lab: crie microsserviços de aplicativos da web altamente escaláveis com o Node.js
  
  
• Comece a usar os microsserviços Java usando o Spring Boot e o Cloudant
  
  
• Crie, execute e implemente microsserviços Spring em cinco minutos
  
  
• Microsserviços, SOA e APIs: amigos ou inimigos?