Condividi tramite

Eseguire la migrazione del carico di lavoro da Service Fabric al servizio Azure Kubernetes

  • Articolo

Molte organizzazioni passano alle app in contenitori come parte di un push verso l'adozione di moderne procedure consigliate per lo sviluppo di app, le procedure consigliate per la manutenzione e le architetture native del cloud. Poiché le tecnologie continuano a evolversi, le organizzazioni devono valutare le numerose piattaforme app in contenitori disponibili nel cloud pubblico.

Non esiste alcuna soluzione adatta alle dimensioni per le app, ma le organizzazioni spesso trovano che servizio Azure Kubernetes (AKS) soddisfi i requisiti per molte delle applicazioni in contenitori. Il servizio Azure Kubernetes è un servizio Kubernetes gestito che semplifica le distribuzioni di applicazioni tramite Kubernetes gestendo il piano di controllo per fornire servizi di base per i carichi di lavoro delle applicazioni. Molte organizzazioni usano il servizio Azure Kubernetes come piattaforma di infrastruttura primaria e passano i carichi di lavoro ospitati in altre piattaforme al servizio Azure Kubernetes.

Questo articolo descrive come eseguire la migrazione di app in contenitori da Azure Service Fabric al servizio Azure Kubernetes. L'articolo presuppone che si abbia familiarità con Service Fabric, ma si è interessati a conoscere il modo in cui le funzionalità e le funzionalità vengono confrontate con quelle del servizio Azure Kubernetes. L'articolo fornisce anche procedure consigliate da considerare durante la migrazione.

Confronto tra servizio Azure Kubernetes e Service Fabric

Per iniziare, vedere Scegliere un servizio di calcolo di Azure insieme ad altri servizi di calcolo di Azure. In questa sezione vengono evidenziate le analogie e le differenze rilevanti per la migrazione.

Service Fabric e servizio Azure Kubernetes sono agenti di orchestrazione dei contenitori. Service Fabric offre supporto per diversi modelli di programmazione, ma il servizio Azure Kubernetes supporta solo i contenitori.

  • Modelli di programmazione: Service Fabric supporta diversi modi per scrivere e gestire i servizi, tra cui contenitori Linux e Windows, Reliable Services, Reliable Actors, ASP.NET Core ed eseguibili guest.

  • Contenitori nel servizio Azure Kubernetes: il servizio Azure Kubernetes supporta solo la containerizzazione con contenitori Windows e Linux eseguiti nel contenitore di runtime del contenitore, che viene gestito automaticamente.

Sia Service Fabric che il servizio Azure Kubernetes forniscono integrazioni con altri servizi di Azure, tra cui Azure Pipelines, Monitoraggio di Azure, Azure Key Vault e Microsoft Entra ID.

Differenze principali

Quando si distribuisce un cluster di Service Fabric tradizionale, anziché un cluster gestito, è necessario definire in modo esplicito una risorsa cluster insieme a molte risorse di supporto nei modelli di Azure Resource Manager (modelli arm) o nei moduli Bicep. Queste risorse includono un set di scalabilità di macchine virtuali per ogni tipo di nodo del cluster, gruppi di sicurezza di rete e servizi di bilanciamento del carico. È responsabilità dell'utente assicurarsi che queste risorse siano configurate correttamente. Al contrario, il modello di incapsulamento per i cluster gestiti di Service Fabric è costituito da una singola risorsa cluster gestita. Tutte le risorse sottostanti per il cluster vengono astratte e gestite da Azure.

Il servizio Azure Kubernetes semplifica la distribuzione di un cluster Kubernetes gestito in Azure eseguendo l'offload del sovraccarico operativo in Azure. Poiché il servizio Azure Kubernetes è un servizio Kubernetes ospitato, Azure gestisce attività critiche come il monitoraggio e la manutenzione dell'infrastruttura. Azure gestisce i nodi master Kubernetes, quindi è sufficiente gestire e gestire i nodi dell'agente.

Per spostare il carico di lavoro da Service Fabric al servizio Azure Kubernetes, è necessario comprendere le differenze nell'infrastruttura sottostante in modo da poter eseguire la migrazione sicura delle applicazioni in contenitori. Nella tabella seguente vengono confrontate le funzionalità e le funzionalità delle due piattaforme di hosting.

Funzionalità o componente Service Fabric servizio Azure Kubernetes
Applicazioni non incluse in contenitori Sì No
Contenitori Linux e Windows Sì Sì
Piano di controllo gestito da Azure No Sì
Supporto per carichi di lavoro senza stato e con stato Sì Sì
Posizionamento dei nodi di lavoro set di scalabilità di macchine virtuali, configurato dal cliente set di scalabilità di macchine virtuali, gestito da Azure
Manifesto della configurazione XML YAML
Integrazione di Monitoraggio di Azure Sì Sì
Supporto nativo per Reliable Services e modello Reliable Actor Sì No
Stack di comunicazione basato su WCF per Reliable Services Sì No
Archiviazione permanente Driver di volume di File di Azure Supporto per vari sistemi di archiviazione, ad esempio dischi gestiti, File di Azure e Archiviazione BLOB di Azure tramite classi di archiviazione CSI, volumi persistenti e attestazioni di volume persistente
Modalità di rete Integrazione di Rete virtuale di Azure Supporto per più plug-in di rete (Azure CNI, kubenet, BYOCNI), criteri di rete (Azure, Calico) e controller di ingresso (gateway applicazione Controller di ingresso, NGINX e altro ancora)
Controller di ingresso Proxy inverso integrato in Service Fabric. Consente ai microservizi eseguiti in un cluster di Service Fabric di individuare e comunicare con altri servizi con endpoint HTTP. È anche possibile usare Traefik in Service Fabric Controller di ingresso NGINX gestito, controller di ingresso BYO open source e controller commerciali che usano servizi di bilanciamento del carico pubblico o interno gestiti dalla piattaforma, ad esempio controller di ingresso NGINX e controller di ingresso gateway applicazione controller di ingresso

Nota

Se si usano contenitori Windows in Service Fabric, è consigliabile usarli nel servizio Azure Kubernetes per semplificare la migrazione.

Passaggi per la migrazione

In generale, i passaggi di migrazione da Service Fabric al servizio Azure Kubernetes sono i seguenti.

Diagramma che mostra i passaggi di migrazione da Service Fabric al servizio Azure Kubernetes.

  1. Stabilire l'architettura di distribuzione e creare il cluster del servizio Azure Kubernetes. Il servizio Azure Kubernetes offre varie opzioni per configurare l'accesso al cluster, la scalabilità dei nodi e dei pod, l'accesso alla rete e la configurazione e altro ancora. Per altre informazioni su un'architettura di distribuzione tipica, vedere Architettura di esempio. L'architettura di base del servizio Azure Kubernetes fornisce anche linee guida per la distribuzione e il monitoraggio del cluster. La costruzione del servizio Azure Kubernetes fornisce modelli di avvio rapido per la distribuzione del cluster del servizio Azure Kubernetes in base ai requisiti aziendali e tecnici.

  2. Riprogettare l'applicazione di Service Fabric. Se si usano modelli di programmazione come Reliable Services o Reliable Actors o se si usano altri costrutti specifici di Service Fabric, potrebbe essere necessario riprogettare l'applicazione. Per implementare la gestione dello stato quando si esegue la migrazione da Reliable Services, usare Distributed Application Runtime (Dapr).To implement state management when you migrate from Reliable Services, use Distributed Application Runtime (Dapr). Kubernetes fornisce modelli ed esempi per la migrazione da Reliable Actors.

  3. Creare il pacchetto dell'applicazione come contenitori. Visual Studio offre opzioni per generare il Dockerfile e creare un pacchetto dell'applicazione come contenitori. Eseguire il push delle immagini del contenitore create per Registro Azure Container.

  4. Riscrivere i file XML di configurazione di Service Fabric come file YAML di Kubernetes. L'applicazione viene distribuita nel servizio Azure Kubernetes usando file YAML o come pacchetto usando grafici Helm. Per altre informazioni, vedere Manifesto dell'applicazione e del servizio.

  5. Distribuire l'applicazione nel cluster del servizio Azure Kubernetes.

  6. Spostare il traffico nel cluster del servizio Azure Kubernetes in base alle strategie di distribuzione e monitorare il comportamento, la disponibilità e le prestazioni dell'applicazione.

Architettura di esempio

Il servizio Azure Kubernetes e Azure offrono flessibilità per configurare l'ambiente in base alle esigenze aziendali. Il servizio Azure Kubernetes è ben integrato con altri servizi di Azure. L'architettura di base del servizio Azure Kubernetes è un esempio.

Diagramma che mostra un'architettura del servizio Azure Kubernetes di base.

Come punto di partenza, acquisire familiarità con alcuni concetti chiave di Kubernetes e quindi esaminare alcune architetture di esempio:

Nota

Quando si esegue la migrazione di un carico di lavoro da Service Fabric al servizio Azure Kubernetes, è possibile sostituire Service Fabric Reliable Actors con il blocco predefinito dapr actors . È possibile sostituire Service Fabric Reliable Collections con il blocco predefinito di gestione dello stato Dapr.

Dapr fornisce API che semplificano la connettività dei microservizi. Per altre informazioni, vedere Introduzione a Dapr. È consigliabile installare Dapr come estensione del servizio Azure Kubernetes.

Manifesto dell'applicazione e del servizio

Service Fabric e servizio Azure Kubernetes hanno diversi tipi e costrutti di file manifesto del servizio e applicazioni. Service Fabric usa file XML per la definizione dell'applicazione e del servizio. Il servizio Azure Kubernetes usa il manifesto del file YAML di Kubernetes per definire oggetti Kubernetes. Non sono disponibili strumenti appositamente progettati per eseguire la migrazione di un file XML di Service Fabric a un file YAML kubernetes. È tuttavia possibile ottenere informazioni sul funzionamento dei file YAML in Kubernetes esaminando le risorse seguenti.

È possibile usare Helm per definire manifesti YAML con parametri e creare modelli generici sostituendo valori statici hardcoded con segnaposto che è possibile sostituire con valori personalizzati forniti in fase di distribuzione. I modelli risultanti che contengono i valori personalizzati vengono visualizzati come manifesti validi per Kubernetes.

Kustomize introduce un modo senza modello per personalizzare la configurazione dell'applicazione che semplifica l'uso di applicazioni non aggiornate. È possibile usare Kustomize insieme a Helm o come alternativa a Helm.

Per altre informazioni su Helm e Kustomize, vedere le risorse seguenti:

Rete

Il servizio Azure Kubernetes offre due opzioni per la rete sottostante:

  • Portare la propria rete virtuale di Azure per effettuare il provisioning dei nodi del cluster del servizio Azure Kubernetes in una subnet da una rete virtuale fornita.

  • Consentire al provider di risorse del servizio Azure Kubernetes di creare automaticamente una nuova rete virtuale di Azure nel gruppo di risorse del nodo che contiene tutte le risorse di Azure usate da un cluster.

Se si sceglie la seconda opzione, Azure gestisce la rete virtuale.

Service Fabric non offre una scelta di plug-in di rete. Se si usa il servizio Azure Kubernetes, è necessario scegliere una delle opzioni seguenti:

  • kubenet. Se si usa kubenet, i nodi ottengono un indirizzo IP dalla subnet della rete virtuale di Azure. I pod ricevono un indirizzo IP da uno spazio indirizzi diverso logicamente da quello della subnet di rete virtuale di Azure dei nodi. Viene poi configurato il protocollo NAT (Network Address Translation) in modo che i pod possano raggiungere le risorse nella rete virtuale di Azure. L'indirizzo IP di origine del traffico viene convertito tramite NAT all'indirizzo IP primario del nodo. Questo approccio riduce significativamente il numero di indirizzi IP che è necessario riservare nello spazio di rete per i pod da usare.

  • Azure CNI. Se si usa l'interfaccia CNI (Container Networking Interface), ogni pod ottiene un indirizzo IP dalla subnet e può essere accessibile direttamente. Questi indirizzi IP devono essere univoci nello spazio di indirizzi della rete e devono essere pianificati in anticipo. Ogni nodo ha un parametro di configurazione per il numero massimo di pod che supporta. Si riserva quindi il numero equivalente di indirizzi IP per ogni nodo. Questo approccio richiede una pianificazione maggiore e spesso comporta l'esaurimento degli indirizzi IP o la necessità di ricompilare i cluster in una subnet più grande man mano che le esigenze dell'applicazione aumentano. È possibile configurare il numero massimo di pod distribuibili in un nodo quando si crea il cluster o quando si creano nuovi pool di nodi.

  • Rete di sovrimpressione CNI di Azure. Se si usa la sovrimpressione CNI di Azure, i nodi del cluster vengono distribuiti in una subnet di Azure Rete virtuale. I pod vengono assegnati indirizzi IP da un CIDR privato che sono logicamente diversi dall'indirizzo della rete virtuale che ospita i nodi. Il traffico di pod e nodi all'interno del cluster usa una rete di sovrapposizione. NAT usa l'indirizzo IP del nodo per raggiungere le risorse all'esterno del cluster. Questa soluzione consente di risparmiare un numero significativo di indirizzi IP di rete virtuale e di ridimensionare facilmente il cluster in dimensioni elevate. Un ulteriore vantaggio è che è possibile riutilizzare il CIDR privato in cluster del servizio Azure Kubernetes diversi, estendendo lo spazio IP disponibile per le applicazioni in contenitori nel servizio Azure Kubernetes.

  • Azure CNI con tecnologia Cilium. Azure CNI Powered by Cilium combina il solido piano di controllo di Azure CNI con il piano dati di Cilium per offrire funzionalità di rete ad alte prestazioni e sicurezza avanzata.

  • Porta il tuo plug-in CNI. Kubernetes non offre un sistema di interfaccia di rete per impostazione predefinita. Questa funzionalità viene fornita dai plug-in di rete. Il servizio Azure Kubernetes offre diversi plug-in CNI supportati. Per altre informazioni sui plug-in supportati, vedere Concetti di rete per le applicazioni nel servizio Azure Kubernetes.

I contenitori di Windows attualmente supportano solo il plug-in Azure CNI . Sono disponibili varie opzioni per i criteri di rete e i controller di ingresso.

Nel servizio Azure Kubernetes è possibile usare i criteri di rete kubernetes per separare e proteggere le comunicazioni all'interno del servizio controllando quali componenti possono comunicare tra loro. Per impostazione predefinita, tutti i pod in Kubernetes possono inviare e ricevere traffico senza limitazioni. Per migliorare la sicurezza, è possibile usare i criteri di rete di Azure o i criteri di rete Calico per definire regole che controllano il flusso di traffico tra microservizi.

Se si vuole usare Gestione criteri di rete di Azure, è necessario usare il plug-in Azure CNI. È possibile usare i criteri di rete Calico con il plug-in Azure CNI o il plug-in kubenet CNI. L'uso di Gestione criteri di rete di Azure per i nodi Windows è supportato solo in Windows Server 2022. Per altre informazioni, vedere Proteggere il traffico tra i pod usando criteri di rete nel servizio Azure Kubernetes. Per altre informazioni sulla rete del servizio Azure Kubernetes, vedere Rete nel servizio Azure Kubernetes.

In Kubernetes un controller di ingresso funge da proxy del servizio e intermediario tra un servizio e l'esterno, consentendo al traffico esterno di accedere al servizio. Il proxy del servizio offre in genere varie funzionalità, ad esempio la terminazione TLS, il routing delle richieste basate sul percorso, il bilanciamento del carico e le funzionalità di sicurezza, ad esempio l'autenticazione e l'autorizzazione. I controller di ingresso forniscono anche un altro livello di astrazione e controllo per il routing del traffico esterno ai servizi Kubernetes in base alle regole HTTP e HTTPS. Questo livello offre un controllo più granulare sul flusso del traffico e sulla gestione del traffico.

Nel servizio Azure Kubernetes sono disponibili più opzioni per distribuire, eseguire e gestire un controller in ingresso. Un'opzione è il controller di ingresso gateway applicazione, che consente di usare app Azure gateway di ingresso come controller di ingresso per la terminazione TLS, il routing basato sul percorso e come firewall di accesso Web. Un'altra opzione è il controller di ingresso NGINX gestito, che offre l'opzione gestita da Azure per il controller di ingresso NGINX ampiamente usato. Il controller di ingresso Traefik è un altro controller di ingresso diffuso per Kubernetes.

Ognuno di questi controller di ingresso presenta punti di forza e punti deboli. Per decidere quale usare, prendere in considerazione i requisiti dell'applicazione e dell'ambiente. Assicurarsi di usare la versione più recente di Helm e di avere accesso al repository Helm appropriato quando si installa un controller di ingresso non gestito.

Archiviazione permanente

Service Fabric e servizio Azure Kubernetes dispongono di meccanismi per fornire l'archiviazione permanente alle applicazioni in contenitori. In Service Fabric, il driver del volume File di Azure, ovvero un plug-in di volume Docker, fornisce volumi File di Azure per i contenitori Linux e Windows. Viene inserita in un pacchetto come applicazione di Service Fabric che è possibile distribuire in un cluster di Service Fabric per fornire volumi per altre applicazioni in contenitori di Service Fabric all'interno del cluster. Per altre informazioni, vedere File di Azure driver di volume per Service Fabric.

Le applicazioni eseguite nel servizio Azure Kubernetes potrebbero dover archiviare e recuperare dati da un sistema di archiviazione file persistente. Il servizio Azure Kubernetes si integra con i servizi di archiviazione di Azure, ad esempio dischi gestiti di Azure, File di Azure, archiviazione BLOB e Archiviazione Azure NetApp (ANF). Si integra anche con sistemi di archiviazione non Microsoft come Rook e GlusterFS tramite driver CSI (Container Storage Interface).

CSI è uno standard per l'esposizione di sistemi di archiviazione di blocchi e file a carichi di lavoro in contenitori in Kubernetes. I provider di archiviazione non Microsoft che usano CSI possono scrivere, distribuire e aggiornare plug-in per esporre nuovi sistemi di archiviazione in Kubernetes o per migliorare quelli esistenti, senza dover modificare il codice Kubernetes principale e attendere i cicli di rilascio.

Il supporto del driver di archiviazione CSI nel servizio Azure Kubernetes consente di usare in modo nativo questi servizi di archiviazione di Azure:

  • Dischi di Azure. È possibile usare Dischi di Azure per creare una risorsa Kubernetes DataDisk. I dischi possono usare l'archiviazione Premium di Azure supportata da unità SSD a prestazioni elevate o da archiviazione standard di Azure supportata da UNITÀ SSD o HDD standard. Per la maggior parte dei carichi di lavoro di produzione e sviluppo, usare l'archiviazione Premium. I dischi di Azure vengono montati come ReadWriteOnce e sono disponibili solo per un nodo nel servizio Azure Kubernetes. Per i volumi di archiviazione a cui possono accedere più pod contemporaneamente, usare File di Azure.

    Service Fabric supporta invece la creazione di un cluster o di un tipo di nodo che usa dischi gestiti, ma non applicazioni che creano in modo dinamico dischi gestiti collegati tramite un approccio dichiarativo. Per altre informazioni, vedere Distribuire un tipo di nodo del cluster di Service Fabric con dischi dati gestiti.

  • File di Azure. È possibile usare File di Azure per montare una condivisione SMB 3.0 o 3.1 supportata da un account di archiviazione di Azure nei pod. Con File di Azure è possibile condividere dati tra più nodi e pod. File di Azure possono usare l'archiviazione standard di Azure supportata da UNITÀ HDD standard o archiviazione Premium di Azure supportate da unità SSD a prestazioni elevate.

    Service Fabric offre un driver di volume File di Azure come plug-in del volume Docker che fornisce volumi File di Azure per i contenitori Docker. Service Fabric offre una versione del driver per i cluster Windows e una per i cluster Linux.

  • Archiviazione BLOB. È possibile usare l'archiviazione BLOB per montare l'archiviazione BLOB (o l'archiviazione di oggetti) come file system in un contenitore o in un pod. L'archiviazione BLOB consente a un cluster del servizio Azure Kubernetes di supportare applicazioni che funzionano con set di dati non strutturati di grandi dimensioni, ad esempio dati di file di log, immagini o documenti e carichi di lavoro HPC. Se si inseriscono dati in Azure Data Lake Storage, è possibile montare direttamente l'archiviazione e usarla nel servizio Azure Kubernetes senza configurare un altro file system provvisorio. Service Fabric non supporta alcun meccanismo per il montaggio dell'archiviazione BLOB in modalità dichiarativa.

Per altre informazioni sulle opzioni di archiviazione, vedere Archiviazione nel servizio Azure Kubernetes.

Monitoraggio di applicazioni e cluster

Sia Service Fabric che il servizio Azure Kubernetes offrono l'integrazione nativa con Monitoraggio di Azure e i relativi servizi, ad esempio Log Analytics. Il monitoraggio e la diagnostica sono fondamentali per sviluppare, testare e distribuire carichi di lavoro in qualsiasi ambiente cloud. Il monitoraggio include il monitoraggio dell'infrastruttura e delle applicazioni.

Ad esempio, è possibile tenere traccia del modo in cui vengono usate le applicazioni, le azioni eseguite dalla piattaforma di Service Fabric, l'utilizzo delle risorse tramite contatori delle prestazioni e l'integrità complessiva del cluster. È possibile usare queste informazioni per diagnosticare e correggere i problemi e impedire che si verifichino in futuro. Per altre informazioni, vedere Monitoraggio e diagnostica per Service Fabric. Quando si ospitano e gestiscono applicazioni in contenitori in un cluster di Service Fabric, è necessario configurare la soluzione di monitoraggio dei contenitori per visualizzare gli eventi e i log dei contenitori.

Tuttavia, il servizio Azure Kubernetes include l'integrazione predefinita con Monitoraggio di Azure e Informazioni dettagliate sui contenitori, progettato per monitorare le prestazioni dei carichi di lavoro in contenitori distribuiti nel cloud. Informazioni dettagliate sui contenitori offre visibilità sulle prestazioni raccogliendo metriche di memoria e processore da controller, nodi e contenitori disponibili in Kubernetes tramite l'API Metriche.

Dopo aver abilitato il monitoraggio dai cluster Kubernetes, le metriche e i log dei contenitori vengono raccolti automaticamente tramite una versione in contenitori dell'agente di Log Analytics per Linux. Le metriche vengono inviate al database delle metriche in Monitoraggio di Azure. I dati di log vengono inviati all'area di lavoro Log Analytics. In questo modo è possibile ottenere dati di monitoraggio e telemetria sia per il cluster del servizio Azure Kubernetes che per le applicazioni in contenitori eseguite su di esso. Per altre informazioni, vedere Monitorare il servizio Azure Kubernetes con Monitoraggio di Azure.

Come soluzione alternativa o complementare a Container Insights, è possibile configurare il cluster del servizio Azure Kubernetes per raccogliere le metriche nel servizio gestito di Monitoraggio di Azure per Prometheus. È possibile usare questa configurazione per raccogliere e analizzare le metriche su larga scala usando una soluzione di monitoraggio compatibile con Prometheus, basata sul progetto Prometheus . Il servizio completamente gestito consente di usare il linguaggio di query Prometheus (PromQL) per analizzare le prestazioni dell'infrastruttura e dei carichi di lavoro monitorati. Consente inoltre di ricevere avvisi senza dover gestire l'infrastruttura sottostante.

Il servizio gestito di Monitoraggio di Azure per Prometheus è un componente delle metriche di Monitoraggio di Azure. Offre maggiore flessibilità nei tipi di dati delle metriche che è possibile raccogliere e analizzare usando Monitoraggio di Azure. Le metriche prometheus condividono alcune funzionalità con metriche personalizzate e piattaforma, ma hanno funzionalità aggiuntive per supportare meglio strumenti open source come PromQLe Grafana.

È possibile configurare il servizio gestito di Monitoraggio di Azure per Prometheus come origine dati per Grafana gestito di Azure e Grafana self-hosted, che può essere eseguito in una macchina virtuale di Azure. Per altre informazioni, vedere Usare il servizio gestito di Monitoraggio di Azure per Prometheus come origine dati per Grafana usando l'identità del sistema gestito.

Componenti aggiuntivi per il servizio Azure Kubernetes

Quando si esegue la migrazione da Service Fabric al servizio Azure Kubernetes, è consigliabile usare componenti aggiuntivi ed estensioni. Il servizio Azure Kubernetes offre funzionalità aggiuntive supportate per i cluster tramite componenti aggiuntivi ed estensioni come Kubernetes Autoscaling basato su eventi (KEDA) e GitOps Flux v2. Molte altre integrazioni fornite da progetti open source e terze parti vengono comunemente usate con il servizio Azure Kubernetes. I criteri di supporto del servizio Azure Kubernetes non riguardano le integrazioni open source e non Microsoft. Per altre informazioni, vedere Componenti aggiuntivi, estensioni e altre integrazioni con il servizio Azure Kubernetes.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi