L’introduction du cloud en entreprise par l’applicatif

Written by admin on February 3, 2014 Categories: OpenStack Tags: , , , , , , ,

Voici un petit billet qui sort de la technique pure et présente plus une réflexion autour du sujet du cloud en entreprise.

Avant de poursuivre, je précise que cette réflexion est très orientée OpenStack. Il est fort probable qu’avec d’autres technos l’approche soit un peu différente. Ceci dit, les concepts généraux que nous allons survoler sont de toute manière des bonnes pratiques cloud, ils seront plus ou moins indispensables suivant la techno de l’infra.

Il y a plus d’un an maintenant que j’aborde la question du cloud dans le cadre de mon job chez un client grand compte. J’ai eu l’occasion de parcourir les différentes offres commerciales actuellement sur le marché et j’ai surtout pu faire des POC sur différentes distributions d’OpenStack. Lorsque le sujet est arrivé chez nous, le mot cloud était sur toutes les lèvres, le buzz complet, mais personne ne savait réellement par quel bout prendre le truc.

Après avoir pris un peu de recul, j’ai eu l’occasion de faire une présentation à mes collègues un peu moins au fait du sujet pour leur expliquer les concepts du cloud en entreprise (IaaS, PaaS, …, cloud hybrid, on demand, j’en passe et des meilleurs). Je terminais ma présentation en expliquant que la virtualisation et le cloud ce n’est pas la même chose, que toutes les applis ne sont pas “cloud ready” et que l’erreur à ne pas faire est de penser qu’on peut utiliser une infra cloud comme une mega plateforme de virtualisation hyper automatisée sans apporter de changement au niveau applicatif.

Cette réflexion s’est confirmée à mesure que je découvrais, d’un point de vue technique, les méthodes cloud implémentées dans OpenStack ainsi que leurs implications. Les discussions avec les acteurs du could open source en France (SuSE, Redhat, eNovance) n’ont fait qu’appuyer cette idée mais je continuais d’aborder la question par la couche infrastructure qui était celle qui m’intéressait. Je tiens d’ailleurs à remercier Fabien Dupont et Jérôme Fenal de RedHat pour leurs pistes sur ces questions.

De la pédagogie et de l’outillage auprès des utilisateurs

L’IaaS apporte un certain nombre d’avantages au gestionnaire de l’infra comme à son utilisateur (on demand, automatisation, facturation à l’utilisation)… Mais si les utilisateurs n’adaptent pas leurs pratiques à cet outil, la facture finale ne sera pas plus légère qu’au temps de la virtualisation. Puisque l’instance (la VM) dans le cloud est éphémère, l’utilisateur doit pouvoir redéployer son environnement rapidement, il doit pouvoir retrouver ses données ou les recharger également. Sans cela, il n’y a aucun avantage au cloud puisque les coûts vont se retrouver ailleurs (on passe plus de temps à redéployer l’application ou on laisse l’instance allumée pour ne pas avoir à refaire l’intégration).

Il est donc important de sensibiliser les utilisateurs aux concepts et surtout leur fournir des outils leur permettant d’exploiter au mieux cette nouvelle techno. C’est le cas par exemple d’OpenShit de Redhat qui amène au développeur une couche d’abstraction à l’utilisation d’OpenStack et l’inscrit dans une démarche pure cloud d’un point de vue automatisation.

Du design et de l’intégration spécifique cloud

Autre approche, l’architecture d’une application pure cloud est bien différente de ce qu’on a fait jusqu’à présent. Je ne vais pas vous reparler du “pets vs cattle” (voir ceci par exemple) mais ici on réfléchit scalabilité, répartition, remplacement et orchestration. Tous les projets ne doivent pas nécessairement rentrer entièrement dans un moule comme celui-là, mais certaines parties peuvent y être candidates. Vous pouvez imaginer que ce genre de choses ne s’apprend pas en une semaine et que c’est une très mauvaise idée de laisser les équipes d’intégration des projets s’improviser architecte cloud.

J’ai eu l’occasion d’observer ce phénomène avec l’arrivée des clusters applicatifs sous Linux et en particulier sous Redhat. Convaincus des bienfaits, les architectes applicatifs proposaient du cluster à tout va aux équipes projets qui ne maîtrisaient pas les concepts et les implications (ceci dit, je ne faisais pas non plus le fier à l’époque). On obtenait par la suite des services qui basculaient mal, voire pas du tout et des coupures à répétition pour maintenance due à la complexité de l’architecture globale, bref, un taux de disponibilité inférieure à un bon vieux serveur standalone… le comble pour un cluster.

Le design et l’intégration de l’application sont donc directement en rapport avec la couche d’infrastructure qui la supporte. C’est une évidence mais si on revient sur notre cloud, on se rend compte que ça devient même critique.

Concrètement, on fait quoi ?

Maintenant qu’on sait que proposer simplement un service cloud aux projets nous mènera droit dans le mur et que c’est plus par l’application que l’infrastructure que le cloud va prendre en entreprise, il faut réfléchir à comment on peut amener ces outils et ce design spécifique au cloud dans le SI. Je n’ai qu’une expérience grand compte, donc je ne pourrais m’appuyer que sur celle-ci. J’imagine quand même que ça peut se décliner facilement dans d’autres sociétés.

J’ai déjà quasiment donné la réponse. C’est au niveau des architectes applicatifs que tout se joue. Il faut qu’au moment de concevoir l’architecture de l’application, des compétences d’intégration cloud soient présentes. Je parle bien d’intégration cloud, pas d’architecture. La raison principale est qu’on va ainsi éviter les problèmes qu’on a rencontrés pour l’introduction des clusters il y a quelques années, à savoir des intégrations forcées aux chausse-pieds, ou du moins on aura un retour bien plus rapide des problèmes. Le petit truc en plus, c’est que ça fait très DevOps et que ça risque de plaire aux chefs 😉

Quand je parle d’intégration cloud, je ne parle pas d’infrastructure, je parle encore de l’applicatif. Le gestionnaire de l’infra fait un travaille différent qui n’est pas le sujet ici. L’équipe en charge de l’intégration cloud est la glu qui va lier les projets, les architectes applicatifs et le gestionnaire de l’infra cloud. Son rôle est avant tout de garantir les bonnes pratiques du cloud :

  • Il y a donc une grosse partie conseille auprès des utilisateurs (outillage, habitude d’utilisation…), surtout dans la phase d’adoption.
  • Il y a également une partie design et architecture à faire conjointement avec les architectes applicatifs au moment de la rédaction du DAT.
  • Enfin, il y a une phase d’intégration à proprement parler pour garnir le catalogue cloud de l’entreprise.

Prenons un exemple pour illustrer tout ça. Un nouveau projet démarre, il contiendra une partie importante de gestion de documents avec une bonne volumétrie, une base de données pour ordonner tout ça, le tout passant par une interface web évidemment. On a donc plusieurs éléments qui peuvent être candidat pour intégrer le cloud de l’entreprise en fonction de son niveau de maturation. Pour la rédaction du DAT, l’équipe va donc proposer peut-être le stockage objet de Swift pour la partie gestion de documents. Pour la partie fronteaux web, ils vont conseiller tel ou tel outil, calibrer pour le cloud et la scalabilité. , et vont travailler sur la création d’une orchestration (un template Heat + des triggers Ceilometer + des images Glance) pour enrichir le catalogue, le tout exploitera les services LBaaS déjà en place. Malheureusement il n’y a pas encore de DBaaS disponible, aucun problème, la base de données reste en mode classique pour le moment. Lors de la phase de dev du projet, l’équipe d’intégration cloud propose différents outils permettant aux développeurs d’instancier le projet en mode standalone dans une VM le matin en arrivant et de l’éteindre le soir.

Bon, c’est un exemple un peu maladroit, mais ça illustre bien que l’intégration cloud est un panel de plusieurs de rôles, bien plus large que l’intégration système et plus ciblée que l’architecture applicative classique.

No Comments on L’introduction du cloud en entreprise par l’applicatif

Leave a Reply

Your email address will not be published. Required fields are marked *