Arquitetura Orientada a Serviços (SOA) ou Microsserviços?

SOA

Antes de falar sobre Arquitetura Orientada a Serviços (SOA) ou Microsserviços, é preciso começar, na verdade, pela Arquitetura Monolítica. Em termos leigos, é possível afirmar que ela seria semelhante a um grande recipiente, onde todos os componentes de software da aplicação são “empacotados” e implantados juntos.

Como  nesse formato o código-fonte da aplicação é incorporado em uma única unidade de implantação, até mesmo as alterações mais insignificantes exigem uma atualização da versão inteira. O que, provavelmente, atrasa o trabalho de muitas equipes.

Logo, a Arquitetura Orientada a Serviços (SOA) vem para resolver essa questão. Semelhante a uma coleção de serviços que se comunicam entre si, ela estrutura as aplicações em serviços distintos e reutilizáveis que se comunicam por meio de um Enterprise Service Bus (ESB). Vantagem que permite criar, testar e ajustar os serviços de maneira simultânea, eliminando os ciclos de desenvolvimento monolíticos. No entanto, se o ESB falha, surge novamente o mesmo problema de disponibilidade.

Enquanto isso, a Arquitetura de Microsserviços decompõe a aplicação por funções básicas e independentes, quase como uma coleção de pequenos serviços autônomos em torno de um domínio de negócios. Ou seja, cada serviço individual pode funcionar ou falhar sem comprometer os demais, dependendo menos de um único ESB e sendo mais tolerante a falhas.

Analisando por etapas: SOA x Microsserviços

1 – Armazenamento de dados

Os microsserviços possuem armazenamento de dados independente, o que significa que cada microsserviço será um serviço independente e não compartilha nenhum armazenamento de dados comum entre si. No modelo SOA, os serviços compartilham a mesma camada de armazenamento de dados no aplicativo.

2 – Flexibilidade

Como os microsserviços são independentes, qualquer alteração pode ser testada e implantada de forma isolada. Isso facilita a concentração nos recursos de negócios de um único microsserviço, em vez de pensar em todo o aplicativo. SOA, por outro lado, possui maior flexibilidade organizacional e as implementações são específicas para o ambiente, ou seja, que possam responder efetivamente a um ambiente de negócios em mudança.

3 – Tolerância ao erro

A tolerância a falhas é a chave para grandes sistemas distribuídos, ela minimiza o impacto de modificações e falhas no cenário do sistema como um todo. SOA permite a integração de componentes de software existentes de diferentes fontes mais rapidamente, tornando possível a tolerância a falhas.

Os microsserviços, por outro lado, são mais propensos a falhas devido à proliferação de serviços e suas comunicações de rede entre serviços. Um determinado aplicativo de microsserviço é uma coleção de serviços independentes e autônomos e uma falha de um ou mais de um serviço não deve reduzir o aplicativo inteiro.

Isso significa que SOA e até mesmo as Arquiteturas Monolíticas estão ultrapassadas?

A verdade é que o método ideal para o seu negócio depende do tamanho da sua aplicação, do tempo e verba disponível para a capacitação do seu time. Cada conceito traz diferenciais benefícios e algumas dessas abordagens ainda são viáveis para aplicações menores, nas quais o tempo de inatividade não causaria tanto prejuízo.

Nós, do Instituto Brasília de Tecnologia e Inovação oferecemos diversos treinamentos tanto para Arquitetura Orientada a Serviços (SOA) quanto Arquitetura de Microsserviços. Entre em contato para saber mais!

Compartilhar no facebook
Facebook
Compartilhar no twitter
Twitter
Compartilhar no linkedin
LinkedIn
Compartilhar no email
Email
Compartilhar no print
Print

Deixe um comentário

O seu endereço de e-mail não será publicado.