Quali sono i vantaggi dei microservizi e pagheranno per la tua attività?

Il concetto di microservizi, un approccio alla progettazione di un'applicazione software come un insieme di piccoli servizi, esiste almeno dal 2015. Offrendo vantaggi come la distribuzione indipendente e la scalabilità dei componenti, i microservizi sono oggi di gran moda. Questo perché questi vantaggi dei microservizi si traducono in velocità di sviluppo software incredibilmente più elevate. Con i consumatori che cambiano rapidamente le loro preferenze e comportamenti, gli utenti di microservizi sono in grado di tenere il passo. La vita ora è fantastica, dicono. Ben il 56% delle aziende partecipanti a un recente sondaggio IMB prevede di adottare un approccio basato sui microservizi nei prossimi 24 mesi.

Quasi l'80% degli utenti attuali afferma che la propria attività probabilmente aumenterà gli investimenti nei microservizi. I vantaggi dei microservizi hanno spinto Netflix, Amazon, eBay, Twitter e molti altri giganti della tecnologia a migrare dall'architettura monolitica a quella dei microservizi. Ma la tua azienda dovrebbe utilizzare i microservizi? Dipende dal contesto e se i vantaggi dei microservizi superano i contro per la tua applicazione. Questo blog offre una panoramica di un approccio tra microservizi e approccio monolitico e cinque vantaggi chiave dell'uso di un'architettura di microservizi. Condivide anche parte dell'esperienza dei microservizi di ITRex e offre suggerimenti su quando le aziende dovrebbero (non) utilizzare i microservizi. Gettarsi.

Definizione e confronto di microservizi con architettura monolitica

Che cos'è un'architettura di microservizi ? Uno stile di microservizi è un approccio allo sviluppo di applicazioni software native del cloud come una suite di piccoli componenti o servizi progettati attorno a un unico flusso di lavoro aziendale e che funzionano insieme. In sostanza, i microservizi fanno parte di un passaggio fondamentale a DevOps, una cultura in cui i team di sviluppo e operazioni IT cooperano strettamente utilizzando strumenti di automazione per fornire più rapidamente.

Microservizi:

• si sviluppano autonomamente,
• utilizzano il proprio database e possono essere scritti in diverse lingue,
• comunicare tramite API con protocolli leggeri come HTTP, broker di messaggi o streaming di eventi e
• eseguire una specifica funzionalità aziendale.

Ad esempio, un'applicazione di e-commerce basata su microservizi potrebbe avere servizi indipendenti responsabili delle immagini dei prodotti, della gestione del profilo utente, della ricerca, della verifica dell'inventario, dell'elaborazione dei pagamenti e della spedizione. Il front end (il lato rivolto al cliente del sito Web) è disaccoppiato dal back end (il lato rivolto al business) in modo che sia possibile personalizzarli e gestirli separatamente. Se prendi un esempio di Amazon, un'architettura di microservizi potrebbe sembrare opprimente, se non terrificante.

Tuttavia, senza l'utilizzo di un'architettura di microservizi, Amazon difficilmente si sarebbe evoluta in una delle aziende più preziose al mondo (valutata da una capitalizzazione di mercato di $ 1,694 trilioni a dicembre 2021). La decisione di sfruttare i vantaggi dei microservizi è stata presa all'inizio degli anni 2000, quando Amazon ha capito che non riusciva a scalare alla velocità della crescita della base clienti a causa di problemi di sviluppo e codifica lenti.

Netflix ha scoperto i vantaggi di un'architettura di microservizi basata su cloud alla fine degli anni 2000 dopo che non è stato in grado di inviare DVD ai clienti per alcuni giorni a causa di una massiccia corruzione del database. Dopo aver suddiviso la loro applicazione in oltre 700 microservizi, gli ingegneri Netflix sono oggi in grado di distribuire il codice migliaia di volte al giorno, consentendo all'azienda di trasmettere in streaming circa 250 milioni di ore di contenuti al giorno a oltre 200 milioni di membri in tutto il mondo. Quale architettura utilizzavano in precedenza queste star della tecnologia e molte altre aziende, nei giorni pre-cloud? Hanno usato monoliti.

Cos'è un'architettura monolitica?

Un'applicazione monolitica viene creata come una singola unità che combina tutti i componenti, tra cui un'interfaccia utente lato client, operazioni lato server e un database. Tipicamente, un'architettura monolitica:

• ha un'unica base di codice per tutte le funzionalità,
• è strettamente accoppiato, e
• utilizza dati centralizzati.

Un'applicazione di e-commerce sviluppata utilizzando un approccio monolitico consisterebbe in servizi front-end e back-end strettamente accoppiati distribuiti come un'unica unità, il che significa che qualsiasi personalizzazione richiederebbe modifiche nella codebase e nella piattaforma front-end (vedere il diagramma seguente per confronto).

Le applicazioni monolitiche sono tutt'altro che morte. In realtà, possono comunque essere una buona scelta perché spesso sono più facili ed economici da costruire (almeno all'inizio). Tuttavia, hanno degli svantaggi. Una modifica in una parte, per scopi di aggiornamento o ridimensionamento, spesso richiede la ricostruzione e la ridistribuzione dell'intero sistema.

Allo stesso modo, l'intero sistema può essere abbattuto da una parte che si comporta male, il che significa che i monoliti sono fragili. Anche i monoliti sono difficili da mantenere man mano che crescono e nemmeno l'integrazione con strumenti di terze parti è una gioia. Questi inconvenienti sono difficili da ignorare nell'attuale contesto di mercato dirompente in cui le aziende dovrebbero reagire rapidamente ai cambiamenti per sopravvivere e prosperare. Da qui il clamore sui vantaggi dei microservizi creati dai team DevOps.

5 vantaggi chiave dei microservizi

1. Distribuzione indipendente

Questo è forse il vantaggio più importante dei microservizi, almeno secondo Sam Newman, uno dei primi pionieri dei microservizi. Apportare modifiche a un'applicazione per migliorare le prestazioni o aggiungere una nuova funzionalità in risposta alle esigenze emergenti degli utenti è un gioco da ragazzi con i microservizi autonomi. Ogni servizio può essere modificato e aggiornato senza toccare l'intero sistema. Possono essere ridimensionati anche indipendentemente l'uno dall'altro se una funzionalità è sottoposta a un carico eccessivo a causa di richieste in eccesso. Ad esempio, puoi ridimensionare il tuo servizio di elaborazione dei pagamenti solo se ricevi più pagamenti, senza aumentare il consumo di risorse da parte di altri servizi. In questo modo il processo richiede meno infrastrutture e porta a risparmi sui costi.

2. Raggio di rottura dell'esplosione inferiore

L'accoppiamento libero di un'architettura di microservizi fornisce anche un altro vantaggio dei microservizi: una migliore resilienza. I confini chiari tra i servizi, insieme alle loro micro dimensioni, limitano l'impatto delle nuove versioni e garantiscono l'isolamento dei guasti. Un errore in un servizio non elimina le funzionalità non correlate, mentre il resto del sistema rimane intatto e continua a fornire servizi agli utenti.

3. Isolamento dei dati

Questo è un terzo vantaggio che i microservizi offrono se eseguiti correttamente. La sovranità dei dati per componente è una caratteristica essenziale dei microservizi. Un'architettura di microservizi consente di delineare chiaramente i servizi che toccano i dati, il che è fondamentale, soprattutto se l'organizzazione deve conformarsi alle normative sui dati sanitari o al GDPR.

4. Uso della giusta tecnologia

Poiché le applicazioni monolitiche hanno un'unica base di codice, è difficile personalizzare un approccio tecnologico per ciascuna funzionalità e spesso si cerca un compromesso. I microservizi, al contrario, sono progettati in base alle capacità aziendali per impostazione predefinita, consentendo ai team di scegliere la migliore tecnologia disponibile per una particolare funzionalità per trarne il massimo. Questo perché i microservizi possono usare diverse tecnologie o linguaggi di programmazione per diversi componenti. I microservizi semplificano inoltre l'adozione della tecnologia più recente o l'integrazione con strumenti di terze parti secondo necessità. L'assenza di vendor lock-in è un altro vantaggio dei microservizi che deriva naturalmente dalla sua architettura debolmente accoppiata.

5. Efficienza

L'approccio dei microservizi consente alle aziende di creare piccoli team interfunzionali attorno a un servizio o una suite di servizi che possono operare in modo agile. Questo modello riduce al minimo gli handoff quando un team deve attendere che un altro completi la propria attività, che si tratti di distribuzione o test, prima di poter iniziare il proprio lavoro. Senza dipendenza da un altro team, la velocità di sviluppo accelera. Secondo il sondaggio IMB su 1.200 dirigenti e sviluppatori IT, gli utenti stanno segnalando molteplici vantaggi derivanti dall'utilizzo dei microservizi. I vantaggi più importanti dei microservizi che hanno riscontrato includono: 30% — Maggiore soddisfazione del cliente 29% — Migliore sicurezza dei dati dell'azienda/cliente 29% — Time to market più rapido 28% — Prestazioni delle applicazioni migliorate 27% — Maggiore flessibilità per aumentare o aumentare le risorse in calo del 26% — Miglioramento della produttività dei dipendenti Ci sono problemi con i microservizi? Bene, come dice una citazione popolare, i microservizi non sono un pranzo gratuito. Continuare a leggere.

La parte negativa dei microservizi

1. Complessità

La complessità intrinseca dei microservizi aumenta con il numero di servizi. Questa complessità è molteplice e attribuita a quanto segue:

• Il controllo dall'alto verso il basso a livello tecnologico e operativo è impossibile
• I test sono difficili e non ci sarà mai troppa automazione dei test
• L'implementazione delle intercomunicazioni è complicata, quindi sono necessari sviluppatori di talento
• La quantità di dati registrati è troppo grande, il che potrebbe portare alla sua incoerenza
• Potrebbero sorgere problemi di compatibilità con le nuove versioni
• Ci sono difficoltà con il provisioning della giusta quantità di risorse

2. Costi

I microservizi offrono alle aziende più opzioni per guadagnare denaro ma non per salvarlo. Oltre al costo di assunzione di sviluppatori in grado di creare un ambiente di microservizi complesso, ci sono fatture cloud e API. La buona notizia è che i costi correnti possono essere notevolmente ottimizzati poiché i microservizi utilizzano risorse su richiesta in base al consumo.

3. Rischi per la sicurezza

La metà degli intervistati nel sondaggio IBM ha citato la sicurezza tra le principali sfide che hanno dovuto affrontare nel percorso di adozione dei microservizi. La sicurezza deve essere integrata fin dall'inizio poiché ogni microservizio ha il proprio set di punti di ingresso per comunicare con gli altri tramite vari livelli di infrastruttura, portando a una maggiore esposizione delle applicazioni agli attacchi. Inoltre, la scalabilità dell'infrastruttura amplifica il rischio di perdere il controllo e la visibilità dei componenti dell'applicazione.

Quando (non) utilizzare i microservizi

E infine, la nostra ultima domanda: quando l'architettura dei microservizi vale la seccatura? Sebbene il ronzio dietro i microservizi come adattamento naturale per le applicazioni native del cloud sia tutto garantito, non dovrebbero essere il tuo stile predefinito. La letteratura lo dice semplicemente: inizia con un monolito e dividilo quando incontri problemi di scalabilità o consumo di risorse o qualsiasi altra cosa che giustifichi il percorso dei microservizi.

Ecco i nostri suggerimenti chiave quando NON utilizzare i microservizi:

1. Se sei una startup, i microservizi sono una cattiva idea. Sarà più saggio iniziare con un'applicazione monolitica e suddividerla in componenti più piccoli quando diventa troppo difficile per una squadra di due pizzaioli. Quello che vuoi è eseguire esperimenti economici piuttosto che investire un sacco di tempo, fatica e denaro nella costruzione di un'architettura complessa per un prodotto il cui valore per il cliente deve ancora essere convalidato. I monoliti sono un modo perfetto per testare (e scartare) gli MVP per imparare velocemente cosa porterà valore ai tuoi clienti. Come afferma Martin Fowler, un altro guru dei microservizi molto rispettato: i) Quasi tutte le storie di successo sui microservizi sono iniziate con un monolito che è diventato troppo grande e si è rotto. ii) Quasi tutti i casi in cui ho sentito parlare di un sistema che è stato costruito da zero come sistema di microservizi, è finito in guai seri. Nota: se il dominio del prodotto è incerto, non dovresti nemmeno usare i microservizi all'inizio. Potrebbe essere troppo presto per lanciarsi in complesse decisioni architettoniche, ed è probabile che il tuo approccio alla creazione di comunicazioni e confini sarà fuori luogo quando il tuo progetto maturerà.

2. I microservizi non sono un'ottima scelta per una soluzione che non è complessa e può essere gestita da un team relativamente piccolo. L'implementazione di una complessa architettura di microservizi per lo strumento di pianificazione degli eventi della tua azienda potrebbe davvero divertire i tuoi sviluppatori, ma ne varrà la pena? I microservizi sono in primo luogo progettati per affrontare un problema: la complessità. Come afferma Martin Fowler, "non considerare nemmeno i microservizi a meno che tu non abbia un sistema troppo complesso da gestire come un monolito".

3. Non scegliere i microservizi se la tua applicazione è troppo piccola per giustificarli. I tuoi sistemi di gestione dell'inventario o di acquisto devono essere convertiti in microservizi se funzionano perfettamente come dovrebbero? Ancora una volta, l'idea di usare i microservizi è quella di suddividere un'applicazione complessa in un insieme di servizi più piccoli. La scomposizione di un codice che è già piccolo e semplice avrebbe solo l'effetto di aggiungere complessità: ora devi affrontare tutti i problemi di distribuzione, interoperabilità e debug con una moltitudine di artefatti invece di distribuire l'intera unità in un buon vecchio modo.

OK, allora, ma quando utilizzare i microservizi per trarne vantaggio?

I microservizi hanno senso quando una qualsiasi delle affermazioni di cui sopra è falsa. In altre parole:

• Quando il tuo prodotto si evolve in qualcosa di complesso che deve essere domato o quando vuoi stare al passo con i cambiamenti e aggiungere funzionalità importanti che sarebbero altrimenti impossibili da implementare a causa dei colli di bottiglia dell'architettura monolitica.
• Quando si costruisce da zero un prodotto grande e complesso con un ambito definito. Ogni volta che un'azienda desidera organizzare dozzine di sviluppatori per creare una soluzione su larga scala con un chiaro insieme di funzionalità, dovrebbe prendere in considerazione la creazione di piccoli team interfunzionali, ciascuno responsabile di un singolo componente. In questo modo ogni team può lavorare in modo indipendente, con persone dedicate che gestiscono la gestione delle API, le pipeline di dati, gli schemi e altre funzionalità.

Un esempio equo e reale del portafoglio ITRex sarebbe uno strumento di sicurezza informatica interno che il cliente desiderava convertire in una piattaforma Security-as-a-Service. I microservizi sono stati una scelta naturale per questo progetto perché un'architettura monolitica non è in grado di fornire la scalabilità di cui una soluzione SaaS ha bisogno per servire il numero crescente di clienti o la flessibilità per evolversi e stare al passo con gli hacker.

Un altro progetto illustrativo era una piattaforma di big data basata sull'intelligenza artificiale per un rivenditore globale. Il nostro cliente desiderava una soluzione indipendente dal cloud costruita da zero. Era chiaro fin dall'inizio che la piattaforma avrebbe gestito tonnellate di dati e avrebbe dovuto essere progettata come scalabile per far fronte a nuove fonti di dati da aggiungere in futuro. Abbiamo anche dovuto tenere conto della necessità di creare comunicazioni con più servizi esterni. Quindi anche realizzare i vantaggi dei microservizi in questo progetto è stata una strategia naturale. L'architettura dei microservizi ci ha consentito di implementare senza problemi questo sistema complesso, utilizzando Kubernetes per l'orchestrazione di microservizi e API.

E c'era uno specchio per il fitness basato sull'intelligenza artificiale dotato di fotocamere 3D e un modello ML fornito con sensori IoT collegati all'attrezzatura dell'utente. I suoi componenti principali, tra cui un pannello di amministrazione, un'app Android e un sistema di gestione delle regole, erano stati creati da diversi team in diverse fasi del progetto, ciascuno utilizzando un codice e un'architettura diversi. Quando la complessità di gestirli tutti è diventata schiacciante, abbiamo capito che dovevamo creare un back-end per la gestione centralizzata. E li abbiamo convertiti in microservizi, riprogettando il loro codice e creando nuovi database. C'erano altri vantaggi nell'utilizzo di un approccio basato sui microservizi, come evitare la duplicazione di codice o funzionalità.

Pertanto, secondo la nostra esperienza, è preferibile utilizzare i microservizi quando è necessario gestire volumi di dati crescenti, gestire complessità di interoperazioni o garantire che il sistema sia sufficientemente flessibile per evolversi con l'azienda.

Nota di chiusura

La rivoluzione dei microservizi si sta svolgendo mentre le aziende stanno realizzando i vantaggi dei microservizi per ottenere un vantaggio nel mercato. I vantaggi dei microservizi consentono alle organizzazioni di essere agili e agili in mezzo a interruzioni che sono diventate la nuova normalità. Essere in grado di distribuire software migliore, più velocemente li rende pronti per tutto ciò che viene dopo "qual è il prossimo". Prima di seguire l'esempio, è solo importante sapere quali vantaggi dei microservizi possono essere disponibili per la tua azienda e se la seccatura sarà giustificata. Oltre a questo, i microservizi possono fare miracoli.

Sei ancora confuso se la tua azienda debba innamorarsi dei vantaggi dei microservizi? Mettiti in contatto con i consulenti ITRex. Ti aiuteremo a capirlo.

Pubblicato originariamente su https://itrexgroup.com il 10 gennaio 2022.