O que são os microsserviços?

Os microsserviços (ou a arquitetura de microsserviços) consistem em uma abordagem arquitetônica nativa de cloud na qual um único aplicativo é composto de muitos componentes ou serviços menores que são implementáveis de forma independente e têm acoplamento fraco. Esses serviços normalmente

• têm a própria stack de tecnologia, incluindo o modelo de banco de dados e gerenciamento de dados;
• comunicam-se sobre uma combinação de APIs de REST, fluxos de eventos e brokers de mensagens; e
• são organizados por recurso de negócios, com a linha separando os serviços que, muitas vezes, são chamados de contexto delimitado.

Embora grande parte da discussão sobre os microsserviços tenha sido relacionada a definições e características arquitetônicas, seu valor pode ser mais facilmente compreendido por meio de benefícios corporativos e de negócios bastante simples:

• O código pode ser atualizado mais facilmente, novos recursos ou funcionalidades podem ser incluídos sem mudar nenhuma parte do aplicativo
• As equipes podem usar stacks e linguagens de programação diferentes para componentes diferentes.
• É possível ajustar a escala dos componentes de forma independente, reduzindo o desperdício e o custo associado ao ajuste de escala de aplicativos inteiros, como nos casos em que há um único recurso sobrecarregado.

Os microsserviços também podem ser entendidos pelo que não são. As duas comparações mais frequentemente associadas à arquitetura de microsserviços são a arquitetura monolítica e a arquitetura orientada a serviços (SOA).

A abordagem da arquitetura monolítica é composta de um grande aplicativo com acoplamento forte, o que é diferente da arquitetura de microsserviços, na qual os microsserviços compõem um único aplicativo de muitos serviços menores com acoplamento fraco.

Para saber mais sobre as diferenças entre a arquitetura monolítica e a de microsserviços, assista a este vídeo (6:37):

 

As diferenças entre a arquitetura de microsserviços e a SOA podem ser um pouco menos claras. Embora seja possível elaborar contrastes técnicos entre a arquitetura de microsserviços e a SOA, especialmente com relação à função do barramento de serviço corporativo (ESB), é mais fácil considerar a diferença dos escopos. A SOA foi um esforço corporativo de padronização da forma como todos os serviços da web em uma empresa conversam entre si e se integram, enquanto a arquitetura de microsserviços é específica do aplicativo.

A postagem "SOA vs. Microservices: What's the Difference?" oferece detalhes adicionais.

Como os microsserviços beneficiam a empresa

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

Os microsserviços são um modelo arquitetônico que facilita a aquisição do modelo operacional desejado. Em uma pesquisa recente da IBM com mais de 1.200 desenvolvedores e executivos de TI, 87% dos usuários de microsserviços concordaram que a adoção deles foi benéfica, tanto economicamente quanto logisticamente. Para sabe mais perspectivas sobre os benefícios e os desafios dos microsserviços, use a ferramenta interativa abaixo:

(Fonte: 'Microservices in the enterprise 2021: Real benefits, worth the challenges').

Veja a seguir apenas alguns dos muitos benefícios corporativos oferecidos pelos microsserviços.

Implementáveis de forma independente

É possível que a característica mais importante dos microsserviços seja que os serviços são menores e implementáveis de forma independente, o que elimina a necessidade de um ato do Congresso para mudar uma linha de código ou incluir um novo recurso no aplicativo.

Os microsserviços prometem às empresas a resolução das frustrações associadas a quantia enorme de tempo que é necessária para fazer pequenas mudanças. Não é necessário ser um Ph.D. em ciência da computação para compreender o valor de uma abordagem que facilita e aprimora a velocidade e a agilidade.

Mas a velocidade não é o único benefício de projetar serviços desta forma. Um novo modelo organizacional comum é unir equipes de diversas funções diferentes na resolução de um problema de negócios, serviço ou produto. O modelo de microsserviços se ajusta facilmente a essa tendência porque possibilita que uma empresa crie equipes pequenas e com diversas funções com relação a um serviço ou a uma coleção deles para agilizar as operações.

O acoplamento fraco dos microsserviços também fornece um nível de isolamento de falhas, além de melhor resiliência para os aplicativos. O pequeno tamanho dos serviços, combinado com seus padrões de comunicação e limites claros, facilita a compreensão dos novos membros da equipe quanto à base de código para acelerar as contribuições, o que oferece um benefício claro em termos de velocidade e engajamento da equipe.

Ferramenta ideal para a tarefa

Nos padrões tradicionais de arquitetura de n camadas, um aplicativo geralmente compartilha uma stack comum com um grande banco de dados relacional que suporta todo o aplicativo. Essa abordagem tem várias desvantagens óbvias, sendo a mais significativa o fato de que todo componente de um aplicativo deve compartilhar uma pilha, um modelo de dados e um banco de dados comuns, mesmo que haja uma ferramenta clara e melhor para a tarefa em determinados elementos. Isso gera uma arquitetura ruim e frustra os desenvolvedores que estão sempre cientes de que há uma maneira melhor e mais eficiente para desenvolver esses componentes.

Por outro lado, em um modelo de microsserviços, os componentes são implementados de forma independente e se comunicam sobre alguma combinação de REST, fluxos de eventos e brokers de mensagens, o que permite que a solução de cada serviço individual seja otimizada para ele. A tecnologia muda o tempo todo, e um aplicativo composto por diversos serviços menores simplifica e reduz os custos do desenvolvimento quando uma tecnologia mais adequada se torna disponível.

Ajuste de escala preciso

Com os microsserviços, a implementação e o ajuste de escala dos serviços ocorre de forma individual. O benefício é óbvio: Quando executados corretamente, os microsserviços requerem menos infraestrutura do que os aplicativos monolíticos porque permitem que um ajuste de escala preciso seja feito somente nos componentes necessários, em vez de em todo o aplicativo, no caso de aplicativos monolíticos.

Há também desafios

Além dos benefícios significativos, há também desafios significativos relativos aos microsserviços. Mudar de uma arquitetura monolítica para uma de microsserviços significa muito mais complexidade de gerenciamento, muito mais serviços, criados por muito mais equipes e implementados em muito mais lugares. Os problemas que ocorrem em um serviço podem causar ou ser a causa de problemas em outros. O registro de dados (usados para o monitoramento e a resolução de problemas) gera mais volume e pode ser inconsistente entre os serviços. Novas versões podem causar problemas de compatibilidade com versões anteriores. Os aplicativos envolvem mais conexões de rede, o que significa mais oportunidades para problemas de latência e conectividade. Uma abordagem de DevOps (como explicado abaixo) pode lidar com diversas dessas questões, mas sua adoção tem desafios próprios.

No entanto, esses desafios não prejudicam a alta adoção dos microsserviços - ou não impedem os usuários de aprofundar seus compromissos com os microsserviços.Novos dados de uma pesquisa feita pela IBM revelam que 56% das pessoas que não são atualmente usuários estão propensas ou muito propensas a adotar os microsserviços nos próximos dois anos. Além disso, 78% dos usuários atuais provavelmente investirão mais tempo, dinheiro e esforços em seus microsserviços (ver Figura 1).

Figura 1: os microsserviços são uma tecnologia duradoura. Nos próximos dois anos, 56% das pessoas que não são atualmente usuários devem adotar os microsserviços, 78% das pessoas que são usuários devem aumentar seu investimento neles e 59% dos aplicativos serão criados com eles. (Fonte: 'Microservices in the enterprise 2021: Real benefits, worth the challenges').

Os microsserviços permitem o uso de DevOps, mas também precisam dele

A arquitetura de microsserviços é frequentemente descrita como otimizada para DevOps e para a integração/entrega contínuas (CI/CD). No contexto de pequenos serviços que podem ser implementados com frequência, é fácil entender o porquê.

Mas outra forma de analisar este relacionamento entre microsserviços e DevOps é que as arquiteturas de microsserviços, na verdade, requerem DevOps para ter sucesso. Embora os aplicativos monolíticos tenham uma variedade de desvantagens (que foram discutidas anteriormente neste artigo), seu benefício é não ser um sistema distribuído e complexo com diversas peças móveis e stacks de tecnologia independentes. Em contraste, dado o enorme aumento de complexidade, movimentação de peças e dependências decorrentes dos microsserviços, são necessários investimentos significativos em implementação, monitoramento e automação do ciclo de vida.

Andrea Crawford oferece mais detalhes sobre DevOps no vídeo a seguir:

Principais tecnologias e ferramentas de ativação

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:

Os contêineres, o Docker e o Kubernetes

Um dos principais elementos de um microsserviço é que ele é geralmente bem pequeno (embora não haja uma quantia arbitrária de código que determine se algo é ou não um microsserviço, "micro" faz parte do nome).

Quando o Docker chegou à era do contêiner moderno em 2013, também apresentou 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.

No vídeo "Kubernetes Explained", Sai Vennam fornece uma visão abrangente de tudo relacionado ao Kubernetes:

 

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. Não é prático adotar uma abordagem com base em apuração constante para saber se os serviços foram atualizados.

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 melhor 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 desenvolver sistemas distribuídos, altamente escaláveis, tolerantes a falhas e extensíveis que são capazes de consumir e processar quantias enormes de eventos ou informações em tempo real.

Sem servidor

As arquiteturas sem servidor 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 sem servidor 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 sem servidor 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.

Microsserviços e serviços em cloud

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 arquitetônico 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 on-premises, 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.

Padrões comuns

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 de 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 agregado e entidade: uma entidade é um objeto distinguido 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 microsserviços de adaptador: os padrões de adaptador são similares aos adaptadores de tomada usados em viagens para outro país. 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 aplicativo estrangulador: 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).

Saiba mais sobre esses padrões em "Como utilizar padrões de desenvolvimento com microsserviços (parte 4)". O IBM Developer também fornece muitas informações para saber mais sobre outros padrões de código de microsserviços.

Antipadrões

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 é não desenvolver microsserviços, ou seja, não começar com 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 adote microsserviços sem DevOps ou serviços de cloud: desenvolver microsserviços significa desenvolver sistemas distribuídos, ou seja, haverá complexidade (especialmente se você tomas 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, concentre-se no estado.
• Não reduza o tamanho dos microsserviços drasticamente: 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 uma 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 vai dar errado.
• Não tente ser 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 numero de ferramentas prontas para uso possível.

Tutoriais: Desenvolva qualificações relacionadas aos microsserviços

Para saber mais sobre como usar microsserviços ou desenvolver qualificações com relação a eles, experiente um destes tutoriais:

• Introdução aos microsserviços
• Laboratório rápido: Criar 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
• Criar, executar e implementar microsserviços Spring em cinco minutos
• Microsserviços, SOA e APIs: amigos ou inimigos?

Microsserviços e a IBM Cloud

Os microsserviços permitem um desenvolvimento inovador e na velocidade dos negócios modernos. Saiba como a potencializar a escalabilidade e a flexibilidade da cloud implementando microsserviços independentes em ambientes de cloud. Veja como seria modernizar seus aplicativos com a ajuda da IBM. 

Dê o próximo passo:

• Libere suas equipes de desenvolvimento ao confiar na iteração automatizada com a ajuda das ferramentas de desenvolvimento nativas de cloud da IBM.
• Saiba mais sobre o Kubernetes gerenciado começando a usar Red Hat OpenShift on IBM Cloud ou IBM Cloud Kubernetes Service. Consulte também IBM Cloud Code Engine para saber mais sobre a computação sem servidor.
• Os microsserviços abrangem tanto a organização e o processo de equipe quanto a tecnologia. Planeje sua abordagem de DevOps estrategicamente com ajuda do IBM DevOps.

Comece a usar hoje com uma conta da IBM Cloud.