Hébergement et cloud

Ce que couvre ce rayon

Les endroits où faire tourner une application : plateformes managées qui déploient depuis un dépôt, services de conteneurs, machines virtuelles et grands fournisseurs de cloud avec plusieurs centaines de services.

La bonne réponse dépend moins de l’échelle que de la quantité de travail d’exploitation que vous voulez assumer. Chaque niveau de contrôle que vous prenez ajoute une obligation qui arrive à une heure inopportune.

Les bases de données ont leur propre rayon dans les bases de données. Surveiller ce qui se passe une fois en production relève de la supervision.

Quatre niveaux de contrôle

Les plateformes managées prennent le code et l’exécutent. Les déploiements viennent d’un dépôt, la montée en charge est un réglage, et la plupart des décisions d’infrastructure sont prises pour vous. C’est le chemin le plus rapide vers la production et le moins souple quand il faut quelque chose d’inhabituel.

Les services de conteneurs se situent un cran plus bas : ils exécutent des images que vous construisez, avec une orchestration que vous configurez. Plus de travail, plus de contrôle, et un artefact portable qui passe d’un fournisseur à l’autre.

Les machines virtuelles vous donnent un système d’exploitation et tout ce qui l’accompagne, y compris les correctifs, la sécurité et les sauvegardes.

Les grands fournisseurs de cloud offrent les trois plus un catalogue de services managés, au prix de la complexité et d’une facture qui demande de l’attention.

Les questions qui décident de la performance

• Choix de la région, près de vos utilisateurs et de votre base de données.
• Démarrages à froid, sur tout ce qui descend à zéro entre deux requêtes.
• Connexions persistantes, que certains modèles serverless gèrent mal.
• Durée de build et de déploiement, car un déploiement de dix minutes change la fréquence des mises en production.
• Diffusion statique, mise en cache près des visiteurs plutôt que servie depuis l’origine à chaque fois.

La distance entre l’application et ses données est le problème auto-infligé le plus courant. Cinquante requêtes par page à travers une frontière de région produisent un site lent qu’aucun travail côté interface ne peut sauver.

Fiabilité, et ce qui arrive un mauvais jour

Les promesses de disponibilité méritent d’être lues plutôt que crues. La plupart couvrent le plan de contrôle du fournisseur lui-même et compensent par des crédits de service, ce qui n’est pas ce que vous coûte une panne.

Interrogez sur les domaines de défaillance : vos instances sont-elles dans une zone ou plusieurs, que fait un redéploiement au trafic en cours, et le retour arrière est-il un bouton ou une reconstruction. Demandez comment les journaux sont conservés et si vous pouvez y accéder quand le tableau de bord est indisponible.

Interrogez ensuite sur la reprise que vous maîtrisez. Une panne du fournisseur est surmontable si vos données ont une copie ailleurs et si votre déploiement est reproductible. Ni l’un ni l’autre n’est vrai par défaut.

Coût, et les lignes qui grossissent discrètement

La puissance de calcul est le chiffre affiché sur la page de tarifs. La facture se compose en général de cinq choses.

Le trafic sortant est facturé au gigaoctet pour les données qui quittent le fournisseur, et il s’accumule le plus vite avec la vidéo, les téléchargements et le trafic entre régions. Le stockage grossit et rétrécit rarement. Les services managés ont leurs propres compteurs. Les minutes de build comptent sur les plateformes qui reconstruisent à chaque push. Les offres de support sont en supplément presque partout au-dessus du niveau de base.

Les environnements de développement et de préproduction doublent une bonne partie de tout cela, sauf s’ils sont réduits ou arrêtés la nuit. Demandez à quoi ressemble le total avec trois fois le trafic actuel, car c’est le chiffre que vous rencontrerez réellement. L’habitude d’enfouir de tels compteurs est traitée dans ce que cachent les pages de tarifs.

Portabilité, et comment la conserver

La dépendance, dans cette catégorie, est rarement spectaculaire. Elle s’accumule un service pratique après l’autre.

Les conteneurs et les environnements d’exécution standard voyagent. Les fonctions, files, services d’identité et bases de données propriétaires non, et chaque adoption augmente le coût de départ. C’est un arbitrage légitime quand le service épargne un vrai travail, et un mauvais quand il épargne un après-midi.

Gardez l’infrastructure définie sous forme de fichiers plutôt que de clics dans une console, et remontez l’ensemble de zéro une fois. Ce que vous apprendrez de cet exercice vaut plus que n’importe quel tableau comparatif.

Adapter la plateforme à l’application

Une application web standard avec une base de données est bien servie par une plateforme managée, et le temps gagné vaut la prime pour presque toute équipe sans personnel d’exploitation dédié.

Les traitements en arrière-plan, les files et les tâches planifiées changent la donne, car les modèles serverless gèrent mal les tâches longues et certaines plateformes n’ont tout simplement aucun endroit où les mettre.

Tout ce qui a des exigences inhabituelles, qu’il s’agisse de matériel précis, d’un trafic élevé et soutenu ou d’une stricte résidence des données, pousse plutôt vers le cloud brut ou des machines dédiées.

Les sites statiques sont à l’extrémité bon marché et ne coûtent souvent rien à servir correctement.

Décidez à partir de la forme de la charge de travail plutôt que de la taille de l’entreprise. De petites équipes font tourner des applications exigeantes, et de grandes en font souvent tourner de simples.