{"id":1048,"date":"2019-06-07T16:26:19","date_gmt":"2019-06-07T14:26:19","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1048"},"modified":"2021-03-17T12:38:58","modified_gmt":"2021-03-17T11:38:58","slug":"turning-monoliths-into-microservices-tips-and-tricks","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/turning-monoliths-into-microservices-tips-and-tricks\/","title":{"rendered":"Turning monoliths into microservices: tips and tricks"},"content":{"rendered":"
Nel primo articolo del nostro viaggio<\/a> in tre parti abbiamo iniziato parlando dei vantaggi di un’applicazione distribuita composta da microservizi rispetto ad una completamente monolitica. In questa seconda parte inizieremo ad avvicinarci a tecniche e suggerimenti per aiutarvi a superare il processo di migrazione in modo pi\u00f9 sicuro e consapevole.<\/span><\/p>\n Questo \u00e8 di gran lunga il passo pi\u00f9 importante, in quanto indica chiaramente se l<\/span>a conoscenza<\/b> della logica del proprio dominio \u00e8 chiara e completa. Infatti, un modo possibile per individuare quali parti della vostra applicazione possono essere convertite in microservizi, \u00e8 proprio quello di verificare se avete una comprensione completa del dominio di tali servizi, il che significa che sar\u00e0 pi\u00f9 facile per il vostro team di sviluppo <\/span>isolarne e migrarne<\/b> la logica.<\/span><\/p>\n Comprendere il dominio di una feature significa anche che, probabilmente, il suo accoppiamento con il resto dell’applicazione \u00e8 molto basso, idealmente nullo, facilitando cos\u00ec la sua separazione dall’applicazione principale.<\/span><\/p>\n Conoscere il proprio dominio significa definire con chiarezza quali servizi sono <\/span>verticali all’applicazione<\/b>, o in altre parole, quali servizi sono pi\u00f9 importanti e mirano alle esigenze specifiche di una determinata base utenti (definendo cos\u00ec l’obiettivo della propria applicazione) o sono particolarmente strategici per la propria azienda.<\/span><\/p>\n I servizi cosiddetti verticali sono spesso costituiti da codice complesso e possono essere molto grandi, ma, come detto in precedenza, non definiamo i microservizi in base alla quantit\u00e0 di codice contenuto, ma mediante la <\/span>definizione degli scopi<\/b> e <\/span>dei confini di un particolare contesto logico<\/b>.<\/span><\/p>\n Arrivati a questo punto \u00e8 importante definire chiaramente il nostro <\/span>target tecnologico<\/b>, nel senso che vogliamo avere ben chiaro che tipo di <\/span>piattaforma<\/b> o <\/span>framework<\/b> vogliamo utilizzare per lo sviluppo e per le procedure di CD\/CI (es. Serverless Framework e AWS Lambda come ambiente di sviluppo) e che tipo di linguaggio di programmazione \u00e8 pi\u00f9 adatto per migrare quella precisa parte della vostra logica di business.\u00a0<\/span><\/p>\n Avere chiaro il target \u00e8 cruciale in quanto aiuta a pensare alla <\/span>fattibilit\u00e0 di una particolare migrazione<\/b>. Dobbiamo anche capire che, anche se la migrazione verso i microservizi \u00e8, in generale, una pratica consigliata, non significa che per la vostra particolare applicazione, o parte di essa, sia una buona scelta, ma analizzeremo nel dettaglio questo aspetto pi\u00f9 avanti.<\/span><\/p>\n In generale durante il brainstorming coinvolto in questa fase \u00e8 necessario verificare i costi in termini di <\/span>migrazione<\/b> del<\/b> codice<\/b> e delle <\/span>infrastrutture<\/b> e il<\/span> valore strategico <\/b>rispetto allo<\/span> sviluppo di nuove funzionalit\u00e0<\/b>.<\/span><\/p>\n Finora abbiamo parlato di preparativi, iniziamo ora a spiegare come scomporre efficacemente la nostra infrastruttura monolitica e quali caratteristiche deve avere un microservizio per essere considerato tale una volta estratto con successo.<\/span><\/p>\n Quando pensiamo di passare da un approccio monolitico ad un ecosistema di microservizi possiamo intraprendere due possibili strade: a) riscrivere il codice da zero utilizzando il nuovo paradigma o b) migrare da quello vecchio.<\/span><\/p>\n Iniziare a riscrivere l’intera applicazione da zero in un’unica passata non \u00e8 generalmente una buona scelta perch\u00e9:<\/span><\/p>\n Quindi l’opzione migliore \u00e8, come abbiamo discusso fino a questo punto, estrarre e convertire l’applicazione <\/span>passo dopo passo<\/b>.\u00a0<\/span><\/p>\n Questo approccio si chiama <\/span>Strangler Pattern<\/b>, un modo per <\/span>trasformare in modo incrementale la vostra applicazione monolitica in microservizi sostituendo le funzionalit\u00e0 una alla volta<\/b>. Una volta codificata la nuova funzionalit\u00e0, il vecchio componente viene \u201c<\/span>strangolato<\/b>\u201d, sostituito e infine <\/span>disattivato<\/b>.<\/span><\/p>\n Questo approccio \u00e8 molto efficace per una serie di ragioni:<\/span><\/p>\n Per implementare lo Strangler Pattern, \u00e8 possibile seguire tre passi: <\/span>Trasformare<\/b>, <\/span>Coesistere<\/b> (la coesistenza \u00e8 necessaria per testare la nuova funzionalit\u00e0 con parte della base utenti), ed <\/span>Eliminare<\/b>.<\/span><\/p>\n Vale la pena spendere due parole in pi\u00f9 sulla fase di Coesistenza in quanto richiede uno sforzo ed una analisi accurata da parte dei vostri team di sviluppo, necessari a mantenere entrambe le code base e i servizi di supporto all\u2019utente fino a quando il componente facente parte del monolite non viene decommissionato. In questa fase \u00e8 bene pianificare le operazioni in anticipo per evitare brutte sorprese.<\/span><\/p>\n Per iniziare ad estrarre gli elementi fondamentali della vostra logica di business, soprattutto se siete nuovi a questo modello di sviluppo, scegliete quelli che hanno:\u00a0<\/span><\/p>\n Inoltre:<\/span><\/p>\n Infine, verificare se esistono parti di codice che possono essere facilmente riutilizzabili in altri progetti, quindi per loro stessa natura <\/span>atomiche<\/b> e<\/span> riutilizzabili: <\/b>ottimi candidati per la promozione a microservizi<\/span>.<\/b><\/p>\n Ci sono strumenti che possono aiutare nella processo di suddivisione, come quelli per la <\/span>Social code analysis<\/b> che arricchisce la nostra comprensione della qualit\u00e0 del codice sovrapponendo il comportamento di uno sviluppatore con l’<\/span>analisi strutturale del codice<\/b>.\u00a0<\/span><\/p>\n Utilizzano informazioni derivanti dai <\/span>Sistemi di Controllo di Versione<\/b>. Uno di questi \u00e8 <\/span>CodeScene<\/b><\/a>.\u00a0<\/b><\/p>\n Per capire se si sta creando un vero e proprio microservizio bisogna verificare se esso aderisce a specifiche <\/span>propriet\u00e0 di isolamento<\/b> sia a <\/span>livello infrastrutturale <\/b>che <\/span>logico<\/b>.<\/span><\/p>\n Un microservizio deve essere <\/span>indipendente<\/b> e <\/span>atomico <\/b>(pu\u00f2 esistere e fornire un servizio in autonomia, possibilmente senza sapere nulla dell’intera applicazione) a livello di <\/span>sviluppo<\/b>, <\/span>test<\/b>, <\/span>distribuzione<\/b>, <\/span>monitoraggio<\/b>, <\/span>debug<\/b> e <\/span>recovery<\/b>. Questo assicura che possiamo svilupparlo, gestirlo e distribuirlo in modo sicuro <\/span>senza interrompere<\/b> il <\/span>ciclo di vita<\/b> dell’applicazione principale.<\/span><\/p>\n Un microservizio deve essere indipendente anche a <\/span>livello di API<\/b>, <\/span>Business Logic<\/b> e <\/span>Base<\/b> Dati<\/b>, per garantire l’<\/span>isolamento del codice <\/b>(l’accesso alle funzionalit\u00e0 del servizio avviene solo tramite API).<\/span><\/p>\n Ci\u00f2 significa che \u00e8 buona norma anche preparare e definire un database indipendente per ogni microservizio invece di un\u2019unica base dati condivisa.\u00a0<\/span><\/p>\n Anche se questa operazione comporta la necessit\u00e0 di definire dei <\/span>descrittori specifici<\/b>,<\/span> necessari per rendere i diversi microservizi parlanti tra loro in termini di dati, si evita un possibile <\/span>single point of failure derivante <\/b>dall\u2019avere un unico database (un malfunzionamento di quest\u2019ultimo pu\u00f2 compromettere l’intero set di microservizi invece di uno solo).<\/span><\/p>\n Come regola d’oro inoltre, verificare sempre che <\/span>nessun microservizio dipenda dal monolite<\/b>.<\/span><\/p>\n In questa seconda parte del nostro viaggio in tre parti su come scomporre un’applicazione monolitica, abbiamo iniziato ad analizzare in profondit\u00e0 alcune tecniche e idee che aiutano il team di sviluppo e di business a decidere quando e come sia possibile dividere il codice legacy in microservizi atomici e indipendenti, come si possa\u00a0 affrontare il ciclo di vita della migrazione e in generale quali propriet\u00e0 deve avere un microservizio per essere considerato tale.\u00a0<\/span><\/p>\n Nel prossimo articolo concluderemo il nostro viaggio, descrivendo come iniziare a codificare efficacemente i vostri microservizi, come affrontare codice complesso ad alto valore intellettuale e anche quando passare ad un ecosistema a microservizi possa non essere una buona scelta. <\/span><\/p>\n Rimanete con noi!<\/span><\/p>\n << Leggi la prima parte<\/a> | <\/span>Leggi la terza parte >><\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Nel primo articolo del nostro viaggio in tre parti abbiamo iniziato parlando dei vantaggi di un’applicazione distribuita composta da microservizi […]<\/p>\n","protected":false},"author":6,"featured_media":1035,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[309,305],"class_list":["post-1048","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting","tag-microservices","tag-software-as-a-service-saas"],"yoast_head":"\nDEFINIRE CHIARAMENTE IL DOMINIO DELLA VOSTRA LOGICA DI BUSINESS<\/span><\/h2>\n
DEFINIRE IL VOSTRO OBIETTIVO TECNOLOGICO<\/span><\/h2>\n
DA DOVE COMINCIARE A SCOMPORRE UN MONOLITE: STRANGLER PATTERN<\/span><\/h2>\n
\n
<\/p>\n
\n
<\/p>\n
\n
\n
COSA RENDE UN MICROSERVICE TALE?<\/span><\/h2>\n
<\/p>\n