Em março deste ano publicamos um artigo sobre o recente crescimento das discussões sobre o termo Microservices (Micro-serviços), questionando se isto representa uma nova abordagem de arquitetura ou, como Steve Jones sugeriu, é simplesmente outro nome para SOA. Considerando os comentários no artigo, parece que a maioria dos leitores (ou a maioria dos que deixaram comentários) acredita que Microservices é na verdade SOA e que não é necessário um novo nome. Após aquele artigo, Steve escreveu um novo post, no qual ele discute como Microservices trata-se apenas de orientação a serviços (Service Oriented Architecture) e como tentar distanciá-lo de SOA não faz sentido:
[...] Microservices definem algumas boas regras para implementar certas partes de uma aplicação corporativa mas eles são melhor servidos pela honestidade na escolha de implementação dentro de uma ampla Arquitetura Orientada a Serviços. Isso não os desvaloriza de nenhuma maneira, apenas os coloca no seu devido contexto.
Via Twitter, Arnon Rotem-Gal-Oz também entrou no debate:
Acredito que seja mais fácil utilizar um novo nome (Microserviços) do que dizer o que SOA realmente significa - http://martinfowler.com/articles/microservices.html.
Assim como Fowler e James, Arnon também acredita que os Microservices não são nada além de SOA, talvez sem alguns de seus equívocos, como a associação a padrões restritivos como o WS-* ou ESBs. Ele então questiona o que é precisamente um Microservice e cita James Hugues:
Antes de qualquer coisa, o que é um Microservice? Bem, não existe uma definição rápida e definitiva, mas por meio de conversas com várias pessoas, parece que existe um consenso que um Microservice é uma aplicação simples que possui entre 10 e 100 linhas de código.
De acordo com Arnon, James admite mais a frente no mesmo artigo que linhas de código é um meio pobre para comparar a implementação de serviços (algo que Jan também explorou em seu outro artigo que trata da utilização do serviço ser mais importante que seu tamanho em linhas de código), mas Arnon quis focar no aspecto de consenso ao qual James se refere:
Então, como é possível ter serviços com 100 linhas de código? Você pode conseguir se fizer uso de frameworks (como Finagle ou Sinatra), gerar código de serialização/desserialização (protobuff, thrift, avro, etc) -- isto é, essencialmente, construir um host de serviço inteligente. Um outro exemplo seria o desenvolvimento em Erlang, com suas hierarquias de supervisors, que também nos leva a reduzir as linhas de código por meio da utilização de linguagens menos verbosas (como o Erlang já mencionado, python ou scala, ao contrário de, por exemplo, Java).
A ideia central de Arnon é que serviços com 10 a 100 linhas de código estão provavelmente expondo funções ao invés de serem um "serviço real". Ele também acredita que, quanto menor o tamanho do serviço (em direção ao que ele chama de "Nano services"), maior a sobrecarga de gerenciamento para se preocupar, custos de serialização/desserialização, segurança, etc. Essencialmente, conforme estes serviços vão sendo reduzidos, mais código de integração você precisa escrever para uni-los em um componente útil. Como Arnon diz:
Nanoservice (Nano-serviço) é um anti-pattern no qual o serviço é muito granular. Um nanoservice é um serviço no qual a sobrecarga (de comunicação, manutenção, etc) supera sua utilidade.
Assim como Steve e outros, Arnon conclui que Microservices é apenas outro nome para SOA. Ele acredita que, há alguns anos atrás, no início da popularização de SOA, talvez um novo nome não fosse uma coisa ruim mas, atualmente, com os conceitos de SOA bem estabelecidos e bem compreendidos, um novo nome não é útil.
Além disso, se nós quisermos denominar apropriadamente SOA por um novo nome, penso que o termo microservices é pobre pois ele nos leva aos nanoservices e às 10 linhas de código que representam apenas o seu velho método de web-service executado por algum host elegante utilizando um novo formato de serialização.
Apesar do fato de muitas pessoas parecerem concordar que o termo Microservice não é novo nem necessário, nós estamos observando um crescimento de frameworks que são vendidos por sua habilidade em suportar Microservices. Então, talvez este seja um termo que a indústria terá de aceitar, mesmo que a maioria o entenda como um novo nome para SOA.