Cosa sono i microservizi?

Vantaggi dei microservizi

I microservizi forniscono un quadro per la costruzione di applicazioni native del cloud, in grado di adattarsi ai mutevoli requisiti aziendali. La miriade di vantaggi deriva dall'architettura dell'applicazione.

Agilità

L'architettura a microservizi si presta allo sviluppo e alla distribuzione indipendenti. A differenza delle applicazioni monolitiche, dove la modifica di una riga di codice comporta l'aggiornamento dell'intera applicazione, gli sviluppatori possono modificare o sostituire i servizi senza influenzare il sistema distribuito. La possibilità di distribuire servizi individuali facilita l'aggiunta di nuove funzionalità o il rollback delle modifiche a un'applicazione.

Scalabilità

Scalare un'intera applicazione non è ottimale. Con i microservizi, vengono scalati solo i componenti che richiedono la scalabilità. Gli sviluppatori possono intervenire su un singolo servizio in base alle esigenze, il che in ultima analisi facilita una migliore performance in presenza di carichi pesanti, l'uso efficiente delle risorse e la riduzione dei costi dell'infrastruttura.

Scelta

Nell'architettura a microservizi, l'applicazione cloud-nativa non condivide uno stack e un database comuni. Gli sviluppatori possono scegliere gli strumenti che preferiscono e le tecnologie per soddisfare i requisiti distinti dei singoli servizi.

Integrazione

Gli sviluppatori possono scrivere microservizi in qualsiasi lingua - e collegarli a microservizi programmati in qualsiasi lingua. Inoltre, i microservizi possono essere eseguiti su qualsiasi piattaforma, il che li rende disponibili per l'integrazione con i sistemi legacy.

Riutilizzo del codice

L'architettura a microservizi consente agli sviluppatori di costruire servizi modulari che possono essere riutilizzati in tutte le applicazioni. Lavorando con componenti riutilizzabili, i programmatori riducono i tempi di sviluppo e migliorano la qualità del codice, poiché investono in una cultura "scrivi una volta, riutilizza spesso".

Tolleranza ai guasti

L'architettura a microservizi promuove la resilienza. Con i servizi progettati per operare in modo autonomo, il guasto di un singolo servizio raramente chiude l'applicazione, come tende a succedere con le applicazioni monolitiche.

Collaborazione

L'architettura a microservizi consente ai team di lavorare su diversi servizi contemporaneamente, il che si traduce in un time-to-market più rapido. Mentre gli sviluppatori prendono decisioni senza dover coordinarsi con altri team, i microservizi promuovono anche la collaborazione tra team, in quanto ogni team è responsabile dello sviluppo e della manutenzione di una parte dell'insieme. Questo può portare a un migliore allineamento con gli obiettivi aziendali e a un uso più efficiente delle risorse.

Iterazione continua

L'applicazione costruita con i microservizi è costruita per evolversi. Gli sviluppatori possono distribuire rapidamente i microservizi principali come prodotto minimo vitale e aggiornare l'applicazione man mano che i team completano i servizi aggiuntivi. Le nuove tecnologie possono essere incorporate nel design man mano che emergono. L'applicazione basata sui microservizi rimane in fase di processo, muovendosi continuamente verso la perfezione teorica.

Quando usare i microservizi

Sebbene i microservizi basati su container offrano molti vantaggi, non sempre sono l'architettura applicativa giusta da scegliere. Quando prende decisioni di ingegneria del software, pensi ai suoi obiettivi per l'applicazione, nonché agli ostacoli allo sviluppo e alle esigenze che prevede in vista del ciclo di vita dell'applicazione. I microservizi funzionano meglio con applicazioni complesse. Gli scenari da considerare per l'utilizzo dei microservizi includono:

Applicazioni di grandi dimensioni

Se sta costruendo un'applicazione grande e complessa, i microservizi le permetteranno di dividere l'applicazione in pezzi gestibili, rendendo più facile lo sviluppo, la distribuzione e la manutenzione.

Complessità della linea temporale

L'architettura a microservizi può ospitare servizi indipendenti con ritmi di sviluppo diversi. Anche se un servizio subisce un ritardo inaspettato, il progetto può continuare senza implicazioni globali sulla tempistica di sviluppo dell'applicazione.

Aggiornamenti frequenti

L'architettura a microservizi è ideale per le applicazioni che richiedono aggiornamenti frequenti, in quanto i servizi indipendenti consentono agli sviluppatori di modificare il modulo anziché l'applicazione.

Alta scalabilità

Se la sua applicazione deve gestire un volume elevato di traffico o deve scalare rapidamente, i microservizi sono essenziali. Questo è particolarmente importante se deve scalare parti specifiche dell'applicazione, piuttosto che scalare l'intera applicazione.

Squadre multiple

Se ha più team di sviluppo che lavorano sulla stessa applicazione, i microservizi la aiuteranno a mantenere agilità ed efficienza. Ogni team può lavorare sul proprio microservizio, utilizzando lo stack tecnologico che funziona per lui, senza preoccuparsi del resto dell'applicazione.

Architettura decentralizzata

Se desidera costruire un'applicazione con un'architettura decentralizzata, i microservizi sono autonomi e possono essere distribuiti in luoghi diversi, anche tra diversi fornitori di servizi cloud.

Cloud ibrido

Se sta pianificando un'architettura cloud ibrida, in cui alcuni servizi continueranno a funzionare in locale e altri verranno eseguiti nel cloud, i microservizi la aiuteranno a gestire la complessità dell'applicazione.

Costruire e distribuire applicazioni basate su microservizi.

L'architettura a microservizi richiede un'attenta pianificazione. Alcune tecnologie e pratiche comuni all'ambiente di produzione consentono agli sviluppatori di sviluppare, mantenere e gestire in modo efficace le applicazioni basate sui microservizi.

DevOps

Le pratiche DevOps, incluso CI/CD, sono essenziali per l'approccio architetturale dei microservizi. A differenza delle applicazioni monolitiche, i microservizi sono sistemi distribuiti intrinsecamente complessi, con numerose parti mobili e stack tecnologici indipendenti. Questa complessità richiede una collaborazione frequente tra i team di sviluppo e operativi, per garantire che i componenti siano perfettamente integrati.

Le pratiche di forniscono gli strumenti di collaborazione, comunicazione e automazione necessari per riunire efficacemente i team durante l'intero ciclo di vita dello sviluppo software.

Consegna continua

La consegna continua va di pari passo con i microservizi, consentendo agli sviluppatori di rilasciare aggiornamenti software in modo frequente e affidabile, utilizzando strumenti di automazione dell'infrastruttura, come i server di integrazione continua, le pipeline di distribuzione e i framework di test automatizzati per semplificare il processo CI/CD.

La consegna continua è particolarmente importante per garantire che ogni servizio possa essere aggiornato e rilasciato indipendentemente dagli altri microservizi.

REST

I microservizi comunicano con i microservizi - e la maggior parte lo fa all'interno di applicazioni web - il che rende REST complementare. REST, o Representational State Transfer (Trasferimento di Stato Rappresentazionale), è un modello di progettazione architettonica per la costruzione di API RESTful, che consentono ai servizi di comunicare via HTTP in formati standard, come XML, HTML e JSON. Ma le API REST sono fondamentali per le applicazioni basate su microservizi per diversi motivi.

Le API REST sono leggere e indipendenti dalla piattaforma, ossia forniscono un'interfaccia standardizzata che consente ai microservizi di comunicare, indipendentemente dalla tecnologia sottostante. Poiché le richieste contengono le informazioni necessarie per completare la richiesta, le API REST non richiedono un contesto memorizzato sul server. Possono gestire grandi volumi di richieste senza compromettere le prestazioni, e i servizi in un'architettura di microservizi basata su REST possono evolvere in modo indipendente, comunicando in modo efficiente in modo stateless.

Contenitori

Mentre i microservizi danno ai team la possibilità di scegliere la lingua e il framework del loro servizio, lavorare con diverse lingue nella stessa pipeline CD pone delle sfide. I contenitori astraggono le differenze tra i servizi, in quanto ogni microservizio diventa un'unità autonoma, confezionata con la sua base di codice, il suo database e le sue dipendenze. La pipeline CD, ora omogenea, può eseguire test coerenti su ogni contenitore.

I servizi sono in grado di interagire senza interferire l'uno con l'altro quando sono separati da contenitori e, una volta distribuiti, i contenitori forniscono un ambiente di runtime leggero e portatile che consente ai servizi di funzionare in modo coerente su tutte le piattaforme. Strumenti come Docker e Kubernetes sono ampiamente utilizzati per gestire microservizi containerizzati.

Orchestratore Kubernetes

Uno strumento di orchestrazione come Kubernetes può astrarre l'infrastruttura sottostante e automatizzare la gestione dei container, la distribuzione e la scalabilità su più server. La sua estensibilità consente inoltre agli sviluppatori e agli operatori di utilizzare gli strumenti software open-source e commerciali preferiti, riducendo il lavoro manuale di gestione dei container.

Senza server

L'informatica senza server è un'altra opzione per distribuire microservizi. Le architetture serverless utilizzano piattaforme functions as a service (FaaS) per creare unità di distribuzione ancora più piccole e scalare su richiesta. Sebbene le architetture serverless possano aumentare le dipendenze dai fornitori, offrono una riduzione dei costi operativi, della complessità e dei tempi di progettazione.

Le migliori pratiche dei microservizi

La progettazione di un'architettura di microservizi richiede un'attenta pianificazione e considerazione. Per costruire applicazioni di successo basate su microservizi, gli sviluppatori devono osservare le seguenti best practice:

• Progettazione guidata dal dominio: La progettazione guidata dal dominio (DDD) è un approccio alla progettazione che si concentra sul dominio aziendale e sul comportamento dell'applicazione. Aiuta gli sviluppatori a suddividere l'applicazione in componenti più piccoli e gestibili, rendendo più facile la costruzione, la distribuzione e la manutenzione.
• Limiti del servizio: Quando si progetta un'architettura di microservizi, è essenziale definire confini chiari per i servizi. Ogni microservizio dovrebbe avere una responsabilità ben definita.
• Piccoli servizi: Mantenga i servizi "micro", concentrati su un'unica responsabilità. Perdere di vista questo principio fondamentale significa sacrificare la gestibilità.
• Design API: I microservizi comunicano attraverso le API, quindi utilizza API coerenti, scalabili e sicure che limitano l'accesso ai dati alle applicazioni, agli utenti e ai server autorizzati.
• Gestione decentralizzata dei dati: Le applicazioni a microservizi richiedono una varietà di opzioni di archiviazione e di database. Ogni microservizio dovrebbe avere il proprio archivio dati. Questo approccio aiuta a evitare le incongruenze dei dati e consente di scalare ogni microservizio in modo autonomo. Lei vuole che il team di sviluppo scelga il database per ogni servizio, per assicurarsi che si adatti al meglio al loro progetto.
• Pipeline CI/CD: L'implementazione del CI/CD la aiuterà a trovare e risolvere i bug in modo rapido, il che è particolarmente prezioso con più codebase da gestire in un'architettura di microservizi.
• Resilienza intenzionale: Proteggere l'applicazione dagli arresti per guasto delle dipendenze. Non utilizzi le chiamate di procedura remote (RPC) tra i microservizi, se possibile, e incorpori funzioni come gli interruttori per arrestare i guasti a cascata.
• SOP: Sviluppa procedure operative standard che definiscono le convenzioni di codifica, le strutture di directory e i protocolli di comunicazione. Seguendo una serie di standard, si otterranno microservizi coerenti e gestibili.

Adottare i microservizi

eBay, Etsy, Uber - innumerevoli aziende hanno smantellato le loro applicazioni monolitiche e le hanno rifattorizzate in architetture basate su microservizi per capitalizzare i vantaggi di scala, l'agilità aziendale e i successi finanziari.

Le organizzazioni che intendono passare ai microservizi dovrebbero prima adottare DevOps, che la preparerà a gestire le complessità che incontrerà. A livello di base, anticipi le fasi descritte di seguito quando traccia il suo progetto.

Identificare le capacità aziendali

Il primo passo per migrare all'architettura a microservizi è identificare le funzionalità aziendali o le caratteristiche che la sua applicazione deve supportare. Questo la aiuterà a definire l'ambito della sua applicazione e ad informare le sue decisioni su quali funzionalità dovrebbero essere prioritarie per lo sviluppo, nonché su come questi microservizi dovrebbero essere progettati e integrati tra loro.

Decomporre l'applicazione monolitica

La maggior parte delle organizzazioni utilizza la progettazione guidata dal dominio o la decomposizione basata sulle caratteristiche per scomporre le loro applicazioni monolitiche.

Dopo aver identificato le funzionalità di business dell'applicazione, si definiscono i confini dei servizi per ogni microservizio, assicurandosi che ogni microservizio abbia una responsabilità distinta e ben definita. Dovrà mappare le dipendenze tra le funzionalità aziendali, gli archivi dati e i sistemi esterni. In base ai contesti e alle dipendenze delimitate, definisce i microservizi che sostituiranno l'applicazione monolitica.

Ogni microservizio, focalizzato su una singola capacità aziendale, deve avere interfacce chiare. Esamini il modo in cui si accede alle entità di dati e, infine, consideri come partizionare i dati per ridurre le dipendenze tra i servizi.

Definire le interfacce del servizio

Implementazione delle interfacce di servizio per ogni microservizio, assicurandosi che l'interfaccia rifletta l'unica responsabilità del microservizio. Può utilizzare diverse tecniche, come le API Restful o i protocolli di messaggistica, per definire le interfacce dei servizi.

Implementazione e test dei servizi

In base ai suoi requisiti e alle sue competenze, scelga i linguaggi di programmazione e i framework per implementare i servizi. Iterare il progetto secondo le necessità, compreso il test delle nuove interfacce, dei protocolli di comunicazione e degli archivi dati.

Containerizzare i servizi

Una volta implementati e testati i servizi, vorrà containerizzarli utilizzando le tecnologie di container, come Docker o Kubernetes. La containerizzazione le permetterà di distribuire e gestire i servizi in modo indipendente.

Automatizza la distribuzione e l'orchestrazione

Automatizzare l'orchestrazione dei servizi utilizzando strumenti come Kubernetes o Docker Swarm. Oltre a semplificare in modo efficiente la distribuzione dei servizi, l'automazione attraverso Kubernetes o Docker migliorerà l'affidabilità e la disponibilità dell'applicazione. Entrambe le piattaforme possono rilevare quando un'istanza di servizio si guasta o non risponde e intervenire per risolvere il problema. Kubernetes, ad esempio, può riavviare le istanze fallite o riprogrammarle su altri nodi, mentre Docker può migrare automaticamente il contenitore fallito su un altro nodo.

Monitorare e gestire i Servizi

La decomposizione di un'applicazione monolitica non è un processo unico. Richiede manutenzione e aggiornamenti in base all'evoluzione delle esigenze dell'applicazione e dei suoi utenti. Monitorare i nuovi microservizi e tenere traccia delle metriche chiave, come il tempo di risposta e l'utilizzo delle risorse.

Proteggere i microservizi

Le applicazioni di microservizi altamente distribuite e cloud-native introducono complessità di sicurezza. Invece di un singolo punto di ingresso, sono dotati di decine, se non centinaia, di potenziali punti di vulnerabilità - e ognuno deve essere protetto. Le API e le dipendenze del codice rappresentano solo due fonti di rischio nella superficie di attacco in espansione dell'applicazione moderna.

Sicurezza delle applicazioni web e delle API

Le applicazioni moderne consumano input da una serie di fonti: richieste web standard, chiamate API di dispositivi mobili, eventi cloud, comunicazioni telemetriche di dispositivi IoT, archiviazione cloud, ecc. Inoltre, la richiesta web di un singolo cliente (ossia il traffico nord-sud) può generare centinaia di chiamate API tra microservizi interni (ossia il traffico est-ovest).

La complessità delle applicazioni web incentrate sulle API richiede strategie scalabili, flessibili e multilivello che funzionino per qualsiasi tipo di carico di lavoro in qualsiasi tipo di ambiente o architettura cloud. Proteggere l'interfaccia Web del frontend dell'applicazione cloud-nativa non è sufficiente. Le applicazioni cloud-native richiedono una protezione a livello di applicazione per le API cloud-native. La sicurezza delle applicazioni web e delle API (WAAS) è essenziale.

Dipendenze del codice e analisi della composizione del software

I componenti software open-source costituiscono circa il 70% delle applicazioni cloud-native. Sebbene questo acceleri lo sviluppo, molti pacchetti open-source e le loro dipendenze contengono vulnerabilità. Inoltre, ogni versione di un pacchetto OSS basato sulle dipendenze può cambiare funzionalità critiche. Senza una visibilità completa, le vulnerabilità non vengono individuate.

Standalone analisi della composizione del software (SCA) evidenziano i rischi dell'open-source troppo tardi nel ciclo di vita dello sviluppo, il che provoca un arretrato di vulnerabilità che non sempre possono essere risolte. Strumenti separati per SCA e sicurezza IaC danno luogo ad avvisi rumorosi senza contesto e conoscenza dei rischi interconnessi. Poiché le lacune sono inevitabili senza copertura del runtime e del carico di lavoro, è meglio proteggere le applicazioni cloud-native con una sicurezza integrata cloud-native.

Code-to-Cloud CNAPP

Identificando e dando priorità ai rischi critici dell'intera applicazione cloud-nativa, una piattaforma di protezione delle applicazioni cloud-native (CNAPP) integra diversi tipi di sicurezza per offrire una protezione completa dal codice al cloud: gestione della postura di sicurezza del cloud (CSPM), protezione del carico di lavoro del cloud, gestione dell'abilitazione dell'infrastruttura del cloud (CIEM), gestione della postura di sicurezza di Kubernetes (KSPM), sicurezza dell'infrastructure-as-code, WAAS, SCA e altro.

La leadership della sicurezza del cloud che sta esplorando il modo migliore per proteggere le esigenze di sviluppo rapido delle applicazioni che impiegano tecnologie cloud-native, come i container, i microservizi e le funzioni serverless, dovrebbe considerare l'adozione di un CNAPP.

Domande frequenti sui microservizi