Windows Azure veut aussi héberger les vieilles machines

Windows Azure enlève une barrière pour les équipes Microsoft. Avec les machines virtuelles encore en préversion, on peut commencer par un serveur Windows familier plutôt que réécrire immédiatement l’application pour la plateforme. Ce point de départ facilite l’essai; il ne transforme pas la vieille machine en architecture cloud.

Le portail ou l’API crée une VM depuis une image, attache des disques virtuels et la place dans un réseau. L’hyperviseur fournit processeur, mémoire et interfaces virtuels sur un hôte physique. Si l’hôte doit être remplacé, la VM peut redémarrer ailleurs. Tout état gardé uniquement sur son disque temporaire ou dans sa mémoire disparaît alors.

Un scénario hybride concret

Pour une application interne avec SQL Server local :

1. créer un réseau virtuel Azure;
2. établir un VPN site à site vers le réseau de l’entreprise;
3. déployer deux serveurs Web dans un ensemble de disponibilité;
4. placer un répartiteur devant eux;
5. garder la base locale pendant le pilote;
6. mesurer latence, débit, coût et comportement à la perte du VPN.

Chaque requête Web traverse maintenant le lien vers SQL. À 30 ms aller-retour, une page qui exécute cent petites requêtes séquentielles ajoute trois secondes. Regrouper les appels ou rapprocher la donnée devient plus important que grossir la VM.

L’ensemble de disponibilité réduit le risque que les deux instances subissent la même maintenance ou panne physique. Il ne protège pas d’un mauvais déploiement envoyé aux deux. Les fichiers de session et téléchargements doivent vivre dans un stockage partagé; sinon l’utilisateur change d’instance et perd son état.

La familiarité conserve les vieilles responsabilités

La VM demande encore correctifs, antivirus, configuration, sauvegarde et surveillance. Une image vieille de six mois démarre avec six mois de correctifs manquants. Je construirais l’image à partir d’une source maîtrisée, appliquerais la configuration par script et limiterais l’administration au VPN avec des comptes distincts.

Les disques persistants offrent de la durabilité, pas une sauvegarde applicative. Pour SQL, il faut des sauvegardes cohérentes, le journal et un test de restauration. Une suppression logique se réplique dans la VM comme ailleurs. Les certificats, DNS et secrets font partie de la reprise.

Le coût variable doit être rapproché des ressources : calcul à l’heure, stockage, transactions et trafic sortant. Éteindre une VM sans libérer les ressources correspondantes ne supprime pas forcément toute la facture. Des étiquettes, budgets et dates d’expiration évitent le laboratoire oublié.

Mesurer le lien hybride comme une dépendance applicative

Le VPN a débit, latence, perte et capacité de reconnexion. Je placerais des sondes des deux côtés, puis suivrais temps DNS, établissement TCP et durée de requêtes SQL. Une seconde liaison n’aide que si son routage et son fournisseur ne partagent pas le même point de panne. Le basculement est testé avec des transactions en cours; les pools de connexions doivent expirer et se rouvrir plutôt que conserver des sockets mortes. Une limite d’appels par page protège le lien. Ces mesures permettent de décider si une table de lecture locale, une file ou un déplacement de la base vaut mieux qu’une connexion toujours plus grosse.

Je profiterais des VM pour mesurer un déplacement, puis je classerais les résultats : composantes à garder telles quelles, état à externaliser et fonctions à repenser. Lift-and-shift peut être une étape honnête. Il devient risqué lorsqu’on confond la possibilité de démarrer une machine avec la capacité d’exploiter un service résilient.

Mise à jour de 2026

Le produit a pris le nom Microsoft Azure le 3 avril 2014, alors que la plateforme dépassait déjà largement Windows. Pour mars 2013, Windows Azure est donc le bon nom historique. Pour le service actuel, il faut dire Microsoft Azure. L’entreprise avait annoncé ce changement de nom quelques jours avant son entrée en vigueur.