Conheça o KumuluzEE – seu novo framework para Microservices

Parece que a nova buzzword é realmente Microservices. A definição do Adam Bien parece perfeita: é um serviço que tem máxima coesão e mínimo acoplamento. A palavra principal parece ser decomposição. Um serviço para tratar REST, outro para WSDL, JMS, JPA e assim por diante, ganhando assim uma melhor escalabilidade, manutenibilidade e tornando os serviços mais fáceis de serem gerenciados e atualizados. Relacionei serviços com especificações, mas obviamente pode ser algo referente ao seu domínio: pagamento, estoque, vendas, geração de e-books, autenticação, notificação, usuários, dentre outros.

Já discutimos sobre a diferença arquitetural entre microservices e serviços monolíticos. Martin Fowler também já resumiu os pré-requisitos para uma arquitetura microservice: monitoração (prometheus, icinga, pagerduty), provisionamento (mesos, aurora, kubernetes) e deploy (travis, jenkins, docker) . Além disso, o Philip Calçado contou a saga da migração de um sistema monolítico para microservices no SoundClound e mostrou o porquê do mercado se interessar tanto por esse “novo” estilo arquitetural.

 

As much as I keep repeating that the term microservices doesn’t mean much, the one thing you can be sure when somebody uses this word to describe their architecture is that there will be a lot of services.

 

De 2014 até o presente momento, o termo cresceu exponencialmente em pesquisas no google. Por quê? Porque desenvolvedor prefere trabalhar com unidades menores, commits menores e a probabilidade de gerar um bug será menor em um sistema menor. E a desvantagem? Bom, agora não existe apenas um sistema, é um ecossistema de aplicações que devem ser devidamente orquestradas. (Eu particularmente ando me perdendo bastante na quantidade de terminais abertos com repositórios gits e branches diferentes por projeto que tenho que lidar)

e os frameworks…

Então você optou por fazer uma arquitetura baseada em microservices, contudo, onde deployar? Em um application server JavaEE? Tomcat? Mas será mesmo que um war é necessário?

Bom, vou mostrar o que de interessante está acontecendo com as implementações no mundo Java relacionadas a esse tema. Busquei no mercado algumas opções para tentar avaliar vantagens e desvantagens, mas no geral todas são bem parecidas. São elas: SparkJava, SpringBoot, Vertx.IO e por fim o KulumuzEE.

Darei uma atenção especial a esse último pois aqui já entra um diferencial dele. Dentre os frameworks de mercado que estudei, ele é o primeiro voltado para o uso da API JavaEE. Portanto, implementamos nosso serviço em um container microservice utilizando especificações já conhecidas como JAX-RS, JPA, CDI. Além disso, ele foi o vencedor do Duke’s Choice Award 2015. Há outros também, como por exemplo o Swarm e o RESTlet.

Não há muita dificuldade em fazer o HelloWorld dos frameworks, todos eles têm um exemplo na página do produto, além de serem mavenizados. Fiquei um pouco mais perdido na documentação do Vertx.IO, mas eles têm um GitHub com exemplos que ajuda bastante.

Muita gente boafez artigo sobre esses caras, então a intenção aqui é apresentar uma visão geral sobre cada um e o código está no meu GitHub. A ideia básica da maioria dos frameworks é ter uma classe com um main e conseguir executá-la. A partir daí, temos um servidor e uma aplicação “deployada”.

vamos para o Kumuluz…

O kumuluz possui uma documentação muito bem detalhada, trazendo diversos exemplos das API’s, das quais irei focar em CDI, JPA e JAX-RS. A execução do Kumuluz é um pouco diferente dos outros pois temos que fazer o clean install da aplicação mavenizada e subir a aplicação por linha de comando

java -cp target/classes:target/dependency/* com.kumuluz.ee.EeApplication

Tive uma dificuldade inicial em configurar o pom com as versões adequadas. No nosso projeto, como ele não gera um WAR ao final, as páginas HTML ficam dentro do src/main/resources/webapp. De resto, é tudo igual a uma aplicação JavaEE convencional, persistence.xml e beans.xml dentro do META-INF e pronto, temos a configuração base da aplicação.No meu código de exemplo usei o H2 como banco para facilitar os testes.

Dividi o projeto em três pacotes para facilitar o aprendizado: servlet, rest e jpa. Siga as instruções

  1. Baixe o projeto – git clone https://github.com/raphaelLacerda/microservice.git
  2. Faça o clean install
  3. Entre na pasta do Kumuluz e rode o comando para subir o projeto
  4. Acesse localhost:8080

Incrível não? Não tenho mais o que ensinar pois ele usa as principais especificações do JavaEE, facilitando muito o aprendizado. Ele não tem suporte ainda para EJB’s, mas você pode usar o deltaspike para fazer alguns controles, como o transacional por exemplo.

Falarei mais sobre os outros em próximos posts…

e o futuro…

Esses dias no trabalho fui surpreendido com a possibilidade do PostgreSQL expor os dados via REST. Isso deu um nó enorme na minha cabeça pensando se fazia sentido ou não (WTF, cadê meu JPA?). Há outros questionamentos também, estamos entrando em um mundo no qual o EAR já deixou de ser necessário e talvez agora o WAR. Diante disso, a tendência é que os applications servers mais robustos passem a ter sua utilização repensada também. O lema que muitos apontam “One JAR to rule them all” pode ser a nova “buzzphrase“. Aguardem os próximos!!

 

 

 

 

Atualização

Para usuários Windows, seguir este link para subir o projeto.

19 Comentários

  1. Rafael Ponte 04/07/2016 at 23:30 #

    Muito bacana o post, Raphael.

    Tenho que dizer que estou temeroso pros próximos anos onde diversas empresas, profissionais e consultores terão que lidar com legado de microservices. Se uma App legada sem testes da trabalho, imagina várias delas. Esse hype sempre me deixa apreensivo, em especial com microservices, pois eles são a exceção para a maioria das apps corporativas. Como o próprio Fowler diz “se você não tem certeza se precisa de microservices, não use.”.

    De qualquer forma, eu fiquei curioso: qual sua motivação pelos estudos no assunto?

  2. Luiz 05/07/2016 at 07:24 #

    Os caras da LightBend estão com um projeto novo tbm… tem coisas interessantes.
    http://www.lightbend.com/lagom

  3. Altair Moura 05/07/2016 at 10:49 #

    Excelente post. Parabéns!

  4. Cesar 05/07/2016 at 11:10 #

    Muito bom!
    Sobre a possibilidade expor o PostgreSQL como uma API REST, expanda isso para qualquer SGBD com o Dream Factory (https://www.dreamfactory.com/). A coisa só piora! 🙂

  5. Caio Candido 05/07/2016 at 12:45 #

    Excelente Post. Excelente trabalho de pesquisa e argumentação. Parabéns.

  6. leonardo klestadt luz 05/07/2016 at 21:33 #

    Boa noite.

    Gostei do artigo.

    Agora peço sua colaboração se possível. Fiz um questionário pequeno sobre frameworks que contém 5 perguntas para serem respondidas e concluir meu trabalho na faculdade.

    Este é o link para o questionário: http://goo.gl/forms/PIIC4hPkHOMatn1E2

    Desde já agradeço a atenção e disponibilização de seu tempo.

  7. Bruno Souza 05/07/2016 at 22:59 #

    Parabéns garoto! Muito bom!

  8. Danilo Siqueira 06/07/2016 at 06:52 #

    Excelente! Parabéns!

  9. BRUNO CICERO R DE SOUZA 06/07/2016 at 14:54 #

    vale muito a pena acompanhar…

  10. Raphael Lacerda 06/07/2016 at 14:55 #

    Ponte, estou fazendo um sistema monolítico que precisa de uma parte de emissão de NFe. Claramente colocar a emissão de NFe no mesmo sistema não estava um bom negócio.

    Separamos isso com mensageria e o NFe passou a ser um outro sistema expondo a API em Rest.

    Agora vou começar a passar esse módulo de NFe para Kumuluz.

  11. Raphael Lacerda 06/07/2016 at 14:56 #

    Leonardo, qual a finalidade da pesquisa?

  12. Bruno 06/07/2016 at 14:57 #

    Amei seu o post!!!

  13. Arthur 07/07/2016 at 14:09 #

    Leonardo parabéns pelo artigo, fiquei bem interessado no assunto, ao mesmo tempo me veio a cabeça toda essa questão de segurança. Se faz idéia de como o mercado está se comportando diante dessa tendência.

  14. Helton 11/07/2016 at 03:13 #

    Excelente post!

  15. Jorge Filho 25/08/2016 at 08:44 #

    Raphael, esqueceu do Wildfly Swarm ? Já ouviu falar ?

  16. Raphael Lacerda 26/08/2016 at 11:35 #

    Jorge, blz?

    Esqueci não cara…

    Acho que vc deu uma pulada em alguns parágrafos =) =P

    “…Além disso, ele foi o vencedor do Duke’s Choice Award 2015. Há outros também, como por exemplo o Swarm e o RESTlet…”

  17. Megaron 06/01/2017 at 15:43 #

    Ótimo post. Parabéns !!!
    🙂

Deixe uma resposta