lug 14, 2023 | Application Modernization Accelerare la Modernizzazione con CAST Imaging

La modernizzazione del software è la riscrittura, la ri-architettura o il porting di un software da un'architettura o un linguaggio di programmazione legacy ad un'architettura o un linguaggio di programmazione moderni.

Le applicazioni moderne si contraddistinguono rispetto alle soluzioni monolitiche per la struttura a microservizi: ogni applicazione è concepita e sviluppata come un insieme di unità funzionali indipendenti, che possono essere aggiunte, eliminate o modificate singolarmente, senza influenzare il comportamento complessivo del sistema. Nell’ambito delle architetture modulari, l’utilizzo delle API si rende necessario per favorire l’integrazione e l’interoperabilità dei diversi servizi, accelerando i tempi di sviluppo per l’aggiunta di ulteriori funzioni. Le applicazioni moderne utilizzano i vantaggi della containerizzazione: le applicazioni o i microservizi girano cioà all’interno di ambienti di runtime completi (container), assicurando il funzionamento indipendentemente dall’hardware sottostante e garantendo così la piena portabilità del software in ambienti ibridi e Multi-Cloud. Inoltre attraverso la metodologia Agile e le pratiche Devops si favorisce la collaborazione tra i team di sviluppo e le Operations, riducendo le tempistiche di deployment applicativo e automatizzando la gestione del ciclo di vita del software.

I vantaggi di una buona modernizzazione applicativa consistono quindi in una scalabilità migliore, in un incremento della resilienza, della qualità e della capacità di adattarsi rapidamente ai cambiamenti. Sostituire o ricostruire totalmente un’applicazione funzionante, che supporta una pluralità di processi, potrebbe rivelarsi pericoloso o comunque particolarmente oneroso. La modernizzazione invece dovrebbe procedere per gradi, permettendo di tenere sotto controllo eventuali errori e di affrontare i costi di intervento in modo dilazionato.

Il punto cruciale per concentrarsi sulla modernizzazione IT è analizzare i risultati che si otterranno prima di iniziare a modernizzare tutte le risorse. In caso contrario, si rischia di trovarsi di fronte a un'architettura mista che è completamente lontana dall'infrastruttura a cui si mira e di effettuare scelte sbagliate con l’introduzione involontaria di difetti di produzione.

Le attività essenziali di modernizzazione e refactoring di una applicazione possono essere accelerate utilizzando la Software Intelligence di CAST Imaging.

CAST Imaging garantisce il successo dei piani di modernizzazione del software fornendo indicazioni chiare su come effettuare il refactoring del software, ad esempio sostituendo la soluzione di accesso ai dati, modernizzando l'autenticazione degli utenti locali o creando nuove funzionalità di login.

Le attività tipiche che si svolgono nei progetti di modernizzazione e di refactoring rientrano in linea di massima in due categorie. L'analisi, che consiste nel comprendere lo stato attuale o nel pianificare lo stato futuro, e l'azione, che consiste nell'eseguire effettivamente il refactoring del software.

Le attività di analisi prevedono le seguenti fasi:

1. Revisione dell'architettura "as-is" - esplorazione dell'architettura "as-is" del sistema per comprendere il progetto complessivo così come è stato implementato nell'applicazione esistente. Questa revisione può portare a scoperte sia tecniche che funzionali del sistema e precede naturalmente la maggior parte degli altri interventi di refactoring.
2.  Pianificare l'architettura di arrivo "go-to" - La nuova architettura deve essere definita in modo abbastanza esplicito da consentire agli sviluppatori di seguirla e agli architetti di verificare la conformità dell'implementazione. Se i componenti sono destinati a essere sostituiti, è possibile tenere traccia di tutte le connessioni a tali componenti.
3. Identificare i candidati per la componentizzazione - Questo comporta l'esame dell'architettura software esistente per vedere dove un componente funzionale può essere trasformato in un microservizio.
4. Identificare l'obsolescenza o le vulnerabilità - questo comporta l'analisi dei framework e dei componenti di terze parti o open source per determinare dove sono i rischi più urgenti.

1. Disaccoppiare una comunità di componenti - questo può assumere molte forme e spesso è legato all'isolamento di un servizio, di un'API, di una transazione o di un intero livello.
2. Riscrivere, esporre o aggiungere un componente - Sia che si tratti di vulnerabilità, sia che si tratti di aggiornare le funzionalità e le regole di business, un approccio al refactoring basato sui componenti ha spesso senso.
3. Inserire un framework - Un nuovo framework può essere utile per le funzionalità comuni: meglio testato, più facile da mantenere e più pronto per il futuro che costruirne uno proprio.

Descriviamo le attività di analisi nel dettaglio con l’utilizzo di Cast Imaging.

Revisione dell'architettura "as-is"

Il più delle volte l'architettura del sistema esistente è sconosciuta. Anche se esiste una documentazione, o non è abbastanza dettagliata o è rimasta indietro rispetto alla realtà implementata. Quasi sempre l'architettura reale "as-is" nella pratica non corrisponde a quella che si potrebbe pensare.

CAST Imaging esegue il reverse engineering e rileva automaticamente i sistemi software costruiti con qualsiasi combinazione di tecnologie 3GL, 4GL, Mobile, Web, Middleware, Framework, Database, Mainframe.

Crea mappe architetturali accurate e zoomabili di tutte le strutture di database, i componenti di codice e le loro interdipendenze.

Con CAST Imaging diventa possibile rispondere velocemente alle seguenti domande:

• Qual è l'architettura dell'applicazione?
• Come influisce una nuova funzione sul resto del sistema?
• Qual è l'effetto a catena della modifica dei componenti esistenti?
• Quali sono le dipendenze da altre applicazioni?
• Quali oggetti compongono la transazione end-to-end?
• Qual è il percorso dall'interfaccia utente al database e viceversa?
• Quali sono le funzioni che accedono indirettamente a questa tabella?
• Cosa succede quando si aggiunge un nuovo campo a questa tabella?
• Qual è l'impatto del cambio del DB con uno nel Cloud?
• Cosa succede se sostituisco questo framework?
• Cosa succede se rendo questa applicazione headless?
• Cosa succede se disaccoppio questa parte dell'applicazione?
• Quali sono i buoni candidati per i microservizi?

 Pianificare l'architettura di arrivo "go-to"

La risposta a queste domande permette di individuare la nuova architettura a cui si vuole arrivare, il “go to”.

Ogni tipo di attività (interfaccia utente, logica di business, gestione dei dati) è gestita da un livello (layer) specifico. Questo aiuta a modularizzare e a isolare i componenti di un sistema, creando livelli di astrazione e rendendolo più flessibile alle modifiche. Questi livelli possono essere definiti nell’architettura “go to” e controllati periodicamente per verificare la conformità e i progressi.

Esaminando tutte le interconnessioni tra i componenti si può capire dove si possono trovare punti di interruzione validi per raggruppare i componenti. In genere, questo è il motivo comune che spinge a creare un nuovo microservizio all'interno di un sistema legacy. Di solito il sistema legacy è un unico blocco (COBOL, C, Java,… ), che ha dimostrato di funzionare bene nel tempo, implementando regole di business complesse e ben testate.

Identificare i candidati per la componentizzazione

Il processo consiste tipicamente nell'identificare un gruppo di componenti in un'area funzionale specifica, che possono essere "confinati" in un nuovo livello, API o microservizio. In seguito, è necessario valutare gli impatti di questo cambiamento e quindi stimare e implementare il progetto.

In genere il team di architetti sw inizia con un punto di ingresso funzionale ed esplora tutti i componenti che scendono lungo la catena di quella funzione. Quindi esamina tutte le aree correlate e capisce quali componenti devono essere rivisti per includerli nel nuovo microservizio o per interfacciarsi con esso dall'esterno. Una volta delimitato il microservizio, si intraprende un progetto di analisi dell'impatto per capire cos'altro dipende da quel componente.

Con CAST Imaging i componenti possono essere selezionati e modellati come se facessero tutti parte di un unico componente, come un'API o un microservizio. Questo esercizio di modellazione può essere semplicemente drag-and-drop, per cui in poche ore il team di architetti può modellare molti scenari alternativi e trovare un compromesso su come disegnare i confini funzionali del nuovo microservizio.

Se questa attività venisse fatta esplorando manualmente il codice dei componenti correlati, la portata del lavoro sarebbe imprevedibile e l’effort ingente. C'è il rischio che alcuni componenti vengano tralasciati e che ci si renda conto di essi solo a collaudo avviato, causando così problemi nell'uso reale o prolungando la durata del progetto.

Identificare l'obsolescenza o le vulnerabilità

In un sistema con migliaia di componenti, è importante tenere sotto controllo le versioni e le vulnerabilità note. Le versioni più vecchie dei componenti OSS presentano in genere un maggior numero di vulnerabilità note e possono diventare completamente obsolete. Tenere sotto controllo questo aspetto può essere un compito enorme. La componente SCA di CAST Highlight consente di effettuare l’analisi della composizione del software identificando velocemente i componenti e i framework obsoleti e a rischio di vulnerabilità note. Una volta identificati tali componenti, è necessario sostituirli o modificare l'architettura per poterne fare a meno. Con CAST Imaging, poi, si può effettuare una rapida ricerca sui componenti identificati verificando il loro contesto all’interno dell’architettura per poter così   stimare il tempo di sostituzione di ciascun componente.