{"id":8049,"date":"2025-09-24T11:02:54","date_gmt":"2025-09-24T09:02:54","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=8049"},"modified":"2025-09-24T14:50:13","modified_gmt":"2025-09-24T12:50:13","slug":"da-monolite-infrastrutturale-a-cloud-native-la-nuova-vita-di-un-vecchio-load-balancer","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/da-monolite-infrastrutturale-a-cloud-native-la-nuova-vita-di-un-vecchio-load-balancer\/","title":{"rendered":"Da monolite infrastrutturale a Cloud-Native: la nuova vita di un vecchio Load Balancer"},"content":{"rendered":"\n
\n\u201cDobbiamo guardare le cose in modo diverso.\u201d Robin Williams (John Keating) \u2013 L\u2019attimo fuggente<\/p>\n<\/blockquote>\n\n\n\n
Ahh, scomporre un monolite! Il classico esercizio da sviluppatore che tutti hanno affrontato almeno una volta nella loro carriera.<\/p>\n\n\n\n
Ma come smantellare un monolite infrastrutturale? Come rendere agile e modulare un sistema grande e complesso? <\/p>\n\n\n\n
Per questo articolo, parliamo di un sistema che ha visto passare generazioni di sysadmin che hanno aggiunto configurazioni secondo il proprio gusto personale. Ci siamo trovati ad avere a che fare con un Load Balancer che ha superato upgrade di kernel, virtualizzazione, cambiamenti del linguaggio di configurazione e migrazioni al punto che nessuno voleva pi\u00f9 toccarlo, nemmeno con un bastone lungo 5 metri!<\/p>\n\n\n\n
Ma a noi piacciono le sfide, quindi quando ci hanno chiesto di partecipare a questo progetto di migrazione quasi impossibile, da sistemi legacy on-premise a servizi gestiti cloud-native AWS mantenendo il sito operativo, abbiamo quasi festeggiato.<\/p>\n\n\n\n
In questo articolo vedremo la parte pi\u00f9 importante del percorso di migrazione, mettendo in evidenza l\u2019approccio e il pattern usato per realizzare questa impresa che sembrava impossibile.<\/p>\n\n\n\n
Il mostro<\/h2>\n\n\n\n
Immaginate un sito aziendale nato a met\u00e0 degli anni \u201990 e che ha visto l\u2019intera trasformazione di Internet. Da un semplice sito statico con tag <blink> e gif animate, \u00e8 diventato un capolavoro di design e il punto centrale per tutto ci\u00f2 che riguarda il business: meeting, calendari, intranet pubblica e privata (per consulenti e staff interno con diversi Identity provider e regole di autenticazione personalizzate), micro-siti marketing con molteplici installazioni dell\u2019onnipresente WordPress. Tutto ovviamente instradato e gestito utilizzando una coppia di load balancer in alta affidabilit\u00e0 e un singolo dominio DNS, senza sapere quali parti del sito fossero ancora utilizzate. Diversi identity provider sono usati, uno per lo staff interno e uno per i contractor, aggiungendo complessit\u00e0 a uno scenario gi\u00e0 complesso.<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
L\u2019approccio<\/h2>\n\n\n\n
Uno dei miei pattern preferiti per smantellare i monoliti \u00e8 lo \u201cStrangler Fig Pattern\u201d di Martin Fowler. Utilizzando questo approccio, si sostituisce un sistema vecchio gradualmente, riscrivendo i componenti in modo incrementale e mettendoli subito in produzione, mantenendo il sistema originale finch\u00e9 serve.<\/p>\n\n\n\n
Nel nostro caso, il sistema \u00e8 composto da tre componenti principali:<\/p>\n\n\n\n
\n
- Backend Load Balancing<\/li>\n\n\n\n
- Un portale di autenticazione che instrada le richieste ai server di autenticazione appropriati in base al dominio dell\u2019utente e usando protocolli diversi (LDAP Active Directory, OIDC, SAML)<\/li>\n\n\n\n
- Routing applicativo per la selezione del backend, basato su subpath<\/li>\n<\/ul>\n\n\n\n
A questo punto, abbiamo compreso che ci serviva qualcosa che potesse instradare le richieste permettendoci di lavorare dietro le quinte e sostituire i componenti in silenzio; la stessa tecnologia doveva permetterci anche di implementare un\u2019architettura Proof-of-Concept per validare le nostre ipotesi. Fortunatamente, esiste Amazon CloudFront.<\/p>\n\n\n\n
CloudFront come strangler fig<\/h4>\n\n\n\n
Amazon CloudFront \u00e8 una CDN globale il cui comportamento \u00e8 facilmente personalizzabile per soddisfare diverse esigenze. Ad esempio, utilizzando CloudFront Functions, \u00e8 possibile modificare le richieste HTTP prima che raggiungano il server o alterare le risposte prima di servirle al client.<\/p>\n\n\n\n
Come inserirsi nel flusso del load balancer<\/h4>\n\n\n\n
Per sostituire il load balancer per prima cosa occorre creare una distribuzione Amazon CloudFront \u201ctemporanea\u201d con il nome di dominio attuale per testare che tutto funzioni. <\/p>\n\n\n\n
\u00c8 possibile importare il certificato esistente in Amazon Certificate Manager (ACM) e configurare il load balancer legacy come origin; poich\u00e9 il record DNS non viene modificato, il sito non subisce malfunzionamenti: per testare il setup, infatti, basta modificare il file hosts puntando agli IP della distribuzione CloudFront.<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
Una volta testato il corretto funzionamento anche con l\u2019inserimento di CloudFront, siamo riusciti ad attaccare la parte pi\u00f9 critica non disponibile nativamente su CloudFront: l\u2019autenticazione<\/strong>.<\/p>\n\n\n\n
Implementando l\u2019autenticazione, possiamo fare replatform o lift-and-shift dei server nel Cloud e scomporre le applicazioni senza toccare il load balancer originale.<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
Flusso di autenticazione<\/h4>\n\n\n\n
Il load balancer legacy ospita un backend interno custom (auth.awesomecorp.org) che gestisce l\u2019autenticazione. <\/p>\n\n\n\n
Ogni richiesta viene intercettata, controllando JWT, Cookie e altri meccanismi di autenticazione. Se l\u2019utente accede a una risorsa protetta senza essere autenticato, viene mostrata una pagina ospitata dal load balancer. <\/p>\n\n\n\n
Dopo l\u2019inserimento delle credenziali, il load balancer stabilisce il backend di autenticazione utente corretto (in base al formato dello username) e procede con l\u2019autenticazione. Terminata l\u2019autenticazione, viene servito un cookie con contenuti diversi a seconda del path dell\u2019applicazione.<\/p>\n\n\n\n
Come possiamo implementare questo meccanismo solo con servizi cloud-native?<\/p>\n\n\n\n