{"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: le dimensioni contano, anche se hai Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

19 settembre a Mosca si \u00e8 svolto<\/a><\/noindex> il primo meetup tematico HUG (Highload++ User Group), dedicato ai microservizi. Durante l'incontro, \u00e8 stata presentata la relazione \"Gestione dei microservizi: le dimensioni contano, anche se hai Kubernetes\", in cui abbiamo condiviso l'ampia esperienza della societ\u00e0 \"Flant\" nella gestione di progetti con architettura a microservizi. Sar\u00e0 particolarmente utile a tutti gli sviluppatori che stanno considerando di adottare questo approccio nel loro progetto attuale o futuro.<\/p>\n

\"Microservizi:
\n
\nPresentiamo il video della presentazione<\/b><\/a><\/noindex> (50 minuti, molto pi\u00f9 informativo di un articolo), insieme a un riassunto principale del contenuto in forma testuale.<\/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, una trama principale e una conclusione. Questa relazione \u00e8 pi\u00f9 simile a un'introduzione, peraltro tragica. \u00c8 anche importante notare che offre una visione sui microservizi dal punto di vista sfruttamento<\/i>.<\/p>\n

Inizio con questo grafico, il cui autore (nel 2015) \u00e8 diventata parte di<\/a><\/noindex> Martin Fowler:<\/p>\n

\"Microservizi:
\n
\nMostra come, nel caso di un'applicazione monolitica, raggiunta una certa dimensione, la produttivit\u00e0 inizia a diminuire. I microservizi si differenziano perch\u00e9 la produttivit\u00e0 iniziale con essi \u00e8 inferiore, ma man mano che aumenta la complessit\u00e0, la degradazione dell'efficienza non \u00e8 cos\u00ec evidente.<\/p>\n

Aggiungo questo grafico per il caso di utilizzo di Kubernetes:<\/p>\n

\"Microservizi:
\n
\nPerch\u00e9 un'applicazione a microservizi funziona meglio? Perch\u00e9 tale architettura pone serie esigenze all'architettura stessa, che sono eccellentemente soddisfatte dalle capacit\u00e0 di Kubernetes. D'altra parte, parte di questa funzionalit\u00e0 sar\u00e0 utile anche per il monolite, soprattutto per il motivo che un tipico monolite al giorno d'oggi non \u00e8 del tutto monolitico (i dettagli verranno presentati nella relazione).<\/p>\n

Come si pu\u00f2 notare, il grafico finale (una volta che sia le applicazioni monolitiche che quelle a microservizi operano su un'infrastruttura con Kubernetes) non differisce molto dall'originale. Discuteremo in seguito delle applicazioni gestite con Kubernetes.<\/p>\n

Microservizi utili e dannosi<\/h2>\n

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

\"Microservizi:
\n
\nCos'\u00e8 un'architettura<\/b> a microservizi normale? Deve portarti un reale vantaggio, aumentando l'efficienza del lavoro. Se torniamo al grafico, ecco cosa significa:<\/p>\n

\"Microservizi:
\n
\nSe la chiamiamo utile<\/b>, quindi dall'altra parte del grafico ci sar\u00e0 microservizi dannosi (intralcia il lavoro):<\/b> microservizi (creano problemi):<\/p>\n

\"Microservizi:
\n
\nTornando al \"pensiero centrale\": vale la pena fidarsi della mia esperienza? Dall'inizio di quest'anno ho guardato 85 progetti<\/b>. Non tutti erano microservizi (questa architettura era presente in circa un terzo a met\u00e0 di essi), ma \u00e8 comunque un numero considerevole. A noi (l'azienda \"Flant\") come fornitori di servizi riesce di vedere una grande variet\u00e0 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 sviluppano nel corso degli anni.<\/p>\n

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

\nAlla domanda sull'utilit\u00e0 dei microservizi c'\u00e8 una risposta<\/a><\/noindex> piuttosto concreta<\/p>\n

    \n
  1. da parte del gi\u00e0 citato Martin Fowler:<\/li>\n
  2. confini chiari di modularit\u00e0;<\/li>\n
  3. deploy indipendente;<\/li>\n<\/ol>\n

    \nlibert\u00e0 di scelta delle tecnologie.<\/p>\n

    \"Microservizi:
    \n
    \nHo parlato molto con architetti e sviluppatori di software, chiedendo loro perch\u00e9 hanno bisogno di microservizi. E ho stilato la mia lista delle loro aspettative. Ecco cosa \u00e8 emerso:<\/p>\n