{"id":3989,"date":"2021-12-24T13:59:00","date_gmt":"2021-12-24T12:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3989"},"modified":"2021-12-22T16:14:37","modified_gmt":"2021-12-22T15:14:37","slug":"migrazione-graduale-e-refactoring-di-applicazioni-verso-lapproccio-serverless-attraverso-lutilizzo-di-amazon-api-gateway","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/migrazione-graduale-e-refactoring-di-applicazioni-verso-lapproccio-serverless-attraverso-lutilizzo-di-amazon-api-gateway\/","title":{"rendered":"Migrazione graduale e refactoring di applicazioni verso l’approccio serverless attraverso l’utilizzo di Amazon API Gateway"},"content":{"rendered":"\n
Oggigiorno sempre pi\u00f9 applicazioni, servizi e progetti vengono sviluppati seguendo l’approccio serverless.<\/p>\n\n\n\n
Molteplici applicazioni potrebbero sfruttare il suddetto approccio per migliorare le proprie performance e al contempo ottenere alta disponibilit\u00e0 ed elasticit\u00e0. Tuttavia, \u00e8 necessario che queste vengano migrate e rifattorizzate nel dettaglio.<\/p>\n\n\n\n
Migrare un’applicazione verso il paradigma serverless implica spesso una parziale riscrittura della codebase al fine di implementare un modello di esecuzione che sia adatto al FaaS selezionato. Inoltre, l’architettura complessiva dovrebbe accogliere l’approccio a microservizi e un flusso basato sugli eventi favorendo, dove possibile, il processamento asincrono e il disaccoppiamento attraverso servizi di messaggistica.<\/p>\n\n\n\n
Lo sforzo e le tempistiche richieste per ottenere le sopra citate specifiche, specialmente nel caso di applicazioni complesse, possono facilmente raggiungere elevati ordini di grandezza. A volte, inoltre, \u00e8 preferibile non rifattorizzare completamente un’applicazione prima del suo rilascio.<\/p>\n\n\n\n
Il presente articolo vi illustrer\u00e0 una tecnica che, attraverso API Gateway, si occuper\u00e0 del routing e dell’adattamento delle richieste dello user, permettendo la graduale migrazione e la rifattorizzazione di applicazione complesse senza compromettere la loro disponibilit\u00e0.<\/p>\n\n\n\n
Perch\u00e9 API Gateway?<\/h2>\n\n\n\n
Amazon API Gateway \u00e8 un servizio managed che rappresenta la front door della propria applicazione. Il servizio funziona come un gateway managed per il backend, pu\u00f2 essere anche direttamente integrato con altri servizi AWS supportati per indirizzare il carico verso il processore adeguato o un sistema di messaggistica.<\/p>\n\n\n\n
API Gateway si occupa di centinaia di migliaia di chiamate API concorrenti, gestisce il traffico, il CORS, l’autorizzazione, il controllo degli accessi, il throttling, il monitoraggio e il versionamento delle API.<\/p>\n\n\n\n
La tecnica utilizzata in questo articolo sfrutta le potenzialit\u00e0 di API Gateway per farlo agire da proxy per l’intero applicativo, per accettare richieste, apportare le modifiche necessarie al formato del payload ed eseguire il routing tra l’applicazione legacy e gli endpoint rifattorizzati.<\/p>\n\n\n\n
Replatforming e rifattorizzazione nella teoria<\/h2>\n\n\n\n
Il metodo proposto in questo articolo permette di mappare tutti gli endpoint dell’applicazione sottoposti a migrazione verso un unico API Gateway, il quale agir\u00e0 da punto di accesso centralizzato dell’applicazione.<\/p>\n\n\n\n
Una volta che l’intero flusso di richieste si dirige verso un singolo oggetto infrastrutturale, sar\u00e0 possibile mantenere due versioni distinte dell’applicazione: il modello legacy e la nuova versione, che possiamo implementare incrementalmente.<\/p>\n\n\n\n