Services de calcul

Ce que vous louez réellement

Le sujet précédent vous a dit qu'IaaS vous donne une machine virtuelle et que PaaS vous donne une plateforme qui fait tourner votre code. Aucun des 2 ne vous a dit ce qui se passe réellement à l'intérieur de cette boîte : une certaine quantité de CPU et de mémoire, installée dans un centre de données, que vous louez à l'heure, à la seconde ou à la requête. Cette ressource, c'est le calcul, et combien vous en obtenez, comment il est empaqueté, et comment vous le payez sont des décisions qui façonnent presque tous les autres choix que vous ferez sur une plateforme cloud.

Machines virtuelles : l'unité de base

La machine virtuelle reste la façon la plus courante de vendre du calcul, et les fournisseurs regroupent leurs offres en familles construites autour de ratios de ressources différents.

Un travail en lot qui passe son temps en calcul en virgule flottante et touche à peine la mémoire appartient à l'optimisée calcul, pas à l'usage général. Une base de données qui garde un large working set en mémoire appartient à l'optimisée mémoire. Choisir la mauvaise famille ne fait pas que gaspiller de l'argent, cela peut aussi priver une charge de la seule ressource dont elle avait réellement besoin.

Les tailles d'instance à l'intérieur d'une famille suivent une progression par doublement : une large passe à une xlarge, qui passe à une 2xlarge, en doublant à peu près vCPU et mémoire à chaque étape. Vous avez vu dans la leçon IaaS qu'une t3.micro, 2 vCPU et 1 Gio de mémoire, coûte environ 7,59 $ par mois hors stockage. Monter d'une taille double à peu près les ressources et la facture, changer de famille à taille comparable change plutôt le ratio de ressources.

Mise à l'échelle verticale contre mise à l'échelle horizontale

Cette même application se met à expirer sous la charge. Un coup d'œil aux métriques montre le CPU bloqué à 100 % pendant que l'usage mémoire reste faible. 2 réponses existent, et elles ne sont pas interchangeables.

La mise à l'échelle verticale redimensionne l'instance existante vers une plus grande, plus de vCPU, plus de mémoire, toujours 1 seule machine. C'est simple, mais cela a un plafond, la plus grande taille disponible dans la famille, et cela interrompt brièvement l'instance pendant le redimensionnement.

La mise à l'échelle horizontale ajoute davantage d'instances de la même taille et répartit la charge entre toutes, typiquement derrière un répartiteur de charge. Cela évite le plafond et ne demande aucune interruption sur les instances existantes, mais cela fonctionne seulement si l'application peut réellement répartir son travail entre plusieurs machines plutôt que de dépendre d'une seule.

Pour l'application au CPU bloqué mais à la mémoire tranquille ci-dessus, les 2 mouvements corrigent le symptôme. Celui qu'une équipe choisit réellement dépend de si l'application a été conçue pour tourner sur plus d'1 instance à la fois, une question de conception, pas une question de calcul, mais une question que les options de calcul vous forcent à trancher.

Calcul géré : quelqu'un d'autre gère la flotte

Vous avez déjà croisé AWS Elastic Beanstalk, Google App Engine et des produits similaires comme exemples de PaaS. En coulisses, ils font toujours tourner votre code sur des machines virtuelles, la différence est qui provisionne et opère ces machines. Une plateforme de calcul géré prend en charge le lancement des instances, le déploiement des nouvelles versions de votre code, et, dans la plupart des cas, la mise à l'échelle de la flotte selon le trafic. Vous choisissez toujours votre runtime et fournissez votre application, vous arrêtez seulement d'écrire les scripts qui auraient sinon provisionné et surveillé les instances à la main.

Le spectre complet du calcul

Machines virtuelles et calcul géré sont 2 points sur une ligne plus longue. Conteneurs et fonctions serverless se situent plus loin dessus, et ce domaine leur consacre à chacun une leçon complète plus tard. Pour l'instant, la forme d'ensemble du spectre compte plus que la mécanique précise de chaque arrêt.

Un conteneur partage le noyau du système d'exploitation de son hôte plutôt que de faire tourner un OS invité complet comme le fait une machine virtuelle, c'est exactement pour cela qu'il démarre en secondes plutôt qu'en minutes. Une fonction serverless, comme une fonction AWS Lambda, va encore plus loin : le fournisseur gère tout l'environnement d'exécution, et vous êtes facturé par requête et par fraction de seconde où la fonction tourne réellement, pas pour le temps d'inactivité entre 2 invocations.

Le piège : "le serverless coûte toujours moins cher"

Il est tentant de croire que payer uniquement ce que vous utilisez bat toujours le fait de payer une machine qui reste là. C'est vrai pour un trafic irrégulier ou de faible volume, où une petite machine virtuelle toujours allumée passe la majeure partie de son temps inactive et facturée quand même. Faites tourner une charge à volume élevé et constant à la place, et le calcul s'inverse : les frais à l'invocation d'une fonction serverless peuvent finir par dépasser ce qu'une instance modeste toujours allumée aurait coûté pour le même travail total. Aucune extrémité du spectre n'est moins chère dans tous les cas. Le profil de trafic tranche, c'est exactement pourquoi la comparaison complète attend sa propre leçon plus loin dans ce domaine.

Où cela vous mène

Chaque option de calcul de ce spectre répond à la même question sous-jacente : combien du travail d'exploitation et de mise à l'échelle voulez-vous garder entre vos mains contre en confier au fournisseur, au prix de combien de contrôle. Les machines virtuelles gardent le plus entre vos mains, les fonctions serverless gardent le moins. La prochaine leçon quitte le calcul et couvre ce qui arrive aux données que ces ressources de calcul lisent et écrivent : le stockage.