Percorso di modernizzazione per le applicazioni .NET su Google Cloud

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

Questo documento è rivolto a cloud architect, amministratori di sistema e CTO che hanno familiarità con Windows e l'ecosistema .NET e vogliono saperne di più su cosa comporta la modernizzazione. Anche se questo documento riguarda le applicazioni server personalizzate, ad esempio le applicazioni ASP.NET o Windows Services, puoi applicare le lezioni ad altri casi d'uso.

Applicazioni legacy e moderne: perché scegliere la modernizzazione?

Modernizzare le applicazioni legacy è un percorso. Il punto di partenza e di arrivo del viaggio, e i vantaggi che ottieni, dipendono in gran parte dallo stato delle tue applicazioni e dal tempo e dallo sforzo che puoi investire per modernizzare.

Nel contesto delle applicazioni .NET, cosa è legacy e cos'è moderno? Non è facile rispondere a questa domanda in modo esaustivo o definitivo. Ogni applicazione ha esigenze distinte di legacy e modernizzazione. 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 basate su cloud monolitiche e moderne.

Un'applicazione .NET legacy è in genere un monolith basato sul framework .NET, 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 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 di licenza associati alla dipendenza da Windows.
  • La difficoltà di eseguire l'upgrade di applicazioni legacy basate su un'architettura monolitica.
  • Poca agilità per pianificare, budget e scalabilità con le risorse on-premise.

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

  • Riduzione al minimo dell'overhead di gestione grazie all'integrazione con i servizi gestiti.
  • Mobilità completa con .NET Core e container, senza dipendenze di Windows o costi di licenza.
  • 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 con un'architettura serverless.

Rispetto all'approccio convenzionale on-premise, 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à per scegliere dove e quando 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 .NET legacy a un'architettura basata su cloud non segue un singolo pattern universale. Come mostra il seguente diagramma, la modernizzazione prevede una serie di passaggi, in cui ogni passaggio rimuove un limite, migliora le capacità dell'applicazione e apre opportunità per le fasi successive della modernizzazione.

Processi, tecnologie e servizi coinvolti nel processo di modernizzazione.

I passaggi per la modernizzazione sono raggruppati in tre fasi:

  1. Rehosting su cloud (noto anche come lift and shift)
  2. Replatforming
  3. Riprogetta e riprogetta

Valutazione e apprendimento pre-modernizzazione

Prima di modernizzarti, devi prepararti. Il primo passaggio consiste nella valutazione delle applicazioni e nelle loro dipendenze per determinare quali applicazioni sono adatte alla modernizzazione e quali non possono essere modificate o spostate (in genere per motivi legati alla precedente o alle normative). Per ulteriori informazioni, consulta Migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro.

Oltre 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 aiutarti a velocizzare il processo di apprendimento.

Dopo aver identificato le applicazioni da modernizzare, puoi iniziare a migrare le applicazioni convenzionali nel cloud così come sono o apportando modifiche minime al codice o alla configurazione dell'applicazione.

Fase 1: rehosting nel cloud

L'obiettivo principale di questa prima fase è trasferire l'onere della gestione del 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 in fasi successive.

Migrazione manuale e migrazione basata su strumenti

Il lift and shift delle applicazioni .NET basate su Windows inizia in genere spostando le istanze Windows Server e SQL Server on-premise sulle istanze di macchine virtuali (VM) 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 in 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 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 vai direttamente a Service gestito per Microsoft Active Directory.

Connettività on-premise e cloud

Quando esegui la migrazione delle VM al 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 requisiti di conformità e normativi locali. Hai bisogno di una VPN o di una soluzione di interconnessione per connettere in modo sicuro risorse cloud e on-premise. Per i vari modi per creare e gestire questa connessione, nonché per altre implicazioni dell'esecuzione di carichi di lavoro ibridi cloud e on-premise, consulta Migrazione a Google Cloud: creazione delle basi.

Vantaggi iniziali

Al termine della fase 1, hai 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 archiviazione) e pagare per ciò che utilizzi; avviare e arrestare VM e ambienti di ripristino di emergenza quando vuoi e pagare solo quando sono in esecuzione. Inoltre, puoi ricevere consigli relativi al dimensionamento ottimale prima della migrazione.
  • Maggiore efficienza operativa. Puoi collegare i dischi permanenti alle VM e creare snapshot per semplificare il backup e il ripristino.
  • Maggiore affidabilità. Non hai più bisogno di pianificare periodi di manutenzione a causa della funzionalità di migrazione live.

Questi vantaggi iniziali sono utili, ma ne vengono ottenuti altri quando inizi a ottimizzare 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 apportando modifiche minime al codebase. L'obiettivo della fase 2 è iniziare a utilizzare le funzionalità cloud per una migliore gestione, resilienza, scalabilità ed elasticità della tua applicazione senza ristrutturarla in modo significativo o senza uscire dall'ambiente VM.

Sfruttare il potenziale 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 dalle configurazioni delle 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 semplice bilanciamento del carico e alla ridondanza, i gruppi di istanze gestite dispongono di funzionalità di scalabilità come la scalabilità automatica, funzionalità ad alta disponibilità come la riparazione automatica, 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 le applicazioni.

Cerca sostituzioni in loco

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

  • Cloud SQL anziché SQL Server self-service, MySQL o Postgres. Cloud SQL ti consente di concentrarti sulla gestione del database anziché sulla gestione 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 rimuovere il requisito per una licenza Windows.
  • Servizio gestito per Microsoft Active Directory invece di Active Directory self-hosted.
  • Memorystore anziché istanze Redis self-hosted.

Queste sostituzioni non dovrebbero richiedere modifiche al codice e solo modifiche minime alla configurazione e offrono i vantaggi di una gestione minima, di una maggiore sicurezza e della 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 ti consentono di eseguire le applicazioni in vari ambienti e in modo più coerente, prevedibile ed efficiente (in particolare quando esegui più container sullo stesso host). L'ecosistema intorno ai container (come Kubernetes, Istio e Knative) offre inoltre una serie di funzionalità di gestione, resilienza e monitoraggio che possono accelerare la trasformazione della tua applicazione da un singolo monolite a un set di microservizi concentrati.

Per un certo periodo, la containerizzazione era una funzionalità solo per Linux. Le applicazioni Windows non potrebbero 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 se non vuoi eseguire la migrazione di applicazioni .NET Framework in .NET Core, ma vuoi comunque ottenere i vantaggi offerti dai container (come agilità, portabilità e controllo). A seconda della versione di .NET Framework devi scegliere il sistema operativo giusto come target e ricorda che non tutto lo stack di Windows è supportato sui container Windows. Per le limitazioni di questo approccio e delle alternative, consulta la sezione Container.NET Core 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 quando un pod di container è inattivo e ricrearlo, pod di scalabilità automatica, implementazioni o rollback automatizzati e controlli di integrità. GKE aggiunge funzionalità come scalabilità automatica dei cluster, cluster a livello di area geografica, piani di controllo a disponibilità elevata e supporto di cloud ibrido e multi-cloud con Anthos. Se decidi di utilizzare GKE o Anthos, 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 nei container senza che tu debba riscrivere o riprogettare le applicazioni.

Sebbene sia possibile ottenere molti vantaggi utilizzando le funzionalità giuste in Compute Engine, il passaggio ai container e a GKE ti aiuta a sfruttare appieno le tue VM pacchettizzando più pod sulle stesse VM. Questa strategia potrebbe comportare una riduzione del numero di VM e una riduzione dei costi di licenza di Windows.

La gestione dichiarativa dei container Windows e Linux con Kubernetes e GKE può anche semplificare la gestione della tua infrastruttura. Con la containerizzazione, il tuo team è pronto per la prossima fase di modernizzazione.

Fase 3: riprogettazione e ricostruzione

Il replatforming è solo l'inizio per trarre il massimo vantaggio dal cloud. La trasformazione della tua architettura in una piattaforma basata su cloud offre numerosi vantaggi, tra cui:

Il passaggio ai servizi gestiti

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

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

I servizi gestiti possono anche supportare le operazioni per la tua applicazione. Puoi archiviare i log dell'applicazione in Cloud Logging e inviare le tue 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.

Container .NET Core e Linux

Se la tua applicazione è un'applicazione .NET Framework legacy che viene eseguita solo su Windows, potresti essere tentata 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 a breve termine, può limitare seriamente a lungo termine. Su Windows sono incluse tariffe per la licenza e un ingombro delle risorse complessivo maggiore rispetto a Linux e questi fattori possono comportare un costo di proprietà più elevato nel lungo termine.

.NET Core è la versione moderna e modulare di .NET Framework. Le linee guida di Microsoft affermano che .NET Core è il futuro di .NET. Anche se Microsoft prevede di supportare .NET Framework, qualsiasi nuova funzionalità verrà aggiunta solo a .NET Core (ed eventualmente .NET 5). Anche se vuoi ancora eseguirlo su Windows, qualsiasi nuovo sviluppo dovrebbe avvenire su .NET Core.

Uno degli aspetti più importanti di .NET Core è il fatto che è multipiattaforma. Puoi containerizzare un'applicazione .NET Core 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 su Windows e dai costi di assegnazione relativi alle licenze.

Trasferimento delle applicazioni .NET Framework a .NET Core

Un buon modo per iniziare a utilizzare .NET Core è leggere la panoramica del trasferimento da .NET Framework a .NET Core. Strumenti come .NET Portability Analyzer e .NET API Analyzer possono aiutarti a determinare se assemblee e API sono portatili. Altri strumenti di trasferimento, come dotnet tentativo di conversione, possono essere utili.

Gli strumenti esterni possono aiutarti a identificare i problemi di compatibilità e a decidere per quali componenti eseguire la migrazione. Infine, dovrai creare i progetti .NET Core, spostare gradualmente il codice .NET Framework nel nuovo progetto e correggere eventuali incompatibilità. Prima di trasferire il codice, è fondamentale eseguire i test e verificare la tua funzionalità dopo il trasferimento. Consigliamo di utilizzare il test A/B per testare i codici vecchi e nuovi. Con i test A/B, puoi mantenere in esecuzione l'applicazione legacy indirizzando 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 Traffic Director.

Trasformazione culturale

La trasformazione da .NET Framework e server Windows a .NET Core e container 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 con strumenti .NET Core, Linux e container come Docker e Kubernetes. Tuttavia, una trasformazione da organizzazione solo Windows a organizzazione multipiattaforma ti consente di accedere a un più ampio insieme di strumenti e competenze.

Decomposizione del monolite

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

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

Come decidi che queste domande devono tenere conto dei vantaggi, del tempo e dei costi associati a ogni approccio. È bello avere un approccio equilibrato in cui non si possa riscrivere tutto insieme. Puoi invece scrivere nuovi servizi in. NET Core e suddividere il monolite esistente in servizi più piccoli in .NET Core quando si presenta l'opportunità. I seguenti white paper possono esserti utili per la tua pianificazione:

Opzioni di deployment per i container .NET Core

Come negli stati Deployment di app .NET su Google Cloud, hai a disposizione opzioni diverse per eseguire il deployment dei container .NET Core su Google Cloud. Quando scomponi la tua applicazione monolitica in microservizi, puoi decidere di utilizzare più di una soluzione di hosting, a seconda dell'architettura e della progettazione dei microservizi.

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

  • Cosa attiva l'applicazione? Tutte le soluzioni di hosting sono adatte per HTTP(S), 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. Cloud Run for Anthos 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à di fare lo scale down a zero.
  • Quanto è importante la latenza e la tolleranza alla tua applicazione per avvii a freddo? Se la tolleranza agli avvii completi è bassa, devi valutare l'utilizzo di un numero minimo di istanze su Cloud Run o GKE con scalabilità automatica.

Ti consigliamo di leggere la documentazione relativa a ciascun ambiente di hosting per acquisire familiarità con le sue capacità, i suoi punti di forza e di debolezza e il modello di prezzo.

Come regola generale, se vuoi creare microservizi per 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 è anche la scelta predefinita se hai un processo a lunga esecuzione, ad esempio un processo che rimane in ascolto in coda o un'applicazione che utilizza protocolli diversi da HTTP(S).

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

Kubernetes e GKE

Se vuoi eseguire un ambiente ottimizzato per i container, questo approccio probabilmente interessa 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 su come ogni deployment viene gestito e gestito.

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 complicato, ma consente di spostare la maggior parte del carico di lavoro per la gestione dei container in Kubernetes. Sono ideali anche per l'architettura di microservizi, in cui un microservizio è un deployment con un set 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, nonché funzionalità di sicurezza come l'isolamento dei container e i registry privati. Anche se ti viene addebitato un costo per ogni nodo nel cluster in GKE, GKE supporta le VM prerilasciabili per ridurre i costi.

GKE può gestire sia container Windows che 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 container stateless .NET Core, 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 overhead per la gestione dell'infrastruttura.

Per il deployment di container in un cluster Kubernetes, Knative fornisce una piattaforma API di livello superiore e inferiore rispetto a Kubernetes. Knative può quindi aiutarvi a evitare le complessità di Kubernetes, semplificando il deployment del 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 è in secondi. Cloud Run fornisce inoltre funzionalità utili, come le revisioni e la suddivisione del traffico.

Cloud Run for Anthos è 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 Anthos consente di aggiungere GPU alle istanze sottostanti che eseguono i container o di fare lo scale up dell'applicazione in 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 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 della tua applicazione, ovvero alla sua creazione, test, deployment e monitoraggio. Pertanto, quando pensi alla modernizzazione, devi considerare le operazioni.

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

La suite operativa di Google Cloud (in precedenza Stackdriver) offre diversi servizi che consentono di modernizzare l'osservabilità dell'applicazione:

Puoi utilizzare la libreria Google.Cloud.Diagnostics.AspNetCore per un'integrazione semplice della suite operativa di Google Cloud nelle applicazioni ASP.NET Core. Per esportare le metriche OpenTelemetry nella suite operativa, puoi utilizzare la libreria delle operazioni suite OpenTelemetry.Exporter.Google Cloud.

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

Passaggi successivi