DevOps sur AWS : une transition pas si facile

Le Cloud public a tout pour optimiser une stratégie DevOps, mais la transition n’est pas sans difficulté.

AWS met à disposition des possibilités de dimensionnement et d’automatisation via des APIs et cela en fait une des meilleures plateformes pour un modèle DevOps. Toutefois, la courbe d’apprentissage est raide, particulièrement pour les entreprises dont les systèmes legacy sont légions, et celles qui négligent la partie opérationnelle. La plateforme souffre également de lacunes dans son outillage que des outils tiers peuvent venir combler. Reste que prendre une telle décision au milieu de cette transition tant technologique et culturelle n’est pas simple.

Logicworks, un fournisseur d’outils de gestion de Cloud, partenaire AWS, accompagne les entreprises vers DevOps via AWS. La société a elle-même entrepris cette transformation : d’un hébergeur, elle est devenue fournisseur de Cloud, passant d’un fonctionnement en silo à DevOps. Cela a pris presque deux années à implémenter, note Jason McKay, senior vice-président et CTO chez Logicworks. Cela était en partie dû à la demande tardive des clients pour de nouveaux services, à mettre en place la bonne équipe, et aussi à monter en compétence sur la plateforme. « Et cela n’est pas fini, explique-t-il. Nous ajoutons en permanence de nouvelles fonctionnalités. »

Toutefois, « les utilisateurs n’ont pas à s’inquiéter d’un éventuel manque en matière d’outillage, au même titre qu’avec d’autres plateformes, car AWS est un acteur incontournable du secteur », explique Theo Kim, à la tête des activités DevOps chez GoPro. « Si vous développez des outils DevOps, sans être supporté par AWS, en natif ou sous la forme de plug-in, vous avez un problème », assure-t-il. « Je dirai qu’il est plus compliqué de faire du DevOps sur Azure, simplement parce que l’intégration est plus difficile. »

 La plupart des outils servant de loin ou de près à des modèles de déploiement se trouvent sur AWS. Cela comprend des outils natifs, comme CloudFormation, OpsWork, CodePipeline, CodeDeploy et CodeCommit. D’autres outils, aujourd’hui très reconnus dans le monde DevOps, sont aussi intégrés à la plateforme : Puppet, Chef, Salt, Ansible et Jenkins.

AWS convient bien à DevOps, mais il existe un risque : celui d’avoir à disposition une centaine d’outils pour effectuer une opération – surtout si cela n’est pas fait correctement, soutient Jason McKay. « Je ne changerai en rien cette flexibilité, mais je pense vraiment qu’il est nécessaire que les entreprises aient une certaine cohérence dans leurs déploiements d’applications », ajoute-t-il.

Des services comme CodePipeline et CodeDeploy sont des exemples de la façon dont AWS pousse vers l’automatisation et  les delivery pipelines. Souvent, les entreprises s’adossent à leurs propres outils pour minimiser le verrou-vendeur, observe Donnie Berkholz, directeur de recherche chez 451 Research.

AWS manque encore de fonctions d’alerte et de monitoring, ainsi que de collaboration comme des services de chat en direct – dont d’ailleurs la popularité continue de croître, ajoute-t-il.

Cloud Elements, un éditeur d’outils de  gestion d’APIs, a récemment migré toutes ses workloads vers AWS. Amazon Virtual Private Cloud est ce qui les a séduits en premier, même s’ils utilisent aussi EC2, Auto Scaling, Lambda, S3, Glacier, CloudWatch et Route 53. Cloud Elements s’est tourné vers HashiCorp pour intégrer l’ensemble de ces services et les exposer sur d’autres plateformes pour ses clients.

L’un des problèmes à faire du DevOps sur AWS est la limite maximale qu’impose le groupe sur ses services, soutient de son côté Rocky Madden, ingénieur DevOps chez Cloud Elements.

Cloud Elements a aussi considéré d’autres fonctions, comme EC2 Container Service ou Lambda, mais aucun ne répond aux besoins propres du groupe. Le service de conteneurs souffre de goulots d’étranglement, tandis que Lambda peut faire rapidement gonfler la facture. Le groupe a en fin de compte abandonné ses projets de voir toutes ses requêtes gérées par des fonctions Lambda et s’est alors tourné vers Kubernetes et Docker Swarm pour exploiter les conteneurs au-dessus d’AWS.

La sécurité est également un autre domaine qui fait nativement défaut à AWS pour répondre aux desiderata du modèle DevOps, souligne Theo Kim. Toutefois, ce problème ne se résume pas à AWS, mais traduire les exigences pour le Cloud peut être difficile, soutient-il encore.