Le sans serveur n’est pas une question d’absence physique de serveurs. Il ne s’agit pas d’un tueur de conteneurs ni d’une tendance passagère. Il s'agit d'une nouvelle approche de la création de systèmes dans le cloud. Dans l'article d'aujourd'hui, nous aborderons l'architecture des applications sans serveur, voyons quel rôle jouent le fournisseur de services sans serveur et les projets open source. Enfin, parlons des problèmes liés à l'utilisation de Serverless.
Je souhaite écrire une partie serveur d'une application (ou même d'une boutique en ligne). Il peut s'agir d'un chat, d'un service de publication de contenu ou d'un équilibreur de charge. Dans tous les cas, il y aura beaucoup de maux de tête : il faudra préparer l'infrastructure, déterminer les dépendances des applications, et réfléchir au système d'exploitation hôte. Ensuite, vous devrez mettre à jour de petits composants qui n'affectent pas le fonctionnement du reste du monolithe. Eh bien, n’oublions pas la mise à l’échelle sous charge.
Et si nous prenions des conteneurs éphémères, dans lesquels les dépendances requises sont déjà préinstallées, et que les conteneurs eux-mêmes sont isolés les uns des autres et du système d'exploitation hôte ? Nous diviserons le monolithe en microservices, chacun pouvant être mis à jour et mis à l'échelle indépendamment des autres. En plaçant le code dans un tel conteneur, je peux l'exécuter sur n'importe quelle infrastructure. Déjà mieux.
Que faire si vous ne souhaitez pas configurer de conteneurs ? Je ne veux pas penser à faire évoluer l’application. Je ne veux pas payer pour des conteneurs inactifs lorsque la charge sur le service est minime. Je veux écrire du code. Concentrez-vous sur la logique métier et commercialisez vos produits à la vitesse de la lumière.
De telles réflexions m'ont conduit vers l'informatique sans serveur. Sans serveur dans ce cas signifie non pas l'absence physique de serveurs, mais l'absence de problèmes de gestion de l'infrastructure.
L’idée est que la logique applicative se décompose en fonctions indépendantes. Ils ont une structure événementielle. Chaque fonction effectue une « microtâche ». Il suffit au développeur de charger les fonctions dans la console fournie par le fournisseur de cloud et de les corréler avec les sources d'événements. Le code sera exécuté à la demande dans un conteneur préparé automatiquement, et je ne paierai que le temps d'exécution.
Voyons maintenant à quoi ressemblera le processus de développement d'applications.
Du côté du développeur
Plus tôt, nous avons commencé à parler d'une application pour une boutique en ligne. Dans l’approche traditionnelle, la logique principale du système est réalisée par une application monolithique. Et le serveur avec l'application fonctionne en permanence, même s'il n'y a aucune charge.
Pour passer au sans serveur, nous divisons l'application en microtâches. Nous écrivons notre propre fonction pour chacun d'eux. Les fonctions sont indépendantes les unes des autres et ne stockent pas d'informations d'état (sans état). Ils peuvent même être rédigés dans des langues différentes. Si l’un d’eux « tombe », l’ensemble de l’application ne s’arrêtera pas. L'architecture de l'application ressemblera à ceci :
La division en fonctions dans Serverless est similaire au travail avec des microservices. Mais un microservice peut effectuer plusieurs tâches, et une fonction devrait idéalement en effectuer une. Imaginons que la tâche consiste à collecter des statistiques et à les afficher à la demande de l'utilisateur. Dans l’approche microservice, une tâche est effectuée par un seul service avec deux points d’entrée : l’écriture et la lecture. Dans l’informatique sans serveur, il s’agira de deux fonctions différentes qui ne sont pas liées l’une à l’autre. Le développeur économise des ressources informatiques si, par exemple, les statistiques sont mises à jour plus souvent que téléchargées.
Les fonctions sans serveur doivent être exécutées dans un court laps de temps (timeout), déterminé par le fournisseur de services. Par exemple, pour AWS, le délai d'attente est de 15 minutes. Cela signifie que les fonctions à long terme devront être modifiées pour répondre aux exigences - c'est ce qui distingue Serverless des autres technologies populaires aujourd'hui (conteneurs et Platform as a Service).
Nous attribuons un événement à chaque fonction. Un événement est le déclencheur d'une action :
Événement
L'action effectuée par la fonction
Une image du produit a été téléchargée dans le référentiel.
Compresser l'image et la télécharger dans un répertoire
L'adresse du magasin physique a été mise à jour dans la base de données
Charger un nouvel emplacement dans les cartes
Le client paie les marchandises
Commencer le traitement du paiement
Les événements peuvent être des requêtes HTTP, des données en streaming, des files d'attente de messages, etc. Les sources d'événements sont des changements ou des occurrences de données. De plus, les fonctions peuvent être déclenchées par une minuterie.
L'architecture a été élaborée et l'application est devenue presque sans serveur. Ensuite, nous nous tournons vers le fournisseur de services.
Du côté du fournisseur
En règle générale, l'informatique sans serveur est proposée par les fournisseurs de services cloud. Ils sont appelés différemment : Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Nous utiliserons le service via la console ou le compte personnel du fournisseur. Le code de fonction peut être téléchargé de l'une des manières suivantes :
- écrire du code dans les éditeurs intégrés via la console web,
- téléchargez l'archive avec le code,
- travailler avec des référentiels git publics ou privés.
Ici, nous configurons les événements qui appellent la fonction. Les ensembles d'événements peuvent différer selon les fournisseurs.
Le fournisseur a construit et automatisé le système Function as a Service (FaaS) sur son infrastructure :
- Le code de fonction finit dans le stockage du côté du fournisseur.
- Lorsqu'un événement se produit, les conteneurs avec un environnement préparé sont automatiquement déployés sur le serveur. Chaque instance de fonction possède son propre conteneur isolé.
- Depuis le stockage, la fonction est envoyée au conteneur, calculée et renvoie le résultat.
- Le nombre d'événements parallèles augmente – le nombre de conteneurs augmente. Le système évolue automatiquement. Si les utilisateurs n'accèdent pas à la fonction, elle sera inactive.
- Le fournisseur définit le temps d'inactivité des conteneurs - si pendant ce temps les fonctions n'apparaissent pas dans le conteneur, celui-ci est détruit.
De cette façon, nous obtenons Serverless dès la sortie de la boîte. Nous paierons le service selon le modèle de paiement à l'utilisation et uniquement pour les fonctions utilisées, et uniquement pour la durée pendant laquelle elles ont été utilisées.
Pour présenter le service aux développeurs, les fournisseurs proposent jusqu'à 12 mois de tests gratuits, mais limitent le temps de calcul total, le nombre de requêtes par mois, les fonds ou la consommation d'énergie.
Le principal avantage de travailler avec un fournisseur est la possibilité de ne pas se soucier de l'infrastructure (serveurs, machines virtuelles, conteneurs). De son côté, le fournisseur peut mettre en œuvre le FaaS à la fois en utilisant ses propres développements et en utilisant des outils open source. Parlons-en plus loin.
Du côté de l'open source
La communauté open source travaille activement sur les outils sans serveur depuis quelques années. Les plus grands acteurs du marché contribuent également au développement des plateformes sans serveur :
- Google propose aux développeurs son outil open source - . IBM, RedHat, Pivotal et SAP ont participé à son développement ;
- IBM travaillé sur une plateforme sans serveur , qui est ensuite devenu un projet de la Fondation Apache ;
- Microsoft partiellement ouvert le code de la plateforme .
Des développements sont également en cours vers des frameworks sans serveur. и déployé dans des clusters Kubernetes pré-préparés, fonctionne avec Kubernetes et Docker Swarm. Le framework agit comme une sorte de contrôleur : sur demande, il prépare un environnement d'exécution à l'intérieur du cluster, puis y lance une fonction.
Les frameworks laissent la possibilité de configurer l'outil en fonction de vos besoins. Ainsi, dans Kubeless, un développeur peut configurer le délai d'exécution de la fonction (la valeur par défaut est de 180 secondes). Fission, pour tenter de résoudre le problème du démarrage à froid, suggère de maintenir certains conteneurs en marche en permanence (bien que cela entraîne des coûts d'indisponibilité des ressources). Et OpenFaaS propose un ensemble de déclencheurs pour tous les goûts et toutes les couleurs : HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT et autres.
Les instructions pour démarrer peuvent être trouvées dans la documentation officielle des frameworks. Travailler avec eux nécessite un peu plus de compétences que lorsque l'on travaille avec un fournisseur - c'est au moins la possibilité de lancer un cluster Kubernetes via la CLI. Tout au plus, incluez d'autres outils open source (par exemple, le gestionnaire de files d'attente Kafka).
Quelle que soit la manière dont nous travaillons avec Serverless - via un fournisseur ou en utilisant l'open source, nous bénéficierons d'un certain nombre d'avantages et d'inconvénients de l'approche Serverless.
Du point de vue des avantages et des inconvénients
Serverless développe les idées d'une infrastructure de conteneurs et d'une approche de microservices, dans lesquelles les équipes peuvent travailler en mode multilingue sans être liées à une seule plateforme. La construction d'un système est simplifiée et les erreurs sont plus faciles à corriger. L'architecture des microservices vous permet d'ajouter de nouvelles fonctionnalités au système beaucoup plus rapidement que dans le cas d'une application monolithique.
Le sans serveur réduit encore davantage le temps de développement, permettant au développeur de se concentrer uniquement sur la logique métier et le codage de l'application. En conséquence, les délais de commercialisation des développements sont réduits.
En prime, nous bénéficions d'une mise à l'échelle automatique pour la charge, et nous payons uniquement pour les ressources utilisées et seulement au moment où elles sont utilisées.
Comme toute technologie, le Serverless présente des inconvénients.
Par exemple, un tel inconvénient peut être le temps de démarrage à froid (en moyenne jusqu'à 1 seconde pour des langages tels que JavaScript, Python, Go, Java, Ruby).
D'une part, en réalité, le temps de démarrage à froid dépend de nombreuses variables : le langage dans lequel la fonction est écrite, le nombre de bibliothèques, la quantité de code, la communication avec des ressources supplémentaires (les mêmes bases de données ou serveurs d'authentification). Puisque le développeur contrôle ces variables, il peut réduire le temps de démarrage. Mais d'un autre côté, le développeur ne peut pas contrôler l'heure de démarrage du conteneur - tout dépend du fournisseur.
Un démarrage à froid peut se transformer en démarrage à chaud lorsqu'une fonction réutilise un conteneur lancé par un événement précédent. Cette situation se présentera dans trois cas :
- si les clients utilisent fréquemment le service et que le nombre d'appels à la fonction augmente ;
- si le fournisseur, la plateforme ou le framework vous permet de faire fonctionner certains conteneurs en permanence ;
- si le développeur exécute des fonctions sur une minuterie (disons toutes les 3 minutes).
Pour de nombreuses applications, un démarrage à froid ne pose pas de problème. Ici, vous devez vous baser sur le type et les tâches du service. Un délai de démarrage d'une seconde n'est pas toujours critique pour une application métier, mais il peut le devenir pour les services médicaux. Dans ce cas, l’approche sans serveur ne sera probablement plus adaptée.
Le prochain inconvénient du Serverless est la courte durée de vie d'une fonction (délai d'attente pendant lequel la fonction doit être exécutée).
Mais si vous devez travailler sur des tâches de longue durée, vous pouvez utiliser une architecture hybride : combinez le sans serveur avec une autre technologie.
Tous les systèmes ne pourront pas fonctionner avec le schéma Serverless.
Certaines applications stockeront toujours les données et l'état pendant l'exécution. Certaines architectures resteront monolithiques et certaines fonctionnalités dureront longtemps. Cependant (comme les technologies cloud puis les conteneurs), le Serverless est une technologie promise à un bel avenir.
Dans cette optique, je voudrais aborder en douceur la question de l'utilisation de l'approche Serverless.
Du côté des applications
Pour 2018, le pourcentage d'utilisation sans serveur . Parmi les entreprises qui ont déjà mis en œuvre la technologie dans leurs services figurent des géants du marché tels que Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. En même temps, il faut comprendre que le Serverless n'est pas une panacée, mais un outil pour résoudre un certain nombre de problèmes :
- Réduisez les temps d’arrêt des ressources. Il n’est pas nécessaire de conserver en permanence une machine virtuelle pour les services nécessitant peu d’appels.
- Traitez les données à la volée. Compressez des images, découpez des arrière-plans, modifiez l'encodage vidéo, travaillez avec des capteurs IoT, effectuez des opérations mathématiques.
- « Collez » d’autres services ensemble. Dépôt Git avec programmes internes, chat bot dans Slack avec Jira et calendrier.
- Équilibrez la charge. Regardons de plus près ici.
Disons qu'il existe un service qui attire 50 personnes. En dessous se trouve une machine virtuelle avec un matériel faible. De temps en temps, la charge sur le service augmente considérablement. Un matériel faible ne peut alors pas faire face.
Vous pouvez inclure un équilibreur dans le système qui répartira la charge, par exemple, sur trois machines virtuelles. À ce stade, nous ne pouvons pas prédire avec précision la charge, nous gardons donc une certaine quantité de ressources en réserve. Et nous payons trop cher pour les temps d'arrêt.
Dans une telle situation, nous pouvons optimiser le système grâce à une approche hybride : nous laissons une machine virtuelle derrière l'équilibreur de charge et mettons un lien vers le Serverless Endpoint avec des fonctions. Si la charge dépasse le seuil, l'équilibreur lance des instances de fonction qui prennent en charge une partie du traitement des requêtes.
Ainsi, Serverless peut être utilisé lorsqu'il est nécessaire de traiter un grand nombre de requêtes pas trop souvent, mais de manière intensive. Dans ce cas, exécuter plusieurs fonctions pendant 15 minutes est plus rentable que de maintenir une machine virtuelle ou un serveur en permanence.
Avec tous les avantages de l'informatique sans serveur, avant la mise en œuvre, vous devez d'abord évaluer la logique de l'application et comprendre quels problèmes sans serveur peut résoudre dans un cas particulier.
Sans serveur et Selectel
Chez Selectel nous sommes déjà via notre panneau de contrôle. Nous construisons maintenant notre propre plateforme FaaS. Nous voulons que les développeurs puissent résoudre leurs problèmes en utilisant Serverless via une interface pratique et flexible.
Si vous avez des idées sur ce que devrait être la plateforme FaaS idéale et sur la manière dont vous souhaitez utiliser Serverless dans vos projets, partagez-les dans les commentaires. Nous prendrons en compte vos souhaits lors du développement de la plateforme.
Matériaux utilisés dans l'article :
Source: habr.com