Le vrai Cloud est en route avec une nouvelle gamme d’outils

Le Cloud Computing est né il y a 10 ans, et pour autant un usage optimal du Cloud n’en est qu’à ses prémices. Il faut concilier les approches des développeurs, des Ops et des architectes pour un meilleur placement du code logiciel dans le nuage. Toute une gamme d’outils monte en puissance.

Si on écoute les sirènes du marketing, passer dans le Cloud se fait en trois clics. Les DSI savent que la réalité est bien plus complexe, et requiert d’adopter une approche holistique, c’est à dire globale, nécessitant de modifier les organisations et de former à de nouvelles technologies.

Flexibilité et réactivité

L’objectif principal pour la DSI du passage dans le Cloud est de gagner en flexibilité et en réactivité tout offrant des services standardisés, sécurisés et ajustables à la charge. Le tout si possible en réduisant les coûts !

Autre atout du Cloud, gérer des ressources matérielles achetées ou louées, réelles ou virtuelles, et son patrimoine applicatif de manière programmatique. Il est ainsi possible de programmer l’infrastructure initiale nécessaire à un applicatif donné et son évolution en fonction de différents critères tels que le coût, la charge ou le type de client. Cela passe par l’automatisation de la production via du développement continu, du déploiement en production et du suivi de production des applications via des compétences et outils devops.

Face à des systèmes distribués de plus en plus complexes, et des évolutions de charge non prédictibles, la conception et la création d’architectures élastiques sont facilitées sur le Cloud.

Le multi-Cloud publics complexe

Se pose alors le choix de savoir s’il faut construire son propre Cloud (souvent en utilisant Openstack ou des systèmes hyperconvergés), utiliser un Cloud public (Amazon AWS, Google Cloud, IBM Bluemix, Microsoft Azure, Rackspace, etc.), ou adopter une approche hybride mixant Cloud privé avec « débordement » sur un Cloud public en cas de nécessité.

Si l’approche multi-Cloud publics semble la moins risquée car il y a moins de dépendance à un fournisseur, elle reste complexe à mettre en œuvre, car chaque éditeur propose des éléments de services à des niveaux différents (Iaas, Paas, SaaS) qu’il est difficile de comparer et d’utiliser en parallèle.

Dans tous les cas, il faudra créer de nouveaux processus et utiliser de nouveaux outils permettant à un programme d’allouer des ressources, de déployer du code et des données, d’appliquer un modèle de sécurité et de s’exécuter de manière résiliente.

Créer des systèmes anti-fragiles

Certaines entreprises utilisatrices, comme Netflix, vont même plus loin et ont créé des applications en charge de « tuer » des services de manière aléatoire (voir le Chaos Monkey) afin de s’assurer que le système est anti-fragile. Les systèmes informatiques anti-fragiles s’améliorent et réagissent aux chocs. Cette approche de construction des applications a aussi bien évidemment des impacts sur la gestion du portefeuille applicatif, des budgets et des coûts d’exploitation.

A chaque DSI son chemin vers le nuage

A partir du moment où il est possible d’allouer des ressources de manière programmatique et de définir les règles d’élasticité d’une application ou des microservices, il reste à modifier les processus de gestion du cycle de vie des applicatifs au sein de la DSI et à former les équipes aux nouvelles fonctionnalités.

Les projets peuvent alors suivre soit une approche bottom-up (des services d’infrastructure sont mis à disposition des développeurs et des Ops) ou Top Down (en fonction des besoins métiers, le choix des technologies Cloud sera réalisé).

Il est à noter que dans les approches top-Down, de plus en plus souvent, le métier à d’ores et déjà fait son choix soit d’une solution sur étagère en mode SaaS (Software as a Service), soit d’une solution ou il sera capable de développer lui-même son applicatif avec une plateforme dite « low code » telle que Outsystems, Mendix, Appian ou Generative Objects.

Les développeurs viennent de Mars, les Ops viennent de Vénus

Le principal écueil pour les DSI dans l’adoption du Cloud est situé au cœur de l’organisation. Car si les développeurs viennent de Mars, les Ops viennent de Vénus et ils ont chacun des attentes différentes !

Les développeurs ont pour principal objectif de créer un logiciel conforme aux besoins Métiers exprimés, sécurisé, et disposant de ses contraintes de déploiement, de configuration initiale et d’évolution dynamique. Le développeur fonctionne au niveau plateforme (ou PAAS, pour Platform As A Service).

Tout développeur qui a déjà utilisé Heroku, Amazon Elastic Beanstalk, ou Microsoft Azure App Service aura du mal à revenir en arrière, tant ces plateformes répondent à leur besoin en facilitant à l’extrême les aspects contraignants de la mise en production d’une application. Et si pendant des années on a appris aux programmeurs à gérer avec parcimonie les ressources utilisées (la mémoire, le disque, etc.), désormais, avec le Cloud, ce qui compte c’est la capacité à gérer la charge et à s’y adapter dynamiquement.

Les Ops, quant à eux, sont longtemps restés attachés au matériel et à la facilité de création de scripts de gestion des opérations avec Ansible, Puppet ou Chef. Naturellement, ils ont appréhendé le Cloud via les couches basses (Infrastructure As A Service) et leurs APIs permettant de créer des infrastructures dédiées à la volée et à un niveau très fin (choix du processeur, choix de la quantité de mémoire, type de stockage, etc.).

Puis, avec l’essor des technologies de conteneurs, ils ont pu s’abstraire un peu plus du matériel. L’approche CaaS (pour Container as a Service) leur permet désormais de gérer uniquement des conteneurs, qui s’exécutent directement sur du « bare Metal, » le serveur sans système d’exploitation ni hyperviseur. Cette approche offre une dépendance réduite vis-à-vis des fournisseurs de Cloud, mais impose de mettre en place un outil d’orchestration des conteneurs tels que docker Swarm, Google Kubernetes, CoreOS Rkt, etc. Cette bataille des systèmes d’orchestration n’est rien d’autre que le combat éternel pour l’accès aux ressources dans une mer de serveurs.

Les architectes de la DSI : « lost in translation »

Les différentes couches d’abstraction et d’orchestration du Cloud révolutionnent la manière dont on conçoit et déploie des applications distribuées. C’est pour cela que les architectes d’entreprise auraient du avoir un rôle majeur à jouer dans l’adoption du Cloud. Garant de la cohérence technologique et fonctionnelle, ils sont aussi les arbitres des différentes forces en présence et aident à trouver des trajectoires de migration de développement lorsque nécessaire. Mais, force est de constater que ce n’est pas encore le cas, car beaucoup de DSI sont encore en phase d’évaluation des solutions du marché.

Les profils nommés « architecte cloud » recherchés sont bien souvent soit des développeurs sachant déployer sur le Cloud, soit des experts techniques des solutions de vendeurs de Cloud public, proches d’un devops. Il est pourtant à noter que les principaux vendeurs de Cloud ont mis en place des sites dédiés pour les architectes : Amazon AWS, IBM Cloud, et Microsoft. Tous ont aussi mis en place des programmes de certifications.

Comme en finance, ce qui compte c’est le placement

Dans tout système distribué, la partie complexe concerne « le bon placement » des éléments logiciels qui composent une application. Chaque changement de mode de pensée (client-serveur, SOA, microservices et Serverless) s’est accompagné d’une réduction de la granularité des éléments logiciels à déployer et de nouvelles technologies pour les mettre en œuvre.

Or, à priori, il est difficile de trouver le meilleur placement pour un élément logiciel. Il faut donc déployer son applicatif au mieux et observer son comportement suivant les profils de charge. Outre une meilleure gestion des performances, l’étude des profils de charge est aussi utilisée pour réduire les coûts en sélectionnant et configurant au plus juste les meilleurs services Cloud.

Il faut aussi comprendre que les services Cloud permettent une gestion du placement basée sur des aspects système et non pas métier. Or, pour de nombreux éditeurs logiciels, créateur de solution SaaS multi-tenant, il est important d’adapter le niveau de service (et le coût induit) en fonction du contrat du client.

Cela requiert donc une gestion fine des droits et des quotas d’utilisation d’une application en fonction de contraintes ùmétiers. La plupart du temps, il faut développer ses propres couches de gestion au dessus du Cloud.

Néanmoins, de nouvelles solutions émergent, mais sont encore récentes comme par exemple Hashicorp Consul, AWS App load balancer ou Microsoft Azure Service. Bien évidemment, toute évolution du placement (ou orchestration de ressources) n’est pas immédiate : on se retrouve alors à devoir prendre en compte les délais de provisionning de ressource, de latence du réseau, et de gestion des adresses IP. Les contraintes de sécurité amènent aussi leur lots de contraintes (gestion des « secrets », clef de cryptage, gestion des identités, etc.).

Formation et certification

Il est important de créer des équipes spécialisées et transverses pour gérer l’adoption du Cloud. Appelons les des tribus ou encore des équipes agiles. Peu importe, du moment que la communication des éléments clés des principes d’adoption du Cloud sont explicites et compris par tous. Il est aussi nécessaire de mettre à jour les outils et de former (voire certifier) les développeurs, architectes et (dev)ops.

Si la mise en place d’un Cloud privé coûte cher et reste complexe à mettre en œuvre, cela n’est pas impossible. De même, la migration dans un Cloud public (stratégie « lift and shift ») sans rationalisation et refonte applicative coûte généralement plus cher que dans un datacenter privé. Néanmoins, cela peut constituer une première étape avant une « optimisation » et une ré-architecture applicative.

Adopter le Cloud, c’est accepter que l’architecture et le placement du code, évoluent de manière parallèle et contrôlée avec l’architecture de l’infrastructure, via des descriptions programmatiques. Et une fois la transition engagée, il sera impossible de faire machine arrière.