Valutazione dell'applicazione

  • Articolo

La razionalizzazione del cloud è il processo di valutazione delle applicazioni per determinare il modo migliore per eseguirne la migrazione o la modernizzazione per il cloud.

I metodi di razionalizzazione includono:

  • Rehosting. Noto anche come migrazione lift-and-shift , il rehosting sposta un'applicazione corrente nel cloud con modifiche minime.
  • Refactoring. Il refactoring di un'applicazione per adattarsi alle opzioni basate su piattaforma distribuita come servizio (PaaS) può ridurre i costi operativi.
  • Riprogettare. Riprogettare le applicazioni invecchiate che non sono compatibili con i componenti cloud o le applicazioni compatibili con il cloud che si renderebbero conto dei costi e dell'efficienza operativa riprogettando in una soluzione nativa del cloud.
  • Ricostruzione. Se le modifiche o i costi per portare avanti un'applicazione sono troppo grandi, è consigliabile creare una nuova codebase nativa del cloud. La ricompilazione è particolarmente appropriata per le applicazioni che in precedenza soddisfano le esigenze aziendali, ma ora non sono supportate o non allineate ai processi aziendali correnti.

Prima di decidere una strategia appropriata, analizzare l'applicazione corrente per determinare il rischio e la complessità di ogni metodo. Prendere in considerazione il ciclo di vita dell'applicazione, la tecnologia, l'infrastruttura, le prestazioni e il monitoraggio e il monitoraggio. Per le architetture multilivello, valutare il livello presentazione, il livello di servizio, il livello di integrazione e il livello dati.

Gli elenchi di controllo seguenti valutano un'applicazione per determinare la complessità e il rischio di riprogettazione o ricompilazione.

Complessità e rischio

Ognuno dei fattori seguenti aggiunge complessità, rischio o entrambi.

Architettura

Definire l'architettura di alto livello, ad esempio applicazione Web, servizi Web, archiviazione dati o memorizzazione nella cache.

Fattore Complessità Rischio
I componenti dell'applicazione non vengono convertiti direttamente in Azure. ✔ ✔
L'applicazione richiede modifiche al codice da eseguire in Azure. ✔ ✔
L'applicazione richiede modifiche di codice importanti e complesse da eseguire in Azure. ✔ ✔

Driver di business

Le applicazioni meno recenti potrebbero richiedere modifiche estese per passare al cloud.

Fattore Complessità Rischio
Questa applicazione è stata intorno per più di tre anni. ✔
Questa applicazione è business critical. ✔
Sono disponibili blocchi tecnologici per la migrazione. ✔
Sono disponibili blocchi aziendali per la migrazione. ✔
Questa applicazione ha requisiti di conformità. ✔
L'applicazione è soggetta ai requisiti dei dati specifici del paese o dell'area geografica. ✔
L'applicazione è accessibile pubblicamente. ✔ ✔

Tecnologia

Fattore Complessità Rischio
Non si tratta di un'applicazione basata sul Web e non è ospitata in un server Web. ✔
L'app non è ospitata in Windows IIS ✔
L'app non è ospitata in Linux ✔
L'applicazione è ospitata in una web farm e richiede più server per ospitare i componenti Web. ✔ ✔
L'applicazione richiede l'installazione di software di terze parti nei server. ✔ ✔
L'applicazione è ospitata in un singolo data center e le operazioni vengono eseguite in un'unica posizione. ✔
L'applicazione accede al Registro di sistema del server. ✔
L'applicazione invia messaggi di posta elettronica e deve accedere a un server SMTP. ✔
Non si tratta di un'applicazione .NET. ✔
L'applicazione usa SQL Server come archivio dati. ✔
L'applicazione archivia i dati nei dischi locali e deve accedere ai dischi per funzionare correttamente. ✔
L'applicazione usa Servizi Windows per elaborare operazioni asincrone o richiede servizi esterni per elaborare dati o operazioni. ✔

Distribuzione

Quando si valutano i requisiti di distribuzione, prendere in considerazione:

  • Numero di utenti giornalieri
  • Numero medio di utenti simultanei
  • Traffico previsto
  • Larghezza di banda in Gbps
  • Richieste al secondo
  • Quantità di memoria necessaria

È possibile ridurre il rischio di distribuzione archiviando il codice sotto il controllo del codice sorgente in un sistema di controllo della versione, ad esempio Git, Azure DevOps Server o SVN.

Fattore Complessità Rischio
L'uso di codice e dati esistenti è una priorità #1. ✔ ✔
Il codice dell'applicazione non è sotto il controllo del codice sorgente. ✔
Non esiste un processo di compilazione automatizzato, ad esempio Azure DevOps Server o Jenkins. ✔
Non esiste alcun processo di rilascio automatico per distribuire l'applicazione. ✔ ✔
L'applicazione ha un contratto di servizio che determina la quantità di tempo di inattività previsto. ✔
L'applicazione riscontra tempi di utilizzo massimi o variabili o carichi. ✔
L'applicazione Web salva lo stato della sessione in fase di elaborazione anziché un archivio dati esterno. ✔

Operazioni

Fattore Complessità Rischio
L'applicazione non ha una strategia di strumentazione consolidata o un framework di strumentazione standard. ✔
L'applicazione non usa gli strumenti di monitoraggio e il team operativo non monitora le prestazioni dell'app. ✔
L'applicazione ha misurato il contratto di servizio sul posto e il team operativo monitora le prestazioni dell'applicazione. ✔
L'applicazione scrive in un archivio log, un registro eventi, un file di log, un database di log o Application Insights. ✔
L'applicazione non scrive in un archivio log, un registro eventi, un file di log, un database di log o Application Insights. ✔
L'applicazione non fa parte del piano di ripristino di emergenza dell'organizzazione. ✔

Sicurezza

Fattore Complessità Rischio
L'applicazione usa Active Directory per autenticare gli utenti. ✔ ✔
L'organizzazione non ha ancora configurato Microsoft Entra ID o non ha configurato Microsoft Entra Connessione per sincronizzare AD locale con Microsoft Entra ID. ✔
L'applicazione richiede l'accesso alle risorse locali, che richiederà la connettività VPN da Azure. ✔
L'organizzazione non ha ancora configurato una connessione VPN tra Azure e l'ambiente locale. ✔ ✔
L'applicazione richiede l'esecuzione di un certificato SSL. ✔ ✔

Risultati

Usando le tabelle precedenti, determinare se ogni fattore si applica all'applicazione. Contare il numero di segni di spunta complessità e rischio per i fattori che si applicano all'applicazione.

  • Il livello previsto di complessità di migrazione o modernizzazione dell'applicazione in Azure è: Fattori di complessità corrispondenti/Fattori di complessità totali possibili.
  • Il rischio previsto è: Fattori di rischio corrispondenti/Fattori di rischio totali possibili.

Total Possible Complexity Factors = 28, Total Possible Risk Factors = 23

Per complessità e rischio, un punteggio ottenuto dal calcolo precedente di <0,3 = basso, <0,7 = medio, >0,7 = alto. Questi punteggi forniscono una scala relativa di complessità e rischio.

Refactoring, riprogettazione o ricompilazione

Per razionalizzare se eseguire il rehosting, il refactoring, la riprogettazione o la ricompilazione dell'applicazione, prendere in considerazione i punti seguenti. Molti di questi fattori contribuiscono anche alla complessità e al rischio.

Determinare se i componenti dell'applicazione possono traslare direttamente in Azure. In tal caso, non sono necessarie modifiche al codice per spostare l'applicazione in Azure e potrebbe usare strategie di rehosting o refactoring. In caso contrario, è necessario riscrivere il codice, quindi è necessario riprogettare o ricompilare.

Se l'app richiede modifiche al codice, determinare la complessità e l'estensione delle modifiche necessarie. Le modifiche secondarie potrebbero consentire la riprogettazione, mentre le modifiche principali potrebbero richiedere la ricompilazione.

Rehosting o refactoring

  • Se si usa codice e dati esistenti è una priorità assoluta, prendere in considerazione una strategia di refactoring anziché riprogettare o ricompilare.

  • Se sono presenti sequenze temporali come l'arresto del data center o la scadenza del contratto, le licenze di fine vita o fusioni o acquisizioni, il modo più rapido per ottenere l'applicazione in Azure potrebbe essere eseguire il rehosting, seguito dal refactoring per sfruttare i vantaggi delle funzionalità cloud.

Riprogettazione o ricompilazione

  • Se sono presenti applicazioni che servono esigenze simili nel portfolio, questa potrebbe essere l'opportunità di riprogettare o ricompilare l'intera soluzione.

  • Se si vuole implementare un'architettura multilivello o microservizi per un'app monolitica, è necessario riprogettare o ricompilare l'app. Se non ti dispiace mantenere la struttura monolitica, potresti essere in grado di eseguire il rehosting o il refactoring.

  • Riprogettare o ricompilare l'app per sfruttare le funzionalità cloud se si prevede di aggiornare l'app più spesso dell'anno, se l'app presenta tempi di utilizzo massimi o variabili o se si prevede che l'app gestisca traffico elevato.

Per decidere tra riprogettazione o ricompilazione, valutare i fattori seguenti. Il risultato di punteggio più grande indica la strategia migliore.

Fattore Riprogettazione Ricostruzione
Esistono altre applicazioni che servono esigenze simili nel portfolio. ✔ ✔
L'applicazione richiede modifiche minime al codice da eseguire in Azure. ✔
L'applicazione richiede modifiche di codice importanti e complesse da eseguire in Azure. ✔
È importante usare il codice esistente. ✔
Si vuole spostare un'applicazione monolitica nell'architettura multilivello. ✔
Si vuole spostare un'applicazione monolitica in un'architettura di microservizi. ✔ ✔
Si prevede che questa app aggiunga funzionalità innovative come intelligenza artificiale, IoT o bot. ✔
Tra le funzionalità, i costi, l'infrastruttura e i processi, la funzionalità è l'aspetto meno efficiente di questa applicazione. ✔
L'applicazione richiede software di terze parti installato nei server. ✔
L'applicazione accede al Registro di sistema del server. ✔
L'applicazione invia messaggi di posta elettronica e deve accedere a un server SMTP. ✔
L'applicazione usa SQL Server come archivio dati. ✔
L'applicazione archivia i dati nei dischi locali e deve accedere ai dischi per l'esecuzione corretta. ✔
L'applicazione usa servizi Windows per elaborare operazioni asincrone o richiede servizi esterni per elaborare dati o operazioni. ✔
Un'applicazione Web salva lo stato della sessione in fase di elaborazione anziché in un archivio dati esterno. ✔
L'app ha tempi di utilizzo massimi e variabili e carichi. ✔ ✔
Si prevede che l'applicazione gestisca traffico elevato. ✔ ✔

Passaggi successivi