Condividi tramite

Valutazione e idoneità dei microservizi

  • Articolo

Un'architettura di microservizi può offrire molti vantaggi per le applicazioni, tra cui agilità, scalabilità e disponibilità elevata. Oltre a questi vantaggi, questa architettura presenta sfide. Quando si creano applicazioni basate su microservizi o si trasformano applicazioni esistenti in un'architettura di microservizi, è necessario analizzare e valutare la situazione corrente per identificare le aree che richiedono miglioramenti.

Questa guida consente di comprendere alcune considerazioni da tenere presenti quando si passa a un'architettura di microservizi. È possibile usare questa guida per valutare la maturità dell'applicazione, dell'infrastruttura, di DevOps, del modello di sviluppo e altro ancora.

Comprendere le priorità aziendali

Per iniziare a valutare un'architettura di microservizi, è prima necessario comprendere le priorità principali dell'azienda. Le priorità principali possono essere correlate all'agilità, all'adozione del cambiamento o allo sviluppo rapido, ad esempio. È necessario analizzare se l'architettura è adatta alle priorità principali. Tenere presente che le priorità aziendali possono cambiare nel tempo. Ad esempio, l'innovazione è una priorità assoluta per le startup, ma dopo alcuni anni, le priorità principali potrebbero essere l'affidabilità e l'efficienza.

Ecco alcune priorità da considerare:

  • Innovazione
  • Affidabilità
  • Efficienza

Documentare i contratti di servizio allineati a varie parti dell'applicazione per garantire un impegno aziendale che possa fungere da guida alla valutazione.

Registrare le decisioni relative all'architettura

Un'architettura di microservizi aiuta i team a diventare autonomi. I team possono prendere decisioni proprie su tecnologie, metodologie e componenti dell'infrastruttura, ad esempio. Tuttavia, queste scelte devono rispettare i principi formalmente concordati, noti come governance condivisa, che esprimono l'accordo tra i team su come affrontare la strategia più ampia per i microservizi.

Tenere presente questi fattori:

  • La governance condivisa è in vigore?
  • Tenere traccia delle decisioni e dei loro compromessi in un journal dell'architettura?
  • Il team può accedere facilmente al journal dell'architettura?
  • Si dispone di un processo per la valutazione di strumenti, tecnologie e framework?

Valutare la composizione del team

È necessario avere la struttura del team appropriata per evitare comunicazioni non necessarie tra i team. Un'architettura di microservizi incoraggia la formazione di team piccoli, mirati e interfunzionali e richiede un cambiamento di mentalità, che deve essere preceduto dalla ristrutturazione del team.

Tenere presente questi fattori:

  • I team sono suddivisi in base ai sottodomini, seguendo i principi di progettazione basata su dominio ??
  • I team sono interfunzionali, con capacità sufficiente per creare e gestire i microservizi correlati in modo indipendente?
  • Quanto tempo viene impiegato in attività e attività ad hoc che non sono correlate ai progetti?
  • Quanto tempo viene dedicato alla collaborazione tra team?
  • Hai un processo per identificare e ridurre al minimo il debito tecnico?
  • Come vengono comunicate le lezioni e l'esperienza tra i team?

Usare la metodologia Twelve-Factor

L'obiettivo fondamentale della scelta di un'architettura di microservizi consiste nel fornire valore più velocemente e adattarsi al cambiamento seguendo le procedure agile. La metodologia di app Twelve-Factor fornisce linee guida per la creazione di applicazioni gestibili e scalabili. Queste linee guida promuovono attributi come immutabilità, effimerità, configurazione dichiarativa e automazione. Incorporando queste linee guida ed evitando problemi comuni, è possibile creare microservizi indipendenti e ad accoppiamento libero.

Comprendere l'approccio di scomposizione

La trasformazione di un'applicazione monolitica in un'architettura di microservizi richiede tempo. Iniziare con i servizi perimetrali. I servizi perimetrali hanno meno dipendenze da altri servizi e possono essere facilmente scomposti dal sistema come servizi indipendenti. È consigliabile usare modelli come Strangler Fig e Livello anti-danneggiamento per mantenere l'applicazione monolitica in uno stato di lavoro fino a quando tutti i servizi non vengono scomposti in microservizi separati. Durante la separazione, i principi di DDD possono aiutare i team a scegliere componenti o servizi dall'applicazione monolitica in base ai sottodomini.

Ad esempio, in un sistema di e-commerce, potrebbero essere disponibili questi moduli: carrello, gestione dei prodotti, gestione degli ordini, prezzi, generazione di fatture e notifica. Si decide di avviare la trasformazione dell'applicazione con il modulo di notifica perché non ha dipendenze da altri moduli. Tuttavia, altri moduli potrebbero dipendere da questo modulo per inviare notifiche. Il modulo di notifica può essere facilmente scomposto in un microservizio separato, ma è necessario apportare alcune modifiche nell'applicazione monolitica per chiamare il nuovo servizio di notifica. Si decide di trasformare il modulo di generazione della fattura successivamente. Questo modulo viene chiamato dopo la generazione di un ordine. È possibile usare modelli come Strangler e Anti-danneggiamento per supportare questa trasformazione.

La sincronizzazione dei dati, le operazioni di multi-scrittura in interfacce monolitiche e microservizi, la proprietà dei dati, la scomposizione dello schema, i join, il volume di dati e l'integrità dei dati potrebbero rendere difficile la suddivisione dei dati e la migrazione. Esistono diverse tecniche che è possibile usare, ad esempio mantenere un database condiviso tra microservizi, disaccoppiare i database da un gruppo di servizi basati su funzionalità o dominio aziendali e isolare i database dai servizi. La soluzione consigliata consiste nel scomporre ogni database con ogni servizio. In molte circostanze, questo non è pratico. In questi casi, è possibile usare modelli come il modello Vista database e il modello servizio di wrapping del database.

Valutare l'idoneità di DevOps

Quando si passa a un'architettura di microservizi, è importante valutare le competenze di DevOps. Un'architettura di microservizi è progettata per facilitare lo sviluppo agile nelle applicazioni per aumentare l'agilità organizzativa. DevOps è una delle procedure chiave da implementare per ottenere questa competenza.

Quando si valuta la funzionalità DevOps per un'architettura di microservizi, tenere presenti questi punti:

  • Gli utenti dell'organizzazione conoscono le procedure e i principi fondamentali di DevOps?
  • I team comprendono gli strumenti di controllo del codice sorgente e la loro integrazione con le pipeline CI/CD?
  • Implementare correttamente le procedure DevOps?
    • Seguire le procedure agile?
    • L'integrazione continua viene implementata?
    • Il recapito continuo è implementato?
    • La distribuzione continua è implementata?
    • Il monitoraggio continuo viene implementato?
    • Infrastruttura distribuita come codice (IaC) è in uso?
  • Si usano gli strumenti appropriati per supportare CI/CD?
  • Come viene gestita la configurazione degli ambienti di gestione temporanea e di produzione per l'applicazione?
  • La catena di strumenti dispone di supporto della community e di un modello di supporto e fornisce canali e documentazione appropriati?

Identificare le aree aziendali che cambiano frequentemente

Un'architettura di microservizi è flessibile e adattabile. Durante la valutazione, guidare una discussione nell'organizzazione per determinare le aree che i colleghi pensano cambieranno frequentemente. La creazione di microservizi consente ai team di rispondere rapidamente alle modifiche richieste dai clienti e ridurre al minimo le attività di test di regressione. In un'applicazione monolitica, una modifica in un modulo richiede numerosi livelli di test di regressione e riduce l'agilità nel rilascio di nuove versioni.

Tenere presente questi fattori:

  • Il servizio è distribuibile in modo indipendente?
  • Il servizio segue i principi DDD?
  • Il servizio segue i principi SOLID?
  • Il database è privato del servizio?
  • Il servizio è stato compilato usando il modello di chassis dei microservizi supportato?

Valutare l'idoneità dell'infrastruttura

Quando si passa a un'architettura di microservizi, l'idoneità dell'infrastruttura è un punto fondamentale da considerare. Le prestazioni, la disponibilità e la scalabilità dell'applicazione saranno interessate se l'infrastruttura non è configurata correttamente o se non vengono usati i servizi o i componenti corretti. A volte viene creata un'applicazione con tutte le metodologie e le procedure suggerite, ma l'infrastruttura non è adeguata. Ciò comporta prestazioni e manutenzione scarse.

Prendere in considerazione questi fattori quando si valuta l'idoneità dell'infrastruttura:

  • L'infrastruttura garantisce la scalabilità dei servizi distribuiti?
  • L'infrastruttura supporta il provisioning tramite script che possono essere automatizzati tramite CI/CD?
  • L'infrastruttura di distribuzione offre un contratto di servizio per la disponibilità?
  • Sono disponibili piani di ripristino di emergenza e pianificazioni di esercitazione di routine?
  • I dati vengono replicati in aree diverse per il ripristino di emergenza?
  • Si dispone di un piano di backup dei dati?
  • Le opzioni di distribuzione sono documentate?
  • L'infrastruttura di distribuzione viene monitorata?
  • L'infrastruttura di distribuzione supporta la riparazione automatica dei servizi?

Valutare i cicli di rilascio

I microservizi sono adattivi per cambiare e sfruttare i vantaggi dello sviluppo agile per abbreviare i cicli di rilascio e portare valore ai clienti. Prendere in considerazione questi fattori quando si valutano i cicli di rilascio:

  • Con quale frequenza si compilano e rilasciano applicazioni?
  • Con quale frequenza le versioni hanno esito negativo dopo la distribuzione?
  • Quanto tempo è necessario per ripristinare o correggere i problemi dopo un'interruzione?
  • Si usa il controllo delle versioni semantiche per le applicazioni?
  • Si mantengono ambienti diversi e si propaga la stessa versione in una sequenza (ad esempio, prima di tutto nella gestione temporanea e quindi nell'ambiente di produzione)?
  • Si usa il controllo delle versioni per le API?
  • Seguire le linee guida appropriate per il controllo delle versioni per le API?
  • Quando si modifica una versione dell'API?
  • Qual è l'approccio per la gestione delle versioni delle API?
    • Controllo delle versioni del percorso URI
    • Controllo delle versioni dei parametri di query
    • Controllo delle versioni dei tipi di contenuto
    • Controllo delle versioni delle intestazioni personalizzate
  • Si dispone di una pratica per il controllo delle versioni degli eventi?

Valutare la comunicazione tra i servizi

I microservizi sono servizi autonomi che comunicano tra loro attraverso i limiti dei processi per affrontare gli scenari aziendali. Per ottenere comunicazioni affidabili e affidabili, è necessario selezionare un protocollo di comunicazione appropriato.

Prendere in considerazione questi fattori:

  • Si segue un approccio API-first, in cui le API vengono considerate come cittadini di prima classe?
  • Sono presenti operazioni a catena prolungata, in cui più servizi comunicano in sequenza tramite un protocollo di comunicazione sincrono?
  • Hai considerato la comunicazione asincrona ovunque nel sistema?
  • È stata valutata la tecnologia del broker di messaggi e le sue funzionalità?
  • Si comprende la velocità effettiva dei messaggi che i servizi ricevono ed elaborano?
  • Si usa la comunicazione diretta da client a servizio?
  • È necessario rendere persistenti i messaggi a livello di broker messaggi?
  • Si usa il modello Visualizzazione materializzata per risolvere il comportamento di chat dei microservizi?
  • Sono stati implementati nuovi tentativi, interruttore, backoff esponenziale e jitter per una comunicazione affidabile? Un modo comune per gestire questo approccio consiste nell'usare il modello Ambassador.
  • Sono stati definiti eventi di dominio per facilitare la comunicazione tra microservizi?

Valutare il modo in cui i servizi vengono esposti ai client

Un gateway API è uno dei componenti principali di un'architettura di microservizi. L'esposizione diretta dei servizi ai client crea problemi in termini di gestibilità, controllo e comunicazione affidabile. Un gateway API funge da server proxy, intercettando il traffico e instradandolo ai servizi back-end. Se è necessario filtrare il traffico in base all'indirizzo IP, all'autorizzazione, alle risposte fittizie e così via, è possibile farlo a livello di gateway API senza apportare modifiche ai servizi.

Prendere in considerazione questi fattori:

  • I servizi vengono usati direttamente dai client?
  • Esiste un gateway API che funge da facciata per tutti i servizi?
  • Il gateway API può configurare criteri come limiti di quota, risposte fittizie e filtro degli indirizzi IP?
  • Si usano più gateway API per soddisfare le esigenze di vari tipi di client, ad esempio app per dispositivi mobili, app Web e partner?
  • Il gateway API fornisce un portale in cui i client possono individuare e sottoscrivere servizi, ad esempio un portale per sviluppatori in Azure Gestione API?
  • La soluzione offre funzionalità di bilanciamento del carico L7 o web application firewall (WAF) insieme al gateway API?

Valutare la gestione delle transazioni

Le transazioni distribuite facilitano l'esecuzione di più operazioni come singola unità di lavoro. In un'architettura di microservizi, il sistema viene scomposto in numerosi servizi. Un singolo caso d'uso aziendale viene risolto da più microservizi come parte di una singola transazione distribuita. In una transazione distribuita, un comando è un'operazione che viene avviata quando si verifica un evento. L'evento attiva un'operazione nel sistema. Se l'operazione ha esito positivo, potrebbe attivare un altro comando, che può quindi attivare un altro evento e così via fino al completamento o al rollback di tutte le transazioni, a seconda che la transazione abbia esito positivo.

Tenere conto delle considerazioni seguenti:

  • Quante transazioni distribuite sono presenti nel sistema?
  • Qual è l'approccio alla gestione delle transazioni distribuite? Valutare l'uso del modello Saga con orchestrazione o coreografia.
  • Quante transazioni si estendono su più servizi?
  • Si segue un modello di transazione ACID o BA edizione Standard per ottenere coerenza e integrità dei dati?
  • Si usano operazioni di concatenamento lungo per le transazioni che si estendono su più servizi?

Valutare il modello di sviluppo del servizio

Uno dei maggiori vantaggi delle architetture di microservizi è la diversità tecnologica. I sistemi basati su microservizi consentono ai team di sviluppare servizi usando le tecnologie scelte. Nello sviluppo di applicazioni tradizionali, è possibile riutilizzare il codice esistente quando si compilano nuovi componenti o creare un framework di sviluppo interno per ridurre le attività di sviluppo. L'uso di più tecnologie può impedire il riutilizzo del codice.

Tenere presente questi fattori:

  • Si usa un modello di servizio per avviare lo sviluppo di nuovi servizi?
  • Si segue la metodologia dell'app Twelve-Factor e si usa una singola codebase per i microservizi, isolando le dipendenze e esternalizzando la configurazione?
  • Mantenere la configurazione sensibile negli insiemi di credenziali delle chiavi?
  • È possibile inserire in contenitori i servizi?
  • Si conoscono i requisiti di coerenza dei dati?

Valutare l'approccio alla distribuzione

L'approccio alla distribuzione è il metodo per rilasciare versioni dell'applicazione in diversi ambienti di distribuzione. I sistemi basati su microservizi offrono l'agilità necessaria per rilasciare le versioni più velocemente rispetto alle applicazioni tradizionali.

Quando si valuta il piano di distribuzione, considerare questi fattori:

  • Si dispone di una strategia per la distribuzione dei servizi?
  • Si usano strumenti e tecnologie moderni per distribuire i servizi?
  • Quale tipo di collaborazione è necessario tra i team quando si distribuiscono i servizi?
  • Effettuare il provisioning dell'infrastruttura usando Infrastruttura come codice (IaC)?
  • Si usano le funzionalità devOps per automatizzare le distribuzioni?
  • Si propagano le stesse compilazioni in più ambienti, come suggerito dalla metodologia di app Twelve-Factor?

Valutare la piattaforma di hosting

La scalabilità è uno dei principali vantaggi delle architetture di microservizi. Ciò è dovuto al fatto che i microservizi vengono mappati ai domini aziendali, in modo che ogni servizio possa essere ridimensionato in modo indipendente. Un'applicazione monolitica viene distribuita come singola unità in una piattaforma di hosting e deve essere ridimensionata in modo olistico. Ciò comporta tempi di inattività, rischi di distribuzione e manutenzione. L'applicazione monolitica potrebbe essere ben progettata, con componenti che indirizzano singoli domini aziendali. Ma a causa di una mancanza di limiti di processo, il potenziale di violare i principi di responsabilità singola diventa più difficile. In questo modo si ottiene un codice spaghetti. Poiché l'applicazione è composta e distribuita come singolo processo di hosting, la scalabilità è difficile.

I microservizi consentono ai team di scegliere la piattaforma di hosting appropriata per supportare le esigenze di scalabilità. Diverse piattaforme di hosting sono disponibili per affrontare queste sfide offrendo funzionalità come la scalabilità automatica, il provisioning elastico, la disponibilità più elevata, la distribuzione più veloce e un monitoraggio semplice.

Tenere presente questi fattori:

  • Quale piattaforma di hosting si usa per distribuire i servizi (macchine virtuali, contenitori, serverless)?
  • La piattaforma di hosting è scalabile? Supporta la scalabilità automatica?
  • Quanto tempo è necessario per ridimensionare la piattaforma di hosting?
  • Si conoscono i contratti di servizio forniti da varie piattaforme di hosting?
  • La piattaforma di hosting supporta il ripristino di emergenza?

Valutare il monitoraggio dei servizi

Il monitoraggio è un elemento importante di un'applicazione basata su microservizi. Poiché l'applicazione è suddivisa in diversi servizi eseguiti in modo indipendente, la risoluzione degli errori può risultare scoraggiante. Se si usa una semantica appropriata per monitorare i servizi, i team possono monitorare, analizzare e rispondere facilmente agli errori.

Tenere presente questi fattori:

  • È possibile monitorare i servizi distribuiti?
  • Si dispone di un meccanismo di registrazione? Quali strumenti si usano?
  • È disponibile un'infrastruttura di traccia distribuita?
  • Registrare le eccezioni?
  • Si mantengono i codici di errore aziendali per identificare rapidamente i problemi?
  • Si usano probe di integrità per i servizi?
  • Si usa la registrazione semantica? Sono state implementate metriche, soglie e indicatori chiave?
  • Si mascherano i dati sensibili durante la registrazione?

Valutare l'assegnazione del token di correlazione

In un'architettura di microservizi, un'applicazione è costituita da vari microservizi ospitati in modo indipendente, interagendo tra loro per gestire diversi casi d'uso aziendali. Quando un'applicazione interagisce con i servizi back-end per eseguire un'operazione, è possibile assegnare un numero univoco, noto come token di correlazione, alla richiesta. È consigliabile usare i token di correlazione, perché possono essere utili per risolvere gli errori. Consentono di determinare la causa radice di un problema, valutare l'impatto e determinare un approccio per risolvere il problema.

È possibile usare i token di correlazione per recuperare l'analisi delle richieste identificando i servizi che contengono il token di correlazione e che non lo fanno. I servizi che non dispongono del token di correlazione per tale richiesta non sono riusciti. Se si verifica un errore, è possibile ritentare la transazione in un secondo momento. Per applicare l'idempotenza, solo i servizi che non dispongono del token di correlazione serviranno la richiesta.

Ad esempio, se si dispone di una lunga catena di operazioni che coinvolge molti servizi, il passaggio di un token di correlazione ai servizi consente di analizzare facilmente i problemi se uno dei servizi ha esito negativo durante una transazione. Ogni servizio ha in genere un proprio database. Il token di correlazione viene mantenuto nel record del database. In caso di riproduzione di una transazione, i servizi che dispongono di quel particolare token di correlazione nei database ignorano la richiesta. Solo i servizi che non dispongono del token servono la richiesta.

Tenere presente questi fattori:

  • In quale fase si assegna il token di correlazione?
  • Quale componente assegna il token di correlazione?
  • Salvare i token di correlazione nel database del servizio?
  • Qual è il formato dei token di correlazione?
  • Si registrano i token di correlazione e altre informazioni sulle richieste?

Valutare la necessità di un framework dello chassis di microservizi

Un framework di chassis di microservizi è un framework di base che offre funzionalità per problemi trasversali, ad esempio la registrazione, la gestione delle eccezioni, la traccia distribuita, la sicurezza e la comunicazione. Quando si usa un framework dello chassis, è necessario concentrarsi maggiormente sull'implementazione del limite del servizio rispetto all'interazione con le funzionalità dell'infrastruttura.

Si supponga, ad esempio, di creare un servizio di gestione del carrello. Si vuole convalidare il token in ingresso, scrivere i log nel database di registrazione e comunicare con un altro servizio richiamando l'endpoint del servizio. Se si usa un framework dello chassis di microservizi, è possibile ridurre le attività di sviluppo. Dapr è un sistema che fornisce vari blocchi predefiniti per l'implementazione di problematiche trasversali.

Tenere presente questi fattori:

  • Si usa un framework dello chassis di microservizi?
  • Si usa Dapr per interagire con problemi trasversali?
  • Il linguaggio del framework dello chassis è indipendente?
  • Il framework dello chassis è generico, quindi supporta tutti i tipi di applicazioni? Un framework dello chassis non deve contenere logica specifica dell'applicazione.
  • Il framework dello chassis fornisce un meccanismo per usare i componenti o i servizi selezionati in base alle esigenze?

Valutare l'approccio ai test delle applicazioni

In genere, i test vengono eseguiti al termine dello sviluppo e l'applicazione è pronta per l'implementazione negli ambienti di test di accettazione utente e produzione. Attualmente è in corso un cambiamento in questo approccio, spostando il test all'inizio (a sinistra) nel ciclo di vita di sviluppo dell'applicazione. I test a sinistra a turno aumentano la qualità delle applicazioni perché i test sono eseguiti durante ogni fase del ciclo di vita di sviluppo delle applicazioni, incluse le fasi di progettazione, sviluppo e post-sviluppo.

Ad esempio, quando si compila un'applicazione, si inizia progettando un'architettura. Quando si usa l'approccio di spostamento a sinistra, si testa la progettazione per individuare le vulnerabilità usando strumenti come Microsoft Threat Modeling. Quando si avvia lo sviluppo, è possibile analizzare il codice sorgente eseguendo strumenti come test di sicurezza delle applicazioni statici (SAST) e usando altri analizzatori per individuare i problemi. Dopo aver distribuito l'applicazione, è possibile usare strumenti come il test di sicurezza delle applicazioni dinamiche (DAST) per testarlo mentre è ospitato. I test funzionali, i test chaos, i test di penetrazione e altri tipi di test vengono eseguiti in un secondo momento.

Tenere presente questi fattori:

  • Si scrivono piani di test che coprono l'intero ciclo di vita di sviluppo?
  • I tester sono inclusi nelle riunioni dei requisiti e nell'intero ciclo di vita di sviluppo delle applicazioni?
  • Si usa la progettazione guidata dai test o la progettazione basata sul comportamento?
  • Si testano le storie utente? Includi i criteri di accettazione nelle tue storie utente?
  • È possibile testare la progettazione usando strumenti come Microsoft Threat Modeling?
  • Si scrivono unit test?
  • Si usano analizzatori di codice statici o altri strumenti per misurare la qualità del codice?
  • Si usano strumenti automatizzati per testare le applicazioni?
  • Si implementano procedure DevOps sicure?
  • Si eseguono test di integrazione, test di applicazioni end-to-end, test di carico/prestazioni, test di penetrazione e test chaos?

Valutare la sicurezza dei microservizi

La protezione dei servizi, l'accesso sicuro e la comunicazione sicura sono tra le considerazioni più importanti per un'architettura di microservizi. Ad esempio, un sistema basato su microservizi che si estende su più servizi e usa la convalida dei token per ogni servizio non è una soluzione valida. Questo sistema influirà sull'agilità del sistema complessivo e sul potenziale di introdurre la deriva dell'implementazione tra i servizi.

I problemi di sicurezza vengono in genere gestiti dal gateway API e dal firewall dell'applicazione. Il gateway e il firewall accettano richieste in ingresso, convalidano i token e applicano vari filtri e criteri, ad esempio l'implementazione dei principi principali 10 di OWASP per intercettare il traffico. Infine, inviano la richiesta ai microservizi back-end. Questa configurazione consente agli sviluppatori di concentrarsi sulle esigenze aziendali anziché sull'importanza trasversale della sicurezza.

Tenere presente questi fattori:

  • L'autenticazione e l'autorizzazione sono necessarie per il servizio?
  • Si usa un gateway API per convalidare i token e le richieste in ingresso?
  • Si usa SSL o mTLS per garantire la sicurezza per la comunicazione del servizio?
  • Sono presenti criteri di sicurezza di rete per consentire la comunicazione necessaria tra i servizi?
  • Si usano firewall (L4, L7) dove applicabile per garantire la sicurezza per le comunicazioni interne ed esterne?
  • Usare i criteri di sicurezza nel gateway API per controllare il traffico?

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