IaaS : trois scénarios détaillés

Les sollicitations pour étudier la capacité à mettre en oeuvre ce type d’architecture ont explosé mon agenda. Bien que le IaaS serve dans de nombreuses configurations telles que l’hébergement d’applications, la diffusion de contenu, les sites de e-commerce ou d’applications mobiles grand public, le HPC, l’encodage et diffusion de médias vidéo ou audio, les outils de recherche, l’hébergement de sites web, le Big Data, et l’externalisation de serveurs, j’ai pu noter un intérêt croissant des entreprises avec lesquelles je travaille sur trois scénarios particuliers, que je partage avec vous aujourd’hui.

Premier scénario : Les moteurs de bases de données et des volumes en augmentation constante

Contrairement aux applications SaaS (Software as a Service), telles qu’Office 365, le IaaS se compose d’une collection d’objets à interconnecter les uns aux autres. On peut résumer les types d’objets comme suit : Compute (des serveurs virtuels), Storage (des espaces de stockage), Networking (des réseaux virtuels), Database (des moteurs de bases de données relationnelles ou non), Application Services (des services additionnels) et Management (des services d’administration et de gestion des composants IaaS).

Une des différences majeures entre les services SaaS et les services IaaS, concerne la facturation à la demande des ressources. Ainsi, contrairement à Office 365 où le montant de votre facturation dépend du package de services auxquels vous vous abonnez (appelé « plan » chez Microsoft) et du nombre de boîtes aux lettres, les offres IaaS sont radicalement basées sur les consommations des ressources et des transferts sortants du centre de données. Ainsi, vous ne payez que pour ce que vous consommez.

Pour vous donner un exemple, chez certains fournisseurs, votre facture sera la même que vous exécutiez un serveur pendant mille heures ou mille serveurs pendant une heure. Dans le premier cas, votre résultat sera disponible dans mille heures, dans le second, d’ici une heure, ce qui fait une très grosse différence pour certains traitements, notamment tous ceux qui peuvent être liés à de l’analyse de données.

Enfin, les ressources sont disponibles, dans une richesse quasi-illimitée, et ce, sans être liées à une quelconque obsolescence matérielle. Prenons un exemple simple : Imaginons que vous ayez à bâtir une architecture qui demande un volume de stockage important, et pour le traiter un serveur multiprocesseurs puissant équipé de SQL Server ou d’Oracle. Le problème de cette architecture, c’est qu’elle repose sur des éléments matériels électroniques dont l’obsolescence programmée mettra en difficulté votre application dans trois ans (généralement la limite de garantie matérielle).

Certes, vous pourrez étendre vos contrats de maintenance, mais à un coût supplémentaire qui finalement augmentera de manière mécanique le prix de vos transactions. Si vous passez à une échelle de dix ans, avec de l’informatique traditionnelle, plus de solution, à moins de réinvestir régulièrement dans vos infrastructures avec, encore une fois, comme résultat d’augmenter le coût de vos transactions. C’est pour cette raison que de nombreuses entreprises font appel aux offres IaaS, telles que Windows Azure ou Amazon Web Services. En effet, de cette manière, ces sociétés se désengagent complètement de la gestion du cycle de vie matériel sans interruption de service, qui revient à la charge du fournisseur.

Bien sûr, le coût annuel de la location de ressources chez un fournisseur sera plus élevé que sur vos propres infrastructures, mais si vous comptez les réinvestissements de matériels et les difficultés pour faire ces mises à jour sans arrêter les transactions, ce surcoût annuel sera très vite amorti. Si vous considérez qu’en plus, vous devez mettre à disposition des infrastructures identiques à votre production pour votre pré-production, votre plan de recouvrement et une architecture limitée à vos équipes de développement et de tests, l’économie d’échelle est encore bien plus grande.
Néanmoins, c’est un domaine dans lequel les expertises sont rares. Non seulement, il est nécessaire de comprendre et de mettre en oeuvre les services IaaS chez différents fournisseurs, mais vous devrez acquérir une compétence variée sur différents systèmes d’exploitation (RedHat, CentOs, Windows) et moteurs de bases de données (SQL Server, MySQL, Oracle) relationnels ou de type NoSQL.

Deuxième scénario : Les plans de recouvrement et les plateformes pour les études

Une deuxième demande en forte croissance concerne les études de plan de recouvrement et de bascule automatisée dès la détection d’un incident de production, ainsi que la fourniture d’environnements de production pour les études à la demande, un peu sur le principe du « copiercoller- démarrer ». Là encore, les infrastructures IaaS sont particulièrement bien adaptées à répondre à ces attentes, même s’il y a beaucoup de travail en amont à réaliser.

La première opération consiste à analyser l’infrastructure en place chez un client, pour en déterminer les silos fonctionnels et les adhérences dans un premier temps. Dans un deuxième temps, il est nécessaire de regrouper les silos en trois catégories :

• La 1ère  constituée des composants étant naturellement déjà compatibles avec les plateformes IaaS.
• La seconde constituée des composants étant incompatibles avec les plateformes IaaS, et qui devront attendre ou être redéveloppés.
• La dernière constituée des composants dont le déplacement vers une plateforme IaaS s’avère être contreproductif pour des raisons économiques, de sécurité ou d’exploitation.

La seconde opération consiste à modifier la production progressivement pour qu’elle puisse être adaptée à des bascules vers les infrastructures IaaS.
Souvent, les entreprises avec lesquelles je travaille ont déjà fait le plus gros des opérations : Création automatisée d’environnements basés sur des images systèmes et applicatives via des scripts, exploitation des serveurs dématérialisés dans des fermes VMware ou Hyper-V, utilisation de console de gestion et de supervision de parcs virtualisés. Si c’est votre cas, vous êtes en bonne position. Si ce n’est pas encore le cas, je pense qu’il est nécessaire de vous y mettre au plus vite.

Troisième scénario : L’externalisation des sauvegardes sur bandes

C’est sans doute le sujet le moins compliqué à première vue pour mettre un pied dans les infrastructures IaaS : l’externalisation des sauvegardes de votre entreprise. La plupart des éditeurs principaux en offres IaaS possèdent à leur catalogue des solutions permettant de gérer virtuellement leur espace de stockage dans le cloud comme un lecteur de bandes virtuelles d’une capacité illimitée.

Ainsi, pour vos exploitants, pas de changement : ceux-ci continueront à utiliser leurs outils de sauvegarde et leurs jeux de sauvegarde. D’un point de vue technique, les bandes seront automatiquement uploadées vers votre espace de stockage sécurisé sur le nuage, vous permettant ainsi de ne plus vous soucier des contraintes d’externalisation des jeux de sauvegarde.

Enfin, plus fort, les bandes stockées dans le cloud pourront être déplacées au bout d’un certain laps de temps sur des espaces de stockage moins coûteux, vous permettant ainsi de réaliser une économie sur l’espace alloué via les solutions d’archivage des éditeurs IaaS.

La différence entre le stockage et l’archivage se situant principalement sur le délai d’accès à votre bande en cas d’incident : L’accès est généralement immédiat pour une bande stockée, alors que pour une bande archivée, le temps de restauration dépend du volume et de la solution de l’éditeur. Par exemple, avec Amazon Web Services, avec son service d’archivage « Glacier », la disponibilité de la bande archivée est généralement d’un délai de 2 à 5 heures, alors qu’elle est immédiate avec son espace de stockage S3.