Oi pessoal, tudo bem?

Estou terminando um artigo sobre Spring Boot (http://projects.spring.io/spring-boot/) que é uma das principais apostas da Pivotal, responsável pela manutenção do ecossistema Spring.  É um projeto incrível que realmente me fez repensar diversos pontos sobre o modo como escrevemos aplicações para a plataforma Java EE e também será a base por trás da versão 3.0 do Grails, que é outro projeto que sempre me atraiu bastante.

Um ponto que achei interessantíssimo foi o fato de  no Spring Boot, por padrão, termos embarcado um container servlet e nosso projeto ser empacotado como um arquivo JAR simples. (executo java -jar [arquivo.jar] e o container é iniciado junto com nosso projeto).

Já havíamos visto algo similar algum tempo atrás no Play Framework, mas como naquele caso lidávamos essencialmente com Scala, cuja base de programadores é bem menor que a do Java, não vi tanta gente falando a respeito ou mesmo vendo as vantagens disto. Agora a coisa vai ficar mainstream ao que tudo indica.

Então resolvi propor uma discussão aqui sobre isto. O que vocês acham desta tendência? Vocês conseguem ver em um futuro próximo a especificação Java EE caminhando nesta direção? Acham que este tipo de abordagem - engolir o container - é algo que traga valor? Estamos engolindo o container?

Exibições: 361

Respostas a este tópico

Oi Henrique,

como a maioria das respostas sobre abordagens arquiteturais, a minha opinião é que depende do cenário.

Acredito que se o aplicativo que você deseja desenvolver tenha como requisito não funcional ser auto contido, acho que é a escolha de um container embutido é algo muito plausível. Nessa esfera, existem ganhos como diminuição da complexidade de deploy e de operação da aplicação. Aplicações que tendem para esse lado são aquelas que serão distribuídas para que os clientes realizam a implantação/operação. Exemplos são: Jenkins, Sonar e Gitblit.

Porém, em ambientes muito corporativos em que existem várias aplicações desenvolvidas, com requisitos não funcionais como escalabilidade e performance, alta disponibilidade, resiliência, gerência de transações complexas (distribuídas), penso que um servidor de aplicações seria a melhor opção.

Nessa categoria, é possível configurar todas as aplicações em um mesmo ambiente, gerenciar clusters, configurar datasources, criar bibliotecas compartilhadas e etc. E, tudo isso, podendo ser reutilizado pelas aplicações

Ainda nesse tópico, não acredito em uma evolução da especificação Java EE. Vejo isso como a 'decisão' de implementação. Já existem servidores 'embutidos' que estão no mercado há mais de 2 anos. Veja o Jetty e Tomcat Embed que são compatíveis com a especificação Servlet.

Então, para as suas perguntas, acredito que a resposta é depende do cenário. Vejo que as duas abordagens existirão em paralelo. E, uma não exclui a outra!

Abraços!

Oi Bruno,

são muito bem colocados os seus pontos. Também não acredito que os servidores embarcados irão substituir a nossa abordagem tradicional aos servidores de aplicação, mas sim que se tornarão uma alternativa bastante popular naqueles projetos em que a implantação do serviço seja mais simples, que é o que ocorre na maior parte dos casos.


Bruno Carneiro disse:

Oi Henrique,

como a maioria das respostas sobre abordagens arquiteturais, a minha opinião é que depende do cenário.

Acredito que se o aplicativo que você deseja desenvolver tenha como requisito não funcional ser auto contido, acho que é a escolha de um container embutido é algo muito plausível. Nessa esfera, existem ganhos como diminuição da complexidade de deploy e de operação da aplicação. Aplicações que tendem para esse lado são aquelas que serão distribuídas para que os clientes realizam a implantação/operação. Exemplos são: Jenkins, Sonar e Gitblit.

Porém, em ambientes muito corporativos em que existem várias aplicações desenvolvidas, com requisitos não funcionais como escalabilidade e performance, alta disponibilidade, resiliência, gerência de transações complexas (distribuídas), penso que um servidor de aplicações seria a melhor opção.

Nessa categoria, é possível configurar todas as aplicações em um mesmo ambiente, gerenciar clusters, configurar datasources, criar bibliotecas compartilhadas e etc. E, tudo isso, podendo ser reutilizado pelas aplicações

Ainda nesse tópico, não acredito em uma evolução da especificação Java EE. Vejo isso como a 'decisão' de implementação. Já existem servidores 'embutidos' que estão no mercado há mais de 2 anos. Veja o Jetty e Tomcat Embed que são compatíveis com a especificação Servlet.

Então, para as suas perguntas, acredito que a resposta é depende do cenário. Vejo que as duas abordagens existirão em paralelo. E, uma não exclui a outra!

Abraços!

Faço minha as palavras do Bruno. Muito bem colocadas por sinal. Reconheço que uma boa gama de aplicações que hoje executam sobre um servlet container fazem uso apenas de um container http. De nada aproveitam do container (cluster, balanceamento de carga, filtros, bibliotecas compartilhadas, recursos jndi entre outros). Isso pois estou mencionando recursos presentes em servlet container e não um servidor de aplicações. Se existe este cenário acredito que muitas aplicações poderão sim fazer uso deste recurso e já que a pivotal está apostando nisso acredito que muitas facilidades e recursos já estão por ai enquanto outras certamente virão. Como sempre, a filosofia por trás do spring é de não "brigar" com a especificação mas sempre oferecer mais opções para a comunidade. Parafraseando o Bruno, tudo vai ficar no famoso "Depende"...

Esse spring boot parece municão prá microservice. Talvez aí esteja a verdadeira discussão.

Eu achei excelente a notícia. Acho que chegou pra ficar. Como o Bruno bem lembrou, já há projetos da natureza, mas já quase fiz um "parto" pra poder fazer funcionar um tomcat embedded uma vez e desde então só se for extremamente necessário (nunca mais foi).

Se isso ficar mais simples, vejo principalmente o cenário de startups se beneficiando a longo prazo, pois subir uma App com um container sem depender da complexidade da configuração de um e já ter uma app em produção em curto espaço de tempo, nos dá o ganho justamente onde arquiteturas(frameworks) full-stack nos ajudam: "Termos rapidamente um produto funcionando". Ótima notícia ;)

Olá,

Ja tem mais de um ano que tenho adotado uma arquitetura bastante parecida com o Spring Boot nas minhas aplicações Java. Só que ao invés de usar o Spring uso o CDI (mais especificamente o Weld, da RedHat). Como container Http uso o Grizzly e para JPA uso o EclipseLink. Para frontend uso o Angular JS no lado do cliente e JAX-RS no lado do servidor. Em um caso em que precisei de uma fila de mensagens incorporei o HornetQ na arquitetura.

Não tenho sentido nenhuma falta de um servidor de aplicação - mas como disse muito bem o Kenji, minhas aplicações se parecem mais com microservices do que com aplicações corporativas Java EE.

Para startups, ao invés de um container autocontido, talvez seja mais interessante um desses PaaS da vida, não?

Adriano Martins Ohana disse:

Eu achei excelente a notícia. Acho que chegou pra ficar. Como o Bruno bem lembrou, já há projetos da natureza, mas já quase fiz um "parto" pra poder fazer funcionar um tomcat embedded uma vez e desde então só se for extremamente necessário (nunca mais foi).

Se isso ficar mais simples, vejo principalmente o cenário de startups se beneficiando a longo prazo, pois subir uma App com um container sem depender da complexidade da configuração de um e já ter uma app em produção em curto espaço de tempo, nos dá o ganho justamente onde arquiteturas(frameworks) full-stack nos ajudam: "Termos rapidamente um produto funcionando". Ótima notícia ;)

Sem dúvidas Leonardo. O que quero dizer, é relação ao conceito de ENTREGA e VALIDAÇÃO rápida. Claro que um PaaS no final das contas resolve a questão, mas eu acabo o meu SIstema e alí mesmo no meu Notebook eu subo para o cliente dar uma olhada sem ter que para isso usar um Heroku ou Openshift da vida, ou mesmo ter que subir e configurar um SC ou AS. Nesse sentido me animei. No final das contas (concordo completamente com você) em produção o cara não irá deixar o autocontido a menos que o modelo de negócios precise. Quanto a isso ainda estou pensando e pesando os possíveis cenários. Abs ;)


Leonardo Kenji Shikida disse:

Para startups, ao invés de um container autocontido, talvez seja mais interessante um desses PaaS da vida, não?

Senhores, 

Não sei se o futuro do container, mas a experência com container contido é fabulosa. Já passei pelos 2 mundos citados pelo Bruno: Spring Boot e Play. A experiência com o Play é muito bacana. O Play é simples rápido de desenvolver e o server é quase transparente e você esquece que está usando um server contido. O play tem 2 problemas: O pacote final fica muito grande e é muito complexo integrar com outros frameworks.

Já com o Spring Boot o container fica leve simples de controlar e o container é "engolido". As integrações com o spring são sempre mais fáceis de fazer. Já uso o spring boot em produção e ele não está arriando! Decidi por colocar cada pequeno serviço contido.

RSS

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço