Percorso di modernizzazione per le applicazioni .NET su Google Cloud

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

Questo documento è rivolto ad architetti cloud, amministratori di sistema e CTO che hanno familiarità con Windows e l'ecosistema .NET e vogliono saperne di più su cosa comporta la modernizzazione. Sebbene questo documento si concentri su applicazioni server personalizzate (come ASP.NET o applicazioni Windows Services), puoi applicare le lezioni ad altri casi d'uso.

Applicazioni legacy e moderne: perché modernizzare?

La modernizzazione delle applicazioni legacy è un percorso. Il punto di partenza e di arrivo di questo percorso, nonché i vantaggi che otterrai, dipendono in gran parte dallo stato delle tue applicazioni e dal tempo e dall'impegno che puoi investire per la modernizzazione.

Nel contesto delle applicazioni .NET, che cosa si intende per legacy e per moderno? Ogni applicazione ha esigenze di modernizzazione e legacy distinte. Tuttavia, le applicazioni legacy condividono alcune limitazioni comuni.

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

Differenze tra applicazioni monolitiche e moderne basate sul cloud.

Un'applicazione .NET legacy è in genere un monolite 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 della tua architettura potrebbero differire da queste caratteristiche generali, ma la maggior parte delle applicazioni monolitiche presenta le seguenti limitazioni:

  • La necessità di gestire server on-premise che eseguono Windows e SQL Server.
  • Gli ambienti di deployment limitati e i costi di licenza associati alla dipendenza da Windows.
  • La difficoltà di eseguire l'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.
  • Piena mobilità con .NET e container e senza dipendenze da Windows o costi di licenza.
  • Un percorso di upgrade ad alta velocità basato su microservizi implementabili in modo indipendente.
  • Piena agilità per scalare e gestire il budget con 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 sul cloud, hai più flessibilità per scegliere dove e quando eseguire il deployment delle tue applicazioni.

Percorso di modernizzazione

Sebbene i vantaggi di un'architettura basata sul cloud siano chiari, il percorso verso il cloud potrebbe non esserlo. La modernizzazione da un'architettura .NET legacy a un'architettura basata sul 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, migliora le funzionalità dell'applicazione 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. Esegui il rehosting nel cloud (noto anche come lift and shift)
  2. Replatforming
  3. Riprogetta e ricrea

Valutazione e apprendimento pre-modernizzazione

Prima di eseguire la modernizzazione, devi prepararti. Il primo passo è valutare le tue applicazioni e le relative dipendenze per determinare quali applicazioni sono adatte alla modernizzazione e quali non possono essere modificate o spostate (in genere per motivi normativi o legacy). Per ulteriori informazioni, vedi Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro.

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

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

Fase 1: esegui il rehosting 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

Il lift and shift delle applicazioni .NET basate su Windows in genere inizia con lo spostamento delle istanze di Windows Server e SQL Server on-premise alle istanze di macchine virtuali (VM) Compute Engine. Puoi eseguire questa 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 dispone anche di 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 istanze SQL Server da immagini SQL Server oppure puoi passare direttamente a una soluzione più gestita: Cloud SQL per SQL Server.

Google Cloud offre anche strumenti di migrazione come Migrate to Virtual Machines 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, 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 virtual private cloud (VPC) o passare direttamente a Managed Service for Microsoft Active Directory.

Connettività on-premise e cloud

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

Vantaggi iniziali

Al termine della fase 1, avrai un'infrastruttura di base in esecuzione nel cloud, che offre vantaggi come i seguenti:

  • Ottimizzazioni dei costi. Puoi creare un tipo di macchina personalizzata (CPU, memoria e spazio di archiviazione) e pagare in base all'utilizzo; avviare e arrestare le VM e gli ambienti di ripristino di emergenza a piacimento e pagare solo quando sono in esecuzione; e ricevere consigli 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 finestre di manutenzione grazie alla funzionalità di migrazione live.

Questi vantaggi iniziali sono utili, ma ne vengono sbloccati altri quando inizi a eseguire l'ottimizzazione per il cloud.

Fase 2: re-platforming

Quando esegui il replatforming, ottimizzi l'applicazione eseguendo l'upgrade di parti dei componenti dell'applicazione, ad esempio 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 una migliore gestione, resilienza, scalabilità ed elasticità dell'applicazione senza ristrutturarla in modo significativo o uscire dall'ambiente VM.

Sfruttare al meglio Compute Engine

Compute Engine fornisce alcune funzionalità standard utili da esplorare. Ad esempio, puoi utilizzare i template di istanza in Compute Engine per creare template dalle configurazioni VM esistenti. I gruppi di istanze sono un parco risorse di VM identiche che ti consentono di scalare in modo efficiente le prestazioni e la ridondanza della tua applicazione. Oltre al bilanciamento del carico e alla ridondanza, i gruppi di istanze gestite dispongono di funzionalità di scalabilità come la scalabilità automatica, funzionalità di alta disponibilità come il ripristino automatico, le implementazioni regionali 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 doverle ristrutturare completamente.

Cercare le sostituzioni in linea

Quando sposti l'applicazione sul cloud, devi cercare opportunità per sostituire l'infrastruttura ospitata con opzioni cloud gestite di Google e partner di terze parti su Cloud Marketplace, tra cui:

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

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

Primi passi con i container Windows

Dopo aver ottimizzato le funzioni di base per il cloud, puoi iniziare a eseguire la migrazione 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 intorno ai container (come Kubernetes, Istio e Knative) fornisce anche una serie di funzionalità di gestione, resilienza e monitoraggio che possono accelerare ulteriormente la trasformazione della tua applicazione da un singolo monolite a un insieme di microservizi mirati.

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

I container Windows sono un'opzione se non vuoi eseguire la migrazione delle applicazioni .NET Framework a .NET, ma vuoi comunque usufruire dei vantaggi dei container (come agilità, portabilità e controllo). Devi scegliere il sistema operativo di destinazione corretto a seconda della versione di .NET Framework e devi ricordare che non tutto lo stack di Windows è supportato sui container Windows. Per le limitazioni di questo approccio e le alternative, vedi Contenitori.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 dell'interruzione di un pod container e la sua ricreazione, la scalabilità automatica dei pod, le implementazioni o i rollback automatizzati e i controlli di integrità. GKE aggiunge funzionalità come la scalabilità automatica dei cluster, i cluster regionali, i control plane ad alta disponibilità e il supporto ibrido e multi-cloud con GKE Enterprise. Se decidi di utilizzare GKE o GKE Enterprise, puoi utilizzare Migrate to Containers per semplificare e accelerare la migrazione delle VM Windows ai container. Migrate to Containers automatizza l'estrazione delle applicazioni dalle VM ai container senza richiedere la riscrittura o la riprogettazione delle applicazioni.

Anche se puoi ottenere molti vantaggi utilizzando le funzionalità giuste in Compute Engine, il passaggio ai container e a GKE ti aiuta a utilizzare completamente le tue VM inserendo più pod nelle stesse VM. Questa strategia potrebbe comportare un numero inferiore di VM e costi di licenza Windows inferiori.

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

Fase 3: riprogettazione e ricostruzione

Il re-platforming è solo l'inizio per sfruttare appieno i vantaggi del cloud. La trasformazione dell'architettura in una piattaforma basata sul cloud offre diversi vantaggi, ad esempio:

Il passaggio ai servizi gestiti

Quando inizi a riscrivere parti della tua applicazione, ti consigliamo di passare dai servizi ospitati a quelli gestiti. Ad esempio, potresti utilizzare quanto segue:

Sebbene sia necessario codice aggiuntivo per integrare l'applicazione con questi servizi, si tratta di un investimento che vale la pena fare, perché il carico di gestione della piattaforma viene trasferito a Google Cloud. Le librerie client.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.Google Cloud

I servizi gestiti possono anche 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 di server e applicazioni. Google Cloud offre librerie client .NET per Cloud Logging, Cloud Monitoring e Cloud Trace.

.NET e container Linux

Se la tua applicazione è un'applicazione .NET Framework legacy che viene eseguita solo su Windows, potresti essere tentato di mantenerla in esecuzione su un server Windows su Compute Engine o in un container Windows Server su GKE. Anche se questo approccio potrebbe funzionare nel breve termine, può limitarti notevolmente nel lungo termine. Windows prevede costi di licenza e un footprint delle risorse complessivamente più ampio rispetto a Linux. Questi fattori possono comportare un costo di proprietà più elevato a lungo termine.

.NET è la versione moderna e modulare di .NET Framework. Sebbene Microsoft preveda di supportare .NET Framework, le nuove funzionalità verranno aggiunte solo a .NET (e infine a .NET 5). Anche se vuoi continuare a utilizzare Windows, qualsiasi nuovo sviluppo deve avvenire su .NET.

Uno degli aspetti più importanti di .NET è che è multipiattaforma. Puoi containerizzare un'applicazione .NET in un contenitore 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 di licenza associati.

Porting delle applicazioni .NET Framework a .NET

Un buon modo per iniziare a passare a .NET è leggere la Panoramica del porting da .NET Framework a .NET. Strumenti come .NET Portability Analyzer e .NET API Analyzer possono aiutarti a determinare se gli assembly e le API sono portabili. Possono essere utili altri strumenti di porting come dotnet try-convert.

Gli strumenti esterni possono aiutarti a identificare i problemi di compatibilità e a decidere quali componenti migrare per primi. Alla fine, devi creare progetti .NET, spostare gradualmente il codice .NET Framework nel nuovo progetto e correggere eventuali incompatibilità lungo il percorso. Prima di eseguire il porting del codice, è fondamentale implementare i test e poi testare la funzionalità dopo il porting. Ti consigliamo di utilizzare i test A/B per testare il codice precedente e quello nuovo. Con i test A/B, puoi mantenere in esecuzione la tua applicazione legacy indirizzando alcuni utenti alla nuova applicazione. Questo approccio ti 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 Cloud Service Mesh.

Trasformazione culturale

La trasformazione da .NET Framework e server Windows a .NET e container Linux non è solo tecnica. Questo cambiamento richiede una trasformazione culturale nella tua organizzazione. Il personale abituato ad ambienti solo Windows deve adattarsi a quelli multipiattaforma. Questa trasformazione culturale richiede tempo e budget per la formazione su .NET, Linux e strumenti per container come Docker e Kubernetes. Tuttavia, una trasformazione da un'organizzazione solo Windows a un'organizzazione multipiattaforma ti consente di accedere a un insieme più ampio di strumenti e competenze.

Decomposizione del monolite

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

  • Riscrivete l'intera applicazione in .NET?
  • Suddividi l'applicazione in servizi più piccoli e li scrivi in .NET?
  • Scrivi nuovi servizi solo in .NET?

Il modo in cui rispondi a queste domande deve tenere conto dei vantaggi, del tempo e dei costi associati a ogni approccio. È bene adottare un approccio equilibrato in cui non riscrivi tutto in una volta sola. In alternativa, puoi scrivere nuovi servizi. NET e suddividi il tuo monolite esistente in servizi più piccoli in .NET man mano che si presenta l'opportunità. I seguenti white paper possono aiutarti nella pianificazione:

Opzioni di deployment per i container .NET

Come Deployment delle app .NET su Google Cloud indica, hai diverse opzioni per il deployment dei container .NET su Google Cloud. Man mano che decostruisci la 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.

Rispondere alle seguenti domande può 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 di scalabilità? Se la tua applicazione ha periodi di inattività, le soluzioni serverless come Cloud Run possono offrire la possibilità dfare lo scale downà 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 l'utilizzo di un numero minimo di istanze su Cloud Run o GKE con scalabilità automatica.

Ti consigliamo di leggere la documentazione relativa a ogni ambiente di hosting per familiarizzare con le sue funzionalità, i suoi punti di forza e di debolezza e il modello di prezzi.

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

Cloud Run Functions è anche una buona opzione di deployment serverless, ma non viene trattata qui perché Cloud Run fornisce la maggior parte delle funzionalità offerte da Cloud Run Functions e Cloud Run Functions non supporta le versioni più recenti di .NET.

Kubernetes e GKE

Se vuoi eseguire in un ambiente ottimizzato per i container, questo approccio probabilmente coinvolge 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 su come vengono eseguiti il deployment e la gestione di ciascuno.

Kubernetes è progettato per eseguire container su larga scala e fornisce blocchi di costruzione come pod, servizi, deployment e set di repliche. Comprendere e utilizzare correttamente questi costrutti può essere difficile, ma ti consentono di trasferire la maggior parte dell'onere di gestione dei container a Kubernetes. Sono adatti anche 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, riparazione automatica e upgrade automatici per semplificare la gestione di Kubernetes e funzionalità di sicurezza come l'isolamento dei container e i registri privati. Sebbene ti venga addebitato un costo per ogni nodo del cluster in GKE, GKE supporta le VM prerilasciabili per ridurre i costi.

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

Knative e Cloud Run

Per i tuoi container .NET stateless, Knative e la sua versione gestita, Cloud Run, forniscono un ambiente serverless per i container. I container serverless offrono vantaggi come il provisioning, la scalabilità automatica e il 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 più piccola di 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, i container in Cloud Run vengono scalati automaticamente e fatturati per la durata della richiesta. Il tempo di deployment è espresso in secondi. Cloud Run fornisce anche funzionalità utili, come revisioni e suddivisione del traffico.

Knative serving è la versione più flessibile di Cloud Run che offre 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 o di scalare la tua applicazione a molti container.

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 scalati automaticamente sia per i microservizi interni attivati dagli eventi.

Modernizzazione delle operazioni

La modernizzazione non riguarda solo il codice dell'applicazione. Si applica all'intero ciclo di vita della tua applicazione: come viene creata, testata, implementata e monitorata. Pertanto, quando pensi alla modernizzazione, devi considerare le 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 lo scanner di vulnerabilità di Container Registry e con Autorizzazione binaria per impedire l'esecuzione nel tuo ambiente di deployment di immagini create da codice sorgente sconosciuto o da 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 saperne di più su come la modernizzazione si applica ai processi e alla cultura del team, consulta le Google Cloud soluzioni per DevOps.

Passaggi successivi