Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / API Gateway spiegato: routing, sicurezza e rate limiting per i microservizi – ne hai davvero bisogno? (Doppiaggio IA)

Transcript

API Gateway spiegato: routing, sicurezza e rate limiting per i microservizi – ne hai davvero bisogno? (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

• 0:00
  Pronti per 10 giorni di Microsoft 365, Copilot, IA, Azure e per chi plasma il futuro del lavoro e per chi plasma il futuro del lavoro.
• 0:08
  Questo gennaio, la M365 contorna e sarà ancora più grande.
• 0:12
  Unitevi a noi per sessioni live, demo reali e conoscenze pratiche da MVP ed esperti del settore di tutto il mondo.
• 0:18
  Niente slide generiche, niente gergo infinito.
• 0:21
  Affrontiamo le sfide reali.
• 0:23
  Copilot Studio, agenti IA, Fabric, Sicurezza, Governance e Automazione e Automazione.
• 0:29
  Che siate professionisti IT, sviluppatori o leader aziendali, ci sono sessioni pensate per voi.
• 0:35
  Con 10 giorni interi potrete esplorare molteplici tecnologie e connettervi con una community globale.
• 0:40
  Seguite in diretta e portate approfondimenti pratici nella vostra organizzazione.
• 0:45
  Gennaio 2027, 10 giorni, un'unica community Microsoft.
• 0:49
  Le iscrizioni sono aperte.
• 0:51
  Andate su m365con.net e assicuratevi il vostro posto oggi stesso.
• 0:55
  È m365con.net.
• 1:00
  Iscrivetevi ora su m365con.net.
• 1:02
  Vi aspettiamo.
• 1:03
  Live a gennaio.
• 1:05
  Avete creato un'app funzionante, poi aggiungete un servizio dopo l'altro e gestire il traffico diventa un incubo.
• 1:11
  Quindi cos'è esattamente un API Gateway e ne avete davvero bisogno?
• 1:14
  Alla fine di questo episodio capirete cosa fa un API Gateway,
• 1:18
  perché risolve il caos di gestire più servizi e come sapere se ne avete bisogno.
• 1:21
  Partiamo dal problema, poi dai componenti e infine da come si integrano.
• 1:27
  Il problema ha troppe porte.
• 1:29
  Immaginate di gestire un'azienda in rapida crescita.
• 1:32
  Avete il team vendita al terzo piano, la contabilità nel seminterrato e le team nella posteriore.
• 1:37
  Ora, immaginate che ogni singolo reparto abbia la sua porta, il suo numero di telefono e la sua guardia di sicurezza che non parla con le altre.
• 1:43
  Se siete un visitatore che deve consegnare un pacco, buona fortuna.
• 1:45
  Dovete sapere esattamente quale porta usare, a quale guardia parlare e cosa fare quando quella guardia è in pausa.
• 1:51
  È esattamente ciò che accade quando la vostra app ha diversi servizi back-end, ogni client chiama ciascuno di essi direttamente.
• 1:56
  Il client, che sia un'app mobile, un sito web o un altro servizio, deve sapere dove si trova ogni servizio,
• 2:01
  come autenticarsi e cosa fare in caso di errore.
• 2:05
  Ogni singolo servizio deve gestire la propria sicurezza, il proprio rate limiting e la propria gestione degli errori.
• 2:09
  È lavoro duplicato ed è facile che si creino incoerenze.
• 2:12
  Vediamo una banca ad esempio.
• 2:14
  Hanno servizi separati per conti, pagamenti, prestiti e rilevamento frodo.
• 2:17
  Nel vecchio metodo ognuno è esposto direttamente.
• 2:19
  Un'app mobile deve conoscere quattro diversi URL, quattro diversi metodi di autenticazione e quattro diverse modalità di gestione degli errori.
• 2:25
  Si tratta di una complessità quadrupla e di un'area di rischio quattro volte superiore
• 2:29
  ed è proprio questo il caos che un API Gateway mira a risolvere.
• 2:32
  Quindi qual è la soluzione?
• 2:34
  Cos'è un API Gateway?
• 2:35
  Immagina un API Gateway come la reception di un hotel.
• 2:37
  Quando entri non hai bisogno di sapere su quale piano si trovi il personale delle pulizie,
• 2:42
  dove sia la cucina o come contattare la manutenzione.
• 2:44
  Vai semplicemente alla reception, spieghi cosa ti serve e loro gestiscono tutto il resto.
• 2:48
  Indirizzano la tua richiesta alla persona giusta.
• 2:50
  Verificano se hai il permesso di essere lì e gestiscono persino le richieste di base autonomamente.
• 2:54
  Un API Gateway fa la stessa cosa per il tuo software.
• 2:57
  È un punto di ingresso unico che si colloca tra i tuoi client e i servizi di back-end.
• 3:01
  Ogni richiesta passa prima attraverso il Gateway.
• 3:03
  Il Gateway decide dove inviarla, se autorizzarla e cosa rimandare indietro.
• 3:07
  Ora, non è un'idea nuova.
• 3:09
  I proxy inversi esistono da decenni, ma l'AP Gateway è diventato essenziale con i microservizi.
• 3:14
  Quando dividi la tua app in molti piccoli servizi, ti ritrovi improvvisamente con molte palle.
• 3:17
  Il Gateway ti offre un unico ingresso principale.
• 3:19
  Nel mondo Azure, Azure API Management è la piattaforma completa
• 3:22
  e il Gateway è il componente principale che gestisce il traffico.
• 3:25
  Tuttavia, il modello è lo stesso ovunque.
• 3:26
  Un punto di ingresso, controllo centralizzato.
• 3:29
  Ogni richiesta arriva.
• 3:30
  Il Gateway la verifica là in strada e invia la risposta.
• 3:33
  Il client non comunica mai direttamente con i servizi di back-end.
• 3:35
  Comunica solo con il Gateway.
• 3:36
  Analizziamo cosa significa realmente.
• 3:39
  Iniziamo con il compito più basilare, l'estradamento.
• 3:42
  Parte 1 è l'estradamento del traffico.
• 3:44
  Il compito più semplice di un'AP Gateway è l'estradamento, ovvero indirizzare ogni richiesta al servizio corretto.
• 3:49
  Pensa a come funziona un sito web.
• 3:50
  Quando clicchi su un link, il tuo browser invia una richiesta.
• 3:53
  Quella richiesta ha un percorso.
• 3:54
  Se hai percorso i users, i Gateway sa di doverli inviare al servizio utenti.
• 3:57
  Se è orders, va al servizio ordini.
• 3:59
  Il Gateway legge il percorso, capisce dove deve andare e lo inoltre, senza un Gateway, i tuoi client devono conoscere l'URL di ogni singolo servizio.
• 4:07
  L'app mobile ha bisogno dell'indirizzo del servizio utenti, del servizio ordini, del servizio pagamenti, del servizio catalogo.
• 4:12
  Sono davvero molti URL da gestire.
• 4:14
  E se uno di questi indirizzi cambia, deve aggiornare ogni singolo client.
• 4:16
  Con un Gateway i client conoscono un solo URL, l'indirizzo del Gateway.
• 4:20
  Non importa dove risiedono realmente i servizi, inviano semplicemente la richiesta al Gateway che gestisce tutto il resto.
• 4:26
  Questo è uno dei casi d'uso più comuni per un API Gateway, il routing basato sulle risorse.
• 4:30
  La ricerca di Apache Apisix lo menziona esplicitamente.
• 4:32
  Si instrada in base al percorso, al metodo HTTP agli header, persino alla geolocalizzazione del client.
• 4:37
  Se qualcuno in Europa invia una richiesta, può instradarlo verso un datacenter europeo.
• 4:41
  Se qualcuno negli user invia una richiesta e viene indirizzato verso un datacenter uniteno.
• 4:44
  Il client non sa nulla di tutto ciò che sta accadendo.
• 4:46
  Ricevi semplicemente una risposta rata.
• 4:48
  Routing gestisce anche il versionamento.
• 4:49
  Supponiamo di avere una nuova versione del servizio te.
• 4:51
  I vecchi client usano ancora Absalash Unelash Users, i nuovi usano Absalash Users.
• 4:55
  Il Gateway è in strada verso back-end differenti.
• 4:58
  Vecchi client continuano a funzionare mentre rilasci la nuova versione.
• 5:01
  Puoi modificare il back-end senza interrompere i tuoi client.
• 5:04
  È un vantaggio enorme quando gestisci un'applicazione live con utenti reali.
• 5:07
  Pensa a una piattaforma di e-commerce.
• 5:08
  Hai servizi separati per catalogo, carrello, checkout e account utente.
• 5:12
  Senza un Gateway, un'app mobile deve conoscere quattro URL differenti.
• 5:17
  Con un Gateway ne conosce uno solo.
• 5:19
  Il Gateway legge il percorso, catalogo, carrello, checkout, account e invia ogni richiesta al servizio corretto.
• 5:25
  Il semplice routing è la parte facile.
• 5:26
  Il compito successivo è dove diventa davvero utile.
• 5:29
  Parte 2 è la sicurezza all'ingresso.
• 5:31
  Ogni chiamata API deve essere controllata.
• 5:33
  Chi sta effettuando queste richieste?
• 5:34
  Hai permessi corretti.
• 5:36
  Senza un Gateway, ogni servizio deve gestire la propria autenticazione.
• 5:39
  Ciò significa lavoro duplicato ed è facile sbagliare.
• 5:42
  Un servizio potrebbe controllare i token correttamente.
• 5:44
  Un altro è saltare un passaggio.
• 5:45
  Un altro è ancora usare un metodo del tutto diverso.
• 5:48
  Finisci per avere una sicurezza incoerente in tutta l'applicazione.
• 5:51
  Il Gateway cambia tutto questo.
• 5:52
  Gestisce autenticazione e autorizzazione in un unico punto centrale.
• 5:55
  Un punto per controllare, uno per applicare, uno per aggiornare quando le policy cambiano.
• 5:59
  È una delle migliori pratiche di sicurezza.
• 6:00
  Valida a chiavi API, JWT, token out o certificati su ogni singola richiesta.
• 6:07
  Ogni richiesta passa attraverso controllo.
• 6:09
  Nessuna eccezione.
• 6:10
  Il Gateway può anche applicare delle regole.
• 6:12
  Puoi dire che questa chiave API può chiamare solo l'inpoint di lettura.
• 6:15
  Oppure questo client può accedere solo al servizio catalogo, non a quello di pagamento.
• 6:19
  Definisci i permessi granulari a livello di Gateway.
• 6:21
  Si applicano automaticamente.
• 6:23
  I servizi di back-end non devono mai preoccuparsi dell'autorizzazione.
• 6:26
  Si limitano a elaborare la richiesta e a restituire i dati.
• 6:28
  Ecco il punto.
• 6:29
  Il Gateway è un punto unico per revocare l'accesso quando qualcosa non va.
• 6:33
  Se la chiave API di un client viene compromessa, la revochi sul Gateway.
• 6:36
  Una sola modifica, defatto.
• 6:37
  Non devi aggiornare ogni servizio o riavviare nulla.
• 6:40
  La richiesta successiva con quella chiave viene rifiutata immediatamente.
• 6:43
  Facciamo un esempio reale.
• 6:44
  Una banca ha un servizio di pagamento e un servizio di fatturazione.
• 6:46
  Solo il servizio di pagamento necessita una scrittura al sistema di fatturazione.
• 6:49
  Il Gateway applica questa regola.
• 6:50
  Se un client tenta di scrivere nel sistema di fatturazione tramite l'endpoint sbagliato,
• 6:54
  il Gateway lo blocca.
• 6:55
  Il servizio di fatturazione non vede nemmeno la richiesta.
• 6:57
  Il Gateway può supportare anche il TLS reciproco e l'integrazione WAF per una protezione più profonda.
• 7:02
  Ma in sostanza è la tua prima linea di difesa.
• 7:04
  La sicurezza è una cosa, ma che succede quando arrivano troppe richieste contemporaneamente?
• 7:08
  Terza parte, gestione del traffico.
• 7:10
  Cosa succede quando 10.000 utenti accedono la tua app nello stesso momento?
• 7:14
  Magari c'è una vendita flash, un lancio di prodotto virale,
• 7:16
  forse è solo un martedì normale e tutti hanno deciso di accedere insieme.
• 7:20
  Senza un Gateway, i servizi di back-end vengono colpiti direttamente e potrebbero andare in crash.
• 7:24
  Non lentamente, tutti insieme.
• 7:26
  È qui che entra in gioco la gestione del traffico.
• 7:28
  Il Gateway può limitare il numero di richieste che ogni client può effettuare.
• 7:32
  Il rate limiting e throttling sono funzionalità standard.
• 7:34
  Imposti le regole sul Gateway ed è lui da applicarle.
• 7:37
  I tuoi servizi di back-end non risentrano mai del piccolo.
• 7:39
  Puoi impostare quote per utente, per chiave API o per indirizzo IP.
• 7:43
  Mettiamo che tu abbia un piano gratuito.
• 7:44
  Gli utenti gratuiti hanno 100 richieste all'ora, gli utenti premium ne hanno 10.000.
• 7:48
  Il Gateway traccia ogni richiesta e applica tali limiti all'ingresso.
• 7:51
  Se un utente gratuito raggiunge il limite, il Gateway invia un cortese messaggio di riprovare più tardi.
• 7:57
  Servizi di back-end non vengono nemmeno a conoscenza delle richieste.
• 7:59
  Continuano a funzionare servendo i clienti paganti.
• 8:02
  Il Gateway gestisce anche il bilanciamento del calcio.
• 8:04
  Se hai tue istanze dello stesso servizio in esecuzione, il Gateway distribuisce le richieste tra di esse.
• 8:08
  Un'istanza riceve una richiesta, la seconda e la successiva, la terza, quella dopo, è tutto automatico.
• 8:14
  E se un'istanza si blocca, il Gateway installa il traffico su un'altra.
• 8:16
  I clienti non se ne accorgono mai.
• 8:17
  Ricevono semplicemente l'orologo.
• 8:19
  Bilanciamento del carico con controllo integrità mantiene tutto fluido.
• 8:22
  Il Gateway esegue il ping di ogni istanza per assicurarsi che si attiva.
• 8:25
  In caso contrario smette di inviare traffico verso quella destinazione.
• 8:27
  Questo è particolarmente importante per le api ad alto traffico.
• 8:29
  Senza il Gateway, un picco di traffico colpisce direttamente i tuoi servizi.
• 8:33
  Con il Gateway, il picco colpisce prima il Gateway, che lo assorbe, lo distribuisce e protegge i tuoi servizi dal sovraccarico.
• 8:40
  D'accordo, ma cosa succede se i dati non sembrano corretti a loro arrivo?
• 8:44
  Parte 4. Trasformazione dei dati.
• 8:47
  A volte i dati inviati dal client non corrispondono a ciò che si aspetta al backend.
• 8:50
  Magari il client invia JSON, ma il tuo backend comprende solo XML.
• 8:54
  Magari i nomi dei campi non coincidono.
• 8:55
  Il client usa First Name e il tuo backend si aspetta nome.
• 8:58
  Queste discrepanze causano error.
• 9:00
  Nel vecchio metodo, avresti dovuto correggere ogni singolo client o riscrivere il backend.
• 9:05
  Il Gateway può trasformare i dati prima che raggiungano il backend.
• 9:08
  Consideralo come un traduttore.
• 9:09
  Si posiziona nel mezzo e può modificare i dati in entrata, in uscita o in trame.
• 9:13
  Questa è la trasformazione di richieste e risposte in sintesi.
• 9:15
  Lascia che ti faccia un esempio reale.
• 9:17
  Immagina di avere un sistema legacy che si aspetta XML.
• 9:19
  E in funzione da 15 anni funziona bene.
• 9:22
  Ma ora stai creando una nuova app mobile.
• 9:23
  L'app mobile parlano JSON.
• 9:24
  Senza un Gateway dovresti riscrivere il sistema legacy o costringere l'app mobile a inviare XML.
• 9:29
  Con un Gateway non devi fare nessuno delle due.
• 9:31
  L'app mobile invia JSON.
• 9:33
  Il Gateway lo converte in XML.
• 9:34
  Il sistema riceve ciò che si aspetta.
• 9:36
  L'app mobile riceve una risposta già in JSON.
• 9:39
  Nessuno ha dovuto riscrivere nulla.
• 9:40
  Questa è la bellezza della cosa.
• 9:41
  Il Gateway può anche aggiungere o rimuovere intestazioni, cambiare URL o mascherare i dati sensibili.
• 9:46
  Immagina che una risposta includa un numero di carta di credito.
• 9:48
  Non vuoi che torni al client.
• 9:50
  Il Gateway può rimuoverlo prima che la risposta parta o sostituirlo con una versione mascherata.
• 9:54
  Il back-end non deve mai cambiare.
• 9:56
  Senza quel Gateway.
• 9:57
  Questo è particolarmente utile quando stai modernizzando vecchi sistemi.
• 9:59
  Non devi riscrivere il back-end.
• 10:01
  Non devi costringere client a cambiare.
• 10:03
  Devi solo modificare il Gateway.
• 10:04
  È come un traduttore a una conferenza internazionale.
• 10:06
  Ognuno parla la propria lingua ma il traduttore assicura che tutti si comprendano.
• 10:10
  Il Gateway è quel traduttore per il tuo software.
• 10:12
  Quindi routing, sicurezza, trottini, trasformazione, motocamia a fuoco.
• 10:15
  Ma non sono quattro cose separate.
• 10:17
  Lascia che i mosi si collegano.
• 10:19
  Ne si collega tutto.
• 10:20
  Ecco il punto.
• 10:21
  Questi quattro compiti non sono separati.
• 10:22
  Lavorano insieme su ogni singola richiesta ogni volta che ne arriva una.
• 10:26
  Gateway verifica l'autenticazione.
• 10:28
  Convalida il limite di frequenza.
• 10:29
  Indirizza verso il servizio.
• 10:31
  Trasforma i dati se necessario.
• 10:33
  Riceve la risposta.
• 10:34
  Trasforma anche quella se serve.
• 10:36
  Poi rimanda tutto al client.
• 10:37
  Non solo al pipeline.
• 10:38
  Ogni passaggio avviene automaticamente.
• 10:40
  In ordine.
• 10:41
  Senza che alcun servizio debba preoccuparsene.
• 10:42
  Il vero potere non risiede in una singola funzione.
• 10:44
  È l'integrazione.
• 10:46
  Puoi aggiungere una nuova policy di sicurezza senza toccare routing.
• 10:49
  Il servizio di back-end senza modificare il client.
• 10:51
  Puoi aggiornare i limiti di velocità senza ridistribuire nulla.
• 10:54
  Ogni pezzo è indipendente ma lavorano tutti nella stessa pipeline.
• 10:58
  E poiché tutto passa da un unico punto.
• 10:59
  Tiene una visibilità completa di ciò che accade.
• 11:02
  Log, metric, analisi.
• 11:03
  Tutto da un unico punto.
• 11:05
  Puoi vedere quante richieste sono arrivate.
• 11:06
  Quali hanno fallito.
• 11:07
  Quali erano lente.
• 11:08
  Quali client usano più risorse.
• 11:10
  Senza un gateway dovresti raccogliere quei dati da ogni singolo servizio.
• 11:13
  Con un gateway tool.
• 11:15
  Questa è la grande intuizione.
• 11:16
  Il gateway non è solo un router.
• 11:18
  È un centro di controllo per l'intera piattaforma API.
• 11:20
  Ogni richiesta, ogni risposta, ogni errore, tutto fluisce attraverso un unico punto.
• 11:24
  Hai un unico pannello di controllo per tutto ciò che accade.
• 11:26
  Quindi, come si usa davvero?
• 11:28
  Parliamo di cosa puoi fare concretamente fin da ora.
• 11:30
  Consigli e pratici.
• 11:31
  Siamo realisti.
• 11:32
  Se hai uno o due servizi, probabilmente non hai ancora bisogno di un API gateway.
• 11:35
  Puoi gestire il routing da solo, gestire l'autenticazione di un servizio.
• 11:38
  Non è elegante ma funziona.
• 11:40
  Ma nel momento in cui arrivi a tre servizi e osponi API a client esterni, la complessità aumenta rapidamente.
• 11:46
  Il gateway si ripaga velocemente.
• 11:47
  Quella è la tua migliore prima mossa.
• 11:48
  Centralizza l'autenticazione nel gateway.
• 11:50
  Fallo prima di ogni altra cosa.
• 11:52
  Scegli un servizio.
• 11:52
  Sposta il suo controllo di autenticazione sul gateway.
• 11:54
  Noterai subito che il codice del tuo servizio diventa più pulito.
• 11:57
  Basta la logica di convalida dei token sparsa ovunque.
• 12:00
  Niente più dubbi se l'hai implementata allo stesso modo in ogni servizio.
• 12:03
  Il gateway la gestisce una volta e ogni servizio ne trae beneficio.
• 12:06
  Prossimo passo, il rate limiti.
• 12:09
  Anche un limite semplice protegge il tuo backend dal sovraccare.
• 12:11
  Inizia con qualcosa di base, come 100 richieste al minuto per client.
• 12:14
  Questo impedisce a un client fuori controllo di mandare in tilt i tuoi servizi.
• 12:17
  Puoi parlare.