Selon la source à laquelle vous choisissez de faire confiance, la médiatisation autour du cloud est soit à deux doigts d’atteindre le « Peak of Inflated Expectations » (les premiers succès accaparant une grande partie de l’attention des médias et des différents secteurs d’activité), soit déjà en train de glisser à une allure vertigineuse vers le « Trough of Disillusionment » (où les premiers déploiements ne sont pas à la hauteur des attentes et les professionnels commencent à réévaluer leur approche). Pour compliquer encore les choses, Gartner place les services du cloud tels que les services PaaS serverless sur la pente montante de la Hype Cycle. Quelle que soit la bonne interprétation, les entreprises s’empressent de déclarer qu’elles ont mis en place des stratégies "Cloud First".
Gartner prévoit qu’au cours de l’année qui vient, « 90% des organisations souffriront de l’absence d’une stratégie d’intégration applicative postmoderne et d’une capacité d’exécution, ce qui entraînera une intégration désordonnée ainsi qu’une complexité et des coûts croissants ».
L’expérience semble confirmer les conclusions de Gartner, surtout en raison de la confusion importante qui entoure la signification réelle de « cloud first » en terme stratégique.
En faisant leurs premiers pas dans le cloud computing, la plupart des entreprises pensent que, lorsqu’elles auront reproduit leur infrastructure dans l’environnement AWS, elles auront exécuté leur stratégie. Sur ce point, elles sont pourtant encore loin d’avoir concrétisé tous les avantages opérationnels et financiers
qu’offre le cloud.
Selon nous, quatre étapes jalonnent le parcours typique d’une organisation désireuse de construire une infrastructure IT réellement durable dans AWS. Où en est votre entreprise dans ce parcours ?
Première phase : la réplication de l’infrastructure IT dans le cloud
Comme nous l’avons mentionné précédemment, pour leurs déploiements initiaux dans le cloud, les entreprises concentrent leurs efforts sur la réplication de leur infrastructure interne sur la plateforme AWS. De manière très compréhensible, la plupart pensent également que ceci constitue également la fin du processus ; elles sont désormais non seulement les heureuses « propriétaires » d’une plateforme extrêmement familière dont elles comprennent tous les mécanismes, mais elles ont également résolu l’un de leurs problèmes les plus gênants, celui des contraintes de capacité.
Les entreprises peuvent passer des années dans cette première phase, se contentant de procéder à une mise à l’échelle vers l’extérieur lorsque la demande en traitement et en stockage augmente. Et, tout étant si familier, le modèle DevOps permet aux entreprises de continuer à fonctionner normalement, en maintenant le niveau de productivité et d’efficacité qui a toujours été le leur.
Cependant, si une entreprise en reste à cette toute première phase de sa stratégie cloud first, elle trouvera peut-être que de nouveaux succès se font attendre.
Deuxième phase : reconstruire et automatiser
Connue également sous le nom de phase « Qu’est-il arrivé à la promesse de réduction des coûts ? », la deuxième phase n’est initiée que lorsque le directeur financier commence à poser des questions sensibles. Même si l’organisation a réduit les dépenses de capital en matériel, les coûts du cloud continuent de monter en flèche, et personne ne sait vraiment pourquoi.
L’évolutivité sans limite d’AWS peut causer des problèmes imprévus pour les développeurs cloud et les ingénieurs système inexpérimentés. Les développeurs peuvent utiliser autant de services AWS qu’ils le souhaitent, mais tous ces services sont facturés sur la base du pay-as-you-use Ce qui signifie qu’ils sont nombreux à allouer un grand volume de ressources AWS de manière inefficace ou superflue.
Ce n’est pas une coïncidence si le « Trough of Disillusionment » de Gartner correspond au fait que des entreprises rencontrent des problèmes dans la phase 1, ce qui les contraint à une réévaluation de leurs déploiements et de leur stratégie cloud. David Stanley, responsable de la livraison de plateforme chez Trainline, parle ainsi des expériences AWS de son entreprise : « Le plus grand changement culturel à mettre en place après avoir accompli tous les changements DevOps, c’est de se concentrer sur les coûts. »
Après s’être fait rappeler à l’ordre par le directeur financier, le département IT entreprend de refondre les systèmes d’information afin de les aligner avec les diverses règles de calcul des coûts AWS. Par exemple, en créant des utilisateurs et des groupes, les entreprises peuvent contrôler qui est autorisé à demander des ressources AWS. Les systèmes deviennent immédiatement plus efficaces en termes d’exploitation et de coûts.
À mesure que leur expérience des technologies du cloud s’intensifie, les développeurs augmentent également le niveau d’automatisation utilisé pour leurs systèmes hébergés. Par exemple, un retour aux principes de traitement par lots des anciennes machines virtuelles sera déclenché pendant les heures creuses afin de réduire les coûts d’exploitation. La fonctionnalité AWS Auto Scaling permet aux développeurs de limiter la mise à l’échelle des ressources en respectant un programme prédéfini, assurant qu’elles soient disponibles en fonction de la demande prévisible et libérées en dehors de ces heures afin que la dépense soit en phase avec l’utilisation.
Avec des systèmes repensés pour le cloud et un fonctionnement rationalisé grâce à l’automatisation, le directeur financier sera satisfait car les factures seront à nouveau sous contrôle. Les dépenses devront peut-être encore subir des hausses, mais ce processus de rationalisation assure que les coûts sont mieux maîtrisés et totalement justifiables.
Troisième phase : le recours aux conteneurs
Même si les coûts AWS sont maintenant sous contrôle, l’infrastructure hébergée nécessite toujours une quantité relativement élevée de ressources pour leur gestion. À la fin de la phase 2, les applications résident toujours sur des machines virtuelles installées dans un hyperviseur, lui-même placé au sommet de la couche AWS.
Bon nombre de ces systèmes virtualisés seront du type « set and forget » (configurés une fois pour toutes), mais c’est minimiser tout le travail qu’implique leur configuration au point de déploiement. Il faudra parfois également procéder à des modifications de configuration à grande échelle, et l’équipe IT devra s’acquitter de cette tâche pour que les systèmes continuent de fonctionner correctement.
Avec des applications, des binaires et des bibliothèques, le système d’exploitation invité et un hyperviseur installé au sommet du système d’exploitation hôte, les niveaux à gérer sont multiples. C’est là que commence la troisième phase, qui vise à simplifier l’architecture applicative et à réduire les frais généraux de gestion et d’utilisation des ressources cloud.
En utilisant un moteur d’orchestration de conteneurs tel que Kubernetes ou Docker installé directement au sommet d’un système d’exploitation invité, les développeurs peuvent reconcevoir les applications sans avoir besoin d’un hyperviseur ou d’une machine virtuelle. Le code est compilé et exécuté dans un « conteneur », qui ne contient rien de plus que les dépendances requises pour l’application. Ceci présente plusieurs avantages :
- L’application conteneurisée est plus légère, ce qui contribue à réduire la demande en ressources serveur et les coûts d’exploitation.
- L’application devient plus mobile, ce qui lui permet d’être redéployée assez facilement dans un autre service du cloud.
- Les développeurs peuvent se consacrer entièrement à la création d’une application ou d’un service, sans se préoccuper du système d’exploitation ou d’autres éléments secondaires qui compliquent le processus.
- Avec moins de couches à gérer, les administrateurs et les ingénieurs peuvent consacrer le temps libéré à des projets stratégiques.
Et avantage supplémentaire, une nouvelle diminution de la demande pour des ressources serveur se traduira par une diminution des coûts AWS … et devrait vous valoir ainsi les félicitations de votre directeur financier !
Quatrième phase : l’IT serverless
À la fin de la troisième phase, les ressources IT d’AWS ont été rationalisées de manière spectaculaire, entraînant une réduction de l’empreinte applicative et des coûts d’exploitation, et augmentant la portabilité du code. La tentation est grande, à nouveau, de supposer que le processus de migration dans le cloud est terminé, mais d’autres améliorations peuvent encore être réalisées.
À ce stade, les applications sont déployées dans des conteneurs autonomes, mais la plateforme Docker sur laquelle elles sont construites consomme toujours des ressources serveur au sein du datacenter AWS. Dans de nombreux cas, les développeurs font tourner des machines virtuelles complètes à l’intérieur de ces conteneurs. Même si cela n’est pas gênant en soi, les applications peuvent encore être plus rationalisées, ce qui réduira en retour les efforts et les coûts de développement.
Plus préoccupant est le fait qu’en maintenant un système d’exploitation dans le conteneur, l’environnement conserve les mêmes frais généraux relatifs à l’administration et à la sécurité. Les efforts initiaux peuvent viser à une densité plus élevée de machines virtuelles, mais inclure un système d’exploitation dans un conteneur ne permet de réduire ni la complexité de la maintenance ni les frais généraux d’exploitation.
La phase finale de la migration « cloud first » consiste à développer et déployer des applications serverless. Comme leur nom l’indique, ces applications sont conçues pour diminuer la dépendance par rapport aux serveurs Kubernetes, Docker et AWS autant que possible. Au lieu de faire appel à des applications totalement compilées et des machines virtuelles, ces applications sont construites en recourant à des bibliothèques conteneurisées et des binaires hébergés sur Amazon ECS et reliées à des API fournies par des services de cloud public.
En d’autres mots, les applications serverless prennent les blocs de construction fournis par différents services en ligne et les « collent » ensemble dans AWS Lambda. En fin de compte, les applications de la phase 4 exploitent les « Functions as a Service » (« Fonctions en tant que service ») pour réduire les coûts et les frais généraux.
Ces applications sont encore infiniment évolutives, elles puisent dans des ressources tierces si nécessaire, mais en ayant une empreinte locale minimale. Relier des services de cette manière permet d’accroître encore la vitesse de développement et de réduire le niveau de maintenance requis pour faire face aux mises à jour apportées aux services utilisés.
En outre, vos nouvelles applications reposant sur des services de niveau SaaS fournis par des tiers, il n’est pas nécessaire (et d’ailleurs il n’y a pas de fonction à cet effet) d’ajuster la configuration de composants tels que httpd ou MongoDB : ces fonctions sont prises en charge par le prestataire tiers. Il existera toujours des frais généraux opérationnels pour les applications basées dans le cloud, mais en externalisant l’infrastructure et les responsabilités OS auprès de prestataires externes, les coûts d’exploitation internes sont encore réduits.
Il est temps d’évaluer votre progression
Une fois le parcours « cloud first » clairement défini, il est beaucoup plus facile d’évaluer où en est votre entreprise. La plupart des organisations qui n’auront entrepris ce parcours que tardivement en seront toujours à la première phase, et auront encore bien du chemin à parcourir. La majorité des organisations aura cependant atteint la deuxième phase, et sera en train d’étudier la meilleure façon d’utiliser l’infrastructure du cloud pour améliorer ses propres opérations.
Le cloud computing représente un changement spectaculaire de l’IT en entreprise. Nombreux sont celles et ceux qui apprennent encore comment profiter pleinement des avantages fournis par AWS. Le manque de compétences étant aggravé par la rapidité du développement de la plateforme AWS, il n’est guère surprenant que les entreprises aient bien du mal à atteindre leurs objectifs « cloud-first ». D’autant que la véritable stratégie de cloud-first reste mal comprise.
Claranet est reconnu « Managed Service Provider Next Gen », confirmant une nouvelle fois ses compétences en termes de conseil, d’implémentation et d’exploitation de plateformes Cloud AWS.