L'informatique sans serveur expliquée :Comparaison des fonctionnalités et des tarifs avec le SaaS, l'IaaS et le PaaS

Lorsque vous envisagez d'héberger votre application, vous voulez qu'elle soit aussi simple que possible.

Après tout, vous êtes sur le point de créer un logiciel qui transformera votre organisation, votre communauté, voire le monde. (Pas besoin de modestie ici !)

Sur ce chemin vers la grandeur, il n'y a pas de place pour accueillir les frustrations.

Tout le monde souhaite une solution d'hébergement qui facilite le déploiement rapide des fonctionnalités. Il doit également être rentable, préserver vos résultats et libérer des ressources à consacrer au développement.

C'est exactement la raison pour laquelle nous aimerions vous parler de Serverless. Wojtek Lichota, notre responsable de la prestation de services à Gdańsk, m'a récemment éclairé sur ce sujet passionnant. Je suis ici pour partager ce que j'ai appris.

Dans cet article, nous expliquerons :

• ce qu'est vraiment Serverless ;
• comment il se compare à d'autres solutions d'hébergement, telles que PaaS et IaaS ;
• quand pouvez-vous bénéficier d'un modèle de tarification sans serveur.

Pourquoi devriez-vous vous soucier de Serverless ?

C'est la question la plus urgente à laquelle répondre, car Serverless arrive. Le battage médiatique pour cela monte.

Gartner, une importante société d'analyse qui étudie le marché de l'informatique, a publié son rapport annuel Hype Cycle for Emerging Technologies. Vous pouvez jeter un œil à l'image pour voir ce qui s'en vient :

Comment fonctionne le Hype Cycle ? Sur le graphique, Serverless est entouré d'un certain nombre d'autres technologies, chacune à une étape différente du cycle. En bref :

1. d'abord, le battage médiatique grandit ;
2. puis, ça culmine ;
3. puis, les gens commencent à voir des problèmes et à critiquer ;
4. Enfin, ils trouvent des moyens de le faire fonctionner :la technologie arrive à maturité.

Jetez un œil à la blockchain, par exemple, qui a un peu dépassé le pic. En ce moment, le battage médiatique pour la blockchain atteint son apogée. Presque toutes les entreprises technologiques avec lesquelles nous parlons veulent en savoir plus sur la blockchain. Il en va de même pour le Deep Learning et l'IoT.

Pour l'informatique sans serveur, le battage médiatique ne fait que commencer, ce qui signifie que vous pouvez vous y mettre tôt.

Pour être juste, le modèle informatique sans serveur n'est pas une idée entièrement nouvelle ; il a au moins 3 à 4 ans. Mais jusqu'à récemment, cela n'était discuté qu'entre experts techniques, développeurs et professionnels DevOps.

Maintenant, Serverless commence à entrer dans la conversation informatique plus large. Comment réagir ?

À tout le moins, vous devriez comprendre ce qui va être dans l'esprit de tout le monde très bientôt. Mais plus important encore, vous souhaiterez peut-être implémenter une architecture sans serveur dans votre projet.

Donc, pour rester à jour, vous devez connaître Serverless.

Et si vous cherchez un moyen de créer facilement des applications sans avoir besoin de compétences DevOps, vous devriez surtout lire la suite.

Qu'est-ce que le modèle sans serveur ?

Le chemin vers le sans serveur

Le nom Serverless peut être un peu trompeur. Lorsque nous parlons de Serverless, nous ne parlons pas seulement de serveurs, mais de l'ensemble de l'écosystème cloud.

La façon la plus simple d'expliquer Serverless est de prendre une vue historique.

Il y a longtemps dans les jours passés, vous faisiez principalement affaire avec des serveurs dédiés . Pour héberger votre application, vous deviez acheter un serveur complet qui serait physiquement situé dans une salle de serveurs. L'ensemble du serveur était à vous et vous étiez responsable de son bon fonctionnement.

Comme vous pouvez l'imaginer, c'était un peu pénible à faire, surtout quand tout ce que vous vouliez vraiment était de créer votre application, pas de passer du temps à mettre à jour et à entretenir votre ou vos serveurs.

En réponse à cela, IaaS — ou Infrastructure en tant que service — est né. En IaaS, le serveur n'est plus à vous; c'est celui du fournisseur. Tout ce dont vous avez à vous soucier est de configurer le système d'exploitation, l'application elle-même, ses fonctions et le service. Un exemple de solution IaaS est AWS EC2 (ou Amazon Web Services Elastic Compute Cloud). Newable Business Finance est un projet où nous avons eu la chance d'appliquer IaaS dans la pratique.

Mais si vous êtes comme moi, cela ressemble toujours à trop d'"Ops" dans votre DevOps.

La prochaine étape est donc la plate-forme en tant que service :PaaS. Ici, le système d'exploitation tombe du côté du fournisseur. Tout ce que vous avez à faire est de créer l'application, tandis que le fournisseur s'inquiète de la mise à jour du système d'exploitation et de sa sécurité. Un exemple est Google App Engine, que nous avons utilisé pour travailler avec des clients tels que KeyIngredient.

Architecture sans serveur :du niveau de l'application au niveau de la fonction

Nous arrivons maintenant au sans serveur, la prochaine étape logique.

Lorsque vous utilisez l'architecture sans serveur pour votre logiciel, vous n'avez pas besoin de créer toute l'application. Au lieu de cela, vous ne créez que des fonctions uniques de l'application, tandis que la couche d'application, la partie qui gère les fonctions, se trouve du côté du fournisseur.

Cela signifie que le fournisseur gère la mise à l'échelle et assure un bon échange d'informations entre les différentes parties de l'application, vous n'avez donc pas à vous en soucier. Dans Serverless, vous et vos développeurs ne vous souciez que de la création de fonctionnalités. Et n'est-ce pas ce que devrait être le développement ?

Sans serveur ou logiciel en tant que service (SaaS)

Enfin, le dernier modèle sur l'image est SaaS , ou logiciel en tant que service. Ici, tout le logiciel est du côté du fournisseur. En tant qu'acheteur, vous obtenez le service, c'est-à-dire ce que le logiciel fait réellement.

Les applications SaaS sont très populaires de nos jours, et vous en utilisez probablement certaines. Pensez à Dropbox, Salesforce, Netflix, Google Apps, etc. si vous payez pour eux, vous n'obtenez que le service qu'ils offrent.

Cependant, nous devons ici faire une distinction clé entre l'utilisation une application et création une application.

Du point de vue de l'utilisateur, Netflix peut relever du SaaS. Après tout, vous voulez juste regarder Stranger Things .

Mais lorsque vous créez un service comme Netflix, vous devez utiliser au moins un modèle sans serveur pour ajouter plus de fonctionnalités à l'application. Si vous souhaitez davantage de contrôle sur la manière dont l'application est créée et hébergée, vous pouvez utiliser PaaS ou IaaS à la place.

Prenons un autre exemple :Foodpanda. Du point de vue de l'utilisateur, il s'agit d'un logiciel en tant que service typique :le service vous aide à commander de la nourriture. Mais en le construisant, vous pouvez soit :

• créer l'ensemble du service dans un framework comme Django, puis l'héberger sur un serveur dédié,
• écrivez-le dans Django et utilisez un IaaS virtuel serveur,
• laissez le système d'exploitation au fournisseur et utilisez quelque chose comme Google App Engine, c'est-à-dire PaaS, ou
• écrire les fonctions du sans serveur manière et l'héberger via par ex. Amazon Lambda.

Mais rappelez-vous :en tant qu'utilisateur de Foodpanda, vous vous en fichez. Vous ne voulez que le service.

Mise à l'échelle dans Serverless par rapport aux autres modèles

Voyons maintenant comment vos coûts évolueront dans chaque modèle.

Foodpanda dispose de nombreuses fonctionnalités :vous répertoriez les restaurants, filtrez selon vos goûts, sélectionnez votre plat, choisissez des ingrédients supplémentaires et enfin traitez votre paiement.

Avec PaaS/IaaS, vous créeriez une application qui a tout :liste, menu et commande.

Avec Serverless, vous diviseriez cela en plusieurs fonctionnalités (ou Lambdas pour Amazon Lambda). Vous ne les combinez pas dans une seule application, mais les envoyez séparément au fournisseur, et le fournisseur crée l'application.

Le fournisseur gère également la mise à l'échelle. Si la fonction de menu est utilisée très souvent, mais que la commande ne reçoit pas beaucoup de demandes, le fournisseur peut adapter chaque fonction individuellement . Ainsi, la fonction de menu populaire obtiendrait plus de puissance de traitement, mais la commande aurait toujours le même niveau.

Alors que dans PaaS/IaaS, vous êtes responsable de la configuration de l'application pour gérer la charge et être évolutive. La différence est que pour assurer une mise à l'échelle appropriée, vous avez besoin de personnel DevOps à vos côtés tandis que dans Serverless, un fournisseur tel qu'Amazon gère tout cela.

TL;DR :l'architecture sans serveur vous permet de vous concentrer sur le code de l'application, et non sur la façon dont le code fonctionnera sur le serveur.

Dois-je me soucier du Serverless si j'externalise ?

Bien sûr, nous serions négligents de ne pas mentionner le scénario d'externalisation. En tant que client, vous engagez une société de logiciels pour gérer la création de logiciels pour vous. Dans certains cas, vous pouvez demander à l'éditeur de logiciels de gérer également DevOps, c'est-à-dire la configuration des serveurs, le déploiement de l'application sur le serveur, l'intégration continue, etc.

Avec Serverless, les DevOps sont hors de l'équation — votre éditeur de logiciels n'a plus à le faire. Mais pourquoi devriez-vous vous en soucier ?

Parce qu'à un moment donné, vous voudrez peut-être ramener le développement en interne, et vos employés n'auront pas non plus à faire de DevOps.

Mais le plus important, vous devez vous en soucier, car dans le scénario interne comme dans le scénario d'externalisation, Serverless sera très souvent la solution la plus rentable, en particulier pour les applications sans grand nombre d'utilisateurs. Parlons-en ensuite.

Prix :Comment Serverless peut vous faire économiser de l'argent

La dernière raison d'envisager Serverless est son modèle de tarification flexible.

Dans IaaS/PaaS, vous payez pour le temps pendant lequel votre application fonctionne et est disponible pour les utilisateurs. Si vous possédez Foodpanda et que vous souhaitez qu'il soit disponible 24 heures sur 24, 7 jours sur 7, vous payez pour chaque heure lorsqu'il est en ligne et en attente de connexion des utilisateurs. Surtout, vous continuez à payer, que le serveur/l'application soit utilisé ou non. Pour évoluer, vous devez ajouter de nouvelles machines virtuelles (IaaS) ou créer de nouvelles instances d'application (PaaS).

Pour Foodpanda, c'est bien ; le site est probablement utilisé par quelqu'un chaque minute de chaque jour.

Mais que se passe-t-il si votre application n'est pas encore présidente du Popularity Club ?

Dans Serverless, s'il arrive que Foodpanda ne soit utilisé par personne pendant une demi-heure, vous ne payez pas pour cela. De manière plus réaliste, vous pourriez avoir une application de bureau que les employés utilisent principalement pendant les heures de bureau. Ce serait "s'ennuyer" toute la nuit, mais il devrait toujours être disponible pour cet employé qui a désespérément besoin de vérifier quelque chose à 2 heures du matin. Dans de tels cas, l'idéal sans serveur, car vous ne payez que l'utilisation réelle de votre application.

Qu'est-ce que j'entends par "combien l'application est utilisée" ? Avec Serverless, vous payez pour le nombre de requêtes reçues par l'application et pour les millisecondes de travail du CPU et de la RAM.

AWS Lambda

Prenons AWS Lambda d'Amazon comme exemple de tarification.

Lambda est actuellement la solution sans serveur la plus populaire. Fait important pour nous (et pour vos projets Python), Lambda est compatible avec Python 2.7 et 3.6.

Quel est donc le prix d'AWS Lambda ? Voici un aperçu provenant directement de la page officielle d'AWS Lambda :

Tarification AWS Lambda

• Approximation à 100 ms.
• Les 1 000 000 premières requêtes chaque mois sont gratuites.
  • Après cela, vous payez 0,0000006 $ par demande.
• Les 400 000 premières Go-secondes sont gratuites.
  • Après cela, vous payez 0,00005001 USD par Go-seconde.

Portez une attention particulière au "niveau gratuit". Avec Lambda, vos 1 000 000 premières requêtes (c'est-à-dire un million) et les 400 000 premières Go-secondes sont entièrement gratuites. Ensuite, chaque requête et chaque Go-seconde utilisés par votre application sont comptabilisés, et vous ne payez que pour cela.

Cette limite est réinitialisée tous les mois. Assez généreux, n'est-ce pas ?

Comparaison des coûts entre Lambda et EC2 (IaaS)

Bien sûr, Serverless n'est pas une solution pour toutes les situations. Dans certains cas, une solution IaaS comme EC2 pourrait mieux vous servir. Cela dépend de l'attention portée à votre application.

Quel est le point d'arrêt pour Serverless vs IaaS ? Jetez un œil à ce tableau, basé sur l'article Medium d'Andy Warzon, AWS Lambda Pricing in Context:A Comparaison to EC2 :

La partie la plus importante est à l'extrême droite :si votre application reçoit plus de 81,9 requêtes par seconde (24h/24 et 7j/7), alors IaaS devient la solution préférée. Si c'est moins que cela, Lambda est plus rentable.

Faisons le calcul là-dessus. Prenez la rangée du haut, dans laquelle chaque demande prend 100 ms et 128 Mo de RAM à traiter. Chaque jour, vous avez besoin en moyenne de 81,9 requêtes par seconde, multipliées par 60 secondes par minute, multipliées par 60 minutes par heure, multipliées par 24 heures…

81,9 x 60 x 60 x 24 =7 076 160 requêtes quotidiennes

Pour ces hypothèses, votre application a besoin de plus de 7 millions de requêtes quotidiennes pour que le Serverless soit plus cher que l'IaaS.

En d'autres termes, votre application doit être vraiment, vraiment populaire pour Lambda comme étant un mauvais choix. Même si l'utilisateur moyen émet généralement plusieurs demandes à chaque visite, vous aurez toujours besoin de centaines de milliers d'utilisateurs pour atteindre ce nombre.

Prenons Foodpanda comme exemple une dernière fois. En tant qu'utilisateur type :

• vous visitez le site,
• énumérez les restaurants près de chez vous,
• voir 5 à 10 restaurants,
• peut-être les filtrer,
• vérifiez peut-être leurs prix,
• mettre quelques éléments de menu dans le panier,
• saisir l'adresse,
• commander et payer.

Plus ou moins, vous devez effectuer 100 demandes pour commander le déjeuner. En supposant une telle moyenne, vous aurez toujours besoin de plus de 71 000 utilisateurs quotidiens pour atteindre le point d'arrêt Serverless/IaaS. Ce n'est peut-être pas un si gros chiffre pour Foodpanda, mais pour les startups et les applications plus spécialisées, vous feriez bien de réfléchir à Serverless.

Comment l'architecture sans serveur affecte le verrouillage du fournisseur

L'informatique sans serveur est un moyen d'exécuter des applications dans le cloud dans lequel le fournisseur de cloud gère tous les serveurs requis. Mais pour que l'application s'exécute sur Serverless, vous devez la construire d'une manière spécifique - elle doit être construite dans une architecture Serverless.

Les applications créées dans une architecture sans serveur dépendent fortement de services tiers. En tant que tel, vous pourriez avoir peur de la dépendance vis-à-vis d'un fournisseur ; une fois que vous en avez choisi un, vous ne pouvez plus revenir en arrière.

Pour citer directement Wojtek :"Ce n'est pas si mal."

La logique métier de l'application se trouve dans ses fonctions, qui peuvent être facilement déplacées vers un autre fournisseur sans serveur.

Cependant, l'application ne se compose pas uniquement de fonctions. Il comprend également d'autres composants tels que la base de données, le stockage de fichiers ou le moteur de recherche. Dans Serverless, vous ne pouvez pas exécuter une base de données sur votre machine virtuelle. Vous devez utiliser les services fournis par le fournisseur de cloud.

Mais même dans ce cas, vous pouvez réduire le risque de dépendance vis-à-vis d'un fournisseur en choisissant des composants non propriétaires qui utilisent une norme commune. Par exemple, vous pouvez utiliser Amazon RDS, c'est-à-dire une base de données SQL. Dans ce cas, changer de fournisseur ou déplacer l'hébergement vers vos propres serveurs sera beaucoup plus facile.

Réflexions finales sur le sans serveur

Alors, quels sont les plats à emporter? Voici pourquoi Serverless mérite qu'on s'y attarde :

• Le battage médiatique ne cesse de croître. L'informatique sans serveur gagnera très probablement en popularité dans les années à venir. Il vaut la peine d'envisager cette option plus tôt que la concurrence.
• Concentrez-vous uniquement sur les fonctionnalités. Avec Serverless, vous pouvez créer des fonctions individuelles de l'application et laissez le fournisseur se charger de les combiner et de les héberger.
• Mise à l'échelle plus fluide. Au lieu de créer des machines virtuelles ou des instances d'application supplémentaires, Serverless vous permet d'évoluer fonction par fonction.
• "Payez au fur et à mesure." Au lieu de payer pour des serveurs inactifs,avec Serverless, vous ne dépensez que ce que vos utilisateurs utilisent réellement l'application.

J'espère que cela vous aidera à comprendre les opportunités que Serverless vous offre. Si vous avez des questions, nous serons heureux d'y répondre dans les commentaires.

Comme toujours, un grand merci à Wojciech Lichota pour partager une fois de plus ses connaissances sur le blog STX Next. Voici quelques autres de ses articles qui pourraient vous plaire :

• Allez, allez Python Rangers ! Comparer Python et Golang
• Introduction aux frameworks Python pour débutants
• Le guide ultime pour embaucher des développeurs de logiciels à fort impact, première partie

Si cela vous a plu et que vous souhaitez en savoir plus sur nos nouveaux articles, pourquoi ne pas vous inscrire à notre newsletter ? Utilisez la case à droite (sur ordinateur) ou faites défiler vers le bas (sur mobile) pour rejoindre notre cercle restreint.