Piu' che altro un rant... Anzi due...
Primo la storia dei microservizi (in ambiente dockerizzato). Sinceramente non capisco questa moda (non so come altro definirla). Posso capire di evitare monoliti, ma se devi esporre tot WS non capisco il senso di avere un progetto per ogni ws esposto.
Si certo li puoi mettere su macchine separate, ma comunque avrai che se la macchina X e' down quel servizio non e' raggiungibile, a meno di non avere 2X macchine.
Se invece ho un applicativo solo replicato su un cluster, ho lo stesso un numero di macchine superiore a 1, ma ho due grossi vantaggi. Non c'e' un servizio che va giu, se va giu' va giu' tutta la macchina e un'altra identica prende il suo posto. Questo vuol dire che ho tutti i ws in continuita' di servizio.
La seconda e' che i cluster hanno meccanismi per comunicare tra le macchine (load balancing, replicazione dei job, keep-alive etc). Questo vuol dire che se un ejb o un job non deve andare giu' in un cluster ho la possibilita' di "spostarlo" sulla macchina viva.
Mi da' l'idea di qualcuno che voleva fare un cluster ma non sapeva come fare,
per cui ha ripiegato sulla soluzione "semplice" (che poi da' anche piu' problemi).
Qual'e' il problema? CHe non usano un server (in realta' lo usano ma non lo sanno), usano spring boot (che ha dentro tomcat). In teoria spring boot "fa tutto lui" tu dovresti solo concentrarti sullo scrivere codice.
Non che ci sia qualcosa di male ad avere un programmatore concentrato, e' il resto il problema. Un programmatore non dovrebbe saper solo programmare, non dico che debba essere un sistemista, ma devi avere una certa comprensione di come funziona tutto quello che non e' codice. Per il semplice fatto che ti ci devi interfacciare.
Spring ha il grossissimo problema (non solo lui, tutti i tool che sostituiscono qualcosa) di mascherare il funzionamento di quello che c'e' sotto (con il peggiorativo che in ambiente J2EE finisci per usare tomcat che e' un servlet container). Quindi finche' funziona tutti contenti. Quando poi ci sono problemi e' molto piu' complicato sapere dove intervenire proprio perche' non hai immediatamente accesso alla struttura sottostante, ma c'e' spring che ti maschera gli errori.
Se poi aggiungi che chi ha sempre usato spring non ha una grande comprensione di come funzioni l'ambiente in cui il suo sw gira (per forza di cose). Il danno e' dietro l'angolo.
Nel mondo dello sviluppo web sono state fatte un monte di framework carini (es jsf). Il problema e' che sono sempre framework. Alla fine si tratta sempre di pagine web (html + js o jsp) e che lavori sempre con le servlet, c'e' una request e una response, anche se non lo vedi.
Per carita' e' infinitamente piu' comodo trovarsi i valori nelle variabili gia' "infilati" senza doverseli estrarre dalla Request, pero' conoscere come funziona "sotto il cofano" puo' darti una mano nel capire quando si verifica un problema.
Wildfly ha una gestione "alla linux" ovvero ci sono i suoi file di configurazione e tramite un banalissimo editor di testo puoi fare tutte le modifiche che vuoi (a server fermo). E' stabile e potente.
Di tomcat dico solo che non conosco nessuno che non lo riavvii almeno una volta al giorno.
Quindi? Niente ridatemi wildfly...
