Decrypt

Je constate encore beaucoup d’interrogations sur les différences impliquées par le choix d’une infrastructure Cloud de type AWS (Amazon Web Services) ou d’une infrastructure physique classique. Tout d’abord, il y a un certain nombre d’idées reçues sur le sujet que je vais tenter de décrypter pour vous. Ensuite, il faut comprendre que chaque infrastructure présente des avantages et des inconvénients : une infrastructure de type Cloud ne correspondra pas forcément à vos besoins dans tous les cas, cependant, elle peut répondre à certains d’entre eux en optimisant ou facilitant ce que propose une infrastructure physique classique. Je vais donc présenter les différences que j’ai notées entre ces 2 infrastructures afin de vous aider à y voir plus clair et que vous puissiez vous faire une idée.

Déjà un an
Je me permets tout d’abord de vous orientez vers un précédent article que j’ai écrit il y a maintenant près d’un an sur le sujet : Un avenir nuageux… Et c’est tant mieux !. Je ne paraphraserai pas ce que j’ai déjà expliqué précédemment dans une optique purement DRY (Don’t Repeat Yourself :o)) et profiterai de cette année d’expérience supplémentaire sur le sujet (le Cloud Computing en général et AWS – Amazon Web Services – en particulier) pour répondre aux interrogations légitimes que j’ai croisées depuis.

Le cadre
Le Cloud
Pour rappel, il y a plusieurs types d’offres au niveau du Cloud et je vais m’attacher à celles de type AWS qui sont des offres orientées infrastructures plutôt que des offres de type Google (GAE ou Google App Engine), pour ne citer que lui, qui propose un environnement d’exécution pour vos applications web développées avec les APIs mises à disposition (un framework en quelque sorte). En effet, dans le dernier cas, on ne peut pas parler au niveau client (nous qui mettons la carte bleue) de gestion d’infrastructure puisque nous uploadons notre application utilisant les APIs fournies et laissons l’intégralité de la gestion de l’infrastructure au fournisseur du service. Il ne s’agit pas moins de Cloud Computing, mais simplement d’une offre de Cloud orientée « PaaS » plutôt que infrastructure.

Plusieurs couches de virtualisation : chaque éditeur oriente son offre vers une ou plusieurs couches.

L’infrastructure physique
Concernant l’infrastructure physique, je considère autant l’infrastructure hébergée soi-même que celle prise en charge chez un hébergeur spécialisé. De même, je considère autant les infrastructures reposant directement sur l’OS de la machine que celles reposant sur des environnements virtualisés. Le Cloud repose également sur de la virtualisation, mais ce n’est pas la technologie qui nous intéresse ici, mais la manière de la mettre à disposition des clients (vous). En effet, vous pourrez démarrer simplement des instances via une console, comme pour les EC2, si vous avez un ESX (VMware) par exemple, mais il s’agit « uniquement » d’un hyperviseur qui partitionne les serveurs physiques en plusieurs machines virtuelles. Vous aurez donc toujours les problématiques d’achat de matériel (lames, …), de configuration du réseau, … Mais nous entrerons dans ces détails plus tard.

Le Cloud Computing = Administrateurs Systèmes en solde ?
Et oui, c’est la période des soldes ! Un pull, une veste, … Un administrateur système ? Plusieurs fois, j’ai croisé des gens pensant que le Cloud (dans le cas des AWS) allait permettre de se passer d’administrateurs systèmes expérimentés et de pouvoir monter une infrastructure avec des connaissances moindre. La réponse est claire : C’est complètement faux !

Peut-être qu’un discours commercial mettant en avant la facilité d’utilisation des différents services laisse envisager cette éventualité et que des AMIs (Amazon Machine Image) déjà prépackagées vont nous faciliter la vie, mais il n’en reste pas moins que une fois les instances EC2 démarrées, vous vous connectez aux machines (SSH / port 22 pour Linux et TSE / port 3389 pour Windows) et vous devez les paramétrer, les tuner, …

Ce qui est vrai pour l’administrateur système dans le cadre des AWS est aussi vrai pour les architectes dans le cadre de services de Cloud Computing proposant l’accès à des couches plus hautes ( « PaaS » comme Google App Engine, …). Il y a besoin d’une personne connaissant le métier et pouvant mettre en place le besoin en termes d’infrastructure : l’outil change, mais les compétences doivent toujours être là. A noter tout de même que si on utilise les GAE, il ne sera pas nécessaire d’avoir un administrateur système pour l’application elle-même. Si l’éditeur de service Cloud propose un service dans une couche donnée (HaaS, IaaS, PaaS, …), il n’y a plus besoin des personnes s’occupant des couches inférieures. Cependant, on accepte le cadre fournit par l’éditeur de Cloud.

L’administrateur système reste incontournable, mais il évolue : il devient de plus en plus un développeur. En effet, la possibilité de lever des ressources à la volée va permettre d’ordonnancer, d’automatiser, la gestion de l’infrastructure via des scripts qui feront appel aux APIs mises à disposition par Amazon permettant de communiquer avec ses services web. Tout est service web chez Amazon : EC2, EBS, SQS, S3, SimpleDB, …), les seules opérations non SOAP ou REST est lorsque vous vous connectez directement aux instances EC2 que vous avez levées via service web ou que les instances EC2 dialoguent avec les EBS que vous avez levés via… Je vous laisse deviner.

L’administrateur peut alors, plutôt que d’aller en salle machine, ajouter un disque, brancher un serveur, … (ce qui serait le cas dans une architecture physique) ou bien prendre le téléphone et demander à l’hébergeur de le faire (prendre un café… Appeler de nouveau… Prendre un Xanax ou un Prozac… ;ob), demander l’obtention de ressources via un script en Ruby, Python, … Il est ensuite possible de pousser beaucoup plus loin l’automatisation d’une infrastructure Cloud via un ensemble de scripts et d’outils (Cf. Mise en place d’une infrastructure sur AWS : best practices !).

Le métier de l’administrateur système évolue donc entre une infrastructure physique et une infrastructure Cloud type AWS : il devient de plus en plus un développeur. Mais il n’en reste pas moins indispensable.

L’Elastic c’est fantastique !
Comme évoqué précédemment, une des différences cruciales entre les 2 types d’infrastructures, c’est la souplesse et le dynamisme apporté par la solution Cloud par rapport à une architecture physique classique (qu’elle repose sur de la virtualisation ou non). C’est à dire la suppression du temps de mise en place de la logistique (achat de matériel, installation de l’OS, raccordement au réseau – physique et configuration des interfaces -, …). De même, quand vous n’avez plus besoin du matériel (instance virtuelle EC2, volume EBS, objet S3, …), vous le rendez au pool de ressources : il est alors réinitialisé afin qu’aucune de vos données ne puissent être récupérées et remis à disposition en attendant un autre appel web service.

Vous avez également un accès total à certains éléments comme les security groups (firewall) appliqués pour chaque machine, … Et c’est très utile. Cela est très pratique, notamment par rapport à un hébergeur classique : rappelez-vous la dernière fois que vous avez dû faire modifier les règles de firewall… Un petit Xanax ? Sûr ? ;ob

Mais il ne faut pas s’arrêter simplement à la notion d’achat de serveurs Vs démarrage d’instances. Derrière AWS, il y a des datacenters déjà montés et éprouvés de manière industrielle. Toutes les normes à respecter en terme de protection contre les incendies, le refroidissement des machines, les alimentations électriques redondantes, la sécurité physique contre les intrusions, la répartition des locaux physiques, … comportent un prix initial colossale et même une fois mises en place, vous ne pourrez reproduire une telle qualité chez vous (en tout cas dans 99% des cas). Vous pourrez cependant retrouver cela pour tout ou partie chez un hébergeur classique.

Mais il y a de plus tous les services plus « logiciels » comme la gestion de la durabilité des données (redondance/réplication comme sur les EBS et sur S3), l’accessibilité ou haute disponibilité, le monitoring hardware (à savoir quand est-ce que les composants physiques montrent des signes de faiblesse), les processus en cas de panne, … Je vous laisse lire Les 9 principes de S3, pour comprendre l’exhaustivité des notions que cela regroupe. Tout cela, vous ne le retrouvez pas chez un hébergeur classique (et oubliez cela chez vous ;ob). La qualité du service est en effet un plus incomparable, surtout par rapport aux prix pratiqués… Les prix parlons-en !

Les coûts
Il n’y a pas de règle figée. Au niveau Cloud, vous payez la ressource à l’heure et lorsque vous la relâchez, vous ne payez plus. Il y a également la possibilité de réserver des instances (Linux pour l’instant) sur les AWS à l’année ou pour 3 ans, c’est ce que l’on appelle les Reserved Instances : vous payez un forfait tout de suite et ensuite vous payez le coût horaire moins cher, ce qui vous amène à une bascule à partir d’un certain pourcentage d’utilisation de la ressource sur l’année (ou les 3 ans). Pour plus de détails, allez ici. Pour un calcul simple de combien vous coûtera votre infrastructure, profitez de la toute nouvelle calculatrice mise à disposition par Amazon, le Simple Monthly Calculator. Dans tous les cas il y a une par liée à l’utilisation horaire et une autre liée au trafic.

Simple Monthly Calculator

Vous pouvez effectuer la comparaison avec le coût de votre infrastructure locale ou bien avec ce que vous coûte votre hébergeur. La formule Cloud est notablement intéressante dans ces cas là :

• La formule est imbattable pour les POCs, les démonstrations/présentations ou bien les tests de charge/validation d’une architecture.
• Elle est très intéressante pour les applications ou APIs montées elles mêmes sur un modèle économique de type SaaS et qui ne nécessitent de dépenser de l’argent pour leurs ressources qu’à partir du moment où des clients paient pour utiliser lesdites APIs.
• Elle est intéressante pour les applications sociales que l’on trouve sur FaceBook, par exemple, et qui peuvent connaître un succès du jour au lendemain en profitant de phénomènes de viralité et voir leur fréquentation exploser (ou baisser).
• Elle est intéressante également lorsque l’on lance une société ou que l’on débute une activité ou un projet spécifique au sein d’une entité plus importante et que l’on ne souhaite pas un fort investissement immédiat dans la logistique.

Il vous faut pour les nombreux autres cas propres à chacun, faire votre calcul personnel.

Laxisme ? Mais noooooooon…
Normalement, quelque soit le type d’infrastructure, les mêmes composants/mécanismes devraient être mis en place. Cependant, force est de constater que bien souvent le côté plus douillet de l’infrastructure hébergé « à la maison » pousse à une certaine forme de laxisme sur un certain nombre de points. Le fait que Amazon, avec ses AWS, propose une solution volatile et dynamique au niveau de ces EC2 oblige à mettre en place des mécanismes (qui devraient être standards) afin de prendre en compte plus sérieusement, du fait de la volatilité de l’outil, les plans de reprise sur incident et identifier les données importantes afin d’assurer leur durabilité (EBS, backups sur S3, …).

Conclusion
On perçoit dans cette première partie l’évolution du métier de responsable d’infrastructure : la manipulation des ressources physiques se fait par le biais d’APIs, les mécanismes sous-jacents assurant la durabilité des données, la disponibilité des services, … jusqu’à l’alimentation électrique des serveurs et la sécurité physique des datacenters sont pris en charge de manière transparente. Au final, on ne voit « plus que » l’API qui dialogue avec un service distant. C’est là qu’est la différence avec les infrastructures physiques. La virtualisation (qui est une des facettes des AWS), que nous connaissons et utilisons déjà depuis quelques temps maintenant, est utilisée par Amazon : ce n’est pas tant une révolution technique, même si je ne doute pas de la complexité de mise en oeuvre derrière, c’est surtout le service offert qui est la vraie valeur ajoutée. Cela est accompagné d’un nouveau modèle économique aaS (as a Service) qui nous fait payer à l’utilisation. Cela permet à des applications (par exemple de type jeux que l’on retrouve sur les réseaux sociaux) de voir le jour, alors qu’il y a quelques années, leur émergence aurait été compromise par l’investissement initial.

Nous verrons les autres aspects différenciant ces architectures dans un second article sur le sujet.

Frédéric FAURE