Avantages et inconvénients du point de vue commercial

Online Coding Courses for Kids

Découvrez les avantages et les inconvénients d’une approche sans serveur pour prendre la bonne décision pour votre pile technologique

Alexandre Vazquez
photo par James Lee sur Unsplash

Sans serveur est un sujet passionné pour de nombreuses personnes, et c’est quelque chose qui a beaucoup évolué depuis sa conception. Cela a commencé par être une approche pour se débarrasser des serveurs, pas du côté technique (évidemment) mais du côté de la gestion.

L’idée derrière cela est de faire en sorte que les développeurs, et les informaticiens en général, se concentrent sur la création de code et son déploiement dans une sorte d’infrastructure gérée. La contraposition habituelle était contre les plateformes basées sur des conteneurs. Avec les services Kubernetes gérés, comme EKS ou AKS, vous êtes toujours responsable des employés qui exécutent votre charge. Vous n’avez pas à vous soucier du composant d’administration. Mais encore une fois, vous devez gérer et gérer certaines parties de l’infrastructure.

Cette approche a également été intégrée dans d’autres systèmes, comme les offres iPaaS et SaaS pures concernant le code faible ou aucun code. Et nous incluons le concept de fonction en tant que service pour faire la différence dans cette approche. La première question est donc la suivante: quelle est la principale différence entre une fonction que vous déployez sur votre fournisseur sans serveur et une application que vous pouvez utiliser sur votre iPaaS?

Cela dépend de la perspective que vous souhaitez analyser.

Je vais sauter les détails techniques sur les capacités de mise à l’échelle à zéro, les techniques d’échauffement, etc., et me concentrer sur la perspective de l’utilisateur. La principale différence est de savoir comment ces services vont vous facturer en fonction de votre utilisation.

Les offres iPaaS ou SaaS similaires vont vous facturer en fonction de l’instance d’application ou de quelque chose de similaire. Mais sans serveur / fonctionner comme une plate-forme de service vous coûtera en fonction de l’utilisation que vous faites de cette fonction. Cela signifie qu’ils vous coûteront en fonction du nombre de demandes reçues par votre fonction.

Cela change la donne. Il fournit la mise en œuvre la plus précise de l’approche optimisée des opérations et de l’élasticité. Dans ce cas, il est clair et direct que vous ne paierez que pour l’utilisation de votre plateforme. L’économie est excellente. Jetez un œil à l’offre AWS Lambda aujourd’hui:

Le niveau d’utilisation gratuite d’AWS Lambda comprend 1 million de demandes gratuites par mois et 400 000 Go-secondes de temps de calcul par mois.

Et après ce premier million de demandes, ils vous factureront 0,20 $ pour chaque million de demandes supplémentaires.

En lisant les phrases ci-dessus, vous pensez probablement: “C’est parfait. Je vais tout migrer vers cette approche! “

Pas si vite. Ce style d’architecture n’est pas valable pour tous les services que vous pouvez avoir. Bien que l’économie soit excellente, ces services sont livrés avec des limitations et des anti-modèles qui signifient que vous devez éviter cette option.

Commençons par les restrictions que la plupart des fournisseurs de cloud définissent pour ces types de services:

  • Temps d’exécution: Cela est généralement limité par votre fournisseur de cloud à un nombre maximum de secondes d’exécution. C’est juste. Si vous allez être facturé sur demande et que vous pouvez effectuer tout le travail en une seule demande qui prend 10 heures pour terminer en utilisant les ressources du fournisseur, c’est probablement ne pas juste pour le fournisseur!
  • Ressources mémoire: Également limité, pour les mêmes raisons.
  • Charge utile de l’interface: Certains fournisseurs limitent également la charge utile que vous pouvez recevoir ou envoyer dans le cadre d’une fonction – un élément à prendre en considération lorsque vous définissez le style d’architecture pour votre charge de travail.

Dans un instant, nous verrons les anti-patterns ou quand vous devriez éviter d’utiliser cette architecture et cette approche

Mais d’abord, une brève introduction à la façon dont cela fonctionne au niveau technique. Cette solution peut être très économique car le temps pendant lequel votre fonction ne traite aucune demande n’est pas chargé dans leurs systèmes. Donc, il n’utilise aucune ressource (juste une petite partie de stockage, mais c’est quelque chose de ridicule) et génère des coûts pour le fournisseur de cloud. Mais cela signifie également que lorsque quelqu’un doit exécuter votre fonction, le système doit la récupérer, la lancer et traiter la demande. C’est ce qu’on appelle généralement le «temps de préchauffage», et sa durée dépend de la technologie que vous utilisez.

  • Services à faible latence et services avec temps de réponse critique: Si votre service nécessite une faible latence ou si le temps de réponse doit être agressif, cette approche ne fonctionnera probablement pas pour vous en raison du temps de préchauffage. Oui, il existe des solutions pour résoudre ce problème, mais elles nécessitent des demandes factices au service pour le maintenir chargé et génèrent des coûts supplémentaires.
  • Processus batch ou planifié: Il s’agit d’une API sans état pour le monde natif du cloud. Si vous avez un processus par lots qui peut prendre du temps, peut-être parce qu’il est planifié la nuit ou le week-end, ce n’est peut-être pas la meilleure idée d’exécuter ce type de charge de travail.
  • Services massifs: Si vous payez sur demande, il est important d’évaluer le nombre de demandes que votre service va recevoir pour vous assurer que les numéros sont toujours de votre côté. Si vous avez un service avec des millions de demandes par seconde, ce ne sera probablement pas la meilleure approche pour votre budget informatique.

En fin de compte, la fonction sans serveur / en tant que service est si géniale en raison de sa simplicité et de son caractère économique. En même temps, ce n’est pas une solution miracle pour couvrir toutes vos charges de travail.

Vous devez l’équilibrer avec d’autres approches architecturales et plates-formes basées sur des conteneurs, ou avec les offres iPaaS et SaaS, pour garder votre boîte à outils pleine d’options pour trouver la meilleure solution pour chaque modèle de charge de travail de votre entreprise.

Close Menu