Recentemente topei novamente (após muito tempo) com o Wildfly em um projeto. Isto me fez pensar: em 2021 o Wildfly (ou estes outros servidores de aplicação) ainda fazem sentido?
O que ganhamos com eles hoje?
1 Curtida
Spring boot usa o tomcat por default em baixo, trocar pelo jetty ou wildfly melhora a performance.
Usar como server separado com varias app dentro já é complicado por que tudo é dockerizado hoje.
1 Curtida
Eu acredito que ainda valha a pena. Existem muitos monolitos por aí e um App Server ainda te dá muita possibilidade pra compor sua aplicacão. A quantidade de clientes que eu pego por aqui que ainda usa JBoss EAP/Wildfly é bem expressiva (um deles, do setor público, tem mais de 100 apps, migrar isso pra fora do Wildfly é algo hérculeo).
Sem contar que o Wildfly ainda traz o MicroProfile. Isso pode ser uma boa pra quem ainda não quer entrar no mundo do Quarkus, por exemplo. Muitas organizacões ainda tem um certo receio de sair dessa esfera e acabam continuando. Sem contar o conhecimento de negócio perdido dentro de apps legados que os tornam quase impossíveis de sair da tecnologia em que estão.
Em termos de cloud eu não vejo tanto ganho além de um lift-and-shift. Se eu fosse fazer algo mirando um Kubernetes/OpenShift da vida, dificilmente eu adotaria Wildfly. Não por ser ruim, mas por não ser algo criado pensando em Cloud, ao contrário do Quarkus.
É interessante notar esse ponto da cloud. Projetos como Infinispan já saíram de cima do Wildfly e agora estão mais “cloud ready”. O Keycloak também está fazendo um esforco parecido (basta olharem o projeto Keycloak.X, que mira em usar o Quarkus como Runtime).
Resumindo: eu ainda vejo sentido em usar Wildfly em casos fora da cloud e com “liberdade reduzida”. Eu infelizmente não posso entrar em maiores detalhes, mas o Wildfly vai continuar firme e forte por um bom tempo, principalmente pra continuar suportando esses casos.
3 Curtidas
Eu acho que sim, principalmente para aplicações corporativas consolidadas, e ambientes onde transações e operações são priorizadas em vez de performance ou localização geográfica.
O triste é que hoje vejo em muitos clientes o servidor de aplicação ser subutilizado, simplesmente como servidor web, onde as aplicações não são pensadas para serem distribuídas. Resultado disso é que se cria a (má) fama do contêiner EJB ser pesado, pois a maioria das aplicações não utilizam JMS, RMI, JTA (distribuído) etc.
Tentaram até resolver isso com as profiles nas novas especificações, mas meio que a abordagem do stateless e action based já dominam o cenário. O resultado é que frameworks bootstraps se encaixaram na proposta de nuvem.
Ainda vejo em clientes a abordagem cloud ser um termo que a gestão de ti utiliza para mostrar inovação, mas sem olhar como agregar a tecnologia ao negócio e aos próprios processos. Mas isso é papo pra outra thread kkk
2 Curtidas
Faz todo sentido para aplicações corporativas que pretendem utilizar o Java como stack principal de desenvolvimento, desde o front-end até o back-end.
A grande vantagem de usar um servidor de aplicação é a possibilidade de subir mais de uma aplicação no mesmo container, aproveitando ao máximo os recursos da JVM. Além de poder gerenciar recursos como threads, pool de conexões JDBC, também temos acesso a coisas mais avançadas como mensageria (JMS) para comunicação entre as aplicações, cache distribuído (Infinispan) para armazenamento de dados em memória e até replicação de sessão, processamento em lote/jobs (Jakarta Batch) etc.
Tudo isso mantido pela atual especificação Jakarta EE 9.1, inclusive é possível utilizar a versão mais recente do Java com essa stack, porém é recomendado usar a versão 11 não só por ter suporte estendido mas sim por ser uma versão bem testada, estou ansioso para a próxima edição LTS, provavelmente será a versão 16. E como o @ataxexe comentou, o Wildfly integra com a especificação do Micro Profile também, existe até um modo de operação focado nisso, é o standalone-microprofile.xml.
Recentemente, escrevi um artigo básico ensinando como configurar um ambiente de desenvolvimento adqueado para termos uma boa experiência de desenvolvimento com essa stack, irei publicar diversos posts nos próximos dias ensinando tópicos mais avançados que eventualmente vou aproveitar na migração de uma aplicação legada.
Segue o link do artigo: https://medium.com/@fercomunello/primeiros-passos-com-o-servidor-de-aplicação-wildfly-jboss-e-jakarta-ee-c2e166719f15
1 Curtida
Vemos por aí muitas aplicações antigas em Java 7/8 que são publicadas em servidores de aplicação utilizando versões defasadas, geralmente esse tipo de aplicação é apenas um arquivo WAR com uma base de código muito grande para dar manutenção, além disso muitas delas nem seguem a especificação Java EE e por consequência terão uma migração dolorosa caso desejem mudar algo ou migrar para o Jakarta EE.
Um caso real disso que estou falando é uma aplicação que roda no Glassfish 4 utilizando o Spring integrado com JSF através de mudanças no ViewScope (gambiarra rsrs), essa aplicação possuí muitos anti-patterns e cada deploy leva cerca de 2 a 3 minutos para concluir, visto que possuí mais de 500 entidades JPA e muitas classes gerenciadas pelo Spring, afinal de contas esses frameworks precisam fazer o uso de muita Reflection para implementar toda a mágica que fazem hahahaha, mas o debate entre usar ORM ou não fica para outra thread. No geral, o servidor de aplicação não influencia no tempo de deploy, pois dificilmente levará mais de 10 segundos para subir, além disso você pode configurar o deploy remoto na IDE, assim o servidor é iniciado apenas uma vez durante o desenvolvimento.
A má fama do servidor de aplicação é apenas desconhecimento dos próprios devs com relação aos tema: Application Server X Web Server e Especificação X Implementação.
2 Curtidas