Consigli per la distribuzione di file war rispetto a jar eseguibili con contenitore incorporato

Sembra esserci una tendenza attuale nello spazio java di allontanarsi dalla distribuzione di applicazioni web java a un contenitore servlet java (o server applicazioni) sotto forma di un file war (o file ear) e invece impacchettare l'applicazione come un jar eseguibile con un servlet / server HTTP incorporato come jetty. E lo intendo maggiormente nel modo in cui i framework più recenti stanno influenzando il modo in cui le nuove applicazioni vengono sviluppate e distribuite piuttosto che come le applicazioni vengono fornite agli utenti finali (perché, ad esempio, capisco perché Jenkins utilizza un contenitore incorporato, molto facile da afferrare e andare ). Esempi di framework che adottano l'opzione jar eseguibile: Dropwizard , Spring Boot e Play (beh, non viene eseguito su un contenitore servlet ma il server HTTP è incorporato).

La mia domanda è, provenendo da un ambiente in cui abbiamo distribuito le nostre applicazioni (fino a questo punto principalmente Struts2) su un singolo server di applicazioni Tomcat, quali modifiche, best practice o considerazioni devono essere fatte se intendiamo utilizzare un approccio contenitore incorporato ? Attualmente, abbiamo circa 10 applicazioni sviluppate internamente in esecuzione su un singolo server Tomcat e per queste applicazioni piccole la capacità di condividere risorse ed essere gestite su un server è piacevole. Le nostre applicazioni non sono pensate per essere distribuite agli utenti finali per essere eseguite nel loro ambiente. Tuttavia, andando avanti se decidiamo di sfruttare un nuovo framework Java, questo approccio dovrebbe cambiare? Il passaggio ai jar eseguibili è stimolato dal crescente utilizzo di implementazioni cloud (ad es. Heroku)?

Se hai esperienza nella gestione di più applicazioni nello stile di distribuzione Play rispetto alla distribuzione tradizionale di file war su un singolo server delle applicazioni, condividi le tue informazioni.

Una domanda interessante. Questa è solo la mia opinione sull'argomento, quindi prendi tutto con le pinze. Occasionalmente ho implementato e gestito applicazioni utilizzando sia contenitori servlet che server incorporati. Sono sicuro che ci sono ancora molte buone ragioni per usare i contenitori servlet, ma cercherò di concentrarmi solo sul motivo per cui sono meno popolari oggi.

Versione breve: i contenitori servlet sono ottimi per gestire più applicazioni su un singolo host ma non sembrano molto utili per gestire una sola applicazione. Con gli ambienti cloud, una singola applicazione per macchina virtuale sembra preferibile e più comune. I framework moderni vogliono essere compatibili con il cloud, quindi il passaggio ai server embedded.

Quindi penso che i servizi cloud siano la ragione principale per abbandonare i contenitori servlet. Proprio come i contenitori servlet ti consentono di gestire le applicazioni, i servizi cloud ti consentono di gestire macchine virtuali, istanze, archiviazione dati e molto altro ancora. Sembra più complicato, ma con gli ambienti cloud c'è stato un passaggio a macchine per app singole. Ciò significa che puoi spesso trattare l'intera macchina come se fosse l' applicazione. Ogni applicazione viene eseguita su una macchina con dimensioni appropriate. Le istanze cloud possono apparire e svanire in qualsiasi momento, il che è ottimo per il ridimensionamento. Se un'applicazione richiede più risorse, crei più istanze.

I server dedicati d'altra parte di solito sono potenti ma con dimensioni fisse, quindi puoi eseguire più applicazioni su una singola macchina per massimizzare l'uso delle risorse. Gestire dozzine di applicazioni, ognuna con le proprie configurazioni, server web, percorsi e connessioni ecc., Non è divertente, quindi l'utilizzo di un servlet container ti aiuta a mantenere tutto gestibile e sano di mente. Tuttavia è più difficile scalare. I contenitori servlet nel cloud non sembrano molto utili. Dovrebbero essere impostati per ogni piccola istanza, senza fornire molto valore poiché gestiscono solo una singola applicazione.

Inoltre, le nuvole sono belle e le cose non cloud sono noiose (se crediamo ancora al clamore). Molti framework cercano di essere scalabili per impostazione predefinita, in modo da poter essere facilmente distribuiti nei cloud. I server incorporati sono veloci da implementare ed eseguire, quindi sembrano una soluzione ragionevole. I contenitori servlet di solito sono ancora supportati ma richiedono una configurazione più complicata.

Alcuni altri punti:

• Il server incorporato potrebbe essere ottimizzato per il framework o è meglio integrato con gli strumenti del framework (come ad esempio la console di gioco).
• Non tutti gli ambienti cloud sono dotati di immagini macchina personalizzabili. Invece di scrivere script di inizializzazione per scaricare e configurare contenitori servlet, l'utilizzo di software dedicato per le distribuzioni di applicazioni cloud è molto più semplice.
• Devo ancora trovare una configurazione Tomcat che non ti accolga con un errore di spazio gen di perm ogni poche ridistribuzioni della tua app. Impiegare un po 'più di tempo per (ri) avviare i server incorporati non è un problema quando puoi passare quasi istantaneamente dalle istanze di staging a quelle di produzione senza tempi di fermo.
• Come già accennato nella domanda, è molto conveniente per l'utente finale eseguire semplicemente l'applicazione.
• I server incorporati sono portatili e convenienti per lo sviluppo. Oggi tutto è rapido , i prototipi e gli MVP devono essere creati e consegnati il ​​più velocemente possibile. Nessuno vuole dedicare troppo tempo alla creazione di un ambiente per ogni sviluppatore.