O que são microsserviços?

Definição de microsserviço

Microsserviços, ou arquitetura de microsserviços, é uma abordagem de arquitetura nativa da nuvem na qual uma única aplicação é composta por muitos componentes ou serviços menores vagamente acoplados e implementáveis de forma independente.

Os microsserviços normalmente:

  • Tenha sua própria pilha de tecnologia, incluindo o banco de dados e o modelo de gerenciamento de dados.
  • Comunicam-se entre si por meio de uma combinação de APIs de transferência de estado representacional (REST), fluxo de eventos e agentes de mensagens.
  • São organizados por capacidade empresarial, com a linha que separa os serviços frequentemente chamada de contexto delimitado.

Embora grande parte da discussão sobre microsserviços tenha girado em torno de definições e características arquitetônicas, seu valor pode ser mais comumente compreendido por meio de benefícios comerciais e organizacionais bastante simples:

  • O código pode ser atualizado com mais facilidade, novos recursos ou funcionalidades podem ser adicionados sem afetar toda a aplicação.
  • As equipes podem utilizar diferentes pilhas e diferentes linguagens de programação para diferentes componentes.
  • Os componentes podem ser dimensionados independentemente uns dos outros, reduzindo o desperdício e o custo associados à necessidade de dimensionar aplicações inteiros porque um único recurso pode estar enfrentando muita carga.

O que os microsserviços não são

Os microsserviços também podem ser entendidos em contraste com duas arquiteturas de aplicações anteriores: arquitetura monolítica e arquitetura baseada em serviços(SOA).

A diferença entre microsserviços e arquitetura monolítica é que os microsserviços compõem uma única aplicação a partir de muitos serviços menores e fracamente acoplados, em oposição à abordagem monolítica de uma aplicação grande e fortemente acoplado.

As diferenças entre microsserviços e SOA podem ser um pouco menos claras. Embora possam ser traçados contrastes técnicos entre microsserviços e SOA, especialmente em relação ao papel do barramento de serviços corporativo, é mais fácil considerar a diferença como uma questão de escopo. A SOA foi um esforço de toda a empresa para padronizar a forma como todos os serviços web em uma organização se comunicam e se integram entre si, enquanto a arquitetura de microsserviços é específica da aplicação.

As mais recentes notícias de tecnologia, corroboradas por insights de especialistas.

Mantenha-se atualizado sobre as tendências mais importantes (e intrigantes) do setor em IA, automação, dados e muito mais com o boletim informativo Think. Consulte a Declaração de privacidade da IBM.

Agradecemos sua inscrição!

Sua assinatura será entregue em inglês. Você pode encontrar um link para cancelar a assinatura em todos os boletins informativos. Você pode gerenciar suas inscrições ou cancelar a inscrição aqui. Consulte nossa Declaração de privacidade da IBM para obter mais informações.

Como os microsserviços beneficiam a organização

É 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 uma nova funcionalidade em uma 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ço se encaixa perfeitamente nessa tendência. O modelo permite que uma organização crie equipes pequenas e multifuncionais em torno de um serviço ou uma coleção de serviços e as faça operar 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 stack comum, com um grande banco de dados relacional que suporta toda 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 stack, 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 implementados de forma independente e se comunicam por meio de uma combinação de REST, fluxo de eventos e agentes de mensagens, portanto é possível que a stack de cada serviço individual seja otimizada para esse serviço. A Tecnologia muda constantemente, e uma aplicação composta por vários serviços menores é muito mais fácil e menos dispendioso para evoluir com a 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.

Também há desafios para os 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, implementados em muito mais lugares. Problemas em um serviço podem causar ou ser cautilizados por problemas em outros serviços. Os dados de registro (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 lidar com 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 mencionados acima revelam que 56% dos não usuários atuais provavelmente ou muito provavelmente adotarão microsserviços nos próximos dois anos. Consequentemente, 78% dos usuários atuais de microsserviços provavelmente aumentarão o tempo, o dinheiro e o esforço investidos em microsserviços.

microsserviços

O que são microsserviços?

Neste vídeo, Dan Bettinger oferece uma visão geral dos microsserviços. Comparando a arquitetura das aplicações de microsserviço com o tipo tradicional de arquitetura monolítica por meio do exemplo de uma aplicação de criação de tíquetes, Dan expõe as inúmeras vantagens dos microsserviços e as soluções que oferecem para os desafios apresentados pelos sistemas monolíticos.

Os microsserviços permitem e exigem o DevOps

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 forma de ver a relação entre microsserviços e DevOps é que as arquiteturas de microsserviços exigem DevOps para ser bem-sucedido. 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 stacks 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 implementação, monitoramento e automação do ciclo de vida.

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

Principais ferramentas e tecnologias facilitadoras

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

Contêineres, Docker e Kubernetes

Um dos principais elementos de um microsserviço é que ele é pequeno. Não há uma quantidade arbitrária de código que determine se algo é ou não um microsserviço, mas "micro" está logo ali no nome.

Quando o Docker inaugurou a era moderna dos contêineres em 2013, ele também introduziu o modelo de computação que se tornaria mais associado aos microsserviços. Como os contêineres individuais não têm a sobrecarga de seu próprio sistema operacional, eles são menores e mais leves do que as máquinas virtuais tradicionais e podem ser ativados e desativados mais rapidamente, o que os torna uma combinação perfeita 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 desafios críticos. O Kubernetes, uma plataforma de orquestração de contêineres de código aberto, surgiu como uma das soluções de orquestração mais populares porque faz esse trabalho muito bem.

Gateways de API

Os microsserviços geralmente se comunicam por meio de API, especialmente ao estabelecer seu estado pela primeira vez. Embora seja verdade que clientes e serviços possam se comunicar uns com os outros diretamente, os API Gateways geralmente são uma camada intermediária útil, especialmente à medida que o número de serviços em uma aplicação cresce com o tempo. Um API Gateway atua como um proxy reverso para clientes, roteando solicitações, distribuindo solicitações em vários serviços e fornecendo segurança e autenticação adicionais.

Existem várias tecnologias que podem ser usadas para implementar API Gateways. Entre essas tecnologias estão as plataformas de gerenciamento de API, mas se a arquitetura de microsserviços estiver sendo implementada usando contêineres e Kubernetes, o gateway normalmente é implementado usando o Ingress ou, mais recentemente, o Istio.

Mensagens e fluxo de eventos

Embora a melhor prática possa ser projetar serviços sem estado, o estado, no entanto, existe e os serviços precisam estar cientes disso. E, embora uma chamada de API seja geralmente uma forma eficaz de estabelecer inicialmente o estado para um serviço específico, não é uma forma eficaz de manter-se atualizado. Uma pesquisa constante, " já estamos lá?" de manter os serviços atualizados não é prática.

Em vez disso, é necessário acoplar chamadas de API de estabelecimento de estado com mensagens ou fluxo de eventos para que os serviços possam transmitir mudanças no estado. Dessa forma, outras partes interessadas podem ouvir essas mudanças e se ajustar adequadamente. Esse trabalho provavelmente é mais adequado para um message broker de uso geral, mas há casos em que uma plataforma de fluxo de eventos, como o Apache Kafka, pode ser uma boa opção. E, ao combinar microsserviços com arquitetura baseada em eventos, os desenvolvedores podem construir sistemas distribuídos, altamente escaláveis, tolerantes a falhas e extensíveis que podem consumir e processar grandes quantidades de eventos ou informações em tempo real.

Sem servidor

As arquiteturas sem servidor levam alguns dos principais padrões de nuvem e microsserviços à sua conclusão lógica. No caso do sem servidor, a unidade de execução não é apenas um pequeno serviço, mas uma função, que muitas vezes pode ser apenas algumas linhas de código. A linha que separa uma função sem servidor de um microsserviço é tênue, mas as funções são comumente consideradas ainda menores do que um microsserviço.

Onde arquiteturas sem servidor e plataformas de funções como serviço compartilham afinidade com microsserviços é que ambas estão interessadas em criar unidades menores de implementação e escalar com precisão de acordo com a demanda.

Microsserviços e serviços de nuvem

Os microsserviços não são necessariamente relevantes exclusivamente para a computação em nuvem. No entanto, há algumas razões importantes pelas quais eles tão 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 os principais benefícios da arquitetura de microsserviços estão os benefícios de uso e custo associados à implementação e ao dimensionamento de componentes individualmente. Embora esses benefícios ainda estejam presentes, até certo ponto, na infraestrutura no local, a combinação de componentes pequenos e independentemente escalá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 stack mais adequada ao seu trabalho específico. A proliferação da stack pode levar a sérias complexidades e despesas gerais quando você a gerencia, mas consumir a stack 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.

Padrões comuns

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

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 compatibilidade com um tipo de back-end por interface de usuário utilizando as melhores opções para essa interface, em vez de tentar oferecer compatibilidade com um back-end genérico que funciona com qualquer interface, mas pode impactar negativamente o desempenho do front-end.

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 integridade 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).

Antipadrões

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 proporcionar compatibilidade com 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.

Tutoriais: desenvolvimento de habilidades em microsserviços

Soluções relacionadas
IBM Red Hat OpenShift

O Red Hat OpenShift on IBM Cloud é uma plataforma de contêineres OpenShift (OCP) totalmente gerenciada.

Explore o Red Hat OpenShift
Soluções de DevOps

Utilize softwares e ferramentas de DevOps para desenvolver, implementar e gerenciar aplicativos nativos da nuvem em diversos dispositivos e ambientes.

Explore as soluções de DevOps
Serviços de consultoria em nuvem 

Libere novos recursos e aumente a agilidade dos negócios com os serviços de consultoria em nuvem da IBM. Descubra como cocriar soluções, acelerar a transformação digital e otimizar o desempenho por meio de estratégias de nuvem híbrida e parcerias especializadas.

Serviço de nuvem
Dê o próximo passo

Libere novos recursos e aumente a agilidade dos negócios com os serviços de consultoria da IBM Cloud.

Explore nossos serviços de consultoria da IBM Cloud Crie sua conta gratuita na IBM Cloud