BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Interviews Discussion sur les Patterns du développement Cloud avec Nicolas de Loof

Discussion sur les Patterns du développement Cloud avec Nicolas de Loof

Favoris
   

2. Nous sommes ici dans le cadre du breizhcamp dont tu es l'organisateur. Peux-tu te présenter et nous dire un mot sur la conférence ?

Je m'appelle Nicolas Deloof et j'organise avec une bande de fous furieux une conférence à Rennes. C'est un petit peu comme la Java One avec du Devoxx mais en mieux et tout cela à Rennes. L'idée, c'est surtout de proposer une conférence qui soit faite par des développeurs pour des développeurs sans se focaliser sur une technologie particulière, ce qui fait que l'on a beaucoup de sessions qui sont sur l'univers Java, Web, l'environnement .NET, Python, Ruby, DevOps. On a essayé d'élargir au maximum. Nous avons également impliqué l'équipe d'Agile Breizh. Cela permet d'avoir un vaste choix de sujets sur 5 tracks en parallèle, le tout sur 2 jours. Cela fait des journées bien rentabilisées notamment pour ceux qui utilisent leur droit individuel à la formation (DIF), ce qui représente quand même 30% des entrées. D'ailleurs ça, c'est un gros avantage et c'est Zenika qui nous a permis d'avoir ce petit droit et ces 30% de participants donc je les remercie pour cela. Et donc c'est un très grand succès cette année puisque l'on a 248 inscrits, sachant que la grande salle fait 200 places. On a donc fait un peu de surbooking et cela s'avère être une bonne idée. On était "SOLD-OUT" à presque un mois avant la conférence, donc il y a encore moyen de grossir.

   

3. Et en ce qui te concerne ?

En ce qui me concerne, c'est marrant, car quand je me suis fait embaucher chez Cloudbees, j'ai commencé par 2 jours de congés pour faire le Breizhcamp et là, ça fait 2 ans que je suis chez Cloudbees et j'ai repris 2 jours pour organiser le breizhcamp. Pour moi c'est la continuité de la création du BreizhJUG, le Java User Group Rennais. Cela permet de renforcer cet esprit communautaire sur Rennes en s'élargissant au-delà du monde Java. Et maintenant nous sommes largement au-delà de Rennes puisque on a des gens de Brest, de Normandie, de Nantes, de Laval également qui participent.

   

4. Toi-même tu participais en tant que conférencier. Ta présentation parlait des bonnes pratiques à respecter pour avoir une chance de voir son application dans les nuages. Pourrais-tu nous présenter avant tout les spécificités du Cloud par rapport à un projet classique comme nous le connaissons habituellement ?

Je résumerais en disant qu'il y a deux spécificités qui sont vraiment très structurantes. La première est que l'on est vraiment en mode cluster. Même en mode single instance, lorsque l'on va redéployer l'application, la redémarrer, on a systématiquement un démarrage from scratch sur un nouveau serveur. Donc cela veut dire qu'il y a tous les aspects persistance du file system qui interviennent et, lorsque l'on veut augmenter les capacités de l'application, on va tout suite faire du scale-out, c'est à dire se répartir sur plusieurs nœuds d'un cluster. Les problématiques de cluster existent depuis longtemps mais c'est vrai que l'on est peu habitué à les adresser. En général, les machines plus ou moins virtuelles, ça dépend des hébergeurs que l'on obtient, sont de petites machines en termes de puissance. Donc on a vraiment besoin de ce mouvement horizontal des applications. Ce sont ces choses que les utilisateurs devraient déjà connaître mais qu'ils sont parfois obligés d'apprendre à leurs frais. Ca c'est la première difficulté. La deuxième, c'est quand on parle du cloud public. L'hébergeur n'est pas sur notre LAN et donc il y a une certaine latence réseau, et donc toutes les bonnes pratiques en termes de packaging de tout ce qui est ressources javascript et tout cela pour tenir compte de ces problématiques prend une dimension assez importante. Ce sont des choses que l'on a tendance à négliger car quand on fait tourner l'application sur son poste c'est très rapide. Donc on charge 38 fichiers Javascript et ça va vite quand-même mais quand on charge ces fichiers depuis un datacenter en Virginie c'est un peu plus long.

   

5. Et donc si je veux profiter de ces avantages, quelles sont les contraintes que je dois respecter pour pouvoir profiter pleinement du cloud ?

Essentiellement, ce sont des bonnes pratiques que l'on devrait déjà tous connaître. Celles que l'on nous rabâche dans de nombreuses conférences, les bonnes pratiques de développement Web, les bonne pratiques d'architecture, qui vont nous permettre d'avoir un code qui est évolutif, modulaire, et qui va pouvoir justement scaler. Quand on part d'une application from scratch c'est plus facile évidement. Quand on a du legacy cela peut être un peu plus compliqué. C'est un équilibre à trouver. Une autre difficulté, ce sont les frameworks que l'on va utiliser. Ils nous aident mais ils cachent les implémentations et on peut avoir des surprises car ils ne sont pas forcement focalisés sur une approche cluster. Donc, on a parfois besoin de se plonger un peu dans la documentation pour comprendre pourquoi ce qui marche bien en mode mono-instance et qui est déployé sur un cluster cloud peut avoir des comportements inattendus.

   

6. Et si je ne respecte pas ces bonnes pratiques, est-ce que mon application peut quand-même être déployée dans le cloud ? Quelles problématiques je risque de rencontrer ?

Ce sont souvent des problématiques de gestion d'état, par exemple l'accès au file system qui est vraiment la chose sur laquelle on tombe assez rapidement. On a beaucoup d'applications, de frameworks qui demandent un paramètre qui est un répertoire de travail, de stockage des fichiers des utilisateurs. Si une application est dans le cloud, quand je redéploie je redémarre sur un nouveau serveur donc forcément le file system n'est pas celui que je voyais quelques secondes avant. Il y a donc cette problématique à adresser. Il faut se demander si quand j'accède à un fichier, ce sont des données temporaires donc dans ce cas il n'y a pas de problème, ou bien est-ce que ce sont des données persistantes, auquel cas il faut que je passe par un service dédié qui soit du stockage persistant. Après, il y a plein de solutions, que ce soit Amazon S3, ou même un blob en base de données. Cela veut dire que l'on peut avoir des phases de refactoring qui peuvent être difficilement automatisées. Dans le code on va avoir un java.io.File et on ne peut pas savoir de manière automatique si c'est un fichier temporaire ou une donnée métier. Donc il y a souvent cette problématique de refactoring. Il y a quelques autres exemples de ce type-là comme par exemple les données de session HTTP. Les plates-formes elles-mêmes peuvent proposer des mécanismes de réplication mais quelquefois cela suggère de reconsidérer un peu l'architecture. Donc, selon le coté legacy de l'application, on va pouvoir prendre un contournement parce que la plate-forme va proposer un service, ou bien on va préférer faire un refactoring pour avoir quelque chose qui sera plus souple et qui va mieux s'intégrer dans le cloud. De manière générale, une application qui a été développée dans le cloud, on n'a aucune difficulté à la faire tourner chez soi car on a plus de souplesse sur un environnement local. Prendre une application legacy qui était strictement mono-serveur et se dire que l'on va la mettre dans le cloud, cela fait rêver les DSI, mais il y a quand même un peu de travail et c’était le sujet de la présentation que j'ai faite avec Eric XXXX.

   

7. Et justement, est ce qu'il y a des pratiques pour passer une application legacy dans le cloud ?

Les pratiques sont très simples. On aimerait bien avoir un consultant qui vient faire un audit pendant 3 jours et qui nous dise "ready for the cloud" ! Alors, il y a des choses que l'on peut identifier facilement, les pièges à éviter que nous avons présentés et puis il y a tout simplement tester. Dans un premier temps c'est expérimental, en se disant que l'on va déployer notre application dans le cloud pour comprendre ses contraintes, comprendre l'impact que cela a sur l'application. Et ensuite la faire évoluer, pas forcément dans l'esprit de mettre l'application en production dans le cloud, mais au moins connaître ces contraintes-là pour apprendre à les domestiquer et, du coup, être plus mâture plus tard sur ces migrations et ce que cela implique. Donc, de manière générale, après c'est toute la logique d'agilité et de DevOps d'avoir quelque chose de très continu, de surveiller ce qui se passe en production, et de comprendre que l’application tourne dans le cloud mais que je ne vais pas forcement avoir une ligne de commande pour scruter ce qui se passe sur un serveur. Donc je dois avoir instrumenté le code de mon application, avoir mis en place tout le monitoring pour être capable de diagnostiquer, pour avoir des analyses de performance. On n'a pas simplement son profiler qui est connecté comme cela à une application en production. C'est un peu plus compliqué quand c'est dans le cloud. C'est vraiment une migration sur les façons de travailler qui fait que l'on arrive à un niveau de mâturité qui permet de pouvoir faire la même chose en production après.

   

8. Comme tu le disais, une des principales spécificités du cloud c'est la scalabilité et la réplication ainsi que la gestion de la concurrence. Est ce que tu as des conseils pour éviter ces problématiques.

De manière générale, les frameworks modernes ont conscience de ces problématiques. Donc, on a des options qui sont plus orientées clustering et qui s'adaptent parfaitement au cloud, on a parfois des petites surprises qui nécessitent un peu de refactoring. Les bonnes pratiques sont très classiques, c'est simplement une bonne structuration du code et ensuite la plate-forme elle-même peut aider, c'est à dire qu'elle va fournir des services de réplication de données sur le cluster de file system persistant. Tous ces mécanismes-là qui font que l'on ne va pas chercher à réinventer la roue. Si on a besoin d'envoyer des mails, on ne s'amuse pas à créer son propre serveur SMTP. On va prendre un service qui fournit déjà cela clé en main pour aller très vite, savoir que l'on s'appuie sur une brique qui est solide et qui est prévue pour le cloud. Donc forcément quand on part d'une feuille blanche cela permet d'aller très vite grâce à cela. Quand on part sur du legacy... Il y a le legacy pas trop moche pour lequel on s'en sort, et l'autre legacy pour lequel on va passer quelques heures... quelques jours... quelques mois... quelques années... !

   

9. Aujourd'hui quel genre d'applications sont hébergées dans le Cloud ? Est ce qu'il y a vraiment un mouvement de migration vers le Cloud ?

Alors Cloudbees à toujours souhaité être orienté application professionnelle. Donc évidemment on a des comptes gratuits pour permettre aux gens de se familiariser avec le cloud, mais nous notre objectif c'est vraiment les entreprises. Ce que l'on observe c'est que bien sûr les startups, pour des questions de facilités et de fraîcheur d'esprit partent sur ces solutions-là, et on a des entreprises beaucoup plus traditionnelles qui partent souvent dans le cloud à cause des applications mobiles. Les données doivent sortir du SI par définition et donc on a tout une série de barrières psychologiques qui sautent. Les données doivent sortir, donc on va devoir ouvrir des réseaux. Donc quand on en est à ce niveau-là, pourquoi ne pas mettre l'application directement dans le cloud quitte à ce que les données (pour plein de raisons comme par exemple parce que l'on a un vieux SAP dans un coin qui ne pourra pas sortir du data-center) restent dans l'entreprise, mais tout le reste va pouvoir profiter de cette logique-là. Donc, on retrouve finalement des utilisateurs très traditionnels qui ont cette démarche sur de nouvelles applications.

   

10. Et d'après toi qu'est ce qui freine encore les développeurs à franchir le pas ?

Les développeurs eux-mêmes sont déjà très consommateurs de cloud. Personne n'a plus l'idée de mettre son code ailleurs que sur GitHub ou BitBucket pour ceux qui préfèrent, mais on ne s'amuserait pas à dire "tiens je vais prendre ma box et installer un serveur Git dessus" juste parce que c'est rigolo à faire. On aimerait pouvoir appliquer la même logique en entreprise. Et là... on se retrouve dans le monde de l'entreprise avec la politique qui va avec, avec toutes les frayeurs qu'il y a autour du cloud : le fait de se dire que le cloud n'est pas sécurisé parce que ce n'est pas chez moi, ce qui suppose que c'est sécurisé quand c'est chez moi... Et malheureusement, on met le doigt sur quelque chose qu'ils essayent de cacher ou qu'ils ont du mal à démontrer. On a régulièrement la question sur notre SLA et combien on a de neufs dans nos garanties. 4 ? 5 ? 12 neufs ? Oui mais vous ? Votre serveur, s'il plante un dimanche matin, il faut combien d'heures pour qu'il soit rétabli ? Bon évidement on évite de parler aux DSI sur ce ton là, mais c'est là que se situe le problème. On a tendance à comparer un Cloud hypothétique merveilleux avec ce que l'on a chez soi dont on n'ose pas trop parler. C'est vraiment une barrière psychologique. Les développeurs, eux, en sont beaucoup plus conscients. Ce qui peut les limiter parfois, surtout les développeurs Java qui aiment beaucoup l'abstraction proposée par la JVM, c'est qu'ils vont devoir rentrer dans le monde des Ops. Ca les effraie, pourtant ça leur fait du bien. Mais au final ce sont vraiment des barrières politiques et psychologiques qui aujourd’hui sont déjà plus faciles a faire sauter car les mentalités ont déjà évolué parce que l'on a des solutions type Amazon VPC qui permettent de garantir la sécurité avec un data-center privé. Cela permet d'aller plus loin dans les discussions et d'avoir des cas d'usage beaucoup plus intéressants.

   

11. On entend souvent parler de cost-driven développement. Quels sont les moyens pour connaître les coûts qu'engendre mon application ?

Paradoxalement, on a les deux extrêmes. On a des plates-formes qui partent sur la logique "pay-per-use", c'est à dire que l'on va être facturé presque à la seconde. A une époque, sur Google App Engine on était facturé au cycle CPU, c’était assez hallucinant. Vous payiez un millionième de cents par cycle CPU donc c’était presque difficile à estimer au bout d'un moment. Maintenant c'est facturé à la minute, à l'heure. Cela permet d’être extrêmement fin sur sa consommation si on gère vraiment ses instances intelligemment, et de réduire les coûts de manière drastique. On va pouvoir se permettre de faire des tests nocturnes sur une instance iso production, parce que finalement elle va tourner, en termes de performance, en une heure, et une heure toutes les nuits ça ne coûte que quelques cents, ou un dollar ou deux. Quelque chose de vraiment ridicule. Après il y a l'autre extrême que l'on rencontre dans les entreprises françaises qui est les centres achats qui sont tous ces gens qui, quand il n'y a pas cinq zéros sur une facture, ne se sentent pas utiles, et donc quand on leur dit que cela s’achète par carte bleue et cela coûte 15 dollars par mois et bien cela ne leur va pas. Donc ce que l'on a mis en place chez Cloudbees c'est un mécanisme qui permet à ces gens-là d'avoir une facturation à l'année qui est adaptée à ce cas d'usage de grandes entreprises qui ne sont pas souples par rapport à ce mode de facturation. A la rigueur, ils préféreraient un forfait. C'est assez étonnant. Alors évidement on ne leur facture que ce qu'ils consomment, mais sur la base d'un forfait. C'est un peu bizarre mais cela correspond à un marché qui est à l'opposé des start-ups qui, elles, cherchent à ce que leurs factures suivent leur montée en puissance. Donc, ils commencent avec des ressources gratuites voire peu chères et qu'ils vont faire progresser, et à l'inverse, des entreprises qui veulent aller dans le cloud et qui ont besoin d'annualiser leurs dépenses mais qui pour autant ne veulent pas se transformer en vache à lait car ils l'ont déjà été pas mal de fois avec pas mal de fournisseurs. Ils apprennent, c'est bien.

29 oct. 2013

BT