{"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\/fr\/blog\/administrirovanie\/mikroservisy-razmer-imeet-znachenie-dazhe-esli-u-vas-kubernetes","title":{"rendered":"Microservices : la taille compte, m\u00eame avec Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

19 septembre \u00e0 Moscou a eu lieu<\/a><\/noindex> premi\u00e8re rencontre th\u00e9matique HUG (Highload++ User Group) consacr\u00e9e aux microservices. Lors de celle-ci, nous avons pr\u00e9sent\u00e9 une conf\u00e9rence intitul\u00e9e \u00ab L'exploitation des microservices : la taille a son importance, m\u00eame si vous avez Kubernetes \u00bb, o\u00f9 nous avons partag\u00e9 l'exp\u00e9rience approfondie de la soci\u00e9t\u00e9 \u00ab Flant \u00bb dans l'exploitation de projets ayant une architecture microservices. Cela sera principalement utile \u00e0 tous les d\u00e9veloppeurs qui envisagent d'appliquer cette approche dans leurs projets actuels ou futurs.<\/p>\n

\"Microservices
\n
\nNous pr\u00e9sentons la vid\u00e9o de la conf\u00e9rence<\/b><\/a><\/noindex> (50 minutes, bien plus informatif qu'un article), ainsi qu'un r\u00e9sum\u00e9 principal sous forme de texte.<\/p>\n

NB : La vid\u00e9o et la pr\u00e9sentation sont \u00e9galement disponibles \u00e0 la fin de cette publication.<\/i><\/a><\/noindex><\/p>\n

Introduction<\/h2>\n

\nEn g\u00e9n\u00e9ral, une bonne histoire a une introduction, un corps principal et une conclusion. Cette conf\u00e9rence ressemble davantage \u00e0 une introduction, qui est en plus tragique. Il est \u00e9galement important de noter qu'elle pr\u00e9sente un point de vue sur les microservices. d'exploitation<\/i>.<\/p>\n

Je commencerai par ce graphique, dont l'auteur (en 2015) a commenc\u00e9<\/a><\/noindex> est Martin Fowler :<\/p>\n

\"Microservices
\n
\nOn peut y voir que dans le cas d'une application monolithique, apr\u00e8s avoir atteint une certaine taille, la productivit\u00e9 commence \u00e0 chuter. Les microservices se distinguent par le fait que leur productivit\u00e9 initiale est plus faible, mais \u00e0 mesure que la complexit\u00e9 augmente, la d\u00e9gradation de l'efficacit\u00e9 pour eux est moins \u00e9vidente.<\/p>\n

Je compl\u00e9terai ce graphique pour le cas d'utilisation de Kubernetes :<\/p>\n

\"Microservices
\n
\nPourquoi l'application avec microservices s'est am\u00e9lior\u00e9e ? Parce que cette architecture impose des exigences s\u00e9rieuses en mati\u00e8re d'architecture, qui sont \u00e0 leur tour bien satisfaites par les possibilit\u00e9s de Kubernetes. D'autre part, une partie de cette fonctionnalit\u00e9 sera \u00e9galement utile pour le monolithe, surtout parce que le monolithe typique aujourd'hui n'est pas tout \u00e0 fait un monolithe (les d\u00e9tails seront abord\u00e9s plus tard dans la conf\u00e9rence).<\/p>\n

Comme on peut le voir, le graphique final (quand les applications monolithiques et microservices sont dans une infrastructure avec Kubernetes) ne diff\u00e8re pas beaucoup de l'original. Ensuite, nous aborderons les applications exploit\u00e9es avec Kubernetes.<\/p>\n

L'utilit\u00e9 et la nocivit\u00e9 des microservices<\/h2>\n

\nEt ici, la pens\u00e9e principale :<\/p>\n

\"Microservices
\n
\nQu'est-ce que une<\/b> architecture microservices normale ? Elle doit vous apporter un r\u00e9el b\u00e9n\u00e9fice, en augmentant l'efficacit\u00e9 du travail. Si l'on se r\u00e9f\u00e8re au graphique, voici \u00e0 quoi cela ressemble :<\/p>\n

\"Microservices
\n
\nSi on l'appelle utile<\/b>, alors de l'autre c\u00f4t\u00e9 du graphique se trouvera la nocivit\u00e9<\/b> des microservices (qui nuisent au travail) :<\/p>\n

\"Microservices
\n
\nRevenons \u00e0 la \u00abpens\u00e9e principale\u00bb : faut-il faire confiance \u00e0 mon exp\u00e9rience ? Depuis le d\u00e9but de cette ann\u00e9e, j'ai regard\u00e9 85 projets<\/b>. Tous n'\u00e9taient pas des microservices (environ un tiers \u00e0 la moiti\u00e9 d'entre eux avaient cette architecture), mais c'est quand m\u00eame un grand nombre. Nous (la soci\u00e9t\u00e9 \u00abFlant\u00bb) en tant que sous-traitants avons la chance de voir une large vari\u00e9t\u00e9 d'applications, d\u00e9velopp\u00e9es tant par de petites entreprises (avec 5 d\u00e9veloppeurs) que par de grandes (~500 d\u00e9veloppeurs). Un autre point positif est que nous voyons comment ces applications vivent et \u00e9voluent au fil des ans.<\/p>\n

Pourquoi les microservices ?<\/h2>\n

\nSur la question de l'utilit\u00e9 des microservices, il existe une r\u00e9ponse<\/a><\/noindex> bien sp\u00e9cifique<\/p>\n

    \n
  1. d'un certain Martin Fowler :<\/li>\n
  2. des fronti\u00e8res claires de modularit\u00e9 ;<\/li>\n
  3. un d\u00e9ploiement ind\u00e9pendant ;<\/li>\n<\/ol>\n

    \nla libert\u00e9 de choix des technologies.<\/p>\n

    \"Microservices
    \n
    \nJ'ai beaucoup discut\u00e9 avec des architectes et des d\u00e9veloppeurs de logiciels, leur demandant pourquoi ils ont besoin de microservices. J'ai \u00e9labor\u00e9 ma propre liste de leurs attentes. Voici ce que j'ai trouv\u00e9 :<\/p>\n