{"id":31761,"date":"2019-10-31T21:42:55","date_gmt":"2019-10-31T18:42:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes\/"},"modified":"2019-10-31T21:42:55","modified_gmt":"2019-10-31T18:42:55","slug":"mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","title":{"rendered":"Microservizi: la dimensione conta, anche se hai Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

19 settembre a Mosca si \u00e8 tenuto<\/a><\/noindex> il primo meetup tematico HUG (Highload++ User Group), dedicato ai microservizi. Durante l'evento \u00e8 stata presentata la relazione \"Gestione dei microservizi: la dimensione conta, anche se hai Kubernetes\", in cui abbiamo condiviso l'ampia esperienza dell'azienda \"Flant\" nella gestione di progetti con architettura a microservizi. Sar\u00e0 particolarmente utile per tutti gli sviluppatori che stanno considerando di adottare questo approccio nei loro progetti attuali o futuri.<\/p>\n

\"Microservizi:
\n
\nPresentiamo il video della presentazione<\/b><\/a><\/noindex> (50 minuti, molto pi\u00f9 informativo di un articolo) e anche un riassunto testuale principale.<\/p>\n

NB: Il video e la presentazione sono disponibili anche alla fine di questa pubblicazione.<\/i><\/a><\/noindex><\/p>\n

Introduzione<\/h2>\n

\nDi solito, una buona storia ha un'introduzione, un conflitto principale e una conclusione. Questa relazione somiglia pi\u00f9 a un'introduzione, e per di pi\u00f9 tragica. \u00c8 importante sottolineare che offre anche una visione dei microservizi dal punto di vista di sfruttamento<\/i>.<\/p>\n

Inizier\u00f2 con questo grafico, la cui autore \u00e8 (nel 2015) ha iniziato<\/a><\/noindex> Martin Fowler:<\/p>\n

\"Microservizi:
\n
\nSi pu\u00f2 osservare come, nel caso di un'applicazione monolitica che ha raggiunto una certa dimensione, inizi a diminuire la produttivit\u00e0. I microservizi si distinguono per il fatto che la loro produttivit\u00e0 iniziale \u00e8 pi\u00f9 bassa, tuttavia, con l'aumento della complessit\u00e0, la degradazione dell'efficacia non \u00e8 cos\u00ec evidente.<\/p>\n

Integrer\u00f2 questo grafico per il caso d'uso di Kubernetes:<\/p>\n

\"Microservizi:
\n
\nPerch\u00e9 un'applicazione con microservizi ha avuto un miglioramento? Perch\u00e9 questa architettura presenta requisiti rigorosi che sono eccellentemente soddisfatti dalle capacit\u00e0 di Kubernetes. D'altra parte, parte di questa funzionalit\u00e0 sar\u00e0 utile anche per il monolite, soprattutto considerando che il monolite tipico attuale non \u00e8 propriamente un monolite (i dettagli seguiranno nel rapporto).<\/p>\n

Come si pu\u00f2 vedere, il grafico finale (con applicazioni sia monolitiche che microservizi nell'infrastruttura Kubernetes) non differisce molto dall'originale. In seguito si parler\u00e0 di applicazioni gestite utilizzando Kubernetes.<\/p>\n

Microservizi utili e dannosi<\/h2>\n

\nE qui la idea principale:<\/p>\n

\"Microservizi:
\n
\nChe cos'\u00e8 normale<\/b> L'architettura a microservizi? Deve offrirvi un reale valore, aumentando l'efficienza del lavoro. Se torniamo al grafico, eccola qui:<\/p>\n

\"Microservizi:
\n
\nSe la chiamiamo utile<\/b>, dall'altra parte del grafico ci sar\u00e0 dannosa<\/b> microservizialit\u00e0 (ostacola il lavoro):<\/p>\n

\"Microservizi:
\n
\nTornando al \u00abconcetto principale\u00bb: dovrei fidarmi della mia esperienza? Dall'inizio di quest'anno ho esaminato 85 progetti<\/b>. Non tutti erano a microservizi (circa un terzo o met\u00e0 di essi avevano tale architettura), ma \u00e8 comunque un numero significativo. Noi (l'azienda \u00abFlant\u00bb) come fornitori di outsourcing riusciamo a vedere una vasta gamma di applicazioni sviluppate sia in piccole aziende (con 5 sviluppatori) che in grandi (~500 sviluppatori). Un ulteriore vantaggio \u00e8 che vediamo come queste applicazioni vivono e si evolvono nel corso degli anni.<\/p>\n

Perch\u00e9 i microservizi?<\/h2>\n

\nLa risposta alla domanda sui benefici dei microservizi \u00e8 abbastanza specifica<\/a><\/noindex> secondo l'ormai citato Martin Fowler:<\/p>\n

    \n
  1. confini modulari chiari;<\/li>\n
  2. deploy indipendente;<\/li>\n
  3. libert\u00e0 di scelta delle tecnologie.<\/li>\n<\/ol>\n

    \nHo parlato molto con architetti e sviluppatori di software, chiedendo loro perch\u00e9 avessero bisogno dei microservizi. Ho creato la mia lista delle loro aspettative. Ecco cosa \u00e8 emerso:<\/p>\n

    \"Microservizi:
    \n
    \nSe descriviamo \u00abnelle sensazioni\u00bb alcuni dei punti, allora:<\/p>\n