Lorsque sont arrivées les machines virtuelles On Premise et pendant de très très longues années (et même encore parfois maintenant), combien de fois avez-vous entendu la phrase suivante : "Ah, Ok, ce n’est pas grave, c'est une VM".
La IaaS Azure n’est pas le Cloud, c’est un Datacenter
La machine virtuelle, une sous machine de l’environnement ? Pas vraiment. Quel client n’a pas dans son parc des machines dont le rôle est essentiel et primordial, comme des bases de données de production ou des contrôleurs de domaine ?
Le constat quelques années plus tard
Quelques dizaines d’années plus tard, qui n’a pas de nouveau entendu cette phrase au sujet des machines de type Cloud : « Ah, Ok, ce n’est pas grave c’est une machine Azure… ». Il n’est pas question ici d’un service managé, mais bien d’une machine d’infrastructure sur le modèle du IaaS (Infrastructure en tant que service).
Comment ne pas vivre son IAAS comme une déception si, dès le départ, cet ajout n’est pas vu comme une extension de son Datacenter ? Car c’est bien de cela dont il est question, un autre Datacenter, un ajout à l’infrastructure existante. Ne plus assurer la gestion physique de ses machines hébergées n’exclut une bonne préparation.
Pourquoi faire attention ?
Alors pourquoi ce sentiment qui laisse penser qu’une machine Azure, ce n’est pas grave ? Il est souvent dû au fait que les déploiements sont accélérés chez les fournisseurs de Cloud. Le déploiement d’un nouveau réseau virtuel ne prend que quelques secondes, celui d’une machine virtuelle quelques minutes. Cette facilité est un peu grisante lors de la phase de découverte. Le mode de facturation de type « paiement à l’utilisation » ajoute à la facilité. C’est un mode de facturation adapté qui impacte peu le budget lors de l’ajout / retrait de ressources principalement dans les phases de tests. Les ressources sont jetables. Ces phases peuvent encore supporter les approximations, les ressources sont détruites, puis redéployées.
Penser Architecture
Puis les ressources sont portées sur les environnements de production, ou des environnements de validation proches de la production. Une architecture logique mal pensée n’est ni viable, ni efficiente On premise. Elle ne le sera pas plus chez un fournisseur de machines Cloud. Un réseau mal pensé, des accès faiblement sécurisés ou une délégation d’administration et de responsabilités incomplète ne sont que quelques-uns des sujets qui peuvent dégrader l’expérience.
Téléchargez cette ressource
Travail à distance – Guide IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
Comment se préparer efficacement ?
Ce passage Test vers Production doit être préparé très sérieusement. Il n’est plus question de déployer, de faire et de défaire.
A cette étape, On Premise = Cloud. Les équipes techniques sont en charge d’identifier le besoin, puis de décrire l’architecture, de fixer les règles. Cette étude menée, une bonne pratique consiste à se pencher sur les modèles d’Architectures de solution Azure.
Ces modèles décrivent les usages pour concevoir et implémenter des solutions résilientes, performantes, hautement disponibles et sécurisées sur Azure (https://azure.microsoft.com/fr-fr/solutions/architecture/). Ces sont des vues et des conseils d’implémentation qui pointent ensuite sur tout un ensemble de ressources de déploiements. INDISPENSABLE !
Aucun déploiement ne devrait se faire sans (a minima) comparer ses choix d’architecture avec les modèles existants.
Cette phase de préparation vous garantit des résultats cohérents et la fin d’un Cloud IaaS en dessous de vos attentes.
Finalement, quel apport par le Cloud ?
L’architecture logique est clairement définie, il reste à profiter des nombreux avantages de l’hébergement Azure. La facilité de déploiement a déjà été abordée dans cet article, et voici quelques exemples supplémentaires pour affiner et adapter l’architecture post installation.
Une machine peut être sous ou sur taillée même après une bonne préparation. Elle n’est pas assez puissante, il est facile d’ajuster sa taille avec une coupure de services de quelques minutes seulement sans réinstallation, juste en ajustant les valeurs CPU / mémoire au travers des modèles.
Elle est trop puissante, donc trop coûteuse pour l’usage ? Sur le modèle précédent, il est facile de retirer de la puissance et d’adapter les coûts.
Mieux même, elle ne sert plus entre 18 h et 8 h ? Elle peut être éteinte puis démarrée automatiquement pour n’être pleinement facturée que lorsqu’elle est réellement utilisée.
Un Datacenter supplémentaire performant pour lequel le Cloud ajoutera souplesse est rapidité, c’est possible si et seulement si ce Datacenter a été bien préparé !
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- AI Speech double toutes vos vidéos !
- Finance : l’IA générative plébiscitée pour les décisions stratégiques
- Cybersécurité : les comportements à risque des collaborateurs
- Prédictions 2025 : voici comment l’intelligence artificielle va redéfinir la sécurité de 3 façons
- Top 5 des technologies à suivre en 2025 et au-delà !