Percorso di modernizzazione per le applicazioni .NET Framework su Google Cloud

Last reviewed 2023-07-13 UTC

Questo documento esamina i limiti comuni delle applicazioni monolitiche e descrive un processo graduale ma strutturato per modernizzarle.

Questo documento è rivolto ai Cloud Architect, agli amministratori di sistema e ai CTO che hanno familiarità con Windows e l'ecosistema .NET e che vogliono saperne di più su cosa comporta la modernizzazione. Sebbene questo documento sia incentrato sulle applicazioni server personalizzate (come le applicazioni ASP.NET o dei servizi Windows), puoi applicare le lezioni ad altri casi d'uso.

Applicazioni legacy e moderne: perché modernizzare?

La modernizzazione delle applicazioni legacy è un viaggio. Il punto di inizio e di fine del percorso e i vantaggi che ottieni dipendono in gran parte dallo stato delle tue applicazioni e dal tempo e dall'impegno che puoi investire per modernizzare.

Nel contesto delle applicazioni .NET Framework, i concetti di legacy e moderno non sono definitivi. Ogni applicazione ha esigenze legacy e di modernizzazione distinte. Tuttavia, le applicazioni legacy condividono alcune limitazioni comuni.

Il seguente diagramma riassume le caratteristiche delle applicazioni legacy e delle moderne applicazioni basate su cloud.

Differenze tra applicazioni monolitiche e moderne basate su cloud.

Un'applicazione .NET Framework legacy è in genere un monolith basato su .NET Framework, ospitato su un server Microsoft Windows on-premise e connesso a un server on-premise che esegue Microsoft SQL Server. I dettagli dell'architettura potrebbero essere diversi da queste caratteristiche generali, ma la maggior parte delle applicazioni monolitiche presenta le seguenti limitazioni:

  • La necessità di gestire i server on-premise che eseguono Windows e SQL Server.
  • Gli ambienti di deployment limitati e i costi delle licenze associati alla dipendenza su Windows.
  • La difficoltà dell'upgrade delle applicazioni legacy basate su un'architettura monolitica.
  • Poca agilità per pianificare, definire il budget e scalare con le risorse on-premise.

Le applicazioni create per un'architettura basata su cloud offrono diversi vantaggi:

  • Overhead di gestione minimo grazie all'integrazione con i servizi gestiti.
  • Mobilità completa con .NET e container e senza dipendenze Windows o costi delle licenze.
  • Un percorso di upgrade ad alta velocità basato su microservizi di cui è possibile eseguire il deployment in modo indipendente.
  • Massima agilità per scalabilità e budget grazie a un'architettura serverless.

Rispetto all'approccio on-premise convenzionale, un'architettura cloud offre un modo più conveniente, efficiente e resiliente per eseguire le tue applicazioni. Con un approccio basato su cloud, hai maggiore flessibilità nella scelta del luogo e del momento in cui eseguire il deployment delle tue applicazioni.

Percorso di modernizzazione

Sebbene i vantaggi di un'architettura basata su cloud siano chiari, il percorso verso il cloud potrebbe non esserlo. La modernizzazione da un'architettura legacy .NET Framework a un'architettura basata su cloud non segue un unico modello unico. Come mostra il seguente diagramma, la modernizzazione prevede una serie di passaggi, in cui ogni passaggio rimuove un limite, eleva le funzionalità delle applicazioni e apre opportunità per le fasi successive della modernizzazione.

Processo, tecnologie e servizi coinvolti nel processo di modernizzazione.

I passaggi per la modernizzazione sono raggruppati in tre fasi:

  1. Rehosting nel cloud (noto anche come lift and shift)
  2. Replatforming
  3. Riprogetta l'architettura e ricrea

Valutazione e apprendimento pre-moderno

Prima di modernizzarsi, è necessario prepararsi. Il primo passaggio consiste nel valutare le applicazioni e le loro dipendenze per determinare quali applicazioni sono adatte alla modernizzazione e quali non possono essere modificate o spostate (in genere per motivi normativi o relativi alle versioni legacy). Per ulteriori informazioni, consulta Migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro.

Parallelamente a questa valutazione, il tuo team deve apprendere le funzionalità del cloud. Google Cloud offre certificazioni, guide tecniche e codelab specifici per Windows e .NET che possono aiutare ad accelerare il processo di apprendimento.

Dopo aver identificato le applicazioni da modernizzare, puoi iniziare a eseguire la migrazione delle applicazioni convenzionali al cloud così come sono o con modifiche minime al codice o alla configurazione dell'applicazione.

Fase 1: nuovo hosting nel cloud

L'obiettivo principale di questa prima fase è trasferire l'onere della gestione dei server dalle risorse on-premise all'infrastruttura cloud. In questa fase, ti assicuri che la tua infrastruttura sia pronta per il cloud, in modo da poterla ottimizzare per il cloud nelle fasi successive.

Migrazione manuale e migrazione basata su strumenti

In genere, il lift and shift delle applicazioni .NET Framework basate su Windows inizia spostando le istanze di Windows Server e SQL Server on-premise su istanze di macchine virtuali (VM) di Compute Engine. Puoi eseguire questo processo manualmente o automatizzarlo con l'aiuto di uno strumento di migrazione.

In una migrazione manuale, puoi utilizzare le immagini Windows Server di Compute Engine per avviare le istanze. Google Cloud Marketplace offre anche soluzioni pronte per il deployment su Compute Engine, ad esempio la soluzione ASP.NET Framework per ottenere una VM Windows Server che include IIS, SQL Express e ASP.NET.

Allo stesso modo, puoi avviare istanze di SQL Server da immagini SQL Server oppure passare direttamente a una soluzione più gestita: Cloud SQL per SQL Server.

Google Cloud offre inoltre strumenti di migrazione come Migrazione alle macchine virtuali o VMware Engine per aiutarti a spostare le VM VMware on-premise in un ambiente VMware su Google Cloud.

Dopo aver configurato le VM, in genere devi creare immagini VM personalizzate in modo da poter ricreare nuove istanze on demand. Questo passaggio è importante anche per i modelli di istanza, di cui parleremo più avanti in questo documento.

Se hai bisogno di servizi di dominio nel cloud, puoi eseguire il deployment di un ambiente Microsoft Active Directory a tolleranza di errore su Compute Engine con un VPC (Virtual Private Cloud) o andare direttamente a Managed Service for Microsoft Active Directory.

Connettività on-premise e cloud

Quando si esegue la migrazione delle VM nel cloud, non è raro mantenere alcuni carichi di lavoro on-premise, ad esempio quando le applicazioni richiedono hardware o software legacy o quando è necessario soddisfare requisiti di conformità e normativi locali. Per connettere in modo sicuro le risorse on-premise e cloud, è necessaria una VPN o una soluzione di interconnessione. Per informazioni sui vari modi per creare e gestire questa connessione, nonché per altre implicazioni dell'esecuzione di carichi di lavoro on-premise e su cloud ibrido, consulta Migrazione a Google Cloud: creare la tua base.

Vantaggi iniziali

Alla fine della fase 1, l'infrastruttura di base è in esecuzione nel cloud, che offre vantaggi quali i seguenti:

  • Ottimizzazioni dei costi. Puoi creare un tipo di macchina personalizzata (CPU, memoria e spazio di archiviazione) e pagare per ciò che utilizzi, avviare e arrestare VM e ambienti di ripristino di emergenza a tuo piacimento e pagare solo quando sono in esecuzione, e ricevere suggerimenti per il dimensionamento ottimale prima della migrazione.
  • Maggiore efficienza operativa. Puoi collegare dischi permanenti alle VM e creare snapshot per semplificare il backup e il ripristino.
  • Maggiore affidabilità. Non è più necessario pianificare periodi di manutenzione a causa della funzionalità di migrazione live.

Questi vantaggi iniziali sono utili, ma ne vengono sbloccati altri quando si inizia l'ottimizzazione per il cloud.

Fase 2: replatforming

Quando esegui il replatforming, ottimizzi l'applicazione eseguendo l'upgrade di parti dei componenti dell'applicazione, come database, livello di memorizzazione nella cache o sistema di archiviazione, senza modificare l'architettura dell'applicazione e con modifiche minime al codebase. L'obiettivo della fase 2 è iniziare a utilizzare le funzionalità del cloud per migliorare la gestione, la resilienza, la scalabilità e l'elasticità della tua applicazione, senza ristrutturarla in modo significativo o uscire dall'ambiente VM.

Sfrutta Compute Engine

Compute Engine fornisce alcune caratteristiche standard utili da esplorare. Ad esempio, puoi utilizzare i modelli di istanza in Compute Engine per creare modelli da configurazioni VM esistenti. I gruppi di istanze sono un parco di VM identiche che consentono di scalare in modo efficiente le prestazioni e la ridondanza della tua applicazione. Oltre al semplice bilanciamento del carico e alla ridondanza, i gruppi di istanze gestite offrono funzionalità di scalabilità come scalabilità automatica, funzionalità ad alta disponibilità come la autohealing, i deployment a livello di regione e funzionalità di sicurezza come l'aggiornamento automatico.

Con queste funzionalità puoi restare nel mondo delle VM, ma aumentare la resilienza, la ridondanza e la disponibilità delle tue applicazioni senza dover ristrutturare completamente l'applicazione.

Cerca sostituzioni in loco

Quando sposti la tua applicazione nel cloud, devi cercare opportunità per sostituire la tua infrastruttura ospitata con opzioni cloud gestite da Google e da partner terzi su Cloud Marketplace, tra cui:

  • Cloud SQL anziché SQL Server, MySQL o Postgres con hosting autonomo. Cloud SQL ti permette di concentrarti sulla gestione del database anziché dell'infrastruttura (ad esempio, applicare patch alle VM del database per la sicurezza o gestire i backup) con l'ulteriore vantaggio di rimuovere il requisito di una licenza Windows.
  • Managed Service per Microsoft Active Directory anziché Active Directory in hosting autonomo.
  • Memorystore invece di istanze Redis ospitate autonomamente.

Queste sostituzioni non dovrebbero richiedere modifiche al codice e solo modifiche minime alla configurazione. Inoltre, presentano i vantaggi di una gestione minima, di una sicurezza avanzata e di una scalabilità.

Primi passaggi con i container Windows

Dopo aver ottimizzato le funzioni di base per il cloud, puoi iniziare il passaggio dalle VM ai container.

Un container è un pacchetto leggero che contiene un'applicazione e tutte le sue dipendenze. Rispetto all'esecuzione dell'applicazione direttamente su una VM, i container ti consentono di eseguire le applicazioni in vari ambienti e in modo più coerente, prevedibile ed efficiente, soprattutto quando esegui più container sullo stesso host. L'ecosistema attorno ai container (come Kubernetes, Istio e Knative) fornisce inoltre una serie di funzionalità di gestione, resilienza e monitoraggio che possono accelerare ulteriormente la trasformazione della tua applicazione da un singolo monolite a un set di microservizi mirati.

Per un po' di tempo, la containerizzazione è stata una funzionalità disponibile solo per Linux. Le applicazioni Windows non potevano trarre vantaggio dai container. La situazione è cambiata con i container Windows e con il successivo supporto in Kubernetes e Google Kubernetes Engine (GKE).

I container Windows sono un'opzione ideale se non vuoi eseguire la migrazione delle applicazioni .NET Framework a .NET, ma vuoi comunque i vantaggi dei container (come agilità, portabilità e controllo). Devi scegliere il sistema operativo giusto da scegliere come target a seconda della versione di .NET Framework e ricordare che non tutto lo stack Windows è supportato nei container Windows. Per le limitazioni di questo approccio e delle alternative, consulta Container.NET e Linux più avanti in questo documento.

Dopo aver containerizzato l'applicazione .NET Framework in un container Windows, ti consigliamo di eseguirla in un cluster Kubernetes. Kubernetes fornisce funzionalità standard come il rilevamento dello stato inattivo di un pod del container e la sua creazione, la scalabilità automatica dei pod, le implementazioni o i rollback automatizzati e i controlli di integrità. GKE aggiunge funzionalità come scalabilità automatica dei cluster, cluster a livello di regione, piani di controllo a disponibilità elevata e supporto ibrido e multi-cloud con GKE Enterprise. Se decidi di utilizzare GKE o GKE Enterprise, puoi utilizzare Migrazione ai container per semplificare e accelerare la migrazione delle VM Windows ai container. Migrate to Containers automatizza l'estrazione delle applicazioni dalle VM ai container senza la necessità di riscrivere o riprogettare le applicazioni.

Sebbene sia possibile ottenere molti vantaggi utilizzando le funzionalità giuste in Compute Engine, il passaggio ai container e GKE ti aiuta a utilizzare al meglio le tue VM pacchettizzando più pod sulle stesse VM. Questa strategia potrebbe comportare un numero inferiore di VM e costi di licenze Windows inferiori.

Anche la gestione dichiarativa dei container Windows e Linux con Kubernetes e GKE può semplificare la gestione dell'infrastruttura. Con la containerizzazione, il tuo team è pronto per la fase successiva della modernizzazione.

Fase 3: riprogettazione e nuova creazione

Il replatforming è solo l'inizio per sfruttare appieno il cloud. La trasformazione della tua architettura in una piattaforma basata su cloud offre diversi vantaggi, tra cui:

Il passaggio ai servizi gestiti

Quando inizi a riscrivere parti della tua applicazione, ti consigliamo di iniziare a passare dai servizi in hosting ai servizi gestiti. Ad esempio, puoi utilizzare quanto segue:

Anche se hai bisogno di codice aggiuntivo per integrare la tua applicazione con questi servizi, è un investimento utile, perché stai trasferendo l'onere della gestione della piattaforma a Google Cloud. Le librerie Google Cloud per .NET, Strumenti per Visual Studio e Cloud Code per Visual Studio Code possono aiutarti a rimanere nell'ecosistema e negli strumenti .NET durante l'integrazione con questi servizi.

Anche i servizi gestiti possono supportare le operazioni per la tua applicazione. Puoi archiviare i log delle applicazioni in Cloud Logging e inviare le metriche delle applicazioni a Cloud Monitoring, dove puoi creare dashboard con metriche del server e delle applicazioni. Google Cloud offre librerie client .NET per Cloud Logging, Cloud Monitoring e Cloud Trace.

Container .NET e Linux

Se la tua applicazione è un'applicazione legacy .NET Framework che viene eseguita solo su Windows, potresti avere la tentazione di mantenerla in esecuzione su un server Windows su Compute Engine o in un container Windows Server su GKE. Sebbene questo approccio funzioni nel breve periodo, può limitarti notevolmente a lungo termine. Windows prevede tariffe per le licenze e un utilizzo complessivo delle risorse maggiore rispetto a Linux, e questi fattori possono portare a un costo di proprietà maggiore a lungo termine.

Uno degli aspetti più importanti di .NET è che è multipiattaforma. Puoi containerizzare un'applicazione .NET in un container Linux. I container Linux sono più leggeri dei container Windows e vengono eseguiti su più piattaforme in modo più efficiente. Questo fattore crea opzioni di deployment per le applicazioni .NET e ti consente di liberarti dalla dipendenza da Windows e dai costi per le licenze associati.

Porting delle applicazioni .NET Framework a .NET

Un buon modo per iniziare a passare a .NET è leggere la Panoramica del trasferimento da .NET Framework a .NET. Strumenti quali .NET Portability Analyzer e Strumento di analisi della compatibilità della piattaforma possono aiutarti a determinare la portabilità di assemblee e API. Altri strumenti di portabilità come dotnet prevent-convert possono essere utili.

Gli strumenti esterni possono aiutarti a identificare i problemi di compatibilità e a decidere quali componenti eseguire per primi. Alla fine, dovrai creare progetti .NET, spostare gradualmente il codice .NET Framework nel nuovo progetto e correggere eventuali incompatibilità. Prima di trasferire il codice, è fondamentale testare i test e verificare la funzionalità dopo il trasferimento. Ti consigliamo di utilizzare il test A/B per testare il vecchio e il nuovo codice. Con il test A/B, puoi mantenere in esecuzione la tua applicazione legacy mentre indirizzi alcuni utenti alla nuova applicazione. Questo approccio consente di testare gli output, la scalabilità e la resilienza della nuova applicazione. Per facilitare i test A/B, Google Cloud offre soluzioni di bilanciamento del carico come l'Application Load Balancer esterno globale.

Trasformazione culturale

La trasformazione da .NET Framework e server Windows ai container .NET e Linux non è solo tecnica. Questo cambiamento richiede una trasformazione culturale nella tua organizzazione. Il personale che potrebbe essere abituato ad ambienti solo Windows deve adattarsi ad ambienti multipiattaforma. Questa trasformazione culturale richiede tempo e budget per l'addestramento in .NET, Linux e in strumenti container come Docker e Kubernetes. Tuttavia, la trasformazione da un'organizzazione solo Windows a un'organizzazione multipiattaforma ti consente di accedere a una gamma più ampia di strumenti e competenze.

Decomposizione del monolite

Il passaggio da .NET Framework a .NET può comportare diverse domande, tra cui:

  • Riscrivi l'intera applicazione in .NET?
  • Suddivide la tua applicazione in servizi più piccoli e li scrivi in .NET?
  • Scrivi solo nuovi servizi in .NET?

Nel valutare queste domande, tieni conto dei vantaggi, del tempo e dei costi associati a ogni approccio. È bene avere un approccio equilibrato, dove non riscrivere tutto in una volta sola. Puoi invece scrivere nuovi servizi in .NET e suddividere il monolite esistente in servizi più piccoli in .NET, man mano che si presentano delle opportunità. I seguenti documenti possono esserti utili durante la pianificazione.

Opzioni di deployment per i container .NET

Allo stato del deployment delle app .NET su Google Cloud, hai a disposizione diverse opzioni per il deployment dei container .NET su Google Cloud. Quando scomponi l'applicazione monolitica in microservizi, potresti decidere di utilizzare più di una soluzione di hosting, a seconda dell'architettura e della progettazione dei tuoi microservizi.

Rispondere alle seguenti domande può aiutarti a decidere la migliore strategia di hosting:

  • Che cosa attiva la tua applicazione? Tutte le soluzioni di hosting sono adatte per HTTP(S) standard, ma se il tuo protocollo è TCP/UDP o di un protocollo proprietario, GKE potrebbe essere la tua unica opzione.
  • La tua applicazione richiede hardware specifico? Cloud Run offre una quantità ragionevole ma limitata di RAM e CPU per ogni richiesta. Cloud Run for Anthos offre ulteriori opzioni di personalizzazione, ad esempio GPU, più memoria e spazio su disco.
  • Quali sono le vostre aspettative in termini di scalabilità? Se la tua applicazione presenta periodi di inattività, le soluzioni serverless come Cloud Run possono offrire la possibilità di fare lo scale down fino a zero.
  • Quanto è importante la latenza e quanto è tollerante la tua applicazione agli avvii a freddo? Se la tolleranza agli avvii a freddo è bassa, valuta una delle seguenti opzioni:

Ti consigliamo di leggere la documentazione di ciascun ambiente di hosting per acquisire familiarità con le funzionalità, i punti di forza e i punti deboli e il modello di determinazione dei prezzi.

Come regola generale, se vuoi creare microservizi che gestiscono le richieste HTTP, devi eseguire il deployment in Cloud Run quando possibile e ricorrere a GKE se vuoi rimanere nell'ecosistema Kubernetes o richiedere più opzioni di personalizzazione. GKE è la scelta predefinita anche se hai un processo a lunga esecuzione, ad esempio un processo che rimane in ascolto su una coda o un'applicazione che utilizza protocolli diversi da HTTP(S).

Cloud Functions è anche un'ottima opzione di deployment serverless, ma non ne viene discussa qui, perché Cloud Run fornisce la maggior parte delle funzionalità di Cloud Functions e Cloud Functions non supporta tutte le versioni di .NET.

Kubernetes e GKE

Se vuoi eseguirlo in un ambiente ottimizzato per i container, questo approccio probabilmente coinvolge Kubernetes e la sua versione gestita, GKE. Kubernetes e GKE sono particolarmente utili se prevedi di eseguire il deployment di molti container con requisiti diversi e vuoi un controllo granulare sulle modalità di deployment e gestione di ciascuno.

Kubernetes è progettato per eseguire container su larga scala e fornisce componenti di base come pod, servizi, deployment e set di repliche. Comprendere e utilizzare correttamente questi costrutti può essere difficile, ma ti consentono di trasferire gran parte del carico di gestione dei container a Kubernetes. Inoltre, sono particolarmente adatti per l'architettura di microservizi, in cui un microservizio è un deployment con un insieme di pod con bilanciamento del carico dietro un servizio.

Oltre a Kubernetes, GKE offre funzionalità come la scalabilità automatica dei cluster, la riparazione e l'upgrade automatico, per semplificare la gestione di Kubernetes, nonché funzionalità di sicurezza come l'isolamento dei container e i registri privati. Anche se ti viene addebitato un costo per ogni nodo nel cluster in GKE, GKE supporta le VM spot per ridurre i costi.

GKE può gestire i container sia Windows sia Linux. Questa funzionalità è utile se vuoi mantenere un unico ambiente ibrido per le applicazioni basate su Windows e Linux.

Knative e Cloud Run

Per i tuoi container .NET stateless, Knative e la sua versione gestita, Cloud Run, forniscono un ambiente container serverless. I container serverless offrono vantaggi come provisioning, scalabilità automatica e bilanciamento del carico senza l'overhead della gestione dell'infrastruttura.

Per il deployment di container in un cluster Kubernetes, Knative fornisce una superficie API di livello superiore e di dimensioni inferiori rispetto a Kubernetes. Knative può quindi aiutarti a evitare le complessità di Kubernetes semplificando il deployment dei container.

Cloud Run segue l'API Knative, ma viene eseguito sull'infrastruttura Google, eliminando così la necessità di cluster Kubernetes. Cloud Run offre un'opzione serverless per i container. Per impostazione predefinita, in Cloud Run, i container vengono scalati automaticamente e fatturati per la durata della richiesta. Il tempo di deployment è in secondi. Cloud Run offre inoltre funzionalità utili, come revisioni e suddivisione del traffico.

Cloud Run for Anthos è la versione più flessibile di Cloud Run per i clienti che desiderano la semplicità di Knative e Cloud Run con la flessibilità operativa di Kubernetes. Ad esempio, Cloud Run su GKE Enterprise ti consente di aggiungere GPU alle istanze sottostanti che eseguono i tuoi container oppure di accedere ad altre VM o cluster GKE nello stesso VPC.

Cloud Run si integra con altri servizi come Pub/Sub, Cloud Scheduler, Cloud Tasks e backend come Cloud SQL. Può essere utilizzato sia per i frontend web con scalabilità automatica sia per i microservizi interni attivati da eventi.

Modernizzazione delle operazioni

La modernizzazione non riguarda solo il codice dell'applicazione. Si applica all'intero ciclo di vita dell'applicazione, in che modo viene creata, testata, sottoposta a deployment e monitorata. Pertanto, quando pensi alla modernizzazione, devi considerare le operazioni.

Cloud Build può aiutarti a modernizzare e automatizzare il ciclo di creazione, test e deployment della tua applicazione. Non solo Cloud Build fornisce builder per .NET, ma Cloud Build si integra anche con lo strumento Vulnerability Scanner di Artifact Registry e con Autorizzazione binaria per impedire l'esecuzione di immagini create da codice sorgente sconosciuto o repository non sicuri nel tuo ambiente di deployment.

Google Cloud Observability (in precedenza Stackdriver) offre diversi servizi che ti consentono di modernizzare l'osservabilità della tua applicazione:

Puoi utilizzare la libreria Google.Cloud.Diagnostics.AspNetCore per esportare log, metriche e tracce in Google Cloud per le applicazioni ASP.NET. Per esportare le metriche di OpenTelemetry in Google Cloud, puoi utilizzare la libreria OpenTelemetry.Exporter.Stackdriver.

Per ulteriori informazioni su come la modernizzazione si applica ai processi e alla cultura dei team, consulta Soluzioni Google Cloud per DevOps.

Passaggi successivi