{"id":1071,"date":"2019-11-29T14:50:42","date_gmt":"2019-11-29T13:50:42","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1071"},"modified":"2024-05-21T17:19:02","modified_gmt":"2024-05-21T15:19:02","slug":"come-sfruttare-al-massimo-i-microservizi-2","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-sfruttare-al-massimo-i-microservizi-2\/","title":{"rendered":"Come sfruttare al massimo i microservizi"},"content":{"rendered":"\n
In quest\u2019ultimo articolo della nostra analisi in tre parti (trovate qui la prima parte<\/a> e qui la seconda parte<\/a>) su come scomporre un’applicazione monolitica, sfrutteremo alcune intuizioni su come un microservizio pu\u00f2 essere creato a partire da un’applicazione esistente, cosa possiamo fare per risolvere problemi legati al codice legacy ad alta tossicit\u00e0 e in generale quali regole possono essere applicate per decidere quando migrare a microservizi. Cominciamo!<\/span><\/p>\n\n\n\n Quando vogliamo creare un microservizio abbiamo davanti due scelte: <\/span><\/p>\n\n\n\n In un primo momento trasferire direttamente il codice pu\u00f2 sembrare una soluzione logica, soprattutto perch\u00e9 il team di sviluppo ha tendenzialmente un <\/span>atteggiamento cognitivo favorevole<\/b> verso il proprio codice MA pu\u00f2 nascondere alcuni aspetti critici dai <\/span>costi elevati<\/b> e dal <\/span>basso valore intellettuale<\/b>:<\/span><\/p>\n\n\n\n Quindi, per riassumere, verificate sempre se il codice che volete riutilizzare ha un <\/span>alto valore di complessit\u00e0 intellettuale <\/b>e <\/span>bassa tossicit\u00e0 <\/b>in termini di accoppiamento con altri servizi e debito tecnico<\/span>: questo \u00e8 un buon candidato<\/b> per l’estrazione e il riutilizzo. Un esempio pu\u00f2 essere un complesso <\/span>sistema di raccomandazioni<\/b> per un cliente di un e-commerce con molte interazioni, personalizzazioni, algoritmi di apprendimento automatico e cos\u00ec via.<\/span><\/p>\n\n\n\n Scrivere codice da zero per un microservizio \u00e8 un ottimo approccio nel senso che costringe il team di Sviluppo e il team di Business a rivedere la logica di base della funzionalit\u00e0 che si vuole riscrivere permettendo:<\/span><\/p>\n\n\n\n Questo approccio pu\u00f2 essere vantaggioso anche nel senso che il microservizio sar\u00e0 probabilmente <\/span>sviluppato pi\u00f9 rapidamente<\/b>. Un esempio pu\u00f2 essere rappresentato dalle <\/span>operazioni CRUD<\/b> perch\u00e9 non contengono propriet\u00e0 intellettuali e possono dipendere tranquillamente da nuove tecnologie e framework.<\/span><\/p>\n\n\n\n Dopo aver riscritto la maggior parte della vostra applicazione mediante microservizi, dovrete affrontare il resto del codice legacy per il quale la conoscenza del dominio \u00e8 incerta. In questi casi, trasferire il codice e anche <\/span>la base dati<\/b> pu\u00f2 essere molto difficile, anche se si consiglia di affrontare il pi\u00f9 velocemente possibile questa parte della vostra infrastruttura, perch\u00e9 il disaccoppiamento dello strato di base dati \u00e8 di gran lunga la parte pi\u00f9 importante del vostro lavoro di migrazione verso un ecosistema a microservizi. <\/span><\/p>\n\n\n\n Possiamo tranquillamente dire che se i dati sono in qualche modo accoppiati ad altri servizi non si \u00e8 sviluppato un vero e proprio microservizio.<\/span><\/p>\n\n\n\n Una tecnica che pu\u00f2 aiutarci in questo processo si chiama <\/span>Reification, <\/b>che \u00e8 un processo per ridefinire i confini del contesto attraverso la decomposizione di parti incerte del dominio logico decostruendo quindi il codice legacy in strutture ben separate e pi\u00f9 semplici che derivano anche da modelli di dati pi\u00f9 definiti.<\/span><\/p>\n\n\n\n \u00c8 inoltre possibile utilizzare strumenti di <\/span>analisi del codice strutturale e di dipendenza come <\/b>Structure101<\/b><\/a> per identificare le criticit\u00e0 di accoppiamento e fattori di vincolo nel codice del monolite.<\/span><\/p>\n\n\n\n AWS pu\u00f2 davvero aiutarci fornendoci gli strumenti per una facile transizione verso un approccio a microservizi, almeno dal punto di vista infrastrutturale.<\/span><\/p>\n\n\n\n A LIVELLO DI BUILDING, TESTING E DEPLOYING:<\/span><\/p>\n\n\n\n CodeCommit, CodeBuild e CodeDeploy.<\/span><\/p>\n\n\n\n MONITORING E DEBUGGING:<\/span><\/p>\n\n\n\n CloudWatch, ElasticSearch with Kibana integration, X-Ray.<\/span><\/p>\n\n\n\n DEPLOY E RECOVERY:<\/span><\/p>\n\n\n\n CloudFormation.<\/span><\/p>\n\n\n\n LOGIC:<\/span><\/p>\n\n\n\n AWS Lambda Functions e Lambda Layers, ECS e AWS Step Functions che coordinano i workers.<\/span><\/p>\n\n\n\n Abbiamo parlato molto di quanto siano efficaci i microservizi e di quanti benefici si avrebbero implementando questo paradigma, ma ci sono alcune situazioni in cui si pu\u00f2 riconsiderare l’idea di utilizzare questo approccio.<\/span><\/p>\n\n\n\n Ad esempio, se avete un piccolo progetto che probabilmente non si evolver\u00e0 in futuro, lo sforzo di disaccoppiamento potrebbe essere troppo grande, in quanto fare microservizi non \u00e8, come abbiamo visto, un compito semplice.<\/span><\/p>\n\n\n\n Se l’applicazione svolge una <\/span>funzione mission-critical<\/b>, come il <\/span>mantenimento di un database legacy insostituibile<\/b>, \u00e8 probabile che non sarete in grado di sostituirlo completamente in pochi anni, in altre parole il vostro team strategico non pu\u00f2 permettersi <\/span>una strategia a lungo termine <\/b>finalizzata alla ricostruzione della base dati.<\/span><\/p>\n\n\n\n Alcune applicazioni per <\/span>loro natura <\/b>richiedono una <\/span>stretta integrazione<\/b> tra i <\/span>singoli componenti e servizi<\/b>. Questo \u00e8 spesso vero, ad esempio, per applicazioni che <\/span>elaborano rapidi flussi di dati in tempo reale<\/b>. Eventuali livelli aggiuntivi di comunicazione tra i servizi <\/span>possono rallentare l’elaborazione in tempo reale<\/b>.<\/span><\/p>\n\n\n\n Per riassumere quanto detto fino a questo punto, riprendiamo i punti chiave pi\u00f9 importanti della nostra discussione:<\/span><\/p>\n\n\n\n Con questo riassunto concludiamo il nostro lungo viaggio su come sia possibile scomporre una grande applicazione monolitica in diversi microservizi al fine di mantenerla meglio, svilupparla, implementarla ed eventualmente recuperarla molto velocemente, concentrandosi cos\u00ec molto di pi\u00f9, sul suo valore aziendale. <\/span><\/p>\n\n\n\n Ci auguriamo che siate soddisfatti. Contattateci<\/a> per feedback, domande o spunti. Saremo felici di fare due chiacchiera insieme a voi \ud83d\ude09<\/span><\/p>\n\n\n\n << Leggi la seconda parte<\/a> | << Leggi la prima parte<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" In quest\u2019ultimo articolo della nostra analisi in tre parti (trovate qui la prima parte e qui la seconda parte) su […]<\/p>\n","protected":false},"author":6,"featured_media":1040,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[309,305],"class_list":["post-1071","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting","tag-microservices","tag-software-as-a-service-saas"],"yoast_head":"\nCOME SCRIVERE UN MICROSERVIZIO<\/span><\/h2>\n\n\n\n
\n
TRASFERIRE IL CODICE<\/span><\/h3>\n\n\n\n
\n
SCRIVERE IL CODICE DA ZERO<\/span><\/h3>\n\n\n\n
\n
COME APPROCCIARSI A CODICE CON ACCOPPIAMENTO FORTE ALL\u2019INTERNO DEL MONOLITE<\/span><\/h2>\n\n\n\n
COME AWS PU\u00f2 AIUTARCI CON I SUOI SERVIZI<\/span><\/h2>\n\n\n\n
PERCH\u00c9 EVITARE INVECE L’APPROCCIO A MICROSERVIZI<\/span><\/h2>\n\n\n\n
CONCLUSIONI<\/span><\/h2>\n\n\n\n
\n