Microsserviços vs SOA

Os microsserviços são o novo SOA? As pessoas ainda falam sobre SOA? Vamos entender as diferenças entre essas duas arquiteturas mais recentes.

Na publicação anterior, “O que são microsserviços”, você entendeu que microsserviços têm arquiteturas distribuídas e oferecem vantagens significativas sobre a arquitetura monolítica. Agora iremos abordar arquiteturas baseadas em camadas e as diferença entre microsserviços e arquitetura SOA.

Antes de nos aprofundarmos nas diferenças entre microsserviços e SOA, vamos primeiramente analisar as diferenças básicas entre arquitetura Monolítica, SOA e Microsserviços:

Em termos leigos, uma Arquitetura Monolítica é semelhante a um grande recipiente, onde todos os componentes de software da aplicação são empacotados e implantados juntos.

Arquitetura Orientada a Serviços (SOA), também em termos leigos, é essencialmente uma arquitetura com uma coleção de serviços que se comunicam entre si. A comunicação pode envolver a passagem de dados simples entre dois ou mais serviços que coordenam alguma atividade.

Microsserviços (Microservice Architecture) é um estilo de arquitetura que estrutura uma aplicação como uma coleção de pequenos serviços autônomos modelados em torno de um domínio de negócios.

Se você conhece o método de decompor aplicações em funções essenciais para evitar os problemas provocados pelas arquiteturas monolíticas é porque o estilo de arquitetura de microsserviços é semelhante ao da arquitetura orientada a serviço (SOA), já consagrado no desenvolvimento de aplicações mas ambos variam muito em termos de características de serviço.

Arquitetura Orientada a Serviços (SOA)

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.

Thomas Erl no seu livro “SOA: Princípios do Design de Serviços”, concretizou os 8 princípios básicos da Arquitetura Orientada a Serviços:

• Serviços são reutilizáveis.
• Serviços compartilham um contrato formal.
• Serviços possuem baixo acoplamento.
• Serviços abstraem a lógica.
• Serviços são capazes de se compor.
• Serviços são autônomos.
• Serviços evitam alocação de recursos por longos períodos.
• Serviços devem possuir a capacidade de serem descobertos.

SOA também define quatro tipos básicos de serviços, conforme visto abaixo:

• Business Services: serviços de “granulação grossa” que coordenam as principais operações de negócios (serviços de orquestração).
• Enterprise Services: implementam a funcionalidade definida pelos serviços de negócios (serviços compartilhados e reutilizáveis).
• Application Services: serviços que estão confinados a um contexto de aplicativo específico.
• Infrastructure Services: implementam tarefas não funcionais, como autenticação, auditoria, segurança, registro, etc.

Afinal, qual o problema com o SOA?

Nos primórdios do desenvolvimento de aplicações, até mesmo as alterações mais insignificantes em uma aplicação pronta exigiam uma atualização da versão inteira, com um ciclo próprio de garantia da qualidade (QA). Isso, provavelmente, atrasava o trabalho de muitas equipes.

Muitas vezes essa abordagem é chamada de “monolítica”, porque o código-fonte da aplicação toda era incorporado em uma única unidade de implantação, como .war ou .ear. Se a atualização de alguma das partes causasse erros, era necessário desativar a aplicação inteira, reverter a escala e corrigir o problema.

Embora essa abordagem ainda seja viável para aplicações menores, as empresas em ampla expansão não podem se dar ao luxo de sofrer com tempo de inatividade ocasionado por esses tipos de problemas.

A Arquitetura Orientada a Serviço serve pra resolver essa questão, pois estrutura as aplicações em serviços distintos e reutilizáveis que se comunicam por meio de um Enterprise Service Bus (ESB). Nessa arquitetura os serviços individuais, cada um deles organizado em torno de um processo de negócios específico, aderem a um protocolo de comunicação, como SOAP, ActiveMQ ou Apache Thrift, para que sejam compartilhados por meio do ESB. Quando reunidos em um pacote integrado por meio de um ESB, esses serviços formam uma aplicação.

Por um lado, isso permite criar, testar e ajustar os serviços de maneira simultânea, eliminando os ciclos de desenvolvimento monolíticos. No entanto, por outro lado, o ESB representa um ponto único de falha no sistema inteiro, criando um problema de disponibilidade. Portanto, todo o esforço empregado para eliminar uma estrutura monolítica, de certo modo, serviu apenas para criar outra: o ESB, que potencialmente pode congestionar toda a organização.

A arquitetura SOA também trás outros problemas, como uma grande complexidade na governança de serviços, pois uma grande quantidade de serviços precisa ser gerenciada. Também é difícil você conseguir ter “responsáveis” para cada serviço, pois muitos serviços são altamente reutilizáveis por diversos sistemas.

A performance também é ponto preocupante, pois a performance depende diretamente do servidor onde o serviço está publicado, como também da rede. Nesse modelo a escalabilidade também é complexa, pois em momentos de pico, você não consegue facilmente criar novas instâncias do seu ESB.

Além dos pontos acima e outros pontos como robustez, testabilidade e segurança, outra questão da arquitetura SOA é a dificuldade de montar um modelo de DevOps, com equipes independentes (squads) e com autonomia no desenvolvimento, pois nesse novo modelo, a implantação de um serviço mesmo com falha, não afeta nenhuma outra parte do sistema, o que não é realidade do SOA que propõe o máximo reuso de serviços.

Evolução para a arquitetura de microsserviços

O que diferencia a arquitetura de microsserviços das abordagens monolíticas tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é denominada a um serviço e que pode ser criada e implantada de maneira independente. Isso significa que cada serviço individual pode funcionar ou falhar sem comprometer os demais.

Os microsserviços podem se comunicar entre si, normalmente de maneira stateless. Portanto, as aplicações criadas dessa maneira podem ser mais tolerantes a falhas e depender menos de um único ESB. Além disso, as equipes de desenvolvimento podem escolher as ferramentas que desejarem, pois os microsserviços podem se comunicar por meio de interfaces de programação de aplicações (APIs) independentes de linguagem.

Levando em consideração a história da SOA, os microsserviços não são uma ideia completamente nova. Porém, eles se tornaram mais viáveis graças aos avanços nas tecnologias de containerização. Com os containers Linux, agora é possível executar várias partes de uma aplicação de maneira independente no mesmo hardware e com um controle muito maior sobre os componentes individuais e ciclos de vida. Juntamente com as APIs e as equipes de DevOps, os microsserviços em contêineres são os pilares das aplicações nativas em cloud.