Video: Un nuovo approccio architetturale: i microservizi. (Novembre 2024)
Il panorama del software aziendale è disseminato di tecnologie dinamiche. Ne abbiamo scritti molti, che si tratti di blockchain, sviluppo di codici bassi o altre tendenze emergenti che stanno cambiando il nostro modo di lavorare. Una nuova parola d'ordine di cui potresti non aver sentito parlare prima è "microservizi".
Questo è di progettazione. I microservizi sono un modo diverso di progettare software basato su una serie di componenti modulari intrecciati piuttosto che sull'idea tradizionale di un "monolito", un'applicazione composta da una montagna di codice in continua crescita. Le app basate su microservizi non sembrano diverse dal lato dell'interfaccia utente (UI), sia che si tratti di un'app per data center complessa o di un'app Web o mobile ospitata su un'infrastruttura cloud scalabile.
Il motivo per cui le aziende dovrebbero preoccuparsi dei microservizi è che, dietro le quinte, l'architettura può aiutare lo sviluppo e i team IT a lavorare e innovare più velocemente, gestire l'infrastruttura e ridurre i costi e la complessità dell'aggiunta di nuove funzionalità e funzionalità a un'app. Al Hilwa, direttore del programma per la ricerca di software per lo sviluppo di applicazioni presso IDC, ha spiegato come avrebbe lanciato microservizi a un dirigente tenendo presente le sfide sia culturali che tecnologiche.
"Quando si costruiscono nuovi sistemi, probabilmente il punto chiave è riconoscere che un singolo microservizio dovrebbe essere costruito da un piccolo team", ha affermato Hilwa. "In secondo luogo, una tolleranza della diversità nei linguaggi di programmazione e nei flussi di lavoro degli sviluppatori è spesso implicata dalla natura indipendente di una cultura generale dei microservizi. Il tono principale di un dirigente è costruire software in modo incrementale usando piccoli team, ognuno dei quali costruisce un modulo coerente con un pubblicato interfaccia. Il vantaggio è che i moduli indipendenti possono essere evoluti a un ritmo molto più veloce indipendentemente se le API pubblicate sono gestite in modo organizzato."
Cosa sono davvero i microservizi?
Hilwa è autore di un rapporto IDC del 2015 intitolato "L'emergere dei microservizi come nuovo approccio architettonico alla costruzione di nuovi sistemi software". Nel rapporto, definisce i microservizi come un'architettura software granulare in cui i componenti dell'app sono progettati ed evoluti in modo indipendente per soddisfare i requisiti di interoperabilità definiti dall'API (ovvero, collegati nuovamente all'app nel suo insieme). Tuttavia, i microservizi non esistono nel vuoto. Una nuova architettura richiede un forte supporto organizzativo e un cambiamento nella cultura IT.
Inoltre, i microservizi non sono definiti da nessuna specifica tecnologia, ma come l'evoluzione del concetto di lunga data di architettura orientata ai servizi (SOA), accresciuta dall'avvento dei container e dalla crescita dell'automazione attraverso approcci di sviluppo come la consegna continua (CD) e l'integrazione continua (CI).
"Le organizzazioni che utilizzano microservizi oggi sono in genere motivate dal desiderio di un ritmo più rapido di evoluzione del servizio", ha affermato Hilwa. "Pertanto, nella maggior parte dei casi, i microservizi utilizzano l'automazione CI / CD in larga misura. Tuttavia, il ritmo della distribuzione effettiva può essere diverso tra i servizi. Penso che la chiave sia dare una buona occhiata alla cultura interna ed essere sicuro di essere disposto a tollerare una maggiore decentralizzazione e diversità nello stack tecnologico ".
Per "cultura interna" Hilwa si riferisce in gran parte a DevOps, una filosofia che combina lo sviluppo del software, le operazioni IT e la garanzia della qualità (QA) in un unico flusso di lavoro collaborativo. L'avvio del software DevOps HashiCorp e i suoi fondatori sono stati a lungo sostenitori dei microservizi. La società, che ha recentemente ottenuto un round di finanziamenti della Serie B da $ 24 milioni, annovera tra i suoi utenti open source e clienti aziendali aziende come Cisco, DigitalOcean, Mozilla e Stripe.
I microservizi sono fondamentali per l'approccio di HashiCorp allo sviluppo dell'infrastruttura DevOps e ai flussi di lavoro delle app attraverso i suoi popolari strumenti open source e la crescente suite di prodotti aziendali. Armon Dadgar, CTO e co-fondatore di HashiCorp, ha abbattuto la differenza tra monoliti e microservizi usando una semplice analogia: Amazon ed eBay.
"Pensa ad Amazon ed eBay come singole applicazioni. Dal punto di vista dell'utente finale, sembrano simili ma, dietro le quinte, le aziende hanno adottato approcci opposti nel modo in cui hanno costruito e progettato le loro applicazioni", ha affermato Dadgar. "Amazon sin dall'inizio è stato un insieme di microservizi; agisce come un'unica app. Ma se prendi la ricerca, il catalogo prodotti, il carrello della spesa, le fatture, i flussi di ordini e dividi quelle funzioni, le due applicazioni funzionano su diversi macchine ".
L'analogia di Amazon si estende anche al modo in cui Amazon stessa è strutturata. Dadgar spiega gli approcci tecnologici come i microservizi come strumenti per supportare il più ampio movimento di processo verso DevOps. "Two Pizza Rule" di Jeff Bezos funziona in modo tale che solo tra le cinque e le otto persone fanno parte di un determinato team di Amazon. Se la squadra diventa più grande, si divide in due.
La gerarchia organizzativa di Amazon inizia a mappare verso quella che Dadgar ha descritto come una "scomposizione della funzionalità". Separato sia a livello di organizzazione che a livello di architettura modulare, ogni team ha quindi la capacità di svilupparsi e sperimentare più liberamente, senza la necessità di coordinarsi su ogni cambiamento, pur continuando a funzionare come parte di un'unica app coesiva.
"eBay ha adottato l'approccio monolitico; ha costruito tutta eBay come una lunga linea da 50 milioni di applicazioni di codice", ha affermato Dadgar. "L'approccio ai microservizi è più doloroso all'inizio perché i problemi di modularità e interoperabilità sono quelli che non esistono in un monolito. Ma le cose iniziano a crollare quando l'app diventa troppo grande. In un monolito, non c'è decomposizione.
"Pensa a centinaia o migliaia di sviluppatori che collaborano su una singola base di codice e provano a coordinarsi. Un team di QA che aggiunge funzionalità su un lato dell'applicazione potrebbe interrompere qualcosa dall'altra parte perché non c'è una chiara separazione di ruoli e responsabilità. si inizia a necessitare di un coordinamento sempre maggiore tra i project manager e un processo di controllo della qualità che può richiedere settimane e lo sviluppo di colli di bottiglia, non importa quanto velocemente il team lavori. Sono troppi i cuochi in cucina."
Container e microservizi in un mondo DevOps
Il modo in cui la tua azienda implementa un'architettura di microservizi farà molto per determinare se l'investimento paga o meno. I microservizi richiedono molto lavoro in anticipo, in particolare nell'integrazione dell'API necessaria per assicurarsi che tutti i servizi si parlino. Hilwa ha spiegato che è ancora più complicato quando si cerca di integrare i microservizi in un sistema esistente; raccomanda alle aziende di costruire nuovi sistemi ogni volta che è possibile, piuttosto che riprogettare un'app monolite legacy per microservizi.
"Le architetture di sistema tradizionali in genere implicano sistemi di database di grandi dimensioni e complessi con schemi elaborati e normalizzati", ha affermato Hilwa. "Il factoring di tali sistemi in componenti più piccoli con i loro sistemi indipendenti richiede molto lavoro di progettazione del database e riscrittura efficace della maggior parte della logica di applicazione principale. Ciò è generalmente proibitivo in termini di costi e di tempo nella maggior parte dei casi."
Se riprogetti un'app legacy, Hilwa ti consiglia di farlo in modo incrementale. Sebbene sia ancora più importante dell'integrazione API, i microservizi non funzionano senza la cultura DevOps dietro di essa. Dadgar di HashiCorp ha affermato che, quando si tratta dell'ampio ombrello di DevOps, i microservizi diventano uno strumento per facilitare un più ampio spostamento del processo verso la modifica sostanziale dei flussi di lavoro con cui forniamo le app. Ha indicato il Tao di HashiCorp presentato quando lui e il co-fondatore Mitchell Hashimoto hanno fondato l'azienda: semplice, modulare e componibile.
"DevOps in un certo senso è un termine ancora più sovraccarico dei microservizi", ha detto Dadgar. "Ma un'azienda è composta da persone con diverse specialità di conoscenza: sviluppatori, operatori, responsabili della sicurezza. E poi hai un processo, il modo in cui organizzi quelle persone. Quindi hai gli strumenti per supportare quel processo, che è dove microservizi e container entra."
I container, resi popolari dall'esplosione open source di Docker, sono lungi dall'essere l'unico strumento che le aziende possono utilizzare per facilitare i microservizi. Hilwa di IDC ha affermato che i contenitori vengono utilizzati nelle app moderne come parte dei flussi di lavoro CI / CD e, in alcuni casi, durante la distribuzione alla produzione. Ma ha detto che i microservizi possono sfruttare anche le macchine virtuali (VM), senza la necessità di contenitori.
Detto questo, quando si tratta dei modi in cui i cloud aziendali si stanno evolvendo, i contenitori e i microservizi Docker sono una potente combinazione di strumenti che viene abbracciata da aziende di tutte le forme e dimensioni, dalle startup come HashiCorp ai giganti aziendali come Oracle. Dadgar di HashiCorp ha detto che i container sono i mezzi convenienti con cui Dev e Ops (e, per associazione, diversi team e servizi) comunicano tra loro.
"Qual è il manufatto che stiamo passando tra gli sviluppatori e gli operatori? Cosa stiamo scorrendo a fondo e costruendo? I contenitori sono un'unità conveniente per passare", ha detto Dadgar. "Pensa a un prodotto di spedizione aziendale globale in tutto il mondo. Che si tratti di una nave mercantile, un treno merci o un camion, è la stessa unità che scorre attraverso l'intero sistema."
DevOps e microservizi sono ancora lontani dall'adozione diffusa da parte delle imprese, ma il mercato è in crescita. Secondo il rapporto IDC, l'architettura dei microservizi entrerà in una fase di maturazione nei prossimi cinque anni. Questa maturità avverrà sulla scia della cultura DevOps che raggiungerà il 50% delle organizzazioni entro il 2020, la continua evoluzione degli strumenti di automazione del software e il dominio di infrastrutture cloud scalabili a basso costo fornite da Amazon Web Services (AWS) e Microsoft Azure.
Dadgar ha affermato che, anche se la piccola parte delle aziende abbraccia DevOps e microservizi al momento, HashiCorp è già ampiamente sottoscritta. Ha raggiunto i suoi primi ricavi a sette cifre dopo soli nove mesi di vendite aziendali, oltre a una comunità open source su GitHub di diversi milioni di utenti attivi mensili. I microservizi sono solo una parte della pipeline degli strumenti per le app del flusso di lavoro di HashiCorp e della roadmap dell'infrastruttura DevOps più ampia. Ma la modularità e l'interoperabilità alla base di tutto ciò che l'azienda costruisce ha alimentato l'ascesa meteorica di una delle startup di software più in voga nella Silicon Valley.
"Quattro anni fa, quando abbiamo iniziato, partecipavamo alle riunioni e proponevamo la nostra visione di come sarebbero state gestite le infrastrutture", ha affermato Dadgar. "Non siamo stati esattamente derisi dalla stanza; sapevamo che era all'inizio. Ma ora i nostri strumenti come Terraform sono sulla buona strada per diventare standard del settore. Quello che vedremo è un effetto domino di pressione competitiva e, nel a lungo termine, il nostro ruolo lavorerà con CIO e CTO per comprendere il cambiamento di processo che devono prendere.
"Pensa alla Toyota nel passato", ha continuato Dadgar. "Avevi un sacco di case automobilistiche che costruivano prodotti ma il costo era più alto di quanto avrebbe dovuto. La Toyota non ha reinventato ciò che un'auto era; erano solo più rigorosi e incrementali nel processo, e sono passati dalle risate alla centrale elettrica, costringendo il il resto del settore ad adottare lo stesso insieme di pratiche per rimanere competitivo. In questo momento, abbiamo leader del settore che chiedono come possono ottenere un vantaggio competitivo e la loro risposta è adottare le pratiche dei googles e delle amazzoni del mercato. punto, colpirà una massa critica ".
