{"id":1065,"date":"2019-11-15T14:33:27","date_gmt":"2019-11-15T13:33:27","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1065"},"modified":"2024-05-21T17:17:43","modified_gmt":"2024-05-21T15:17:43","slug":"turning-monoliths-into-microservices-tips-and-tricks-2","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/turning-monoliths-into-microservices-tips-and-tricks-2\/","title":{"rendered":"Turning monoliths into microservices: tips and tricks"},"content":{"rendered":"\n

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\n\n\n

DEFINIRE CHIARAMENTE IL DOMINIO DELLA VOSTRA LOGICA DI BUSINESS<\/span><\/h2>\n\n\n\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\n\n\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\n\n\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\n\n\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\n\n\n

DEFINIRE IL VOSTRO OBIETTIVO TECNOLOGICO<\/span><\/h2>\n\n\n\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. <\/span><\/p>\n\n\n\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\n\n\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\n\n\n

DA DOVE COMINCIARE A SCOMPORRE UN MONOLITE: STRANGLER PATTERN<\/span><\/h2>\n\n\n\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\n\n\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\n\n\n

Iniziare a riscrivere l’intera applicazione da zero in un’unica passata non \u00e8 generalmente una buona scelta perch\u00e9:<\/span><\/p>\n\n\n\n