L’architecture serveur du futur se fera-t-elle via une virtualisation des ressources ou via un architecture physique louée comme telle ? C’est la question que nous nous posions dans les commentaires du billet sur l’arrivée des dédibox v3. Cela tombe bien : ça faisait assez longtemps que j’avais envie de parler des nouveaux types d’architecture pour les hébergeurs, et que je ne trouvait pas l’occasion de le faire. En effet, à l’heure actuelle, au moins trois poids lourds en terme de capitalisation ont lancé des offres de serveurs, toutes virtualisées.
Ces poids lourds, qui sont-ils ?
- Il y a d’abord Google, avec AppEngine,
- mais également Microsoft avec Azure,
- et enfin (peut-être le plus connu) Amazon avec les Amazon Web Services.
Notons de surcroît que les hébergeurs plus « classiques » commencent à se lancer sur le secteurs, avec notamment :
- 1and1 qui propose ses serveurs « Cloud Dynamique »,
- GoDaddy avec ses Cloud Servers powered by MacOS X (je ne sais pas du tout ce que ça vaut),
- OVH avec son miniCloud, ou
- Gandi avec son système de parts.
Tout ça pour dire que la tendance aux serveurs « dynamiques » semble être une tendance de fond et pas simplement une mode. Elle permet notamment une flexibilité dans les ressources, tout en allant progressivement vers des performances aussi bonnes que celles d’un serveur physique. Certains, comme Google avec AppEngine, cachent complètement le souci des ressources ou de leur quantité, et ne fait payer qu’à la quantité de calculs pour le processeur, à la quantité de bande passante consommée, à la quantité de mémoire, etc. On ne paye que ce que l’on consomme. Dans un sens, c’est sympathique : on ne se préoccupe pas de la qualité du processeur et on se concentre sur la qualité de l’application ; par contre, point de mot à dire sur le type de serveur utilisé et les temps de réponses moyens. Je lisais d’ailleurs un billet récemment sur Google AppEngine (et bien sûr, je ne parviens pas à le retrouver) d’une personne déçue par le service, car elle s’était rendue compte que Google lui mettait son application en sommeil dès que celle-ci n’était plus visitée pendant une certaine durée, et que l’utilisateur suivant avait un temps de réponse un peu supérieur (le temps de « réveiller » l’application). Cette virtualisation des ressources a donc ses avantages et ses inconvénients.
Pour autant, j’ai tendance à penser qu’elle finira par prendre le pas sur les architectures physiques telles les dédibox v3 ou les Kimsufi 250G. En effet : les offres Cloud sont déjà parmi celles qui sont louées aux prix les plus bas, donc les serveurs dédiés ne pourront pas longtemps rester en compétition avec eux. Ensuite, le Cloud offre l’avantage pour l’hébergeur de pouvoir rassembler plusieurs offres qu’il avait avant : les serveurs privés virtuels sont en fait à peu de chose près des offres Cloud, les hébergement mutualisés en sont aussi, et les serveurs dédiés dont le stockage est délocalisés peuvent également être considérés comme tels. Finalement, seuls les besoins « professionnels » et très spécifiques vont encore avoir besoin de serveurs « nominatifs » (par exemple pour les entreprises ayant besoin de réaliser un audit de sécurité sur l’accès physique au serveur), et donc il est possible que ce type d’offre devienne progressivement marginal.
Au passage, les hébergeurs classiques risquent d’avoir très mal le jour où Google supportera le PHP et MySQL (s’il les supportent un jour), car son mode de paiement à la consommation risque de séduire une partie importante des sites web hébergés…
Je rajoute que, malgré les récentes offres proposées par les hébergeurs (les « offres à 15 euros pour des serveurs mini »), je ne vois pas de possibilité de vérifier si le serveur est effectivement virtualisé ou non, dans la mesure où tous les niveaux réseaux et processeurs peuvent être gérés/virtualisés…
Edit : Merci à Thomas pour la relecture.
pour savoir si l’on est sur un système virtualisé, on peut :
– Regarder si les flags vmx ou [celui d’AMD je ne me rappelle plus] sont présents dans le cpu (s’ils le sont c’est un serveur physique – pour le moment – , sinon ça ne veut pas non plus dire que c’est une VM)
– Regarder le nom du BIOS (si on trouve un truc genre BOSH ou autre, on est sur que c’est un serveur virtuel, mais l’inverse ne prouve pas que nous sommes sur une machine physique)
Bref il n’est pas impossible (mais pas facile) de savoir si l’on est sur une VM ou non.
@primalmotion: Oui, c’est ce que je voulais dire dans le : « dans la mesure où tous les niveaux réseaux et processeurs peuvent être gérés/virtualisés… » => Y’a toujours moyen de cacher le fait que c’est une virtualisée…
Oui j’avais compris. Moi je voulais dire que malgré le fait qu’ils essayent de cacher, il y a toujours un moyen de savoir si c’est une virtualisée 🙂 Le chat la souris, bref la beauté de l’informatique quoi
Je pense qu’il faudrait dissocier des cas d’emplois différents selon moi. Google comme Zoho offrent du SaaS (GMail ou bien Zoho CRM) et du PaaS (AppEngine et Zoho Merketplace).
Rien ne prouve qu’il y ait de virtualisation de serveur. On peut très bien rendre les applications étanches avec des serveurs 100% physiques. Si je ne me trompe pas, Azure est sur le même modèle.
Maintenant, les comparer à Amazon (et consors) qui font du IaaS, c’est-à-dire louer de la VM ne me semble pas pertinents.
En prenant du PaaS, tu veux justement ne plus avoir les problèmes physiques à traiter et pour ce faire, tu es d’accord pour coder selon certaines normes. Alors qu’IaaS t’offre de la vCPU, tu restes maître des autres choix techniques (OS, etc…)
Donc, j’organiserais la lutte ainsi : Hébergeur vs IaaS vendors (pour ceux qui aiment le hard)
Ensuite, la seconde lutte serait : Software on Premise vs on Demand vs PaaS vs SaaS (choix bien plus compliqué mais plus stratégique selon moi)
C’est pourquoi, je pense que la révolution Salesforce est bien plus révélatrice que celle d’Amazon…
@H4mm3r: Ton commentaire est très intéressant : je me suis demandé si je l’ajoutais à l’article en Edit ou pas. En effet, j’ai occulté l’asapect différentiation entre SaaS/PaaS et IaaS dans mon billet, et c’est vrai que si tu les différenties, tu arrives aux conclusions que tu donnes. J’ai choisis de ne pas les différentier, c’est certainement une erreur (mais peut-être est-ce plus simple).
Pour le reste, je suis à 100% d’accord avec toi. Précisément :
=> Oui, mais tu n’es plus lié à la machine physique, justement car tu bénéficies de la virtualisation. Ce qui te permet de rajouter/retirer des ressources de façon « logicielle » plutôt que matérielle.
=> Oui, tu ne gères plus les problèmes « bas niveau » et tu te concentres sur les aspects « logiciel » de ton service/site.
=> Plus largement, ça regroupe d’un côté la virtualisation (IaaS) et de l’autre les plateformes logicielles (SaaS/PaaS).
Par contre, je ne comprends pas pourquoi tu dis :