Implementação de MicroServices com Java EE ou Spring

@cvinicius se você pesquisar por JEE x Spring verá que esta discussão é infinita, há os que são ponderados, os que defendem JEE ou Spring com unhas e dentes e por aí em diante. O fato da equipe de vocês possuirem know-how em ambas é bom. Vou expor meu ponto de vista.

Eu defendo que quanto menor a dependência de um software, em particular um microservice, de tecnologias, melhor. Se você desenvolver em Spring, teu microservice passa a depender desta estrutura, obviamente. Não somente por isso, hoje não vejo justificativa para não usar JEE “puro”, haja visto que o JEE 7 está muito evoluido, sendo possível usar CDI (desde o JEE 6…mas enfim), Websocket, REST, Interceptors entre outros tudo na “base da injeção”, o que deixa bem transparente teu sistema e independente de tecnologias externas.

Por fim, o Wildfly é bem estável e implementa a especificação completa do JEE 7. Eu, na minha humilde opinião, iria com a consciênca tranquila em JEE. Já criei alguns microservices em JEE e não obtive nenhum problema. Lembrando que o fator “como se implementa/defini arquitetura”, não depende da tecnologia escolhida e sim da experiência do time que irá trabalhar no serviço em questão.

Boa sorte e sucesso.

@cvinicius Bom dia.
Essa discussão de Spring x JavaEE é de fato infinita como disse nosso amigo @nel.
O ponto importante quando falamos de microservices é não ter dependência…
Pensando assim, se você for subir um container Docker para seu serviço e seu serviço estiver estruturado com JavaEE teria que ter um container docker com wildfly, pensando em SpringBoot você tem um container apenas com um Java8 por exemplo.
Eu acredito que o melhor caminho é seguir é user SprintBoot por não depender de lib externa de wildfly ou outros containers…
Minha humilde opinião meus amigos!

@nel obrigado pela resposta, com certeza concordo com você, tenho experiência em ambos os lados e particularmente gosto dos modelos, aqui na empresa temos produtos feitos em Spring(Boot) e também temos em JEE 7, a pesquisa era justamente pra ver o que o pessoal vem utilizando para implementar este modelo de arquitetura.

Aqui estamos com a arquitetura do produto principal quase pronta, e agora estamos realizando provas de conceito e protótipos para validar os requisitos, curva de aprendizado, etc, pelos resultados em nossos testes, ambas as plataformas são muito estáveis para trabalhar com MicroServices, provavelmente iremos adotar aquela que mais atender aos nossos requisitos gerais.

Valeu.

@gilmar_soares obrigado Gilmar, sim meu ponto nem era comparar as duas plataformas, e sim ver o que o pessoal vem adotando quando falamos desse modelo de arquitetura.

Você tem razão o Spring Boot é fantástico nesse ponto, em nossos protótipos conseguimos implementar e gerenciar MicroServices de uma forma extremamente produtiva, como nossa plataforma é grande, já temos algumas coisas feitas em Spring Boot, e obtivemos bons resultados com as migrações.

Valeu.

@cvinicius o caminho é justamente esse, partir de POC e colher os resultados. Vocês terão muito mais segurança ao solidificar a decisão de vocês.

@gilmar_soares é um ponto de vista interessante, mas não vejo problemas utilizar o Wildfly neste caso porque a dependência não é direta para ele, pois há outros servidores de aplicação e containers que implementam a especificação JEE, sendo que, dependendo do que utilizarem, sequer precisa ser um FullSpec. Obrigado por compartilhar opinião.

Abraços pessoal.

@cvinicius acho que a escolha depende muito como você pretende estruturar sua arquitetura em conjunto com o DevOps.

Já assisti algumas palestras de microservices e muitos frisam que microservices consiste na separação de contextos ou domínios, mas nunca ficou claro pra mim qual a definição ou limite do que é o contexto. Por ex:

1. Poderia quebrar em assuntos usando um conteiner com a solução completa (ex: webservices + banco) cada uma isolada da outra. Ficando assim:

• Conteiner 1: Produtos
• Conteiner 2: Usuários
• Conteiner 3: Pedidos
• Conteiner 4: Estoque

2. Pensar em contextos como as áreas de uma empresa, ex:

• Conteiner 1: Servidor LAMP para o e-commerce
• Conteiner 2: Servidores de Aplicação JEE + Banco para aplicações corporativas
• Conteiner 3: Solução de ERP

3. Ou então em contextos como funcionalidades dos servidores + assuntos:

• Conteiner 1: Servidor Web Usuarios
• Conteiner 2: Servidor Web Produtos
• Conteiner 3: Servidor Web E-Commerce
• Conteiner 4: Banco de Dados (separar por assunto talvez? onde alguns casos seria melhor BD orientado a grafos ou a documentos e em outros relacional)
• Conteiner 5: Fila de pedidos

De todas opções acima, acredito que a 3 é a que está mais alinhada com o pensamento de microserviços. Por esse mesmo motivo, o SpringBoot é mais adequado já que ele adiciona comportamentos à sua aplicação apenas do que está sendo usado de fato, não trazendo um monte de dependências desnecessárias (no caso de servidores não modulares) do JavaEE.

Se você quiser usar JavaEE nessa mesma linha de raciocínio, daí é obrigatório o uso de servidores leves e modulares como WildFly ou o Liberty onde cada especificação ex: EJB, MDB, JMS, Secutiry, JAX-RS, JSF, JAX-WS etc… deve ser habilitada explicitamente.

um servidor de aplicação é usado pra rodar várias aplicações e gerenciar diversos aspectos dessas aplicações (transações, mensagens, banco) em um só lugar. Numa arquitetura microservice não vejo vantagem usar um app server porque serviços rodam de maneira distribuída, cada um em sua própria instância, se comunicando com outros serviços e a infra pela rede.

Tudo bem @bruno_rg, então também estou estudando bastante o assunto, achei vários pontos legais que ajudam a definir se realmente uma arquitetura de microservices é adequada aos seus requisitos, porque como tudo em TI, existe muita modinha, então precisamos realmente estudar para adotar uma arquitetura que venha a agregar.

Como ajuda estou lendo um livro bem legal, que é o Building Microservice do Sam Newman

O Spring Boot adiciona uma infra pronta para cada camada do sistema, além da possibilidade do uso de container embedded que facilita uma escalabilidade, entre outras coisas.

Com JEE também há esta possibilidade, por exemplo com Widlfly Swarm, mas este ainda esta em evolução, e pelas pesquisas que realizamos ainda não esta totalmente pronto para uso, mas acredito que logo deve ser algo que irá pegar muito no mercado de microservices.

Nos exemplos que você citou, acho que o exemplo 1 e 3 são os que estão mais próximos de uma arquitetura microservices, até achei alguns cenários reais de utilização que demonstram sistemas parecidos com esses cenários.

Valeu.

O que seria o numero 1? parece que está tentando modelar cada entidade no sistema como um serviço. Não acho que isso seja viável ou desejável na maioria das vezes…

@pfk66 sim tem razão, uma das premissas de microservices seria o trabalho isolado, ao trabalhar com microservice e JEE, não precisamos ter todos em um mesmo container, mas podemos ter containers isolados por service, grupo de services, etc, isso depende da sua arquitetura e de seus requisitos.

Poderíamos ter vários containers (Wildfly, Tomcat, Weblogic) cada um responsável por uma parte do domínio, lógico que isso adiciona complexidade na infra, mas ai entram em jogo as ferramentas de gerenciamento e deployment, até nesse livro que citei acima, o autor explica que em arquiteturas de microservices é muito importante estar aliado com ferramentas de DevOps, para ajudar a manter cenários distribuídos como estes.

Valeu.

Não ficou bom o exemplo, ficou parecendo que é apenas um CRUD exposto como serviço mas na verdade o que queria dizer é: um conteiner com todas as regras relacionadas a determinado assunto, assim se você precisar parar uma parte do sistema (aqui me refiro a conjunto de conteiners), você irá afetar indisponibilizar apenas uma pequena parte do todo.

Imagine um cenário de Telecom, onde há um microservice responsável apenas pela parte de Portabilidade, qualquer problema nesse modulo você conseguiria isolar e não precisaria indisponibilizar outros como Produtos, Vendas, Provisionamento, Cadastro de Clientes, CRM, Análise de Crédito.

Esse isolamento, apesar de ser possível com a modularização das aplicações nos servidores de aplicações JavaEE e com o uso de SOA, na prática não funciona tão bem e de forma ágil.

Na minha opinião SpringBoot, como já explicaram. A discussão é infinita mas os argumentos de quem adota o JEE são sempre os mesmos, de seguir especificação oficial etc, o que nunca representou vantagens na prática, muitas vezes pelo contrário, vide JSF, EJB. JEE é historicamente atrasado ou com soluções complexas que são desencorajadas a longo prazo como as já citadas. Não é a toa do que vem mais crescendo no mercado em relação a Java é o uso do Spring. Mas a decisão final vai de cada um.

uma vantagem de usar container é poder rodar vários services na porta 80. Mas se for rodar um serviço isolado não precisa nem de container. Uma aplicação java com jetty embarcado e executado com java -jar service.jar é suficiente…

quando gerenciamento de transações, acesso a dados, e outros aspectos da infra passam a ser um serviço disponível na rede qual a vantagem de usar frameworks como Spring ou JavaEE?

Não importa o quanto as aplicações estão modularizadas no app server, se há necessidade de parar o sistema por falha no hardware por exemplo, todas ficarão indisponíveis. Acho que 3 é mais alinhado com a idéia de microservices porque é o único realmente isolado verticalmente até o hardware.

SpringBoot está sendo bem aceito para esse cenário de micro serviços. Se existem opções sem usar frameworks, vai do risco de cada um usar o que é menos seguido.

Poderia citar algum projeto famoso baseado na arquitetura microservice que usa spring, gostaria de dar uma olhada no código.

Não conheço, só coloquei que SpringBoot está sendo bem aceito para esse cenário, para quem vive de Java claro. Se quiser ver código basta pesquisar e vai encontrar facilmente muita coisa sobre microservices com SpringBoot. Como por exemplo: http://blog.c2b2.co.uk/2016/01/spring-boot-as-microservice-platform.html

Obrigado. Perguntei porque não programa em Java faz tempo.

Como imaginei, springboot pode ser usado pra criar um Jar pra executar, sem precisar de container externo.