{"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 sul tema dell'architettura a microservizi da tempo, ma due aspetti mi hanno sempre fermato: pi\u00f9 mi immergevo nell'argomento, pi\u00f9 mi sembrava che ci\u00f2 che sapevo fosse ovvio, e ci\u00f2 che non sapevo dovesse ancora essere studiato. D'altro canto, ritengo che ci sia gi\u00e0 qualcosa di cui discutere con un pubblico pi\u00f9 ampio. Quindi, opinioni alternative sono benvenute.
\n<\/a><\/noindex><\/p>\n

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

\nMi permetto 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 dei team in quella organizzazione\u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

A mio avviso, questa legge si riferisce maggiormente alla ragionevolezza dell'organizzazione aziendale, piuttosto che direttamente al sistema informativo. Lo spiego con un esempio. Supponiamo di avere un'opportunit\u00e0 di business sufficientemente stabile con un ciclo di vita cos\u00ec lungo da giustificare l'organizzazione di un'impresa (non \u00e8 un refuso, ma mi piace molto questo termine che ho rubato). \u00c8 naturale che il sistema di supporto di questo business sar\u00e0 organizzativo e processualmente adeguato a questo business.<\/p>\n

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

\n\"Microservizi:
\n
\nLo spiego con un esempio. Supponiamo di avere un'opportunit\u00e0 di business legata all'organizzazione di un'attivit\u00e0 di vendita di pizze. Nella versione V1 (chiamiamola pre-informativa), l'azienda era composta da una pizzeria, una cassa e un servizio di consegna. Questa versione \u00e8 durata a lungo in un contesto di bassa variabilit\u00e0 dell'ambiente circostante. Poi \u00e8 arrivata la versione 2 \u2014 pi\u00f9 avanzata e capace di utilizzare un sistema informativo come base per un business con architettura monolitica. E qui, a mio avviso, si presenta una terribile ingiustizia nei confronti dei monoliti \u2014 si sostiene che l'architettura monolitica non corrisponda al modello di dominio del business<\/b>. Se fosse cos\u00ec, il sistema non potrebbe funzionare affatto - in contraddizione con la stessa legge di Conway e il buon senso. No, l'architettura monolitica corrisponde perfettamente al modello di business in questa fase dello sviluppo aziendale \u2014 intendo chiaramente la fase in cui il sistema \u00e8 gi\u00e0 stato creato e messo in esercizio. \u00c8 un fatto assolutamente notevole che, indipendentemente dall'approccio architetturale, sia l'architettura orientata ai servizi di versione 3 che l'architettura a microservizi di versione N funzioneranno altrettanto bene. Dove sta il trucco?<\/p>\n

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

\n Prima di procedere, consideriamo alcuni fraintendimenti riguardo l'architettura a microservizi.<\/p>\n

I sostenitori dell'uso dell'approccio a microservizi affermano spesso che spezzare un monolite in microservizi semplifica l'approccio allo sviluppo grazie alla riduzione della base di codice di servizi singoli. A mio avviso, questa affermazione \u00e8 completamente insensata. Sul serio, l'interazione ovvia all'interno di un monolite 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 a microservizi \u00e8 ben pi\u00f9 comune. La complessit\u00e0 non svanisce, semplicemente si trasferisce da singoli moduli a interfacce (che si tratti di bus di dati, RPC, API e altri protocolli) e sistemi di orchestrazione. Ed \u00e8 questo\u2014\u00e8 complicato! <\/p>\n

Il vantaggio dell'uso di uno stack eterogeneo \u00e8 altrettanto dubbio. Non discuter\u00f2 che sia possibile, ma nella realt\u00e0 \u00e8 raro (per anticipare \u2014 dovrebbe avere luogo, ma piuttosto come conseguenza, piuttosto che come vantaggio).<\/p>\n

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

\nDai un'altra occhiata al diagramma sopra. Non ho segnato per caso il ciclo di vita decrescente di ogni singola versione del business - nelle attuali condizioni, proprio l'accelerazione del passaggio tra le versioni \u00e8 determinante per il suo successo. Il successo del prodotto \u00e8 determinato dalla velocit\u00e0 di verifica delle ipotesi di business in esso.<\/b>. E qui, a mio avviso, \u00e8 sepolto il vantaggio chiave dell'architettura a microservizi. Ma andiamo con ordine. <\/p>\n

Passiamo al prossimo livello dell'evoluzione dei sistemi informativi: l'architettura orientata ai servizi SOA. Quindi, a un certo punto, abbiamo identificato nel nostro prodotto servizi a lungo termine<\/b> \u2014 longevi nel senso che durante il passaggio tra le versioni del prodotto c'\u00e8 la possibilit\u00e0 che il ciclo di vita del servizio sia pi\u00f9 lungo del ciclo di vita della versione del prodotto successiva. Sarebbe logico non modificarli affatto \u2014 per noi \u00e8 importante proprio la velocit\u00e0 di transizione alla versione successiva<\/b>. Purtroppo, siamo costretti a fare modifiche costanti ai servizi \u2014 e qui abbiamo tutto ci\u00f2 che serve, dalle pratiche DevOps, alla containerizzazione, e altro ancora \u2014 tutto ci\u00f2 che ci viene in mente. Ma non stiamo ancora parlando di microservizi! <\/p>\n

Microservizi come mezzo per combattere la complessit\u00e0\u2026 gestione della configurazione<\/h2>\n

\n E qui possiamo finalmente passare al ruolo definitorio dei microservizi: \u00e8 un approccio che semplifica la gestione della configurazione del prodotto. In altre parole, la funzione di ogni microservizio descrive precisamente una funzione di business all'interno del prodotto secondo il modello di dominio \u2014 e queste sono gi\u00e0 cose che non vivono in una versione a breve termine, ma in un'opportunit\u00e0 di business a lungo termine. E il passaggio alla versione successiva del prodotto avviene in maniera praticamente impercettibile: si modifica \/ si aggiunge un microservizio, o magari semplicemente lo schema delle loro interazioni, e ci si ritrova improvvisamente nel futuro, lasciando dietro di s\u00e9 concorrenti piangenti, che continuano a saltare tra le versioni dei loro monoliti. Ora immaginate di avere una quantit\u00e0 sufficiente di microservizi con interfacce e opportunit\u00e0 di business gi\u00e0 definite. E voi arrivate e costruite la struttura del vostro prodotto a partire da microservizi pronti \u2014 semplicemente disegnando un diagramma, per esempio. Congratulazioni: avete creato una piattaforma e ora potete generare affari. <\/p>\n

Conclusioni<\/h2>\n

<\/p>\n