Produzione

Nella fase di produzione i servizi creati e testati vengono messi a dispozione degli utenti finali.

Gli utenti finali possono accedere ai servizi implementati.

89

Capitolo 9

Conclusioni

All’interno della tesi vi è un focus sul tema dei microservizi: inizialmente ho analizzato il tema dal punto di vista teorico, successivamente mi è stato possibile apprezzarne l’applicazione dal punto di vista pratico nel corso del progetto di stage svolto.

Mettendo a confronto quanto studiato dalla teoria e quanto osservato durante lo stage, ho trovato un forte riscontro sul tema della flessibilità dei microservizi, sotto vari aspetti: dimensione, tecnologie utilizzate, aggiornamenti nel corso del tempo in fase di sviluppo.

Relativamente al tema delle dimensioni, problema aperto nell’ambito dei microservizi, ho potuto notare una forte differenza tra i molteplici microservizi sviluppati all’interno del progetto: non ci si è posto un limite in termini quantitativi, bensì ogni microservizio racchiude gli endpoint associati ad una determinata

funzionalità dell’applicativo, ed è utilizzato nello sviluppo di uno o più widget;

soprattutto relativamente ai microservizi di dominio subentra la possibilità che siano riutilizzati da più BFF al fine di ridurre la quantità di codice duplicato e mantenere un buon livello di disaccoppiamento, invece, in generale i BFF sono associati ad una singola widget.

Ho potuto, inoltre, osservare la dinamicità dal punto di vista delle tecnologie

utilizzate, soprattutto nella parte finale del progetto, che sto seguendo tutt’ora, sono state proposte nuove tecnologie e modifiche ai microservizi, ad esempio è stato introdotto l’utilizzo di springbatch per permettere l’aggiornamento più frequente dei dati interni ad alcune widget. Ho trovato, anche in questo caso, un riscontro con la teoria studiata ed ho potuto apprezzare come nell’effettivo la modifica di un

microservizio non abbia avuto un impatto sugli altri, il che ha reso possibile la

90

sperimentazione di nuove tecnologie che sono state poi estese anche ad altri microservizi successivamente.

Nel progetto di stage, l’architettura proposta prevedeva che per ogni widget

sviluppato, i componenti di frontend, backend e dati fossero trattati su progetti GIT distinti; questa suddivisione rende ogni componente quasi indipendente dagli altri nella fase di sviluppo, nonostante essi sono comunque correlati dal punto di vista della funzionalità. Si creano, quindi, dei collegamenti “verticali”: la chiamata parte dal frontend verso il microservizio di backend for frontend, che a sua volta chiama uno o più microservizi di dominio; questo meccanismo richiede un allineamento delle interfaccie.

Anche all’interno del meccanismo appena descritto, si ripropone la questione delle dimensioni di un microservizio: ogni widget viene frammentato rendendo ogni microservizio che lo compone quasi autonomo; in questo modo è stato possibile parallelizzare bene il lavoro di sviluppo all’interno del team, tuttavia ciò è stato accompagnato da una forte comunicazione che ha permesso di mantenere i

componenti allineati sui vari team di sviluppo (frontend, backend e dati); soprattutto per quanto riguarda il rilascio dei microservizi negli ambienti di test, infatti, ogni microservizio viene rilasciato in maniera autonoma ed installato sull’ambiente di destinazione, quindi, se i tre componenti non sono correttamente allineati è possibile che la funzionalità non risponda correttamente alle richieste o che vengano ritornati errori dovuti alla “rottura” del meccanismo.

A questo punto possiamo chiederci se questo meccanismo di sviluppo e rilascio dei componenti potesse essere implementato diversamente e se, ad esempio, si potesse trarre un maggiore beneficio accorpando in un unico rilascio i componenti inerenti ad una stessa widget e, quindi, ottenendo un unico pacchetto: a mio avviso, ho trovato che il metodo scelto risulti molto utile nei casi in cui sia necessario apportare piccole modifiche solo ad uno dei tre componenti: ad esempio, una correzione sulla logica di business nel microservizio di dominio che non prevede una modifica dell’interfaccia, o una modifica relativa al microservizio di backend for frontend e, quindi,

all’orchestrazione dei microservizi di dominio chiamati, che però non richiede una modifica su questi ultimi, oppure nel caso in cui sia necessaria una modifica sul frontend dovuta ad un dato utilizzato nel modo scorretto, piuttosto che all’interfaccia utente che non richieda cambiamenti sui dati utilizzati; in tutti questi casi, il metodo scelto ha permesso di apportare modifiche al singolo microservizio in maniera

efficiente senza impattare sugli altri componenti, rendendo il rilascio più dinamico, in quanto riferito ad un numero minore di microservizi e, quindi, a pacchetti di

dimensioni minori, inoltre ha permesso una buona parallelizzazione del lavoro tra i vari team.

Ho trovato molto interessante analizzare il progetto dal punto di vista architetturale e poter trovare riscontro nella pratica di quanto analizzato nella fase teorica del mio studio.

Attualmente, sono ancora impegnata in questo progetto, per il quale sono previsti sviluppi futuri in termini di aggiunta di nuove funzionalità ed implementazione di

91

nuove widget, nonché di un aggiornamento delle widget già esistenti dal punto di vista di miglioramenti dell’efficienza, ad esempio sperimentando l’utilizzo di nuove tecnologie, o correzioni dovute alla fase di testing dell’applicativo richieste dal cliente nella fase di UAT.

92

Bibliografia e Fonti

[1] Building Microservices – designing fine-grained systems – Sam Newman

[2] Monolith vs SOA vs MicroServices and when to use what - Fredrik Christenson - https://www.youtube.com/watch?v=FT5ZABfdzE8

[3] Best Architecture for an MVP: Monolith, SOA, Microservices, or Serverless? - RubyGarage - Author: Anastasia D., Copywriter -

https://rubygarage.org/blog/monolith-soa-microservices-serverless

[4] System Innovation Academy, System Design, Service Oriented Architecture - https://www.systemsinnovation.io/systems-design/,

https://www.youtube.com/watch?v=_dFJOSR-aFs

[5] Service-Oriented Architecture -SOA - Software/Web Application Architecture – The techCave - https://www.youtube.com/watch?v=jNiEMmoTDoE

[6] Documentazione Spring - https://spring.io/

[7] Sito web di IntelliJ - url: https://www.jetbrains.com/idea/

[8] Sito Web di Postman - https://www.getpostman.com/

[9] Geek and Job - https://www.geekandjob.com/