Se unisco molte app Web in una sola, salverò le risorse?

È poco chiaro se intendi condividere lo stesso contenitore J2EE o server fisico. Indipendentemente da ciò, il mio approccio suggerito è lo stesso, ma non so se sto suggerendo l'opzione 2 (che penso di essere) o una terza opzione che non hai considerato.

Se provi a ospitare molte app come un'unica app, significa che soffrirai molto di più da cose come il sovraccarico di thread all'interno dell'applicazione. Il sistema operativo è più abile nel gestire questo genere di cose di solito. Inoltre, soprattutto con la crescita del numero di app, è molto utile poter distribuire solo un punto. In generale sarà un po 'meno, ma un'app più grande avrà un overhead minimo in modo che la differenza non sia così pronunciata come indica il diagramma e stiamo parlando di piccole quantità di risorse che dovresti favorire l'approccio robusto e flessibile per pochi megabyte di memoria.

La mia azienda ha recentemente gettato un container Jetty monolitico in cambio di molte piccole webapp ciascuna con il proprio server Jetty integrato che gira sullo stesso server. Principalmente perché ci sono voluti più di 30 minuti per riavviare il server!

Sì, può utilizzare un po 'di più in termini di risorse iniziali, ma le risorse di coordinamento sono minori. Hai anche la possibilità di dividerli su più caselle. Anche un crash di un componente ha meno probabilità di influenzare gli altri. Inoltre puoi ridimensionarli individualmente, ad es. potresti aver bisogno di 3 istanze di app 2 ma solo 1 delle altre. Inoltre, puoi modificare le risorse minime assegnate su base per-app che probabilmente ti permetteranno di abbinarlo più piccolo.

Inoltre unirli insieme può rendere più difficile rintracciare la causa di un problema poiché la causa principale potrebbe non essere nell'app che ha avuto esito negativo. Questo di solito si riduce alle risorse in cui App2 potrebbe creare molti oggetti affamati di App3 che causano una OOM in app3. Ciò eliminerebbe tutti e 3 ma sembrerebbe che app3 sia stata la causa quando in realtà era app2

Quindi la consulenza in termini di risorse, flessibilità, scalabilità e robustezza è l'opzione 2, molte piccole app.

Potresti risparmiare un po 'di spazio su disco con l'approccio dell'applicazione divina, che btw è un anti-pattern.
Ma stai ottenendo un incubo di manutenzione, incubi di distribuzione, incubi di supporto, ecc. Ecc. Ecc. Penso che tu abbia ricevuto il messaggio.
Piuttosto che implementare solo una parte che è cambiata e lasciare il resto, è necessario che ogni volta che qualcosa di piccolo cambia in un sottosistema si distribuisca tutto da zero, non è una buona idea.

So che questa domanda riguarda app e servizi ma potresti voler leggere questo articolo perché l'idea di dividere un servizio in microservizi non è dissimile da dividere un'app in (eventualmente) micro app.

Generalmente molte app / servizi più piccoli sono la strada da percorrere, ma ...

"I microservizi implicano un sistema distribuito, mentre prima potevamo avere una chiamata al metodo che fungeva da confine del sottosistema, ora introduciamo molte chiamate di procedure remote, API REST o messaggistica per incollare i componenti tra diversi processi e server."

link

Se le tue app separate non avranno bisogno di interagire tra loro, tutto andrà bene, ma se suddividendo la tua singola app in app separate allora dovrai iniziare a fare chiamate API l'una con l'altra, allora dovresti incontrare lavoro e test aggiuntivi .

Un'altra cosa da considerare sono i cookie di sessione. Con la tua attuale app "dio" probabilmente hai solo una sessione per tutte le app. Se suddividendo le app esse sono veramente separate con la propria autenticazione, gestione delle sessioni e interfaccia web, tutto va bene. Ma se no, allora hai del lavoro extra da fare.

Il problema non riguarderebbe il risparmio di risorse, ma maggiori informazioni sulla gestione della complessità.

Saluti,