SOA versus microsserviço: qual éa a diferença?

Se você trabalha em TI ou na área de computação em nuvem, provavelmente está ciente do debate entre arquitetura orientada a serviços (SOA) e microsserviços. Afinal de contas, todo mundo está falando sobre microsserviços e aplicações ágeis esses dias.

À primeira vista, as duas abordagens parecem semelhantes e, de certa forma, são. Ambos envolvem ambientes de nuvem ou nuvem híbrida para o desenvolvimento e a implementação ágil de aplicações e ambos podem ser dimensionados para atender às demandas operacionais e de velocidade do big data. Ambos dividem aplicações grandes e complexas em componentes pequenos e flexíveis que são mais fáceis de trabalhar. E ambas diferem da arquitetura monolítica tradicional porque cada serviço tem sua própria responsabilidade.

No entanto, mesmo com essas semelhanças importantes, um exame mais detalhado das duas abordagens revela diferenças importantes.

A arquitetura orientada a serviços (SOA) é uma abordagem de toda a empresa para o desenvolvimento de software de componentes de aplicação que aproveite componentes de software ou serviços reutilizáveis. Na arquitetura de software SOA, cada serviço é composto pelo código e pelas integrações de dados necessárias para executar uma função de negócios específica, por exemplo, verificar o crédito de um cliente, entrar em um site ou processar uma aplicação de hipoteca.

As interfaces de serviço fornecem um acoplamento solto, o que significa que podem ser chamadas com pouco ou nenhum conhecimento de como a integração é implementada abaixo. Devido a esse acoplamento frouxo e à forma como os serviços são publicados, as equipes de desenvolvimento podem economizar tempo reutilizando componentes em outras aplicações em toda a empresa. Isso é tanto um benefício quanto um risco. Como resultado do acesso compartilhado ao barramento de serviços empresariais (ESB), se surgirem problemas, eles também poderão afetar os outros serviços conectados.

Os dados de XML são um ingrediente essencial para soluções baseadas na arquitetura SOA. As aplicações SOA baseadas em XML podem ser usadas para construir serviços da web, por exemplo.

A SOA surgiu no final da década de 1990 e representa um estágio importante na evolução do desenvolvimento e integração de aplicações. Antes que a SOA fosse uma opção, conectar uma aplicação monolítica a dados ou funções em outro sistema exigia uma integração ponto a ponto complexa que os desenvolvedores tinham que recriar para cada novo projeto de desenvolvimento. Expor essas funções por meio de SOA elimina a necessidade de recriar a integração profunda todas as vezes.

A SOA fornece quatro tipos diferentes de serviços:

1. Serviços funcionais (ou seja, serviços comerciais), que são críticos para as aplicações.
2. Serviços empresariais, que servem para implementar funções.
3. Serviços de aplicações, que são usados para desenvolver e implementar aplicativos.
4. Serviços de infraestrutura, fundamentais para processos de back-end, como segurança e autenticação.

Cada serviço consiste em três componentes:

1. A interface, que define como um provedor de serviço executa solicitações de um consumidor de serviço.
2. O contrato, que define como o provedor de serviços e o consumidor de serviços devem interagir.
3. A implementação, que é o código de serviço.

Os serviços de SOA podem ser combinados para criar serviços e aplicações de nível superior.

Assim como a SOA, as arquiteturas de microsserviços são compostas por componentes especializados, reutilizáveis e de acoplamento frouxo, que geralmente funcionam independentemente uns dos outros. Microsserviços também usam um alto grau de coesão, também conhecido como contexto limitado. O contexto limitado refere-se à relação entre um componente e seus dados como uma entidade ou unidade autônoma com poucas dependências. Em vez de serem adotados em toda a empresa, os microsserviços normalmente se comunicam por meio de interfaces de programação de aplicativos (APIs) para criar aplicação individuais que executam uma funcionalidade comercial específica. Essa abordagem os torna mais ágeis, escaláveis e resilientes, especialmente para áreas específicas da empresa. Normalmente, Java é a linguagem de programação de escolha para desenvolver microsserviços. Outras linguagens de programação também podem ser usadas, como Golang e Python.

Os microsserviços são uma verdadeira abordagem de arquitetura nativa da nuvem, geralmente operando em contêineres, o que os torna mais Escalável e portáteis para a criação de serviços independentes. As equipes podem usar microsserviços para atualizar o código com mais facilidade, usar stacks diferentes para componentes diferentes e dimensionar os componentes de forma independente uns dos outros. Essa abordagem reduz o desperdício e o custo associados à necessidade de escalar aplicações inteiras, pois uma única funcionalidade pode estar enfrentando carga demais. Devido à sua independência, os microsserviços produzem serviços mais tolerantes a falhas do que as alternativas.

Confira o vídeo a seguir para obter mais informações sobre arquitetura de microsserviço:

A principal distinção entre as duas abordagens se resume ao escopo. Simplificando, a arquitetura orientada a serviços (SOA) tem um escopo corporativo, enquanto a arquitetura de microsserviços tem um escopo de aplicação.

Muitos dos princípios fundamentais de cada abordagem tornam-se incompatíveis quando você negligencia essa diferença. Se você aceitar a diferença de escopo, poderá rapidamente perceber que os dois podem se complementar, em vez de competir.

Aqui estão alguns casos de uso em que essa distinção entra em jogo:

Na SOA, a reutilização das integrações é o principal objetivo e, no nível empresarial, é essencial esforçar-se para alcançar algum nível de reutilização.A reutilização e o compartilhamento de componentes em uma arquitetura SOA aumentam a escalabilidade e a eficiência.

Na arquitetura de microsserviços, a criação de um componente de microsserviços que é reutilizado no tempo de execução em uma aplicação resulta em dependências que reduzem a agilidade e a resiliência. Os componentes de microsserviços geralmente preferem reutilizar o código copiando e aceitando a duplicação de dados para ajudar a melhorar o desacoplamento.

Os serviços reutilizáveis em SOA estão disponíveis em toda a empresa por meio de protocolos predominantemente síncronos, como APIs RESTful.

Entretanto, em uma aplicação de microsserviço, as chamadas síncronas introduzem dependências em tempo real, resultando em uma perda de resiliência. Essas dependências também podem causar latência, o que impacta o desempenho. Dentro de uma aplicação de microsserviços, os padrões de interação baseados em comunicação assíncrona são preferidos, como o fornecimento de eventos, no qual um modelo de publicação/inscreva-se é usado para permitir que um componente de microsserviços permaneça atualizado sobre as mudanças que ocorrem com os dados em outro componente.

Um objetivo claro da prestação de serviços em uma SOA é que todas as aplicações obtenham e alterem dados de forma síncrona diretamente em sua fonte primária, o que reduz a necessidade de manter padrões complexos de sincronização de dados.

Em aplicações de microsserviços, o ideal é que cada microsserviço tenha acesso local a todos os dados necessários para garantir sua independência de outros microsserviços (e também de outras aplicações) mesmo que isso signifique alguma duplicação de dados em outros sistemas. É claro que essa duplicação adiciona complexidade, portanto deve ser equilibrada com os ganhos em agilidade e desempenho, mas isso é aceito como uma realidade do projeto de microsserviços.

• Comunicação: em uma arquitetura de microsserviço, cada serviço é desenvolvido de forma independente, com seu próprio protocolo de comunicação. Com a SOA, cada serviço deve compartilhar um mecanismo de comunicação comum chamado barramento de serviço corporativo (ESB). A SOA gerencia e coordena os serviços que fornece por meio do ESB. No entanto, o ESB pode se tornar um ponto único de falha para toda a empresa e, se um único serviço ficar lento, todo o sistema poderá ser afetado.
• Interoperabilidade: no interesse de manter as coisas simples, os microsserviços usam protocolos de mensagens leves, como HTTP/REST (Representational State Transfers) e JMS (Java Messaging Service). Os SOA são mais abertos a protocolos de mensagens heterogêneos, como SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol) e MSMQ (Microsoft Messaging Queuing).
• Granularidade do serviço: as arquiteturas de microsserviços são compostas por serviços altamente especializados, cada um dos quais é projetado para fazer muito bem uma coisa. Os serviços que compõem os SOAs, por outro lado, podem variar de serviços pequenos e especializados a serviços abrangentes da empresa.
• Velocidade: usando as vantagens de compartilhar uma arquitetura comum, os SOAs simplificam o desenvolvimento e a solução de problemas. No entanto, isso também tende a fazer com que os SOAs operem mais lentamente do que as arquiteturas de microsserviços, que minimizam o compartilhamento em favor da duplicação.
• Governança: a natureza da SOA, envolvendo recursos compartilhados, permite a implementação de normas comuns de gestão de dados em todos os serviços. A natureza independente dos microsserviços não permite uma gestão de dados consistente. Isso proporciona maior flexibilidade para cada serviço, o que pode incentivar uma maior colaboração em toda a organização.
• Armazenamento: SOA e microsserviços também diferem em termos de como os Recursos de armazenamento são alocados. A arquitetura SOA normalmente inclui uma única camada de armazenamento de dados que é compartilhada por todos os serviços em uma aplicação, enquanto os microsserviços dedicarão um servidor ou banco de dados para armazenamento de dados para qualquer serviço que precisar dele.

Para algumas organizações, a arquitetura SOA é um trampolim para substituir o monólito, proporcionando um ambiente mais flexível e ágil. Os serviços de SOA podem ser desenvolvidos e usados em um grande ambiente, mas não lidam com as necessidades específicas de empresas individuais que desejam lidar com os processos de negócios dentro de sua alçada. O DevOps pode ser usado para ajudar uma organização a fazer a transição da arquitetura SOA para microsserviços, a fim de lidar com necessidades específicas.

Os estilos arquitetônicos têm suas vantagens; então, como determinar qual deles funciona melhor para seus objetivos? Em geral, depende do tamanho e da diversidade do seu ambiente de aplicações.

Tanto a SOA quanto microserviços podem usar automação para acelerar processos de negócios. Ambientes maiores e mais diversos tendem a se apoiar na arquitetura orientada a serviços (SOA), que são compatíveis com a integração entre aplicações heterogêneas e protocolos de mensagens VIA um barramento de serviços corporativos (ESB). Ambientes menores, incluindo aplicações web e aplicações móveis, não exigem uma camada de comunicação tão robusta e são mais fáceis de desenvolver usando uma arquitetura de microsserviços.

Alguns apontarão que o debate SOA versus microsserviços é muito mais complicado, e isso é verdade. Há muito mais envolvido. Para uma explicação técnica mais detalhada dessas nuances, incentivamos você a ler os artigos do Hub de Aprendizado de SOA e microsserviços, que fornecem muitas informações detalhadas. No entanto, do ponto de vista dos negócios, o escopo é a distinção crucial.

• O que são microsserviços?
• O que é SOA (arquitetura orientada a serviços)?
• Ágil versus cascata

Para aprender mais sobre como construir aplicações ágeis, baixe sua cópia gratuita do ebook Arquitetura de aplicações ágeis.