A chaque fois que l'on me demande d'intervenir sur un projet d'infrastructure "Cloud" (IaaS), j'ai toujours un doute sur le mouton à cinq pattes qui devrait en sortir. J’ai donc une liste de questions, non exhaustive, permettant de dessiner les contours de l'animal.
Pour commencer, la définition du Cloud par le NIST (sept. 2011) est une bonne base:
| Vraiment cloud | Pas vraiment cloud | |
|---|---|---|
| On-demand self-service | Chaque client pourra déployer à sa convenance des VM, réseaux, services... sans intervention humaine, dans la limite, ou non, des quotas qui lui seront associés. | Nous avons un catalogue de services. Chaque demande dans ce catalogue suivra un processus de validation avant déploiement. |
| Broad network access | Sur un projet de cloud public, l'accès par Internet est une évidence. Pour un cloud privé ou dédié, on peut comprendre que cela soit limité à l'accès depuis l'entreprise. | La sécurité est notre priorité et toutes les demandes d'ouverture de flux seront validées par une équipe sécurité. |
| Resource pooling | Peu importe où se trouvent les ressources et les données dans la plateforme du moment que l'isolation entre les clients est respectée et qu’ils sont servis correctement en ressources et en débits. | Les ressources serveurs, stockage, réseaux sont dédiés à chaque client pour garantir les performances et le service offert par l'infrastructure. |
| Rapid elasticity | Chaque client pourra changer de taille. Statistiquement, la moyenne globale permet d'absorber les pics et de se concentrer sur la tendance globale. Le changement d'échelle de l'infrastructure devra être linéaire et sans remettre en cause de l'architecture. |
A chaque demande d'évolution du client, nous aurons un délai raisonnable pour lui provisionner les équipements nécessaires. |
| Measured service | La consommation et la réservation de ressources seront mesurées en continu. La facturation des ressources, en toute transparence, est le contre poids de la liberté. Sans cela, il n'y aurait pas de limites au gaspillage de ressources. | Le contrôle des coûts se fait à chaque demande. Ainsi, nous maitrisons le budget. |
Ensuite viennent les questions plus philosophiques:
| Vraiment cloud | Pas vraiment cloud | |
|---|---|---|
| Gouvernance | Gouvernance par délégation | Gouvernance centralisée |
| Approche | Prêt-à-porter | Sur mesure |
| Organisation | Les équipes applications sont indépendantes des équipes infrastructures. | Le rôle des équipes infrastructure est de comprendre les architectures applicatives afin de mieux répondre à leurs besoins. |
| Gestion de projets | Multiples projets en simultané, basés sur l'expérimentation. Le succès est mesuré par l'adoption. | Projets planifiés basés sur des études approfondies avant mise en oeuvre. |
| Continuité de services sur la plateforme | Les applications doivent être conçues ou transformées pour apporter de la continuité de service, quelles que soient les défaillances de l'infrastructure. | L'infrastructure doit mettre en oeuvre tous les mécanismes permettant de garantir la continuité et la performance aux applications. Nous devons accepter, sans modification, toutes les applications existantes. |
| Continuité de services entre plateformes | Les applications sont distribuées sur plusieurs sites et les données sont propagées instantanément. | C'est l'infrastructure qui assure la continuité et la reprise d'activité entre sites. |
| Applications critiques | Le fonctionnement des applications critique est garanti par la répartition multi-datacenter. Les performances sont assumées par l'élasticité automatique. | Des infrastructures dédiées sont nécessaires pour les applications critiques afin de garantir les performances et la continuité de service. |
| Bases de données | Scale-out et "share nothing". | Scale-in et clustering avec Quorum. |
Mis à part pour le cloudwashing marketing, tous les projets d'infrastructures n'ont pas forcément besoin d'être "Cloud". Mais, il est bon d'appeler un chat, un chat. Chercher à obtenir les réductions de coûts et la simplicité d'un côté, et les sophistications de l'autre alimenteront encore pour longtemps les réunions de projets. Pendant ce temps, le shadow-IT sur le cloud public et les concurrents auront pris une bonne longueur d'avance.
De même, l'arrivée du "Software-Defined" ne résout pas tout, et n'est pas uniquement destinée à faire du "Cloud". D'ailleurs certains projets sont bien partis pour faire de belles usines à gaz d'orchestration (comme c'est possible, il ne faudrait pas s'en priver !). Heureusement, les applications ont entamé leurs transformations afin de ne plus rien attendre des infrastructures autres que des ressources.
