Entrazure
La plupart des applications devraient rester sur une machine virtuelle
La phrase est inhabituelle sur une page qui vend de la modernisation applicative, alors voici le raisonnement.
Réhéberger une machine virtuelle se compte en heures et se défait. Moderniser une application se compte en semaines d’ingénierie, touche la configuration, l’état, l’identité, la journalisation, le réseau et le processus de déploiement, et ne se défait que dans la mesure où l’ancien serveur est encore éteint quelque part. Le retour vient de ce que la plateforme fait ensuite pour vous chaque semaine : les correctifs que vous n’appliquez plus, les mises en service qui prennent des minutes au lieu d’une fenêtre de maintenance, la capacité qui suit la charge au lieu d’être dimensionnée pour la pire heure de l’année.
Une application qui livre deux fois par an ne récolte presque rien de tout ça. Une application qui livre chaque semaine le récolte en continu. La variable n’est pas l’âge, et ce n’est pas non plus le désagrément que procure la lecture du code. C’est la fréquence de changement.
Le premier livrable du mandat est donc en général une liste plus courte que celle qu’on nous a remise. C’est exactement l’intérêt de l’exercice. Un cabinet qui recommande de tout moderniser décrit son propre plan de charge, pas votre parc.
Le test que nous appliquons
À quelle fréquence change-t-elle ? Le nombre de livraisons par an, tiré de l’historique du dépôt et non de la mémoire des équipes. C’est le meilleur indicateur isolé de rentabilité.
Que coûte réellement la machine virtuelle ? Pas la ligne de calcul. La fenêtre de correctifs, la montée de version du système d’exploitation qui attend dans deux ans, les licences Windows et SQL Server, et l’ingénieur qui est le seul à savoir comment le service se redémarre.
La charge varie-t-elle ? Une application à charge plate toute la semaine gagne peu à l’élasticité. Une application inactive la nuit et saturée en fin de mois y gagne beaucoup, et la mise à l’échelle jusqu’à zéro de Container Apps change l’arithmétique des outils internes.
Y a-t-il une frontière de support ? Si l’éditeur ne supporte son produit que sur machine virtuelle, la décision est prise pour vous. Conteneuriser un produit du commerce hors de son support, c’est échanger un problème de correctifs contre un problème de contrat.
Qui l’exploite après ? Une plateforme que votre équipe sait exploiter vaut mieux qu’une meilleure plateforme qu’elle ne sait pas exploiter. Cette question tranche entre App Service et Kubernetes plus souvent que n’importe quel argument technique.
Où atterrissent les applications
App Service. Le choix par défaut pour les applications web et les API. Emplacements de déploiement, certificats intégrés, mise à l’échelle automatique, et plus aucun système d’exploitation à votre charge. La plupart des couches web .NET, Java, Node et Python ont leur place ici, et la migration se résume le plus souvent à un pipeline de compilation et à un changement de configuration plutôt qu’à une réécriture.
Azure Container Apps. Traitements de fond, travaux déclenchés par événement, traitements planifiés et petits ensembles de services qui se parlent. Mise à l’échelle jusqu’à zéro, aucun cluster à exploiter, et rien de la surface Kubernetes qu’il faudrait sinon savoir tenir.
Azure Kubernetes Service. Pour les vraies plateformes multiservices, les exigences de portabilité et les profils de montée en charge qui justifient un cluster. Quand nous le recommandons, nous concevons avec lui les pools de nœuds, l’identité de charge de travail, l’entrée réseau et les limites de coût, parce qu’un cluster sans bornes est un incident budgétaire en attente. Quand nous ne le recommandons pas, nous écrivons pourquoi.
Azure Functions. La colle événementielle : arrivée de fichier, traitement de file, tâches planifiées. Souvent la bonne destination pour les scripts qui tournent sur une machine virtuelle que personne n’ose redémarrer.
Les données en dessous. SQL Server vers Azure SQL Managed Instance ou Azure SQL Database selon l’évaluation de compatibilité, PostgreSQL et MySQL vers leurs équivalents gérés. L’application et sa base bougent ensemble, sinon l’exercice est à moitié fait.
Ce que le travail contient vraiment
La modernisation est surtout ingrate, et ça vaut la peine de le nommer, parce que les estimations qui dérapent sont celles qui n’ont compté que la construction du conteneur.
L’état quitte le disque local. Sessions, fichiers déposés et caches partent vers des services faits pour les tenir, et c’est en général le changement qui casse des hypothèses écrites en 2014. La configuration et les secrets quittent le système de fichiers et la chaîne de connexion, et l’application s’authentifie avec une identité de charge de travail dans Microsoft Entra ID au lieu d’un mot de passe dans un fichier. La journalisation part vers Log Analytics, avec une corrélation qui survit à la multiplication des instances. Le réseau privé remplace la sécurité implicite d’une machine posée sur un sous-réseau interne, au moyen de points de terminaison privés plutôt que de règles de pare-feu tenues à la main. Et le processus de mise en service devient un pipeline GitHub Actions ou Azure DevOps, avec une promotion d’environnement et un retour arrière déjà éprouvé.
Chacun de ces éléments est petit. Ensemble, ils constituent le mandat, et ensemble ils expliquent pourquoi un plan honnête modernise peu d’applications correctement plutôt que beaucoup d’applications mal.
Ce que vous gardez
- Une liste de candidates notée, avec les applications que nous avons déconseillées et pourquoi.
- La plateforme cible par application, avec le raisonnement et le coût d’exploitation retiré.
- Le code en état de marche dans votre organisation Git, dès le premier commit.
- Les pipelines de compilation et de mise en service, avec promotion d’environnement et retour arrière éprouvé.
- Des procédures d’exploitation couvrant le déploiement, la montée en charge, les modes de panne et l’emplacement des journaux.
- Une référence écrite du comportement avant et après, pour qu’une discussion sur une régression s’appuie sur des faits.
Pour qui c’est
Des organisations déjà sur Azure, ou en train d’y aller, avec un petit nombre d’applications qui portent du vrai changement d’affaires et que les machines en dessous retiennent. C’est fréquent après une migration infonuagique stabilisée, et c’est fréquent quand une équipe de développement livre assez vite pour que l’infrastructure soit devenue la contrainte.
C’est aussi pour les organisations à qui l’on a chiffré une réécriture complète et qui veulent un deuxième avis. Bien souvent, la réponse est que deux composants méritent l’investissement et que le reste mérite un système d’exploitation supporté et une vie tranquille.
Pour qui ce n’est pas
Si le parc n’a pas encore bougé, ce n’est pas le premier mandat. Déplacez d’abord avec la migration infonuagique, puis modernisez ce qui le mérite, ou tranchez le sort de tout le portefeuille avec la modernisation du système d’information.
Si l’application est achetée et non construite, c’est l’éditeur qui décide. Moderniser un logiciel du commerce hors de son modèle de déploiement supporté finit avec un produit non supporté et un contrat d’assistance que vous payez toujours.
Si l’objectif est de réduire la facture Azure, c’est la route lente. L’optimisation des coûts infonuagiques y arrive plus vite, et redimensionner une machine virtuelle coûte une fraction de la reconstruction de ce qui tourne dessus.
Pages liées
- Modernisation du système d’information, la décision de portefeuille qui précède celle-ci.
- Migration infonuagique et sortie de VMware, où la plupart des applications atterrissent d’abord.
- DevOps et infrastructure en code, les pipelines dont dépend une application modernisée.
- Stratégie infonuagique, la question faire ou acheter sous une réécriture.
- Tous les services Azure, le catalogue derrière les plateformes cibles.
Questions fréquentes
Comment décidez-vous qu’une application mérite d’être modernisée ?
La fréquence de changement d’abord, puis le coût d’exploitation, puis le profil de charge, puis la frontière de support. Une application qui livre souvent, que personne ne corrige en particulier et qui reste inactive la plupart de la semaine est un cas net. Une application qui n’a pas changé depuis trois ans et tourne à charge constante ne l’est pas, quoi que son âge suggère. Le test est écrit et appliqué de la même façon à toutes les candidates.
Faut-il utiliser Kubernetes ?
Probablement pas, et le dire nous coûte du revenu. App Service ou Container Apps couvre la majorité des charges avec une fraction de la charge d’exploitation. Azure Kubernetes Service gagne sa place quand il y a une vraie orchestration multiservices, une exigence de portabilité ou un profil de montée en charge qui justifie le cluster, et quand quelqu’un l’exploitera encore dans deux ans.
Pouvez-vous moderniser une application que vous n’avez pas écrite ?
Oui, et c’est le cas courant. Ce qui compte, c’est l’accès au code source, une compilation qui fonctionne et quelqu’un capable de confirmer le comportement attendu. Quand le code source n’est pas disponible ou que l’éditeur ne supporte son produit que sur machine virtuelle, la réponse honnête est de conserver ou de réhéberger, et nous le disons plutôt que de conteneuriser quelque chose que vous ne pourrez plus faire supporter.
Faut-il le faire pendant la migration ?
Rarement, et mener les deux de front est la façon classique de faire déraper une migration. Réhéberger d’abord, stabiliser, puis moderniser le petit ensemble d’applications qui le méritent, avec une référence de fonctionnement à laquelle se comparer. L’exception est une application déjà en fin de support de son système d’exploitation, où déplacer et changer en même temps évite de payer le déplacement deux fois.
Qu’advient-il des bases de données ?
Elles bougent avec l’application, sinon elles annulent le bénéfice. SQL Server va vers Azure SQL Managed Instance ou Azure SQL Database selon l’évaluation de compatibilité, et les parcs PostgreSQL et MySQL vont vers leurs équivalents gérés. Laisser la base sur une machine virtuelle pendant que l’application part vers une plateforme gérée conserve exactement les obligations de correctifs que vous vouliez retirer.
Qui l’exploite ensuite ?
Votre équipe, avec les pipelines et la documentation pour le faire, ou nous dans le cadre d’une entente d’infogérance, décidé avant de commencer plutôt qu’après. Moderniser une application vers une plateforme que votre équipe ne sait pas exploiter déplace le problème au lieu de le régler ; nous préférons alors cadrer une cible plus simple, mais réellement exploitée.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.