Condividi tramite

Valutazione e idoneità dei microservizi

Un'architettura di microservizi può offrire molti vantaggi per le applicazioni, tra cui agilità, scalabilità e disponibilità elevata. Questa architettura può anche presentare problemi. 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.

Questo articolo descrive 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, del devOps e del modello di sviluppo.

Comprendere le priorità aziendali

Per valutare un'architettura di microservizi, è prima necessario comprendere le priorità principali dell'azienda. Ad esempio, le priorità principali potrebbero essere correlate all'agilità, all'adozione del cambiamento o allo sviluppo rapido. È 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. Tuttavia, dopo alcuni anni, le priorità principali potrebbero essere l'affidabilità e l'efficienza.

Considerare le priorità seguenti:

  • Innovazione, inclusa la promozione dell'agilità e della sperimentazione
  • Affidabilità, inclusa la garanzia della disponibilità elevata e della tolleranza di errore
  • Efficienza, inclusa l'ottimizzazione delle risorse e della produttività

Documentare gli obiettivi del livello di servizio (SLO) allineati a varie parti dell'applicazione per garantire un impegno aziendale che possa guidare la valutazione.

Registrare le decisioni relative all'architettura

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

Prendere in considerazione i fattori seguenti:

  • Indica se la governance condivisa è in vigore per guidare le decisioni relative all'architettura tra i team

  • Se si mantengono record di decisioni di architettura (ADR) che includono logica chiara, compromessi e stato

  • Se si mantiene un diario dell'architettura per catturare esplorazioni di design e contesto in evoluzione

  • Se il team può accedere e cercare facilmente le ADR e il registro dell'architettura

  • Se si ha un framework di valutazione della tecnologia per valutare nuovi strumenti e framework

  • Se sono stati stabiliti principi per la selezione e la standardizzazione della tecnologia

  • Se le decisioni relative all'architettura vengono esaminate e aggiornate regolarmente man mano che i requisiti aziendali e tecnici si evolvono

Valutare la composizione del team

È necessario strutturare correttamente il team per evitare comunicazioni non necessarie tra i team. I team di piccole dimensioni, incentrati e interfunzionali sono la soluzione migliore per un'architettura di microservizi. Queste modifiche richiedono spesso un cambiamento di mentalità, che deve precedere la ristrutturazione del team.

Prendere in considerazione i fattori seguenti:

  • Se i team sono divisi in base ai sottodomini e seguono i principi di progettazione basata su dominio (DDD)

  • Se i team sono interfunzionali e hanno capacità sufficiente per creare e gestire i microservizi correlati in modo indipendente

  • Quantità di tempo impiegato in attività e attività non pianificate che non sono correlate ai progetti

  • Quantità di tempo impiegato per la collaborazione tra team

  • Se si dispone di un processo per identificare e ridurre al minimo il debito tecnico

  • Come i team imparano le lezioni e come comunicano questa esperienza

Usa la metodologia Twelve-Factor

L'obiettivo fondamentale della scelta di un'architettura di microservizi è offrire valore più veloce e adattarsi al cambiamento seguendo le procedure agile. La metodologia dell'appTwelve-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 separati dal sistema come servizi indipendenti. Si raccomanda vivamente di utilizzare modelli come Strangler Fig e Livello Anti-Corruzione per mantenere le applicazioni monolitiche funzionanti, fino a che tutti i servizi siano suddivisi 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, un sistema di e-commerce potrebbe avere moduli come 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. È possibile rendere il modulo di notifica un microservizio separato, ma è anche necessario aggiornare l'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 Fig e Anti-Corruption Layer per supportare questa trasformazione.

La sincronizzazione dei dati, scritture multiple su interfacce sia monolitiche che di microservizi, gestione della proprietà dei dati, scomposizione dello schema, join, volume di dati e integrità dei dati potrebbero rendere difficile la suddivisione e la migrazione dei dati. 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. Una soluzione ideale consiste nel scomporre ogni database con ogni servizio. Alcune circostanze potrebbero rendere questo approccio poco pratico. In questi casi, è possibile applicare modelli come il modello di visualizzazione materializzata e gli approcci, ad esempio la modernizzazione delle applicazioni usando un wrapper API per astrarre e modernizzare l'accesso ai dati legacy o condivisi.

Valutare l'idoneità di DevOps

Quando si passa a un'architettura di microservizi, è importante valutare le competenze di DevOps. Un'architettura di microservizi deve 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, considerare i punti seguenti:

  • Se gli utenti dell'organizzazione conoscono le procedure e i principi fondamentali di DevOps

  • Se i team comprendono gli strumenti di controllo del codice sorgente e il modo in cui si integrano con pipeline di integrazione continua e recapito continuo (CI/CD)

  • Se si implementano correttamente le procedure DevOps, tra cui:

    • Seguire le pratiche agili.

    • Implementazione dell'integrazione continua.

    • Implementazione del recapito continuo in cui le modifiche al codice vengono compilate, testate e preparate automaticamente per il rilascio nell'ambiente di produzione. Questo approccio consente di garantire che il software possa essere rilasciato in modo sicuro in qualsiasi momento e con approvazione manuale.

    • Implementazione della distribuzione continua che estende il recapito continuo distribuendo automaticamente le modifiche al codice nell'ambiente di produzione dopo aver superato tutti i test automatizzati, senza intervento manuale.

    • Incorporamento del monitoraggio continuo in tutte le fasi di DevOps e operazioni IT per garantire l'integrità, le prestazioni e l'affidabilità continue delle applicazioni e dell'infrastruttura durante il passaggio dallo sviluppo agli ambienti di produzione e cliente.

  • Se la strategia di automazione dei processi di build e deployment è allineata agli obiettivi di consegna e ai requisiti operativi del team

  • Che si utilizzino i feature flag e le strategie di rilascio progressivo

  • Come viene gestita la configurazione degli ambienti di gestione temporanea e di produzione per l'applicazione

  • Indica se la catena di strumenti dispone del 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 si aspettano di cambiare 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à nelle nuove versioni.

Prendere in considerazione i fattori seguenti:

  • Indica se il servizio è distribuibile in modo indipendente

  • Indica se il servizio segue i principi DDD

  • Indipendentemente dal fatto che il servizio segua i principi di responsabilità singola, aperto-chiuso, sostituzione di Liskov, segregazione dell'interfaccia e inversione delle dipendenze (SOLID)

  • Indica se il database è privato del servizio

  • Che tu costruisca il servizio utilizzando il framework supportato per microservizi

Valutare l'idoneità dell'infrastruttura

Quando si passa a un'architettura di microservizi, l'idoneità dell'infrastruttura è un punto fondamentale da considerare. La configurazione non corretta dell'infrastruttura o l'uso dei servizi o dei componenti appropriati influisce sulle prestazioni, la disponibilità e la scalabilità dell'applicazione. È possibile usare tutte le metodologie e le procedure suggerite per creare un'applicazione. Tuttavia, se l'infrastruttura non è adeguata, l'applicazione potrebbe avere prestazioni scarse e richiedere manutenzione aggiuntiva.

Quando si valuta l'idoneità dell'infrastruttura, tenere presenti i fattori seguenti:

  • Indica se l'infrastruttura garantisce la scalabilità dei servizi distribuiti

  • Se l'infrastruttura dei contenitori è pronta per la distribuzione di microservizi

  • Indica se l'infrastruttura supporta il provisioning tramite script che possono essere automatizzati tramite CI/CD

  • Indica se l'infrastruttura di distribuzione offre un contratto di servizio per la disponibilità

  • Se si dispone di un piano di ripristino di emergenza (DR) e programmi di esercitazioni di routine

  • Indica se i dati vengono replicati in aree diverse per il ripristino di emergenza

  • Se si dispone di un piano di backup dei dati

  • Indica se le opzioni di distribuzione sono documentate

  • Indica se l'infrastruttura di distribuzione viene monitorata

  • Indica se l'infrastruttura di distribuzione supporta la riparazione automatica dei servizi

Valutare i cicli di rilascio

I microservizi possono adattarsi al cambiamento e sfruttare lo sviluppo agile per abbreviare i cicli di rilascio e portare valore ai clienti più velocemente. Quando si valutano i cicli di rilascio, tenere presenti i fattori seguenti:

  • Frequenza di compilazione e rilascio delle applicazioni.

  • Frequenza con cui i rilasci hanno esito negativo dopo la distribuzione.

  • Tempo necessario per ripristinare o correggere i problemi dopo un'interruzione.

  • Indica se si usa il controllo delle versioni semantiche per le applicazioni.

  • Se si mantengono ambienti diversi e si propaga la stessa versione in una sequenza. Ad esempio, si effettua il rilascio prima nell'ambiente di staging e poi in produzione.

  • Se si usa il controllo delle versioni per le API.

  • Se si seguono le linee guida appropriate per il controllo delle versioni per le API.

  • Quando si modifica una versione dell'API.

  • Qual è l'approccio alla gestione delle versioni delle API, tra cui:

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

  • Se hai una pratica in atto per il versionamento 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 i fattori seguenti:

  • Se si segue un approccio API-first, in cui si progettano e mantengono le API come componenti principali dell'architettura di sistema.

  • Se si valutano protocolli ad alte prestazioni, ad esempio gRPC, HTTP/2 o messaggistica asincrona come Kafka o NATS, per una comunicazione efficiente da servizio a servizio.

  • Indipendentemente dal fatto che siano presenti operazioni a catena prolungata, in cui più servizi comunicano in sequenza tramite un protocollo di comunicazione sincrono.

  • Indica se si usano piattaforme di streaming di eventi per l'elaborazione dei dati in tempo reale.

  • Indica se si prevede di implementare la comunicazione asincrona ovunque nel sistema.

  • Indica se si prevede di valutare la tecnologia di Message Broker e le relative funzionalità.

  • Indica se si comprende la velocità effettiva dei messaggi che i servizi ricevono ed elaborano.

  • Indica se si usa la comunicazione diretta da client a servizio.

  • Se è necessario rendere persistenti i messaggi a livello di broker di messaggi.

  • Indica se si usa il modello Visualizzazione materializzata per risolvere il comportamento di chat dei microservizi.

  • Sia che si preveda di implementare modelli di ritentare, circuit breaker, ritardo esponenziale, o jitter per una comunicazione affidabile. Un modo comune per gestire queste funzionalità consiste nell'usare il modello Ambassador.

  • Indica se 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 di gestibilità, controllo e comunicazione affidabile. Un gateway API funge da server proxy che intercetta il traffico e lo instrada ai servizi back-end. Se è necessario filtrare il traffico in base all'indirizzo IP, all'autorizzazione o alle risposte fittizie, è possibile filtrarlo a livello di gateway API senza apportare modifiche ai servizi.

Prendere in considerazione i fattori seguenti:

  • Indica se i client utilizzano direttamente i servizi

  • Indica se un gateway API funge da facciata unificata per tutti i servizi

  • Se si implementa il Backends for Frontends (BFF) pattern per diversi tipi di client

  • Indica se il gateway API può configurare criteri come limiti di quota, risposte fittizie e filtro degli indirizzi IP

  • Se si usano più gateway API per soddisfare le esigenze di vari tipi di client, ad esempio app per dispositivi mobili, app Web e partner

  • Se il gateway API fornisce un portale in cui i client possono individuare e sottoscrivere servizi, ad esempio un portale per sviluppatori in Gestione API di Azure

  • Se 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 consentono di eseguire più operazioni come singola unità di lavoro. In un'architettura di microservizi, il sistema viene scomposto in numerosi servizi. Più microservizi indirizzano un singolo caso d'uso aziendale 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. Questo processo continua fino al completamento o al rollback di tutte le transazioni, a seconda che la transazione abbia esito positivo.

Prendere in considerazione i fattori seguenti:

  • Numero di transazioni distribuite nel sistema

  • Come gestire le transazioni distribuite, incluso l'uso del modello Saga con orchestrazione o coreografia

  • Che si usi event sourcing per mantenere la cronologia delle transazioni e lo stato

  • Se si implementano modelli CQRS (Command Query Responsibility Segregation)

  • Quante transazioni si estendono su più servizi

  • Sia che si segua un modello di transazione atomicità, coerenza, isolamento e durabilità (ACID) o un modello di transazione sostanzialmente disponibile, flessibile e infine coerente (BASE) per ottenere la coerenza e l'integrità dei dati

  • Indica se si usano operazioni di concatenamento lungo per le transazioni che si estendono su più servizi

  • Se si implementano modelli di compensazione oltre a Saga per il rollback delle transazioni

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.

Prendere in considerazione i fattori seguenti:

  • Se si usa un modello di servizio standardizzato per accelerare lo sviluppo di nuovi servizi e garantire la coerenza nelle procedure di architettura, distribuzione e DevOps

  • Se si segue la metodologia dell'app Twelve-Factor e si usa una singola codebase per i microservizi per isolare le dipendenze ed esternalizzare la configurazione

  • Se si mantiene la configurazione sensibile negli archivi delle chiavi

  • Se [tu] containerizzi i servizi

  • Se 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 i fattori seguenti:

  • Se si ha una strategia per la distribuzione dei servizi

  • Se si usano strumenti e tecnologie moderni per distribuire i servizi

  • Tipo di collaborazione che i team richiedono quando si distribuiscono i servizi

  • Se si configura l'infrastruttura utilizzando l'infrastruttura come codice (IaC)

  • Se tu segui i principi dell'infrastruttura immutabile

  • Se si usano funzionalità DevOps per automatizzare le distribuzioni

  • Indica se si propagano le stesse compilazioni in più ambienti, come suggerito dalla metodologia dell'app Twelve-Factor

Valutare la piattaforma di hosting

La scalabilità è uno dei principali vantaggi delle architetture di microservizi. I microservizi corrispondono ai domini aziendali, così puoi scalare ogni servizio in modo indipendente. Un'applicazione monolitica viene distribuita come singola unità in una piattaforma di hosting, quindi è necessario ridimensionarla in modo olistico. Questo approccio comporta tempi di inattività, rischi di distribuzione e manutenzione. L'applicazione monolitica potrebbe essere ben progettata e avere 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 aumenta. Gli sforzi per garantire i principi della singola responsabilità possono comportare codice che non dispone di struttura ed è difficile da gestire. Poiché l'applicazione è composta e distribuita come singolo processo di hosting, la scalabilità è difficile da ottenere.

I microservizi consentono ai team di scegliere la piattaforma di hosting appropriata per supportare le esigenze di scalabilità. Diverse piattaforme di hosting possono risolvere questi problemi fornendo funzionalità come la scalabilità automatica, il provisioning elastico, la disponibilità più elevata, la distribuzione più veloce e il monitoraggio semplice.

Prendere in considerazione i fattori seguenti:

  • Quale piattaforma di hosting, ad esempio macchine virtuali, contenitori o piattaforme serverless, viene usata per distribuire i servizi

  • Indica se la piattaforma di hosting è scalabile e supporta la scalabilità automatica

  • Quanto tempo è necessario per ridimensionare la piattaforma di hosting

  • Se si conoscono i contratti di servizio forniti da varie piattaforme di hosting

  • Indica se 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. La risoluzione degli errori può risultare scoraggiante perché l'applicazione è suddivisa in molti servizi eseguiti in modo indipendente. Se si usa una semantica appropriata per monitorare i servizi, i team possono monitorare, analizzare e rispondere facilmente agli errori.

Prendere in considerazione i fattori seguenti:

  • Se si monitorano i servizi distribuiti

  • Se si sono definiti gli obiettivi di livello di servizio

  • Se si ha un meccanismo di registrazione e quali strumenti si usano

  • Se si dispone di un'infrastruttura di traccia distribuita sul posto

  • Se si registrano eccezioni

  • Se si mantengono i codici di errore aziendali per identificare rapidamente i problemi

  • Se utilizzi sonde di salute per i servizi

  • Se si usa la registrazione semantica e si implementano metriche chiave, soglie e indicatori

  • Se si mascherano i dati sensibili durante la registrazione

  • Se si monitorano le dipendenze del servizio e le integrazioni esterne

Valutare l'assegnazione del token di correlazione

In un'architettura di microservizi, un'applicazione è costituita da vari microservizi ospitati in modo indipendente e interagiscono 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é consentono di 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. Per applicare l'idempotenza, solo i servizi che non dispongono del token di correlazione elaborano la richiesta.

Ad esempio, se si dispone di una lunga catena di operazioni che include 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. Se una transazione viene riprodotta, i servizi che dispongono di tale token di correlazione specifico nei database ignorano la richiesta. Solo i servizi che non dispongono del token servono la richiesta.

Prendere in considerazione i fattori seguenti:

  • In quale fase si assegna il token di correlazione

  • Quale componente assegna il token di correlazione

  • Se si salvano i token di correlazione nel database del servizio

  • Formato dei token di correlazione

  • Indica se si registrano token di correlazione e altre informazioni sulla richiesta

Valutare la necessità di un framework di chassis per 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 di chassis di microservizi, è possibile ridurre gli sforzi di sviluppo. Dapr è un sistema che fornisce vari blocchi predefiniti per l'implementazione di problematiche trasversali.

Prendere in considerazione i fattori seguenti:

  • Se si utilizza un framework chassis per microservizi.

  • Se si utilizza Dapr per interagire con preoccupazioni trasversali.

  • Indica se il framework dello chassis è agnostico rispetto al linguaggio.

  • Se il framework dello chassis è generico in modo che possa supportare tutti i tipi di applicazioni. Un framework dello chassis non deve contenere logica specifica dell'applicazione.

  • Indica se 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 si testa l'applicazione dopo il completamento dello sviluppo ed è pronta per l'implementazione negli ambienti di test di accettazione utente e produzione. Prendere in considerazione il test in precedenza nel ciclo di vita dello sviluppo dell'applicazione. Questo approccio è noto come test di spostamento a sinistra. Aumenta la qualità delle applicazioni perché si eseguono test durante ogni fase del ciclo di vita dello sviluppo dell'applicazione, 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.

Prendere in considerazione i fattori seguenti:

  • Se si scrivono piani di test che coprono l'intero ciclo di vita dello sviluppo

  • Se si includono tester nelle riunioni dei requisiti e nell'intero ciclo di vita dello sviluppo di applicazioni

  • Se si usa la progettazione guidata dai test o la progettazione basata sul comportamento

  • Se si testano le storie utente e si includono criteri di accettazione nelle storie utente

  • Se si testa la progettazione usando strumenti come Microsoft Threat Modeling

  • Se scrivi test unità

  • Se si usano analizzatori di codice statici o altri strumenti per misurare la qualità del codice

  • Se si usano strumenti automatizzati per testare le applicazioni

  • Se implementate pratiche DevOps sicure

  • Se si eseguono test di integrazione, test di applicazioni end-to-end, test di carico e prestazioni, test di penetrazione e test del caos

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 tipo di sistema influisce sull'agilità del sistema complessivo e potrebbe introdurre deviazioni di implementazione tra i servizi.

Il gateway API e il firewall dell'applicazione gestiscono in genere problemi di sicurezza. 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 invece di preoccuparsi del problema trasversale della sicurezza.

Prendere in considerazione i fattori seguenti:

  • Indica se il servizio richiede l'autenticazione e l'autorizzazione e se si implementano i principi dell'architettura Zero Trust

  • Se si dispone di una strategia completa di gestione delle informazioni riservate che include la rotazione delle chiavi, la gestione del ciclo di vita e il controllo, oltre all'archiviazione delle informazioni riservate in un archivio di chiavi

  • Indica se si usa un gateway API per convalidare i token e le richieste in ingresso

  • Se si usa Secure Sockets Layer (SSL) o mTLS (Mutual Transport Layer Security) per garantire la sicurezza per la comunicazione del servizio

  • Se si implementa l'analisi di sicurezza dei contenitori e delle immagini

  • Se si implementano criteri di sicurezza di rete per consentire la comunicazione necessaria tra i servizi

  • Sia che si usino firewall, ad esempio L4 o L7, se applicabile per garantire maggiore sicurezza per le comunicazioni interne ed esterne

  • Se si usano criteri di sicurezza nei gateway API per controllare il traffico

  • Indica se è disponibile il monitoraggio della sicurezza di runtime per rilevare un comportamento anomalo

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

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

Passaggi successivi

  • Last updated on