{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microservizi: cosa sono, a cosa servono e quando \u00e8 necessario implementarli","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Volevo scrivere un articolo sulla microservizi da tempo, ma sono sempre stato fermato da due aspetti: pi\u00f9 mi immergevo nell'argomento, pi\u00f9 mi sembrava che ci\u00f2 che sapevo fosse ovvio, mentre ci\u00f2 che non sapevo richiedesse ancora studio. D'altra parte, ritengo che ci sia gi\u00e0 molto di cui discutere con un pubblico pi\u00f9 ampio. Pertanto, opinioni alternative sono benvenute.
\n<\/a><\/noindex><\/p>\n

La legge di Conway e il legame tra affari, organizzazione e sistema informativo<\/h2>\n

\nPermettetemi di citare ancora una volta:<\/p>\n

\u00abQualsiasi organizzazione che progetti un sistema (in senso ampio) otterr\u00e0 un design la cui struttura copia la struttura delle squadre in quell'organizzazione\u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

A mio avviso, questa legge si riferisce pi\u00f9 alla ragionevolezza di organizzare un'impresa piuttosto che direttamente a un sistema informatico. Spiegher\u00f2 con un esempio. Supponiamo di avere un'opportunit\u00e0 imprenditoriale abbastanza stabile con un ciclo di vita cos\u00ec lungo da giustificare l'organizzazione di un'iniziativa (non \u00e8 un errore di battitura, ma mi piace molto questo termine che ho ripreso). \u00c8 naturale che il sistema a supporto di questo business sia organizzativamente e processualmente in linea con esso.<\/p>\n

Orientamento al business dei sistemi informatici<\/h2>\n

\n\"Microservizi:
\n
\nSpiegher\u00f2 con un esempio. Supponiamo di avere un'opportunit\u00e0 imprenditoriale per organizzare un'attivit\u00e0 di vendita di pizze. Nella versione V1 (chiamiamola pre-informativa), l'azienda era una pizzeria, una cassa e un servizio di consegna. Questa versione \u00e8 durata a lungo in condizioni di bassa variabilit\u00e0 del mondo circostante. Poi \u00e8 arrivata la versione 2 \u2014 pi\u00f9 avanzata e in grado di utilizzare un sistema informatico come base per un business con architettura monolitica. E qui, a mio avviso, si presenta una vera e propria ingiustizia nei confronti dei monoliti \u2014 un'architettura monolitica apparentemente non corrisponde al modello di dominio aziendale<\/b>. Se cos\u00ec fosse, il sistema non potrebbe funzionare affatto - in contraddizione con la stessa legge di Conway e il buon senso. No, l'architettura monolitica si adatta perfettamente al modello di business in questa fase di sviluppo dell'azienda \u2014 e intendo ovviamente la fase in cui il sistema \u00e8 gi\u00e0 stato creato e messo in produzione. Il fatto sorprendente \u00e8 che, indipendentemente dall'approccio architettonico, sia l'architettura orientata ai servizi versione 3 sia l'architettura a microservizi versione N funzioneranno altrettanto bene. Qual \u00e8 il trucco?<\/p>\n

Tutto scorre, tutto cambia o i microservizi sono un mezzo per combattere la complessit\u00e0?<\/h2>\n

\n Prima di continuare, esaminiamo alcuni dei fraintendimenti riguardanti l'architettura a microservizi.<\/p>\n

I sostenitori dell'approccio ai microservizi affermano spesso che suddividere un monolite in microservizi semplifica lo sviluppo riducendo la base di codice di singoli servizi. A mio avviso, questa affermazione \u00e8 completamente insensata. Sul serio, l'interazione evidente all'interno di un monolito e di codice omogeneo sembra complessa? Se fosse davvero cos\u00ec, tutti i progetti sarebbero inizialmente costruiti come microservizi, mentre la pratica dimostra che la migrazione da un monolite ai microservizi \u00e8 molto pi\u00f9 comune. La complessit\u00e0 non scompare, semplicemente si sposta da singoli moduli a interfacce (che siano bus dei dati, RPC, API e altri protocolli) e sistemi di orchestrazione. E questo \u00e8 difficile! <\/p>\n

Il vantaggio di utilizzare uno stack eterogeneo \u00e8 anch'esso discutibile. Non dir\u00f2 che ci\u00f2 sia impossibile, ma nella realt\u00e0 \u00e8 raro (A proposito, dovrebbe avvenire \u2013 ma pi\u00f9 come conseguenza che come vantaggio).<\/p>\n

Il ciclo di vita del prodotto e il ciclo di vita del servizio<\/h2>\n

\nDai un'occhiata di nuovo al diagramma sopra. Non ho segnato casualmente la diminuzione del ciclo di vita di una singola versione aziendale: nelle condizioni moderne, \u00e8 proprio l'accelerazione del passaggio dell'azienda tra le versioni a determinare il suo successo. Il successo del prodotto \u00e8 definito dalla velocit\u00e0 con cui vengono verificate le ipotesi aziendali al suo interno.<\/b>. E qui, a mio avviso, si trova il principale vantaggio dell'architettura a microservizi. Ma andiamo con ordine. <\/p>\n

Passiamo al prossimo stadio dell'evoluzione dei sistemi informatici: l'architettura orientata ai servizi SOA. Quindi, a un certo punto, abbiamo identificato nel nostro prodotto servizi a lunga durata<\/b> \u2014 servizi che, nel passaggio tra le versioni del prodotto, hanno la possibilit\u00e0 di avere un ciclo di vita pi\u00f9 lungo rispetto al ciclo di vita di una nuova versione del prodotto. Sarebbe logico non modificarli affatto: ci\u00f2 che ci interessa \u00e8 proprio la velocit\u00e0 nel passare alla versione successiva. \u00c8 proprio questo il nostro obiettivo.<\/b>. Ma purtroppo, siamo costretti a apportare modifiche costanti ai servizi \u2014 e qui ci viene in aiuto qualsiasi pratica, sia il DevOps che la containerizzazione e altro \u2014 qualsiasi cosa venga in mente. Ma questo non \u00e8 ancora microservizio! <\/p>\n

I microservizi come strumento per gestire la complessit\u00e0\u2026 della gestione della configurazione<\/h2>\n

\n E qui possiamo finalmente fare riferimento al ruolo chiave dei microservizi: si tratta di un approccio che semplifica la gestione della configurazione del prodotto. Pi\u00f9 precisamente, la funzione di ciascun microservizio descrive una specifica funzione aziendale all'interno del prodotto secondo il modello di dominio \u2014 e queste sono cose che non abitano in una versione a breve termine, ma in un'opportunit\u00e0 di business a lungo termine. Il passaggio alla successiva versione del prodotto avviene in maniera quasi impercettibile: si modifica o si aggiunge un microservizio, o forse semplicemente si riorganizza il modo in cui interagiscono e ci si ritrova improvvisamente nel futuro, lasciando indietro i concorrenti che continuano a saltare tra le versioni dei loro monoliti. Ora immaginate di avere un numero sufficiente di microservizi con interfacce e opportunit\u00e0 aziendali predefinite. Arrivate e costruite la struttura del vostro prodotto utilizzando i microservizi gi\u00e0 pronti \u2014 semplicemente tracciando un diagramma, per esempio. Congratulazioni: avete creato una piattaforma \u2014 e ora potete costruire il vostro business. Sogni, sogni. <\/p>\n

Conclusioni<\/h2>\n

<\/p>\n