Un prix affiché à l’heure rend le mot cloud beaucoup plus concret. Amazon permet déjà de lancer du calcul avec EC2 et de conserver des objets dans S3. En mars 2008, il ne faut pas projeter sur ces services toutes les fonctions qui viendront plus tard : le mécanisme de base suffit déjà à changer l’architecture.

EC2 démarre une machine virtuelle à partir d’une image, avec une taille de processeur et de mémoire choisie. L’instance obtient un réseau et un stockage local lié à sa vie. Si elle disparaît, ce disque local ne doit pas être traité comme la seule copie d’une donnée importante. S3, de son côté, conserve des objets identifiés par un bucket et une clé, accessibles par des requêtes HTTP signées.

utilisateur -> DNS -> instance EC2 -> traitement
                         |          -> logs copiés vers S3
                         `----------> objets durables dans S3

Le serveur Web peut donc devenir remplaçable si son code vient d’une image connue, sa configuration d’une source séparée et ses fichiers importants de S3. Une session gardée uniquement en mémoire sera perdue au redémarrage; il faut accepter une nouvelle connexion ou placer l’état ailleurs.

Recréer plutôt que réparer à la main

Je préparerais un petit service d’images ainsi :

1. construire une image EC2 avec le système corrigé et le runtime;
2. au démarrage, récupérer la configuration depuis un emplacement protégé;
3. lire l’image source dans S3, produire la miniature et écrire le résultat sous une autre clé;
4. journaliser l’identifiant de l’objet, pas seulement le nom local;
5. arrêter volontairement l’instance et recommencer sur une nouvelle.

Ce test révèle les réglages faits à la main, les secrets laissés dans l’image et les données qui n’ont jamais quitté le disque local. Il donne aussi un temps de reprise mesurable.

La facture demande son propre calcul. Une instance à 0,10 $ l’heure coûte environ 72 $ pour 30 jours si elle reste allumée, avant le stockage et les transferts. Dix instances oubliées transforment vite une expérience peu chère en dépense régulière. Il faut associer chaque ressource à un propriétaire et arrêter ce qui n’a plus de travail.

La sécurité change de forme. Les clés d’accès ne doivent pas être intégrées au code ni dans une image partagée. Les règles réseau devraient n’ouvrir que les ports nécessaires. Un objet S3 privé doit rester privé par défaut; une mauvaise politique peut exposer des données sans qu’aucun pare-feu interne ne sonne.

Une panne du fournisseur ou du réseau reste possible. Je conserverais une copie exportable des données critiques, documenterais la région utilisée et mesurerais le temps nécessaire pour repartir. Si l’application dépend d’une seule instance, le cloud n’a pas supprimé le point de défaillance; il l’a loué.

Je commencerais avec une charge limitée et reproductible. La réussite n’est pas de lancer une instance en quelques minutes. C’est de la perdre, d’en créer une autre à partir de la recette, de retrouver les objets et de connaître la facture exacte de l’exercice.