{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless par \u00e9tapes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nLe Serverless ne signifie pas l'absence physique de serveurs. Ce n'est pas un \u00ab tueur \u00bb de conteneurs, ni une mode passag\u00e8re. C'est une nouvelle approche pour construire des syst\u00e8mes dans le cloud. Dans cet article, nous aborderons l'architecture des applications Serverless, examinerons le r\u00f4le du fournisseur de services Serverless et des projets open-source. Enfin, nous discuterons des questions li\u00e9es \u00e0 l'application de Serverless.
\n<\/a><\/noindex>
\nJe veux \u00e9crire la partie serveur d'une application (m\u00eame si c'est un magasin en ligne). Cela peut \u00eatre un chat, un service de publication de contenu ou un \u00e9quilibreur de charge. Quoi qu'il en soit, il y aura beaucoup de casse-t\u00eate : il faudra pr\u00e9parer l'infrastructure, d\u00e9finir les d\u00e9pendances de l'application, r\u00e9fl\u00e9chir au syst\u00e8me d'exploitation de l'h\u00f4te. Ensuite, il sera n\u00e9cessaire de mettre \u00e0 jour de petits composants qui n'affectent pas le fonctionnement du reste du monolithe. Et n'oublions pas la mont\u00e9e en charge.<\/p>\n

Et si nous utilisions des conteneurs \u00e9ph\u00e9m\u00e8res, dans lesquels les d\u00e9pendances n\u00e9cessaires sont d\u00e9j\u00e0 pr\u00e9install\u00e9es, et o\u00f9 les conteneurs sont isol\u00e9s les uns des autres et de l'OS h\u00f4te ? Nous allons d\u00e9composer le monolithe en microservices, chacun pouvant \u00eatre mis \u00e0 jour et mis \u00e0 l'\u00e9chelle ind\u00e9pendamment des autres. En pla\u00e7ant le code dans un tel conteneur, je pourrai l'ex\u00e9cuter sur n'importe quelle infrastructure. C'est d\u00e9j\u00e0 mieux. <\/p>\n

Et si je ne veux pas configurer des conteneurs ? Je ne veux pas penser \u00e0 la mont\u00e9e en charge de l'application. Je ne veux pas payer pour le temps d'arr\u00eat des conteneurs en cours d'ex\u00e9cution lorsque la charge de service est minimale. Je veux \u00e9crire du code. Me concentrer sur la logique m\u00e9tier et lancer des produits sur le march\u00e9 \u00e0 la vitesse de la lumi\u00e8re. <\/p>\n

Ces pens\u00e9es m'ont conduit au calcul sans serveur. Serverless, dans ce cas, signifie pas l'absence physique de serveurs, mais l'absence de casse-t\u00eate li\u00e9e \u00e0 la gestion de l'infrastructure.<\/em><\/p>\n

L'id\u00e9e est que la logique de l'application est d\u00e9compos\u00e9e en fonctions ind\u00e9pendantes. Elles ont une structure \u00e9v\u00e9nementielle. Chaque fonction ex\u00e9cute une \u00ab micro-t\u00e2che \u00bb. Tout ce que le d\u00e9veloppeur doit faire est de t\u00e9l\u00e9charger les fonctions dans la console fournie par le fournisseur de cloud et de les relier aux sources d'\u00e9v\u00e9nements. Le code sera ex\u00e9cut\u00e9 \u00e0 la demande dans un conteneur automatiquement pr\u00e9par\u00e9, et je ne paierai que pour le temps d'ex\u00e9cution. <\/p>\n

Voyons maintenant \u00e0 quoi ressemblera le processus de d\u00e9veloppement de l'application.<\/p>\n

Du point de vue du d\u00e9veloppeur<\/h2>\n

\nAuparavant, nous avons commenc\u00e9 \u00e0 parler d'une application pour un magasin en ligne. Dans l'approche traditionnelle, la logique principale du syst\u00e8me est ex\u00e9cut\u00e9e par une application monolithique. Et le serveur avec l'application est toujours en cours d'ex\u00e9cution, m\u00eame si il n'y a pas de charge.<\/p>\n

Pour passer au serverless, nous d\u00e9composons l'application en micro-t\u00e2ches.<\/strong> Pour chacune d'elles, nous \u00e9crivons notre propre fonction. Les fonctions sont ind\u00e9pendantes les unes des autres et ne conservent pas d'informations sur l'\u00e9tat (sans \u00e9tat). Elles peuvent m\u00eame \u00eatre \u00e9crites dans diff\u00e9rents langages. Si l'une d'elles \u00ab tombe \u00bb, l'application dans son ensemble ne s'arr\u00eate pas. L'architecture de l'application ressemblera \u00e0 ceci :<\/p>\n

\"Serverless
\nLa division en fonctions dans Serverless ressemble au travail avec des microservices. Mais un microservice peut ex\u00e9cuter plusieurs t\u00e2ches, tandis qu'une fonction doit id\u00e9alement en ex\u00e9cuter une seule. Imaginons qu'il y a une t\u00e2che \u00e0 accomplir pour collecter des statistiques et les afficher sur demande de l'utilisateur. Dans l'approche microservices, une seule service ex\u00e9cute la t\u00e2che avec deux points d'entr\u00e9e : un pour l'\u00e9criture et un pour la lecture. Dans le calcul sans serveur, ce seront deux fonctions diff\u00e9rentes, non li\u00e9es entre elles. Le d\u00e9veloppeur \u00e9conomise des ressources de calcul si, par exemple, les statistiques sont mises \u00e0 jour plus fr\u00e9quemment qu'elles ne sont export\u00e9es. <\/p>\n

Les fonctions Serverless doivent s'ex\u00e9cuter pendant un court laps de temps (timeout), qui est d\u00e9fini par le fournisseur de services. Par exemple, pour AWS, le timeout est de 15 minutes. Cela signifie que les fonctions \u00e0 long terme devront \u00eatre adapt\u00e9es aux exigences \u2015 c'est ce qui distingue Serverless d'autres technologies populaires aujourd'hui (conteneurs et Platform as a Service).<\/p>\n

Nous attribuons un \u00e9v\u00e9nement \u00e0 chaque fonction.<\/strong> Un \u00e9v\u00e9nement est un d\u00e9clencheur pour une action :<\/p>\n

\u00c9v\u00e9nement<\/strong>
\nAction ex\u00e9cut\u00e9e par la fonction<\/strong><\/p>\n

Une image du produit a \u00e9t\u00e9 t\u00e9l\u00e9charg\u00e9e dans le stockage
\nCompresser l'image et l'exporter dans le r\u00e9pertoire<\/p>\n

L'adresse du magasin physique a \u00e9t\u00e9 mise \u00e0 jour dans la base de donn\u00e9es
\nCharger la nouvelle localisation sur les cartes<\/p>\n

Le client paie le produit
\nD\u00e9marrer le traitement du paiement<\/p>\n

Les \u00e9v\u00e9nements peuvent \u00eatre des requ\u00eates HTTP, des donn\u00e9es en streaming, des files d'attente de messages, etc. Les sources d'\u00e9v\u00e9nements sont des modifications ou l'apparition de donn\u00e9es. De plus, les fonctions peuvent \u00eatre d\u00e9clench\u00e9es par un minuteur.<\/p>\n

L'architecture a \u00e9t\u00e9 d\u00e9velopp\u00e9e et l'application est presque devenue sans serveur. Passons ensuite au fournisseur de services.<\/p>\n

C\u00f4t\u00e9 fournisseur<\/h2>\n

\nEn g\u00e9n\u00e9ral, le calcul sans serveur est propos\u00e9 par les fournisseurs de services cloud. Ils l'appellent diff\u00e9remment : Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Nous utiliserons le service via la console ou le tableau de bord du fournisseur. Le code des fonctions peut \u00eatre t\u00e9l\u00e9charg\u00e9 de l'une des mani\u00e8res suivantes :<\/p>\n