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 modernizzarli.

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ù di cosa implica la modernizzazione. Sebbene questo documento sia incentrato applicazioni server personalizzate (come ASP.NET o Windows Services applicazioni), puoi applicare le lezioni ad altri casi d'uso.

Applicazioni legacy e moderne: perché modernizzare?

La modernizzazione delle applicazioni legacy è un viaggio. L'inizio e la fine di un percorso di acquisto e i vantaggi che ottieni, dipendono in gran parte dallo stato applicazioni e il tempo e gli sforzi che puoi investire per modernizzare.

Nel contesto delle applicazioni .NET Framework, i concetti di legacy e moderni non sono definitivi. Ogni applicazione ha caratteristiche legacy e modernizzazione distinte e alle esigenze aziendali. Tuttavia, le applicazioni legacy hanno alcuni limiti comuni.

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

Differenze tra basato su cloud monolitico e moderno diverse applicazioni.

Un'applicazione .NET Framework legacy è in genere un monolite basato su .NET Framework, ospitato su un sistema operativo e connesso a un server on-premise che esegue Microsoft SQL Server. La 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 implementazione limitati e i costi delle licenze associati la 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 e nessuna dipendenza Windows, o costi di licenza.
  • Un percorso di upgrade ad alta velocità basato su deployment indipendenti di microservizi.
  • Piena agilità per la scalabilità e il budget grazie a un'architettura serverless.

Rispetto al convenzionale approccio on-premise, l'architettura cloud offre una più economica, efficiente e resiliente per eseguire le tue applicazioni. In un basato su cloud, offre maggiore flessibilità nella scelta di dove e quando il deployment delle tue applicazioni.

Percorso di modernizzazione

Sebbene i vantaggi di un'architettura basata su cloud siano evidenti, il percorso verso potrebbe non esserlo. Modernizzazione da un'architettura .NET Framework legacy a basata su cloud non segue un unico modello universale. Come il seguente diagramma mostra che la modernizzazione prevede una serie di passaggi, in cui ogni passaggio rimuove un limite, aumenta le capacità dell'applicazione e apre per le fasi successive della modernizzazione.

Processi, tecnologie e servizi coinvolti nella modernizzazione e il processo di sviluppo.

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 è valutare le applicazioni e le loro dipendenze per determinare le applicazioni sono adatte alla modernizzazione e non possono cambiare o spostare (in genere per motivi normativi o relativi alla versione precedente). Per ulteriori informazioni le 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 specifiche per Windows e .NET codelabs che possono accelerare il processo di apprendimento.

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

Fase 1: rehosting nel cloud

L'obiettivo principale di questa prima fase è trasferire l'onere del server dalla gestione delle risorse on-premise all'infrastruttura cloud. In questo assicuratevi che l'infrastruttura sia pronta per il cloud, 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 spostando da istanze Windows Server e SQL Server on-premise alla Compute Engine virtuale di Compute Engine (VM). Puoi eseguire questa procedura manualmente o automatizzarla con l'aiuto di uno strumento di migrazione.

Con una migrazione manuale puoi usare Compute Engine Immagini Windows Server per avviare le istanze. Google Cloud Marketplace offre anche soluzioni pronte per il deployment su Compute Engine, come Soluzione ASP.NET Framework per ottenere una VM Windows Server che includa IIS, SQL Express e ASP.NET.

Analogamente, puoi avviare istanze SQL Server Immagini SQL Server, In alternativa, puoi andare direttamente a un Cloud SQL per SQL Server.

Google Cloud offre anche strumenti di migrazione come Eseguire la migrazione alle 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 creare nuove istanze on demand. Questo passaggio è importante anche modelli, che verranno discussi più avanti nel documento.

Se hai bisogno di servizi di dominio nel cloud, puoi eseguire il deployment Ambiente Microsoft Active Directory a tolleranza di errore su Compute Engine con un VPC (Virtual Private Cloud) o andare direttamente Servizio gestito 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 legacy o software oppure quando devi soddisfare i requisiti di conformità e i tuoi requisiti. Per connetterti in modo sicuro, è necessaria una VPN o una soluzione di interconnessione risorse on-premise e cloud. Per conoscere i vari modi per creare e gestire connessione, oltre ad altre implicazioni dell'esecuzione di cloud ibridi per carichi di lavoro on-premise, vedi Migrazione a Google Cloud: creare le basi.

Vantaggi iniziali

Alla fine 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 paghi per ciò che utilizzi. avviare e arrestare le VM gli ambienti di ripristino di emergenza a proprio piacimento e pagano solo quando sono in esecuzione; e otterrai consigli relativi al dimensionamento ottimale prima della migrazione.
  • Maggiore efficienza operativa. Puoi collegare i dischi permanenti VM e creazione di snapshot per semplificare il backup e il ripristino.
  • Maggiore affidabilità. Non è più necessario pianificare la manutenzione a causa degli migrazione live funzionalità.

Questi vantaggi iniziali sono utili, ma puoi ottenere altri vantaggi quando per iniziare l'ottimizzazione per il cloud.

Fase 2: replatforming

Quando esegui il replatforming, ottimizzi la tua applicazione eseguendo l'upgrade di parti dell'applicazione, come il database, il livello di memorizzazione nella cache o l'archiviazione sistema, senza modificare l'architettura dell'applicazione e con il minimo modifiche al codebase. L'obiettivo della fase 2 è iniziare a utilizzare il cloud per migliorare la gestione, la resilienza, la scalabilità e l'elasticità del senza doverla ristrutturare o lasciare la VM completamente gestito di Google Cloud.

Sfrutta i vantaggi di Compute Engine

Compute Engine offre alcune funzionalità standard utili esplora. Ad esempio, puoi utilizzare modelli di istanze in Compute Engine per creare modelli dalle configurazioni VM esistenti. Gruppi di istanze un parco risorse di VM identiche che ti consentono di scalare e ridondanza delle risorse. Oltre al semplice bilanciamento del carico e ridondanza, I gruppi di istanze hanno funzionalità di scalabilità, come scalabilità automatica, disponibilità funzionalità come riparazione automatica, deployment a livello di regione, e le funzionalità di sicurezza, come aggiornamento automatico.

Con queste funzionalità, puoi rimanere nel mondo delle VM, ma aumentare la resilienza, ridondanza e disponibilità delle applicazioni senza la necessità di ristrutturarle completamente la tua applicazione.

Cerca sostituzioni in loco

Quando sposti la tua applicazione nel cloud, devi cercare opportunità di sostituire l'infrastruttura in hosting con le opzioni cloud gestite di Google e partner terzi su Cloud Marketplace tra cui:

  • Cloud SQL anziché SQL Server, MySQL o Postgres con hosting autonomo. Cloud SQL ti consente ci si concentra sulla gestione del database invece che sulla gestione dell'infrastruttura (ad esempio l'applicazione di patch alle VM dei database per la sicurezza o la gestione dei backup) il vantaggio aggiuntivo di rimuovere il requisito della licenza Windows.
  • Servizio gestito per Microsoft Active Directory anziché l'Active Directory in hosting autonomo.
  • Memorystore anziché istanze Redis ospitate autonomamente.

Queste sostituzioni non dovrebbero richiedere la modifica del codice e richiede solo un intervento minimo. modifiche alla configurazione e presentano i vantaggi di una gestione, sicurezza e scalabilità avanzate.

Primi passi con i container Windows

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

Un container è un pacchetto leggero che contiene un'applicazione e tutti i suoi delle dipendenze. Rispetto all'esecuzione dell'applicazione direttamente su una VM, i container di eseguire le tue applicazioni in vari ambienti e in modo più prevedibile ed efficiente (soprattutto quando esegui più container lo stesso host). L'ecosistema dedicato ai container, come Kubernetes, Istio Knative) offre anche vari strumenti di gestione, resilienza di funzionalità di monitoraggio che possono accelerare ulteriormente da un singolo monolite a un insieme di microservizi mirati.

Per un certo periodo, la containerizzazione è stata una funzionalità solo di Linux. Applicazioni Windows non potrebbero trarre vantaggio dai container. Il problema è cambiato con i container Windows le loro successive in Kubernetes e Google Kubernetes Engine (GKE)

I container Windows sono un'opzione se non vuoi eseguire la migrazione di .NET Framework le tue applicazioni a .NET, ma che vogliono comunque i vantaggi dei container (come agilità, portabilità e controllo). Devi scegliere il sistema operativo giusto per il targeting a seconda della versione di .NET Framework, non tutto lo stack Windows è supportato dei container Windows. Per i limiti 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 un container, ti consigliamo di eseguirlo in un cluster Kubernetes. Kubernetes Fornisce funzionalità standard come il rilevamento quando un pod di container è inattivo ricrearlo, scalare automaticamente i pod, le implementazioni o i rollback automatizzati e l'integrità controlli. GKE aggiunge funzionalità come scalabilità automatica cluster regionali, piani di controllo a disponibilità elevata e supporto di ambienti ibridi 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 nei container. Migrate to Containers automatizza l'estrazione delle applicazioni dalle VM ai container senza dover riscrivere o riprogettare le applicazioni.

Sebbene si possa ottenere molti vantaggi utilizzando le funzionalità giuste in Compute Engine, il passaggio ai container e a GKE puoi utilizzare completamente le tue VM pacchettizzando più pod nelle stesse VM. Questo di strategia, può portare a un minor numero di VM e a costi di licenza di Windows inferiori.

Gestione dichiarativa sia dei container Windows che di Linux con Kubernetes e GKE può anche semplificare la gestione dell'infrastruttura. Con la containerizzazione, il tuo team è pronto per la fase successiva 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 diverse vantaggi, come i seguenti:

Il passaggio ai servizi gestiti

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

Sebbene sia necessario codice aggiuntivo per integrare l'applicazione con di Google Cloud, è un investimento conveniente, perché la gestione della piattaforma a Google Cloud. Librerie Google Cloud per .NET, Strumenti per Visual Studio, e Cloud Code per Visual Studio Code può aiutarti a rimanere nell'ecosistema e negli strumenti .NET mentre integrare con questi servizi.

I servizi gestiti possono inoltre supportare le operazioni per la tua applicazione. Puoi archivia i log delle tue applicazioni in Cloud Logging e invia la tua applicazione le metriche a Cloud Monitoring, dove puoi creare dashboard con dati metriche dell'applicazione. 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 Windows, potresti volerlo mantenere in esecuzione su un server Windows su in Compute Engine o in un container Windows Server con GKE. Sebbene questo approccio possa funzionare a breve termine, può limitare notevolmente il tuo rendimento nel lungo periodo. Windows include le tariffe per la licenza e un utilizzo delle risorse complessivo maggiore rispetto a Linux, e questi fattori possono comportano un costo di proprietà più elevato sul lungo periodo.

Uno degli aspetti più importanti di .NET è che è multipiattaforma. Tu può containerizzare un'applicazione .NET in un container Linux. Linux sono più leggeri di quelli Windows e vengono eseguiti su piattaforme in modo più efficiente. Questo fattore crea opzioni di deployment per .NET ed eliminare le dipendenze su Windows e i costi di licenza associati.

Portare le applicazioni da .NET Framework a .NET

Un buon modo per iniziare a passare a .NET è leggere Panoramica della portabilità da .NET Framework a .NET. Strumenti come Analizzatore portabilità.NET e Strumento di analisi della compatibilità delle piattaforme può aiutarti a determinare se gli assembli e le API sono portabili. Altri strumenti di portabilità come prova con conversione dotnet può essere utile.

Gli strumenti esterni possono aiutarti a identificare i problemi di compatibilità e a decidere quali di cui eseguire la migrazione. Infine, devi creare progetti .NET, spostare gradualmente il codice .NET Framework nel nuovo progetto e correggere incompatibilità lungo il percorso. Prima di trasferire il codice, è fondamentale porre i test in corso e poi testare la funzionalità dopo il trasferimento. È consigliabile usi Test A/B per testare codice vecchio e nuovo. Con i test A/B, puoi mantenere la tua applicazione legacy mentre indirizzerai alcuni utenti alla nuova applicazione. Questo approccio consente di testare gli output, la scalabilità e la resilienza della nuova applicazione. Per supportare i test A/B, Google Cloud offre soluzioni di bilanciamento del carico come Bilanciatore del carico delle applicazioni esterno globale.

Trasformazione culturale

La trasformazione da .NET Framework e Windows Server a .NET e I container Linux non sono solo tecnici. Questo cambiamento richiede nella tua organizzazione. Personale abituato soltanto agli utenti Windows ambienti multipiattaforma devono adattarsi. Questo percorso culturale la trasformazione richiede tempo e budget per l'addestramento in .NET, Linux di container come Docker e Kubernetes. Tuttavia, una trasformazione da una Solo Windows in 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 .NET?
  • Scrivi nuovi servizi solo in .NET?

Nel considerare queste domande, tenete conto dei vantaggi, del tempo e associati ai costi associati a ciascun approccio. È positivo avere un approccio equilibrato in cui non si riscrive tutto in una volta. Puoi invece scrivere nuovi servizi in .NET e suddividi il monolite esistente in servizi più piccoli in .NET man mano che si presenta l'opportunità. In base alla pianificazione, i seguenti documenti possono essere utili:

Opzioni di deployment per i container .NET

Come Deployment di app .NET su Google Cloud esistono diverse opzioni per il deployment di container .NET in Google Cloud. Quando scomponi la tua applicazione monolitica di microservizi, potresti decidere di usare più di una soluzione di hosting, a seconda sull'architettura e sulla progettazione dei tuoi microservizi.

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

  • Che cosa attiva la tua applicazione? Sono idonee tutte le soluzioni di hosting per HTTP(S) standard, ma se il protocollo è TCP/UDP o un protocollo 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 più 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 offrono 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 è basso, devi prendere in considerazione una delle seguenti opzioni:

Ti consigliamo di leggere la documentazione relativa a ciascun ambiente di hosting per a conoscere le sue capacità, i suoi punti forti e i suoi punti deboli e il modello di determinazione del prezzo.

Come regola generale, per creare microservizi che gestiscono richieste HTTP, devi eseguire il deployment in Cloud Run quando possibile e poi se vuoi rimanere nell'ecosistema Kubernetes sono necessarie più opzioni di personalizzazione. GKE è l'ambiente predefinito se hai un processo di lunga durata, ad esempio un processo che ascolta su una o un'applicazione che utilizza protocolli diversi da HTTP(S).

Anche Cloud Functions è una buona opzione di deployment serverless, 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 le operazioni in un ambiente ottimizzato per i container, è probabile che questo approccio riguarda Kubernetes e la sua versione gestita, GKE Kubernetes e GKE sono particolarmente adatti se prevedi eseguire il deployment di molti container con requisiti diversi e avere un controllo granulare sul deployment e sulla gestione di ognuna.

Kubernetes è progettato per eseguire container su larga scala e fornisce i componenti di base come pod, servizi, deployment e set di repliche. Comprensione corretta e l'utilizzo di questi costrutti può essere impegnativo, ma ti consentono di il carico della gestione dei container su Kubernetes. Sono inoltre adatte a in cui un microservizio è un deployment con una serie con bilanciamento del carico dietro un servizio.

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

GKE può gestire container sia Windows che Linux. Questo è utile se si desidera mantenere un unico ambiente ibrido basate su Windows e sulle moderne applicazioni basate su Linux.

Knative e Cloud Run

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

Per eseguire il deployment di container in un cluster Kubernetes, Knative fornisce una superficie API di livello superiore e minore 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 dell'infrastruttura Google, eliminando così la necessità di cluster Kubernetes. Cloud Run offre un'opzione serverless per i container. Per impostazione predefinita in Cloud Run, viene applicata la scalabilità automatica dei container e vengono addebitati i costi durata della richiesta. Il tempo di deployment è in secondi. Cloud Run offre inoltre funzionalità utili, come revisioni e suddivisione del traffico.

Knative serving è la versione più flessibile di Cloud Run per i clienti vuoi 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 di container o consente di accedere ad altre VM o cluster GKE sullo stesso VPC.

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

Modernizzazione delle operazioni

La modernizzazione non riguarda solo il codice dell'applicazione. Si applica all'insieme ciclo di vita della tua applicazione: come viene creata, testata, sottoposta a deployment monitorati. Pertanto, quando si pensa alla modernizzazione, occorre considerare operations.

Cloud Build può aiutarti a modernizzare e automatizzare il ciclo di build, test e deployment della tua applicazione. Cloud Build non fornisce solo builder per .NET, Cloud Build si integra inoltre con Analisi delle vulnerabilità e con Autorizzazione binaria per impedire immagini create a partire da codice sorgente sconosciuto o non l'esecuzione di repository nell'ambiente di deployment.

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

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

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

Passaggi successivi