Repensando micro serviços (microservices)

A questão dos micro serviços ainda me acompanha. Desde a publicação do meu último post sobre o assunto venho recebendo feedback de diversas pessoas além de ter entrado em contato com tantas outras. Com a mente um pouco mais clara (ao menos espero) chegou a hora de expor minhas conclusões correntes sobre o assunto.

A grande questão: é SOA?

A conclusão que cheguei é quase óbvia: sim e com poucas novidades. Alguém que me influenciou fortemente este ponto foi Steve Jones em um dos seus posts (a propósito, excelente blog). Outra fonte muito importante foi o modelo de referência SOA desenvolvido pelo OASIS em 2006 que você pode baixar aqui.

O modelo de referência do OASIS é um documento bastante árido mas que lido com atenção nos fornece um sólido conceitual para entender, de fato, o que é SOA.

O que é SOA?

Citando o modelo de referência do OASIS, SOA seria

(…) um paradigma que visa organizar e usar funcionalidades (capabilities) distribuídas que podem pertencer a distintos donos (ownership domains). Provê uma maneira uniforme de oferecer, descobrir e interagir e usar as funcionalidades visando gerar efeitos no mundo real de forma consistente com as expectativas dos consumidores e de forma mensurável.” (Reference Model for Service Oriented Architecture 1.0, linhas 863-867)

Há um conceitual muito importante (e interessante) neste documento que é importante divulgar aqui. O que é um efeito no mundo real? É o resultado do uso de um serviço por um cliente que gera a alteração no estado compartilhado entre este e seu consumidor e outras entidades que pertençam ao mesmo domínio.

Imagine um sistema de compras online: há mais de um serviço interagindo, como, por exemplo, operador de cartão de crédito, estoque, etc. Ao finalizar uma compra, o estado compartilhado por todos estes participantes será alterado: a conta do comprador terá um valor abatido e o estoque terá sua quantidade reduzida. O mundo se alterou: o estado interno do serviço não faz parte do mundo real (algo interessante para pensar hoje na hora de dormir). Este é o primeiro dos três conceitos fundamentais de SOA neste modelo de referência: efeito.

E o que é um serviço dentro deste conceitual? Segundo o modelo de referência, um serviço seria o mecanismo que permite acessar as funcionalidades (capability) que interessam o consumidor. Momento loop: o que é uma funciondalidae (capability)? É um efeito no mundo real provido por um serviço. O provedor de um serviço deve sempre oferecer duas informações aos interessados em interagir com este:

• O modelo de dados e comportamento exposto através de sua interface.
• A informação mínima para que o interessado em seu uso saiba que está usando o serviço certo para suas necessidades.

Estas informações são fundamentais para que o serviço possa ser descoberto. Ainda mais importante: é também interessante que o consumidor do serviço também se apresente, assim torna-se fácil descobrir quem supre a necessidade de quem. Este é o segundo dos três conceitos fundamentais de SOA neste modelo de referência: visibilidade (seção 3.2.1 do modelo de referência).

Finalmente, não faria sentido termos todos estes serviços isolados. Faz-se necessário que estes interajam de alguma maneira. No caso, pode ser tanto como troca de mensagens, como também alterando o estado de um recurso compartilhado (como um banco de dados) ou mesmo através de chamadas HTTP (REST). Para que SOA se consolide, faz-se necessário que o terceiro conceito fundamental se manifeste: interação. 

Há alguns pontos interessantes neste documento. Busque por ESB e você não encontrará menção alguma. É dito apenas que os serviços devam ser visíveis, exatamente como é dito na literatura sobre micro serviços. Outro ponto importante: vemos também que pela mensageria ou REST já teríamos uma interação bem definida. Ainda mais bacana, como no caso dos micro serviços temos um sistema no qual todos já estão por padrão no mesmo domínio, temos efeitos no mundo real o tempo inteiro.

Interessante que se você ler novamente o texto de Martin Fowler e James Lewis sobre micro serviços e logo em seguida o modelo de referência OASIS verá que o primeiro é na realidade uma vesão agradável do segundo.

Então, temos aqui SOA novamente, mas o modo de aplicação é distinto. A principal diferença que vejo é a ausência do ESB e também o fato de os serviços se conhecerem a priori. Como menciono no meu primeiro post sobre o assunto, acredito que conforme o sistema cresça um ESB ou diretório de serviços acabará surgindo novamente, o que pode acabar com o prefixo “micro”.

“Produtos, não projetos” é inviável

Outro ponto interessante nesta discussão sobre micro serviços é o conceito de produtos, e nao projetos. A idéia é simples: a equipe seria dividida em funcionalidades. Então eu seria responsável pelo serviço A e você pelo B, e esta seria nossa única responsabilidade. Lindo né? O problema é que não vai funcionar por um motivo bastante simples: você não quer ociosidade entre os seus funcionários.

Devemos ficar inativos enquanto não houver necessidade de alteração em nossos serviços? Ou será que na prática não iriamos simplesmente passear entre os serviços? Acredito que o passeio não é só consequencia, mas também necessidade. Ainda mais se levarmos em consideração que em equipes ágeis o conhecimento do todo se mostra fundamental.

Pode até ser viável em alguns lugares, mas acredito que seja apenas em alguns lugares ou situações nas quais os serviços terão evolução constante e contínua.

SOA pode significar várias coisas? Não.

O artigo de Fowler e Lewis sobre micro serviços depois recebeu um box entitulado “Microservices and SOA” que não irá lhe responder se micro serviços são ou não uma forma de SOA: apenas lhe dirá que há pessoas que dizem que sim e outras que dizem o contrário. O problema é o argumento usado de que  “SOA pode significar várias coisas”. Papo furado.

Ainda pior: se você reconhece que o público possuí dificuldade em saber a definição de algo, por que se esquivar do problema e não simplesmente buscar popularizar o real significado do termo? Dada a imensa literatura existente sobre SOA hoje apontando para o mesmo significado dizer algo assim é falso. A não ser, é claro, que você queira vender o velho como se fosse algo novo, não é mesmo?

(uma das pessoas que comentou o post de Steve Jones sobre SOA e Micro serviços aponta para o fato de que Fowler e Lewis inclusive cometeram uma falácia grave neste ponto. (esta é a falácia))

Digo mais: se quisermos ser levados a sério temos de evitar esta postura. Pouco tempo atrás mencionei um exemplo similar neste blog ao falar sobre tempo real. Indo além, se algo “significa várias coisas” é por que temos na realidade uma classificação e não um objeto disforme. Exemplo: a palavra animal pode significar várias coisas a um distraído, como coelho, cachorro, homem, etc. No entanto, sei que animal é uma classe que contém subdivisões, cada uma destas apontando para um tipo de animal diferente.

O mesmo acredito que ocorra com SOA. Há o conceito fundamental de SOA, aquele apresentado no modelo de referência que citei acima. E há as diferentes formas nas quais este é implementado, o que geraria uma subclassificação. Uma destas classificações provávelmente será a de micro serviços.

Micro serviços são uma reação

A impressão que tenho neste momento é que micro serviços são uma reação ao modo predominante que vimos SOA ser aplicado (usando ESBs). Algo muito similar ao que vimos com a popularização do REST, que era uma resposta aos webservices baseados em SOAP.

É uma maneira de implementar o SOA com menos elementos e de uma forma mais “light” removendo o ESB e tornando os micro serviços.

(perguntei ao Steve Jones se micro serviços podem ser vistos com uma reação ao SOA tradicional. A sua resposta foi bastante interessante e pode ser lida neste link)

 

SOA é para integrar sistemas e micro serviços para integrar componentes de um mesmo sistema? Não.

Em uma discussão muito interessante e rica com um colega sobre o assunto foi levantado o seguinte ponto:

“SOA não é uma arquitetura para desenvolvimento de sistemas mas sim para integração entre sistemas distintos ao contrário de micro serviços que são uma solução para o modo como interagem sistemas de uma mesma aplicação.”

Antes de mais nada é muito importante sempre nos lembrarmos o que o “A” de SOA significa: Arquitetura. Quando estou integrando diferentes sistemas estou na realidade criando e projetando um novo sistema.  A diferença é que os componentes podem não pertencer ao mesmo domínio de propriedade.

Mais que isto: é importante salientar que nem toda integração é SOA. Se integro meu site com o PagSeguro, por exemplo, será que poderia dizer estar eu implementando um SOA? E se eu defino que todos os sistemas da minha empresa irão expor uma API REST, é SOA?

Indo além: observando o modo como SOA é implantado em diversas empresas vemos que estamos na realidade criando um sistema composto por diversos outros sistemas, todos eles pertencentes a um mesmo domínio de posse, ou seja,  à uma mesma empresa. De novo, algo muito similar ao descrito na arquitetura de micro serviços hein? (de novo a mesma coisa)

Então, não: SOA não é apenas uma estratégia de integração, mas sim uma estratégia arquitetural na modelagem de sistemas. Especialmente se formos levar em questão que o analista SOA também faz a análise dos processos de negócios internos do cliente. De novo, olha o projeto de sistemas aí.

ESB é algo maligno? Não.

Em algumas discussões vi emergir a impressão de que ESBs seriam algo maligno. Discordo: o maligno é o mal uso da ferramenta. Aliás, é interessante observar que Fowler e Lewis em seu box “Microservices and SOA” terminam com uma postura nesta direção ao dizerem que “talvez micro serviços sejam SOA feito direito”, baseando-se no fato de terem vistos diversos projetos baseados em ESB fracassarem.

Eles se esqueceram de algo básico: ver uma estratégia fracassando algumas vezes não quer dizer que esta sempre irá falhar, mas sim que temos um indício de que pode ter sido mal aplicada.

Conclusões

Estes foram os principais pontos que enfrentei ao me questionar a respeito dos micro serviços. O mais importante na minha opinião é o reconhecimento de que micro serviços são na realidade uma outra estratégia na aplicação do SOA.

Acredito que pensar de forma distinta, vendo micro serviços como algo completamente distinto equivale a jogar fora anos de experiência na aplicação do SOA. Todo este conhecimento (especialmente a respeito do que não funciona) deveria ser mais valorizado na minha opinião.

Pode ser que eu mude de idéia no futuro. Isto, claro, irá depender muito das opiniões de vocês a este respeito. E você, passada esta semana, o que pensa a respeito dos micro serviços?