Une traduction de l'article a été préparée pour les étudiants du cours DevOps Practices and Tools du projet éducatif OTUS .

Lorsque les premiers didacticiels ont commencé à utiliser AWS Lambda et l'API Gateway en 2015, il n'était pas surprenant qu'ils se concentrent principalement sur la copie de l'architecture de microservice. Mais pour ceux qui ont utilisé AWS Lambda à grande échelle, il est devenu clair au fil du temps qu'il y avait des limites importantes à l'application de l'approche microservice à AWS Lambda ... Au moins, il y avait des restrictions sur ce que la plupart des gens entendaient par la construction appropriée de microservices.

Parlons du pourquoi des microservices

Les microservices sont apparus principalement en raison de la frustration des applications monolithiques. Monolith est une application dans laquelle toute la logique est dans une seule base de code logique.

Il y avait des moments où, en raison du coût élevé des serveurs, il était courant de déployer l’application entière sur un seul serveur. Le déploiement d'un monolithe signifiait que sur le serveur, vous déployiez une partie ou la totalité de l'application.

De plus, le déploiement d'un monolithe signifiait que vous deviez être sûr de ne rien casser. Très souvent, de petits changements entraînent la défaillance de l'ensemble du serveur et de l'ensemble de l'application.

Par conséquent, lorsque les nuages ​​sont apparus avec la possibilité de fournir des instances en un seul clic en quelques minutes (plutôt qu'en jours ou semaines), la possibilité de séparation des tâches est devenue claire.
La destruction du monolithe est devenue une idée évidente, et l'idée de microservices est née.

Au lieu de créer un monolithe avec toute la logique sur un serveur / instance, vous pouvez placer des parties de l'application sur différents serveurs et les connecter ensemble à l'aide d'une sorte de protocole léger - généralement une API HTTP.

Ainsi, l'architecture d'application est passée des monolithes aux microservices.

Mais je me demande pourquoi? La valeur de cette approche est que, lors de la modification du code, vous modifiez la base de code non pas de l'application entière, mais du microservice - uniquement la partie composante de l'application. Cela signifie que vous ne pouvez pas interrompre l'application entière.

Bien que ce ne soit que théoriquement, mais cette théorie est meilleure qu'un monolithe, bien qu'elle ne soit pas idéale.

Un élément clé pour chaque service est ...

Interface de service

Il s'agit souvent d'une forme d'interface HTTP (au moins, c'est l'approche la plus courante). En règle générale, ce n'est pas un problème, sauf lorsque vous avez un grand nombre de services et qu'il peut y avoir un problème de coordination.

Vers une architecture sans serveur

Par conséquent, l'approche initiale de la création d'applications sans serveur sur AWS était «créons des microservices» ...

Cela signifiait créer une API de passerelle avec la fonction Lambda derrière elle et une instruction switch qui agit comme un routeur.

Chaque API de passerelle est devenue une interface de service, et cela semblait logique.

Vous pouvez créer plusieurs services qui évoluent séparément les uns des autres, ce qui dans certains cas peut être très important.

Sauf que cela n'a aucun sens lorsque vous réalisez que les fonctions AWS Lambda et FaaS en général ne doivent pas être considérées comme une instance / un serveur.

Parce que bien qu'ils aient des serveurs sous le capot (hé, il y a des serveurs sous la plupart des choses qui fonctionnent sur Internet, mais personne ne dit "S3 a toujours des serveurs" ou "BigTable a toujours des serveurs" ou "Azure Active Directory tous possède toujours des serveurs »...), on pense que vous devriez traiter la fonction FaaS de la même manière que le service ...« minilith », comme certains l'appellent.

Le problème est qu'il manque ici ce qui, à mon avis, est la clé de l'architecture sans serveur:

L'architecture sans serveur est une question d'événements

Architecture, événements et déclencheurs sans serveur

Les systèmes sans serveur sont intrinsèquement des systèmes pilotés par les événements et sont donc des représentants de l'architecture pilotée par les événements. Cela change votre approche de la conception, de la gestion et de l'architecture.

Dans le cas des microservices, l'essentiel est de répondre à une interface - c'est le principal mécanisme d'interaction avec la logique.

La solution sans serveur consiste à répondre aux événements, et l'API n'est en fait qu'un mécanisme pour générer des événements.

Dans le cadre de l'écosystème AWS, qui est la plus mature des solutions sans serveur, l'API n'est pas considérée comme l'interface principale. Les événements sont beaucoup plus importants.

Et c'est pourquoi environ 50 événements peuvent déclencher la fonction Lambda à partir d'autres services AWS.

L'astuce est que si vous pouvez exécuter la fonction Lambda sans passer par l'API de passerelle, elle sera beaucoup plus rapide et plus efficace que l'utilisation de l'API de passerelle, surtout si vous l'exécutez à partir d'une autre interface AWS.

Jetez un œil aux meilleures pratiques sans serveur , vous verrez un certain nombre de points qui diffèrent du nombre de microservices de conception.

Tout d'abord, les fonctions unidirectionnelles. La plupart des microservices utilisent généralement une architecture de demande-réponse car la plupart des applications Web fonctionnent de cette façon. Les fonctions dans une application sans serveur, en règle générale, sont unidirectionnelles, et les files d'attente sont utilisées comme un «disjoncteur», de sorte que la réponse à la demande devient moins courante.

La couche de données est également gérée et comprise de différentes manières. La meilleure pratique consiste à avoir plusieurs fonctions, plutôt qu'une seule fonction proxy avec une instruction switch.

L'idée de fonctions multiples offre également des avantages supplémentaires par rapport aux microservices. Si une fonction renvoie une erreur, cela n'affectera que cette fonction, et non le reste de l'application, car la fonction n'a pas d'état (au moins, elle devrait l'être!). Et c'est une très bonne raison de ne pas faire de "minilith"!

Par conséquent, l'expérience de la construction de microservices, bien qu'elle vous donne certains avantages lors de la conception de solutions sans serveur, mais en réalité, vous pouvez manquer la plupart de ce qui rend les applications sans serveur précieuses.

Les microservices diffèrent généralement d'une application sans serveur bien conçue de plusieurs manières. Cela signifie que bien que vous puissiez créer des microservices avec un serveur sans serveur, il n'y a vraiment pas de chemin direct des microservices vers une architecture sans serveur.

Le chemin des microservices à l'architecture sans serveur

Alors, quel est le chemin des microservices aux solutions sans serveur? Existe-t-il un moyen rapide d'apprendre les bases pour simplifier la transition de l'un à l'autre, car les microservices sont très répandus?

Je pense que c'est ce que le monde sans serveur intrigue. Récemment, il y a eu une grande discussion sur Twitter dans laquelle nous avons discuté de ce sujet. Ici, il vaut la peine d'y faire référence, ne serait-ce que pour voir ce dont la communauté parle (regardez les différentes réponses et vous verrez de nombreuses opinions sur ce sujet, bien que personne ne mentionne directement les microservices).

Ils parlent de certains outils qui seront expliqués pour faciliter la création d'applications sans serveur, mais à la fin ils deviendront la plate-forme sur laquelle vous devrez tout construire. Je ne pense pas que cela bénéficiera ou aidera quelqu'un à mieux comprendre le style architectural.

En tant que communauté, nous comprenons que l'architecture sans serveur est l'avenir. Mais la transition des anciens styles architecturaux ne sera pas toujours facile, même lorsque l'architecture sans serveur est le bon (et parfois pas le bon) choix.

Il y a une raison à cela. Il n’est pas si facile de changer la façon de penser d’une personne. Il est facile de créer une fonction Lambda. Mais la création d'une application sans serveur bien conçue n'est pas facile. Parce que cela nécessite un changement de mentalité, et c'est relativement difficile.

Et comme je l'ai dit à plusieurs reprises, nous devons cesser d'enseigner aux gens les applications «bonjour le monde» et nous arrêter là car beaucoup de gens pensent que cela leur suffira.

La raison pour laquelle j'ai écrit les meilleures pratiques sans serveur était d'aider les gens à comprendre qu'ils ne devraient pas faire d'hypothèses sur la façon de créer des applications sans serveur sur la base des connaissances actuelles.

Les outils que nous utilisons maintenant pour créer des solutions sans serveur sont les mêmes que ceux que nous utilisons pour créer des applications «cloud 1.0», mais ils ne conviennent pas complètement à ces fins. Ces outils sont imparfaits, mais nous essayons de les expliquer et de les rendre aussi bons que possible.

Qu'avons-nous besoin de vous

Je pense que la communauté, en fait, est très ouverte pour aider les gens dans la formation et le développement à créer des solutions sans serveur.

Nous avons donc, en tant que communauté, besoin de vos questions:
- Quelles sont vos difficultés?
- Où sont les lacunes?
- Quels tutoriels manquent?

Et quelque chose comme ça.

Je suis prêt à aider les entreprises à faire cette transition. J'ai travaillé avec la haute direction, les CTO et les PDG pour aider à déterminer la valeur créée par une entreprise en utilisant une approche sans serveur, et je suis heureux d'aider d'autres entreprises.

Je suis très heureux de vous aider. Contactez LinkedIn ici .