Deploying SpringBoot Applications

[Giuseppe Coniglio]

ciao a tutti,

sto sviluppando nuovi progetti che invocano oppure espongono api rest e li sto realizzando tutti con Spring Boot.

Non abbiamo un cloud, come descritto nella pagina ufficiale https://docs.spring.io/.../reference/html/deployment.html, il jar che creo viene copiato nel mio server Linux con 8 Gb di ram ed avviato con la versione openJdk 17 ivi presente.

Mi sono accorto che man mano che sto aumentando il numero di "jar" nella cartella e li avvio (anche distribuendo la memoria con i parametri 'Xms' e 'Xmx') la memoria libera sta terminando 

Le domande che pongo quindi:

• I nuovi sviluppi aumenteranno ed anche il numero di jar aumenterà da oggi al futuro, bisogna aggiungere sempre più Ram e prendere altri server Linux (avrò magari 100 microservizi, 25 in ogni server ad esempio, boh) ?
• Non capisco una cosa , ma se prima si usavano tecnologie “obsolete” come apache cxf, spring-ws /axis2 , in cui mettevi un “war” in un application server (Wildfly, Glassfish, Tomcat….) nel server Linux, con l’avvento di spring boot è paragonabile ad avere tanti application server in esecuzione, ma allora era meglio prima a livello di memoria utilizzata dal server, ora ho sì il vantaggio con i microservizi di spegnerne uno senza dover interrompere il totale funzionamento del sistema ma il consumo di memoria aumenta a dismisura..

E' corretto ?

E secondo voi come posso risolvere il problema della memoria, a parte aumentare la ram nel server ?

Grazie infinite

[Danilo Ventura]

Ciao

In genere la best practice è containerizzare e affidarti ad un orchestratore di container, soprattutto se i servizi cresceranno molto. I container ti permettono di eseguire più servizi nella stessa macchina sfruttando meglio le risorse. Un orchestratore come kubernetes, installandolo su 2/3 macchine fisiche ti aiuta a gestire risorse e container.

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/9584cd3c-3182-4bae-9b7a-2d103bd23573n%40googlegroups.com.

[Giuseppe Coniglio]

Ciao Danilo,

quindi per metterci  kubernetes  vVorrebbe dire cambiare anche server, è un'operazione impegnativa e dobbiamo contemplare i molti costi rispetto all'architettura attuale. 

Ho capito bene?

Grazie :-) 

[Giuseppe Coniglio]

Vi spiego perchè da qualche anno abbiamo usato spring boot per i nuovi progetti "backend" Java.
Quando sono arrivato nel 2017 ho ereditato la situazione seguente, nel Wildlfy oltre ad avere il war del nostro sito web, ho trovato diverse applicazioni war create con diverse tecnologie (ognuno usava quella che conosceva meglio), quindi un'applicazione con Apache CXF affinchè dal mio sito web al click di un pulsante invocasse il war creato con Apache CXF che a suo volta invoca un servizio esterno Soap in mutua autenticazione; poi sempre dentro lo stesso Wildfly ho trovato un war in cui esponiamo ad un soggetto terzo un endpoint soap (progetto creato con Spring Web Services); poi ho trovato un axis2.war che ha al suo interno diversi "aar" in cui ognuno è un servizio utilizzato direttamente dal mio sito web oppure che si scambiano dati fra di loro (in un aar ho addirittura inserito la chiamata con MA ad un endpoint rest terzo); arriviamo al 2017 e dobbiamo creare delle applicazioni utilizzate dal nostro sito oppure da nostri batch schedulati nel server, in cui entrambe le tipologie devono invocare endpoint esterni soap o rest -> usiamo SPRING BOOT; dobbiamo creare delle applicazioni java in cui siamo noi che esponiamo endpoint soap o rest a terzi -> usiamo SPRING BOOT.

Quindi la scelta di usare Spring boot è collegata al fatto di avere/esporre degli endpoint non dipendenti dal WILDFLY (come il sito web) in modo che con i microservizi posso spegnerne uno senza dover interrompere il totale funzionamento del sistema, cosa che con Wildfly non posso fare. Mi dispiaceva dover usare/esporre servizi rest mettendo il codice nei progetti "vecchi" e dover quindi stoppare il wilfly per il deploy ed aggiornamento....quindi abbiamo optato per spring boot, ognuno vive di vita propria.

Crescendo gli attori che invochiamo e/o ci invocano, crescendo le funzionalità di tutte , etc... arriviamo ad avere sempre più JAR Spring boot avviati nel nostro server Linux e quindi la RAM free sta diminuendo.

[Roberto Franchini]

ehi, quanta carne al fuoco!

Comincerei dalle basi, rileggendo questo: https://12factor.net/

E poi andro' un po' in ordine sparso, perche' le cose da dire sono tante. 

Primo: la memoria non e' infinita. Che tu stia deployando tutti i war in un singolo app-server o singoli jar, la memoria prima o poi finira'. Ed 8gb finiscono prima di subito. 

Piccolo appunto, anche se non andate in cloud, 8gb sono veramente pochi, per qualsiasi cosa.   

L'inganno del singolo app-server con molti war dentro, e' che gli assegni un tot di ram (6gb?) e poi lasci che le app deployate si scannino per le risorse, ma non hai controllo.

Con i singoli servizi puoi dare la giusta quantita' di memoria ad ognuno e spostare, in caso di necessita', quelli che richiedono piu' risorse (ram. I/o, CPU) su altre macchine.

In ogni caso, si', avendo una JVM per servizio, la somma non fa 6gb, perche' hai l'overhead della JVM PER servizio, mentre prima avevi una singola JVM per app-server. 

In ogni caso, nessuno ti vieta di mettere insieme i tuoi microservizi in un singolo jar e creare una situazione simile alla precedente: un monolite composto di micro-servizi.

NOTA a margine: Penso di aver comprato gli ultimi server bare-metal nel 2014 con almeno 64gb di ram. Oggi il mio laptop ne ha 32. Faccio fatica ad immaginare un server in produzione con 8gb di ram che faccia piu' di una/due cose.

Secondo: nessuna risorsa e' infinita. Non ho idea di cosa tu stia sviluppando, ma potresi avere servizi memory bound, altri I/O boud, altri CPU bound: deployarli separatamente, con una buona infrastruttura di monitoring, ti permette di capire chi e' il "cattivo" del gruppo. 

Cosa molto complicata da fare con il singolo app-server pieno di WARs.

Terzo: il futuro. Se stai effettivamente pensando di avere in futuro 100 servizi, no, non puoi assolutamente pensare di gestirli a "mano". Gli orchestratori sono nati per questo. 

Come diceva Danilo, se stai andando in quella direzione, dovreste cominciare ad acquisire conoscenza sul percorso che ti porta dai jar deployati a mano ad un cloud casalingo (io non sono un fan del cloud pubblico a tutti i costi, e farsi le ossa con k8s su bare-metal potrebbe essere molto istruttivo). 

PEr questo cominciare a deployare i tuoi servizi come docker container, passare ad un docker-compose e poi a k8s (oppure mettere subito k8s e farsi le ossa su quello). potrebbe essere, POTREBBE, essere una via. 

Non solo, devei avere in piedi una pipeline di CI/CD, ma questa la do per scontata, nel 2023.

Quarto:  ma perche' complicarsi la vita, il mio jar funziona benissimo. 

Ci sono affermazioni che fai che lasciano intuire che questi servizi non siano essenziali: li puoi spegnere quando vuoi e nessuno si lamenta. E non sembra che ci siano problemi di avaliability/scalability: hai una sola copia del singolo servizio in esecuzione.  

Questa situazione e' sostenibile nel medio lungo periodo? Dovrei garantire degli SLA e ridurre i tempi di fermo macchina a quasi zero? Dovrai poter scalare i singoli servizi perche' aumenta il carico su un singoo servizio (ecco il vantaggio, se solo un servizio e' sotto carico, scali solo quello)?

FRANK

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/9584cd3c-3182-4bae-9b7a-2d103bd23573n%40googlegroups.com.

--

Roberto Franchini
"The impossible is inevitable"
https://github.com/robfrank/
https://twitter.com/robfrankie
https://www.linkedin.com/in/robfrank

[Giuseppe Coniglio]

Hi Frank 😊

grazie per il link, ho già iniziato la lettura!
Ero convinto che dobbiamo andare in Cloud e con le vostre delucidazioni ne sono ancora più convito ..e quindi far sborsare i quattrini al cliente 😉

Sono riuscito a stoppare e far ripartire tutti i microservizi nel mio server Linux impostando la memoria con i parametri Xmx  e Xms, ed ora anziché avere solo 160 MB di memoria free ne ho recuperata 1.6 GB .. il presente è sistemato, possiamo quindi partire con gli studi per il Cloud e Kubernetes, perchè appunto  a tendere con gli sviluppi nuovi quindi aumenteranno il numero dei microservizi ,  prima o poi la memoria free sarà veramente ridotta al lumicino continuando come ora...ovviamente la prima spesa come ben dici sarà di aumentare la  RAM per i nostri server ! 

“il singolo app-server pieno di WARs” questo vale per i web services che ho ereditato e sviluppati con le tecnologie più disparate (axis2, Spring Ws, Apache CXF…) : ovviamente anche questi dovranno funzionare in Cloud (ho tre istanze di Wildfly, un application server ha il sito web e alcuni web services, le altre due istanze contengono web services)

Con Docker da quanto ho capito non avrei un miglioramento di prestazione ma solo una manutenibilità diversa

" Li puoi spegnere quando vuoi e nessuno si lamenta" : non ho mai detto questo, se spengo un microservizio che espone un api rest mi arriva subito la segnalazione dal soggetto chiamante che non riesce ad invocarci e non ha i dati che gli servono :-)

Il mio discorso riguarda l'aggiornamento di un jar, rispetto ad un war dentro il wildfly: nel caso del microservizio stoppo , copio , incollo , start in 30 secondi; nel caso di un war invece posso farlo "a caldo" oppure stoppare il Wildfly ( e quindi tutte le applicazioni war non sono accessibili , non soltanto il war che intendo aggiornare) - copiare e incollare il nuovo war - avviare il Wildfly con tempi anche più elevati di restart

Grazie molte per le informazioni ricevute 😊

Buon inizio settimana a tutti

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAMpo0wgGrLq6V9XJSRNOh36ZvNHmh2a6qiHnuQdVNrSqmgRdVA%40mail.gmail.com.

[Roberto Franchini]

Rispondo in linea

On Sun, Mar 5, 2023 at 9:34 PM Giuseppe Coniglio <jackf...@gmail.com> wrote:

Hi Frank 😊

grazie per il link, ho già iniziato la lettura!
Ero convinto che dobbiamo andare in Cloud e con le vostre delucidazioni ne sono ancora più convito ..e quindi far sborsare i quattrini al cliente 😉

Ho detto chiaramente che puoi anche costruirlo in casa.

Cosa significa far spendere soldi al cliente?

I server fisici non li compri? non li alimenti con la corrente elettrica? non hai piani di backup? i dischi non si rompono?

Certe scelte non sono solo tecniche: dove voglio spendere i soldi? Preferisco POSSEDERE o AFFITTARE?

Se il tuo modello di business non prevede di scalare in modo repentino, potresti non aver bisogno del cloud.

MA devi avere uno o piu' (meglio piu') sistemisti che tengano a bada la fattoria (la farm).

Aggiornamento delle macchine, security, fermare gli attacchi, etc.

Sostanzialmente devi decidere dove spendere i soldi.

Ma non e' una decisione solo tecnica.

 

Sono riuscito a stoppare e far ripartire tutti i microservizi nel mio server Linux impostando la memoria con i parametri Xmx  e Xms, ed ora anziché avere solo 160 MB di memoria free ne ho recuperata 1.6 GB .. il presente è sistemato, possiamo quindi partire con gli studi per il Cloud e Kubernetes, perchè appunto  a tendere con gli sviluppi nuovi quindi aumenteranno il numero dei microservizi ,  prima o poi la memoria free sarà veramente ridotta al lumicino continuando come ora...ovviamente la prima spesa come ben dici sarà di aumentare la  RAM per i nostri server ! 

MA seriamente avete un solo server con 8gB di ram in produzione?

Senza ridondanza? Esposto su internet?

Avete anche un ambiente di staging?

 

“il singolo app-server pieno di WARs” questo vale per i web services che ho ereditato e sviluppati con le tecnologie più disparate (axis2, Spring Ws, Apache CXF…) : ovviamente anche questi dovranno funzionare in Cloud (ho tre istanze di Wildfly, un application server ha il sito web e alcuni web services, le altre due istanze contengono web services)

Con Docker da quanto ho capito non avrei un miglioramento di prestazione ma solo una manutenibilità diversa

MA intanto fai un passo. Siamo nel 2023.

Pensare di fare test di integrazione automatici senza docker (testcontainers rulez) mi pare impossibile oggi.

I container sono isolati, non sporcano la tua macchina, non possono fare zozzerie.

Come testi i tuoi servizi, se ad esempio devono usare un db? O un altro servizio?

" Li puoi spegnere quando vuoi e nessuno si lamenta" : non ho mai detto questo, se spengo un microservizio che espone un api rest mi arriva subito la segnalazione dal soggetto chiamante che non riesce ad invocarci e non ha i dati che gli servono :-)

Il mio discorso riguarda l'aggiornamento di un jar, rispetto ad un war dentro il wildfly: nel caso del microservizio stoppo , copio , incollo , start in 30 secondi; nel caso di un war invece posso farlo "a caldo" oppure stoppare il Wildfly ( e quindi tutte le applicazioni war non sono accessibili , non soltanto il war che intendo aggiornare) - copiare e incollare il nuovo war - avviare il Wildfly con tempi anche più elevati di restart

Nel senso che non c'e' un processo di deploy automatico dal server di CI (avete la CI, vero?): sposti i jar a mano da una macchina all'altra? 

 

Grazie molte per le informazioni ricevute 😊

Scusa se in alcuni punti posso sembrare polemico, ma la mia e' sincera curiosita'.

FRANK

 

[Giuseppe Coniglio]

ciao, ti rispondo sotto 

Il giorno dom 5 mar 2023 alle ore 23:06 Roberto Franchini <ro.fra...@gmail.com> ha scritto:

Rispondo in linea

On Sun, Mar 5, 2023 at 9:34 PM Giuseppe Coniglio <jackf...@gmail.com> wrote:

Hi Frank 😊

grazie per il link, ho già iniziato la lettura!
Ero convinto che dobbiamo andare in Cloud e con le vostre delucidazioni ne sono ancora più convito ..e quindi far sborsare i quattrini al cliente 😉

Ho detto chiaramente che puoi anche costruirlo in casa.

Cosa significa far spendere soldi al cliente?

I server fisici non li compri? non li alimenti con la corrente elettrica? non hai piani di backup? i dischi non si rompono?

Certe scelte non sono solo tecniche: dove voglio spendere i soldi? Preferisco POSSEDERE o AFFITTARE?

Se il tuo modello di business non prevede di scalare in modo repentino, potresti non aver bisogno del cloud.

MA devi avere uno o piu' (meglio piu') sistemisti che tengano a bada la fattoria (la farm).

Aggiornamento delle macchine, security, fermare gli attacchi, etc.

Sostanzialmente devi decidere dove spendere i soldi.

Ma non e' una decisione solo tecnica.

Abbiamo sì una server Farm gestiti da sistemisti e specialist vari, ad oggi è on-prem, quindi possediamo. Sicuramente io sto analizzando la parte "tecnica" da sviluppatore non posso decidere se possedere o affittare, ma vorrei capire appunto in base agli sviluppi futuri e l'architettura attuale se continuare così , opzione aumento a 64 GB di RAM e poi dopo che vado in pensione chi viene dopo si arrangia oppure preferisco aggiornare il tutto come fatto con gli sviluppi con Java 17 / Spring Boot etc... :-)

 

Sono riuscito a stoppare e far ripartire tutti i microservizi nel mio server Linux impostando la memoria con i parametri Xmx  e Xms, ed ora anziché avere solo 160 MB di memoria free ne ho recuperata 1.6 GB .. il presente è sistemato, possiamo quindi partire con gli studi per il Cloud e Kubernetes, perchè appunto  a tendere con gli sviluppi nuovi quindi aumenteranno il numero dei microservizi ,  prima o poi la memoria free sarà veramente ridotta al lumicino continuando come ora...ovviamente la prima spesa come ben dici sarà di aumentare la  RAM per i nostri server ! 

MA seriamente avete un solo server con 8gB di ram in produzione?

Senza ridondanza? Esposto su internet?

Avete anche un ambiente di staging?

Abbiamo un server apache esposto per il nostro sito www.miosito.com , poi c'è un HAPROXY e poi ci sono due server con 8Gb di RAM, l'ho trovato così e non ho potuto farci niente all'epoca in cui sono arrivato, per tutte le altre domande come sopra ci sono sistemisti e specialist vari che ne occupano.

 

 

“il singolo app-server pieno di WARs” questo vale per i web services che ho ereditato e sviluppati con le tecnologie più disparate (axis2, Spring Ws, Apache CXF…) : ovviamente anche questi dovranno funzionare in Cloud (ho tre istanze di Wildfly, un application server ha il sito web e alcuni web services, le altre due istanze contengono web services)

Con Docker da quanto ho capito non avrei un miglioramento di prestazione ma solo una manutenibilità diversa

MA intanto fai un passo. Siamo nel 2023.

Pensare di fare test di integrazione automatici senza docker (testcontainers rulez) mi pare impossibile oggi.

I container sono isolati, non sporcano la tua macchina, non possono fare zozzerie.

Come testi i tuoi servizi, se ad esempio devono usare un db? O un altro servizio?

Ok Docker non ho detto che sono contrario al suo utilizzo, ma a prescindere da Docker adesso l'urgenza è un 'altra.

Ci sono servizi che espongo  che sì fanno chiamate al mio DB e restituiscono dati, altri invece che non fanno alcuna chiamata al DB (esempio ho esposto un microservizio che invoca il VIES https://ec.europa.eu/taxation_customs/vies/#/technical-information)

 

" Li puoi spegnere quando vuoi e nessuno si lamenta" : non ho mai detto questo, se spengo un microservizio che espone un api rest mi arriva subito la segnalazione dal soggetto chiamante che non riesce ad invocarci e non ha i dati che gli servono :-)

Il mio discorso riguarda l'aggiornamento di un jar, rispetto ad un war dentro il wildfly: nel caso del microservizio stoppo , copio , incollo , start in 30 secondi; nel caso di un war invece posso farlo "a caldo" oppure stoppare il Wildfly ( e quindi tutte le applicazioni war non sono accessibili , non soltanto il war che intendo aggiornare) - copiare e incollare il nuovo war - avviare il Wildfly con tempi anche più elevati di restart

Nel senso che non c'e' un processo di deploy automatico dal server di CI (avete la CI, vero?): sposti i jar a mano da una macchina all'altra? 

Sì, sono uno e trino :-)

 

Grazie molte per le informazioni ricevute 😊

Scusa se in alcuni punti posso sembrare polemico, ma la mia e' sincera curiosita'.

FRANK

Ma figurati, nessuna polemica, anzi ben vengano i vostri consigli 

Grazie ancora

😊

 

 

--

Roberto Franchini
"The impossible is inevitable"
https://github.com/robfrank/
https://twitter.com/robfrankie
https://www.linkedin.com/in/robfrank

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAMpo0whYA33VCKV6KqSU20W-8iB6JOLP0%3D1_qVxiTHswPVU_yg%40mail.gmail.com.

[Giuseppe Coniglio]

 From simple to complex, here are the five ways of running microservices :-) 

1. Single machine, multiple processes: buy or rent a server and run the microservices as processes.
2. Multiple machines, multiple processes: the obvious next step is adding more servers and distributing the load, offering more scalability and availability.
3. Containers: packaging the microservices inside a container makes it easier to deploy and run along with other services. It’s also the first step towards Kubernetes.
4. Orchestrator: orchestrators such as Kubernetes or Nomad are complete platforms designed to run thousands of containers simultaneously.
5. Serverless: serverless allows us to forget about processes, containers, and servers, and run code directly in the cloud.