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 vogliono saperne di più su ciò che la modernizzazione comporta. Sebbene questo documento sia incentrato sulle applicazioni server personalizzate (ad esempio applicazioni ASP.NET o Windows Services), 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 dagli sforzi che puoi investire per la modernizzazione.

Nel contesto delle applicazioni .NET Framework, i concetti legacy e moderno non sono definitivi. Ogni applicazione ha esigenze diverse in termini di legacy e modernizzazione. Tuttavia, le applicazioni legacy hanno alcuni limiti 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 monolite creato 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 possono differire 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 da Windows.
  • La difficoltà dell'upgrade delle applicazioni legacy basate su un'architettura monolitica.
  • Poca agilità per la pianificazione, il budget e la scalabilità con le risorse on-premise.

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

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

Rispetto al convenzionale approccio on-premise, un'architettura cloud offre un modo più economico, efficiente e resiliente per eseguire le tue applicazioni. In un approccio basato su cloud, hai maggiore flessibilità per scegliere dove e quando eseguire il deployment delle tue applicazioni.

Percorso di modernizzazione

Sebbene i vantaggi di un'architettura basata su cloud siano evidenti, 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 pattern universale. Come mostra il seguente diagramma, la modernizzazione prevede una serie di passaggi, in cui ogni passaggio rimuove una limitazione, aumenta le capacità dell'applicazione e offre opportunità per fasi successive di modernizzazione.

Processi, tecnologie e servizi coinvolti nel processo di modernizzazione.

I passaggi verso la modernizzazione sono raggruppati in tre fasi:

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

Valutazione e apprendimento pre-modernizzazione

Prima di eseguire la modernizzazione, è 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 cambiare o spostare (in genere per motivi normativi o legati alla versione precedente). Per ulteriori informazioni, consulta Migrazione a Google Cloud: valutazione e rilevamento 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 la migrazione delle tue applicazioni convenzionali al cloud così come sono o con modifiche minime al codice o alla configurazione dell'applicazione.

Fase 1: rehosting nel cloud

L'obiettivo principale di questa prima fase è trasferire il carico 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.

Confronto tra migrazione manuale e migrazione basata su strumenti

Il lift and shift delle applicazioni .NET Framework basate su Windows in genere inizia con il trasferimento delle istanze Windows Server e SQL Server on-premise alle istanze di macchine virtuali (VM) di Compute Engine. Puoi eseguire la procedura manualmente o automatizzarla 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, come la soluzione ASP.NET Framework per ottenere una VM Windows Server che include IIS, SQL Express e ASP.NET.

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

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

Dopo aver configurato le VM, in genere crei immagini VM personalizzate in modo da poter ricreare nuove istanze on demand. Questo passaggio è importante anche per i modelli di istanza, descritti 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 Virtual Private Cloud (VPC) o passare direttamente a Managed Service per Microsoft Active Directory.

Connettività on-premise e cloud

Quando esegui la migrazione delle VM nel cloud, non è raro mantenere alcuni carichi di lavoro on-premise, ad esempio quando hai applicazioni che richiedono hardware o software legacy o quando devi soddisfare i requisiti normativi e di conformità locali. Hai bisogno di una VPN o di una soluzione di interconnessione per connettere in modo sicuro le risorse on-premise e su cloud. Per conoscere i vari modi per creare e gestire questa connessione, nonché altre implicazioni dell'esecuzione di carichi di lavoro ibridi e on-premise, consulta Migrazione a Google Cloud: creare gli elementi di base.

Vantaggi iniziali

Al termine della fase 1, l'infrastruttura di base è in esecuzione nel cloud, che offre vantaggi quali:

  • Ottimizzazioni dei costi. Puoi creare un tipo di macchina personalizzata (CPU, memoria e spazio di archiviazione) e pagare in base a ciò che utilizzi, avviare e arrestare VM e ambienti di ripristino di emergenza in base alle tue esigenze e pagare solo quando sono in esecuzione. Inoltre, puoi ricevere suggerimenti per il dimensionamento ottimale prima della migrazione.
  • Maggiore efficienza operativa. Puoi collegare dischi permanenti alle VM e creare snapshot per backup e ripristino semplificati.
  • 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 la tua applicazione eseguendo l'upgrade di parti dei componenti dell'applicazione, come il database, il livello di memorizzazione nella cache o il 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à cloud per migliorare la gestione, la resilienza, la scalabilità e l'elasticità dell'applicazione senza effettuare una ristrutturazione significativa o lasciare l'ambiente VM.

Sfrutta i vantaggi di Compute Engine

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

Con queste funzionalità puoi rimanere 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 in hosting con opzioni cloud gestite di Google e di partner terzi su Cloud Marketplace, tra cui:

  • Cloud SQL anziché SQL Server, MySQL o Postgres ospitati autonomamente. Cloud SQL consente di concentrarti sulla gestione del database anziché sulla gestione dell'infrastruttura (ad esempio applicando patch alle VM dei database per la sicurezza o alla gestione dei backup) con il vantaggio aggiuntivo di rimuovere il requisito di una licenza Windows.
  • Managed Service for Microsoft Active Directory anziché Active Directory self-hosted.
  • Memorystore anziché istanze Redis ospitate autonomamente.

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

Primi passi 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 consentono di eseguire le applicazioni in vari ambienti e in modo più coerente, prevedibile ed efficiente (soprattutto quando si eseguono più container sullo stesso host). L'ecosistema dedicato ai container (come Kubernetes, Istio e Knative) offre anche una serie di funzionalità di gestione, resilienza e monitoraggio che possono accelerare ulteriormente il passaggio della tua applicazione da un singolo monolite a un insieme di microservizi mirati.

Per un certo periodo, la containerizzazione è stata una funzionalità solo di Linux. Le applicazioni Windows non potrebbero trarre vantaggio dai container. Questo è cambiato 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 usufruire dei vantaggi dei container (ad esempio agilità, portabilità e controllo). Devi scegliere il sistema operativo corretto per la destinazione a seconda della versione di .NET Framework e ricorda che non tutto lo stack di Windows è supportato nei container Windows. Per i limiti di questo approccio e le 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 offre funzionalità standard come il rilevamento quando un pod di container è inattivo e lo ricrea, 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 regionali, 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.

L'utilizzo delle funzionalità giuste in Compute Engine offre molti vantaggi, ma il passaggio ai container e a GKE ti consente di utilizzare appieno le tue VM pacchettizzando più pod nelle stesse VM. Questa strategia potrebbe comportare un minor numero di VM e dei costi di licenza di Windows.

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 prossima fase della modernizzazione.

Fase 3: riprogetta e ricrea l'architettura

Il replatforming è solo l'inizio per trarre il massimo vantaggio dal 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, potresti utilizzare:

Sebbene sia necessario codice aggiuntivo per integrare l'applicazione con questi servizi, è un investimento utile, perché stai trasferendo l'onere della gestione della piattaforma su Google Cloud. Le librerie Google Cloud per .NET, gli 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.

I servizi gestiti possono inoltre supportare le operazioni per la tua applicazione. Puoi archiviare i log delle tue applicazioni in Cloud Logging e inviare le metriche dell'applicazione 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 .NET Framework legacy 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. Questo approccio può funzionare a breve termine, ma può limitare notevolmente la tua attività nel lungo periodo. Windows prevede tariffe per la licenza e un utilizzo delle risorse complessivo maggiore rispetto a Linux. Questi fattori possono comportare un costo di proprietà più elevato 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 consente di liberarsi dalla dipendenza su Windows e dai costi delle licenze associati.

Portare le applicazioni da .NET Framework a .NET

Un buon modo per iniziare il passaggio a .NET è leggere Panoramica della portabilità da .NET Framework a .NET. Strumenti come Analizzatore portabilità.NET e Analizzatore di compatibilità della piattaforma possono aiutarti a determinare se assiemi e API sono portabili. Altri strumenti di portabilità come dotnet test-convert possono essere utili.

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

Trasformazione culturale

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

Decomposizione monolite

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

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

Nel considerare queste domande, devi tenere conto dei vantaggi, del tempo e dei costi associati a ciascun approccio. È bene avere un approccio equilibrato che 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 quando si presenta l'opportunità. In base alla pianificazione, i seguenti documenti possono essere utili:

Opzioni di deployment per i container .NET

Come stato del deployment di app .NET su Google Cloud, hai diverse opzioni per il deployment di container .NET su Google Cloud. Durante la scomposizione della tua applicazione monolitica in microservizi, potresti decidere di utilizzare più di una soluzione di hosting, a seconda dell'architettura e della progettazione dei tuoi microservizi.

Le risposte alle seguenti domande possono aiutarti a decidere la strategia di hosting migliore:

  • 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 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. Knative serving offre ulteriori opzioni di personalizzazione come GPU, più memoria e spazio su disco.
  • Quali sono le tue aspettative in termini di scalabilità? Se la tua applicazione prevede 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, devi prendere in considerazione una delle seguenti opzioni:

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

In generale, per creare microservizi che gestiscono richieste HTTP, devi eseguire il deployment su Cloud Run quando possibile e utilizzare GKE se vuoi rimanere nell'ecosistema Kubernetes o hai bisogno di ulteriori opzioni di personalizzazione. GKE è anche la scelta predefinita se hai un processo a lunga esecuzione, come un processo che rimane in ascolto su una coda o un'applicazione che utilizza protocolli diversi da HTTP(S).

Anche Cloud Functions è una buona opzione di deployment serverless, ma non è discusso qui, perché Cloud Run fornisce la maggior parte delle funzionalità fornite da Cloud Functions e Cloud Functions non supporta tutte le versioni di .NET.

Kubernetes e GKE

Se vuoi eseguire l'esecuzione in un ambiente ottimizzato per i container, questo approccio probabilmente riguarda Kubernetes e la sua versione gestita, GKE. Kubernetes e GKE sono particolarmente adatti se prevedi di eseguire il deployment di molti container con requisiti diversi e vuoi un controllo granulare sul modo in cui viene eseguito il deployment e la 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 impegnativo, ma ti consentono di spostare la maggior parte del carico di gestione dei container su Kubernetes. Sono inoltre particolarmente indicati 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 scalabilità automatica dei cluster, riparazione automatica e upgrade automatico per semplificare la gestione di Kubernetes e funzionalità di sicurezza come l'isolamento dei container e i registri privati. Anche se ti viene addebitato un costo per ciascun nodo nel cluster in GKE, GKE supporta le VM spot per ridurre i costi.

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

Knative e Cloud Run

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

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

Cloud Run segue l'API Knative, ma viene eseguito sull'infrastruttura di 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 fornisce inoltre funzionalità utili, come revisioni e suddivisione del traffico.

Knative serving è 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 consente di aggiungere GPU alle istanze sottostanti che eseguono i container o 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 frontend web con scalabilità automatica sia per 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, ovvero come viene creata, testata, sottoposta a deployment e monitorata. Perciò, quando pensi alla modernizzazione, devi pensare alle operazioni.

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

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 tue applicazioni ASP.NET. Per esportare le metriche OpenTelemetry in Google Cloud, puoi utilizzare la libreria OpenTelemetry.Exporter.Stackdriver.

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

Passaggi successivi