Bien, après ces quelques mois de torpeur estivale, fini les open-spaces abandonnés dès 16h, les allers-retours au boulot sans embouteillage,  les semaines entières sans croiser de commercial épileptique, remuons-nous un peu la couenne ! Et quoi de mieux qu’un bon vieux retour des familles sur une conf de cloud computing ? Haha…

Mardi 25 juin avait lieu à Paris la Défense une conférence Amazon Web Services (AWS).
Proposées chaque années dans 12 grandes villes mondiales, ces événements sont l’occasion pour l’entreprise de faire évidemment sa propre promotion, que ce soit à travers les dernières nouveautés proposées aux utilisateurs, l’assurance de leur probité ou encore le témoignage de clients venant illustrer les deux points précédents et de multiples autres qualités.
C’est donc l’endroit rêvé pour aller tirer, à travers des exemples bien concrets (et présentés en toute objectivité) , la substantifique moelle du cloud computing. Parce que oui, il y en a une. Parfois.

Pour ceux qui apprenne à l’instant qu’Amazon n’est pas qu’un vendeur de bouquins (une diablerie de vendeur pas très cocorico d’ailleurs, si on en croit notre élite nationale joufflue), ou un fleuve, ou encore une antique tribu de guerrières fougueuses, ou plein d’autres trucs qui ne ressemble pas à du cloud computing, et bien ça veut dire qu’entre autre vous n’avez pas lu avec suffisamment d’attention, voir pas du tout (faquins !) ces anciens articles de votre serviteur ici et ici (qui ne parlent il est vrai que très rapidement d’AWS). Alors pour faire rapide, vous allez voir cette page du Gartner [EDIT 07/2015: le Gartner ne présentant plus l’info en gratos, ça pointe maintenant sur un article qui souligne la même idée] et notamment le magic quadrant qui met bien les choses à leurs places, à savoir qu’Amazon Web Services, ça roxX du bébé phoque niveau cloud computing (fieu comme il leur met grave le seum ! Et IBM tout bouffi en bas à gauche, le démon qu’il prend ! [EDIT 07/2015: c’était le cas avant que le lien change vers une analyse Gartner plus récente… comme quoi IBM se rattrape]).
Et si vous ne savez pas ce qu’est le cloud computing, soit vous débarquez d’un forum de my little pony, soit vous avez atteint le stade ultime de la conscience.

Revenons à nos petites instances. Sur cette journée j’ai assisté à la conférence globale du matin, ainsi que trois (deux et demi) ateliers l’après-midi, dans l’ordre : « Big Data Analytics » , « Étendez vos datacenters avec le cloud AWS » et enfin « Déployer des applications hautement scalables sur AWS » . Le principe des ateliers est de mixer employés d’AWS (pour poser le contexte et faire le lien avec une de leurs solutions) avec un retour d’un client ou partenaire d’AWS qui apporte le dur, le palpable, le tangible.

Il y avait aussi possibilité de manipuler un peu AWS à travers des petits exercices pratiques dans des workshops en coin, mais pour le coup il y avait vraiment beaucoup de monde pour trop peu d’encadrants, j’ai trouvé l’exercice assez peu efficace (mais ça permet tout de même de récupérer un bon pour certification AWS gratis !).

Avant de se lancer, petite mise en garde pour ceux qui exècrent AWS (pour des raisons aussi futiles que la confidentialité des données… Peuh !) : ça risque de tartiner sec de façon admirative.
Je suis d’accord avec la plupart de vos arguments. MAIS… quand même, ils envoient du fat.

C’est parti.

La présentation d’intro du matin

Oublions tout de suite cette première conférence, qui n’est qu’une vaste introduction à la journée et durant laquelle on n’apprend rien pour peu qu’on ait déjà une expérience (même simplement théorique) d’AWS. C’est trop long.
On a bien quelques interventions de clients (Réseaux Ferrés de France, Millésima Bordeaux et Lafarge) qui viennent témoigner que vraiment, AWS c’est grave de la balle, qui parce qu’ils ont besoin ponctuellement d’une grosse puissance de calcul, qui parce que la disponibilité doit être à toute épreuve, etc., en bref ça manque cruellement de concret réel de la vrai vie du techos de terrain. On se doute bien qu’il y en a – par exemple, la migration d’un SI de la dimension de celui de Lafarge vers AWS doit bien contenir des centaines de trucs croustillants – mais malheureusement on a sur scène des représentants, donc on est surtout nourris à la punch line abstraite et aux petites phrases qui vont bien.

Entre-deux

Premières heures mitigées donc, d’autant plus qu’on se heurte (comme toujours) sur le problème classique du cloud computing : l’impression de nager dans du bullshit opaque sans réelle signification.
Heureusement, nos hôtes ont le bon goût de nous enlever cette impression partagée à base de petites verrines pour la plupart fort goûtues. C’est certes assez loin de notre sujet d’origine, mais ça fait toujours plaisir, surtout que la conf est gratuite à la base.
Et puis j’aime bien manger.

Bref.

Big Data Analytics

1) AWS guy

Cet atelier est introduit par un gars d’AWS qui va surtout définir le « Big Data ». Et pour de vrai, c’est carrément agréable de savoir ce que ça veut dire d’un pro qui sait ce qu’il dit.
Alors définition : le Big Data, c’est « travailler (efficacement) sur des données sans limite d’échelle » . Ce qui est recherché derrière, c’est de disposer d’un outil d’aide à la décision, en accédant rapidement à des quantités immenses de corrélations. L’exemple bateau est celui du vendeur d’un bien X qui veut savoir le meilleur moment de la journée pour lancer son produit, mais ça ne se limite bien évidemment pas à cela puisqu’on peut aussi s’en servir pour anticiper la propagation de maladies ou l’évolution du climat, collecter des données astronomiques, etc. etc.
La base de tout cela est la donnée, dans de grandes proportions bien sûr (Big Data, m’voyez ?) puisque l’idée est de préciser la faible pertinence de la donnée par la quantité. De cette façon, n’importe quelle source d’information peut nourrir des serveurs qui vont calculer tout et n’importe quoi. Les données sont divisées en données publiques (Open Data) qui viennent des Gentils, comme par exemples les états (sauf quand ils sont de mauvaise volonté ou qu’ils ont des choses à cacher), et les données vendues par les Méchants contre de l’argent maléfique qui corrompt le corps et l’esprit (vos photos de soirées sur Facebook ou Google+, petits malins).

Tout ça, on le met dans la machine et pouf ça crache du diagramme qu’il est bien pour la décision.

Et mais justement, cette machine là, comment elle marche ?
Alors pour commencer, AWS ne vend pas l’algo de rêve qui permet d’avoir des résultats ultimes directement. Ça, on considère que c’est le métier du client, de faire ses corrélations lui-même. Par contre, AWS peut vous aider pour deux trucs, fondamentaux lorsqu’on reprend le « sans limite d’échelle » de la définition : l’accès aux données et la scalabilité.

L’accès aux données est une question de performance. Le problème du stockage informatique « traditionnel » (comprendre relationnel) est qu’il demande, pour avoir des performances honnêtes, que les bases de données soient définies de façon rigides, dans le sens où les données stockées sont bien définies et classées par tables, les tables ont des relations entre elles, etc. Le souci est que ce schéma n’est pas adapté au Big Data : les données n’ont a priori pas de relations entre elles (c’est justement souvent ce qu’on cherche), elles sont massivement lacunaires et leurs quantités peuvent provoquer des requêtes très longues dans les bases.
Sur ce point, AWS propose son service DynamoDB, qui se repose sur des bases de données NoSQL, censé garantir des accès très rapides aux données et des possibilités de stockage très souples. En fait, il suffit juste de préciser les performances qu’on attend en accès lectures/écritures par seconde, AWS s’occupe du reste ! Il est bien sûr possible de modifier à chaud les performances, et le service propose par défaut de lever une alerte si un certain seuil est dépassé.

Pour ce qui est de la scalabilité, AWS a intégré Apache Hadoop – un framework développé spécialement pour tirer parti d’environnements distribués – à ses services pour former Elastic MapReduce. On peut donc facilement connecter une base de données (RDS, DynamoDB ou encore une BDD perso) à son application développée dans Elastic MapReduce (et hébergée sur des instances EC2). Une fois cela en place, on peut paramétrer le service pour générer plus d’instances (qui seront automatiquement alimentées en données) si la charge de calcul devient trop importante, et inversement en réduire le nombre si le système se retrouve en sous charge. Et on paye tout ça à l’utilisation bien sûr…

2) Intel guy

Autant l’intervenant d’AWS présentait des services qui, sans être totalement révolutionnaires, semblaient tout de même assez pêchus et innovants, autant celui d’Intel n’apportait rien de très fou… Mais c’est vrai qu’en informatique, les constructeurs hardware font souvent les taches obscures, indispensables mais peu voyantes sur le produit final.
Il n’empêche qu’entre l’amélioration du silicium, le développement de standards ouverts et les instructions AES pour x86, le cloud bien palpable du début semblait bien lointain. Non pas qu’il n’y a pas de lien, mais c’était un peu trop abstrait j’imagine…

Étendez vos datacenter

LA conf la plus intéressante de la journée ! On remerciera pour cela les deux intervenants, M. Gilot, architecte chez AWS, et M. Marie de Schneider Electric, très funs et carrés. La problématique traitée est la communication entre différents datacenter dispersés un peu partout dans le monde.

1) AWS guy

Bien  sûr, le premier service d’AWS pour améliorer l’inter-connectivité est le VPC (Virtual Private Cloud) qui permet de regrouper ses ressources (où quelle soient) dans un réseau virtuel, avec sa plage d’adresses IP, ses règles d’entrée/sortie, ses sous-réseaux, DMZ, accès internet, etc.
Si les ressources sont dans le cloud AWS, la gestion est instantanée. Si on veut agréger des ressources physiques internes comme un datacenter, AWS propose la Virtual Private Gateway qu’on ajoute à notre VPC et qui servira de point d’entrée du cloud à des connexions VPN provenant du datacenter si on passe par Internet. Ou alors on demande à AWS de brancher directement nos ressources à ses datacenters avec son offre Direct Connect (mais ça douille) … Tout ça se regroupe sous le nom de Cloud Hub.

Il reste cependant le cas où une application locale exploite des données dans le cloud avec des grosses exigences (en perf, en robustesse, le truc critique quoi). Une simple connexion n’est alors pas suffisante pour apporter toutes les garanties nécessaires (intégrité toussa), dans ce cas il faut installer sur site une machine virtuelle (appelée AWS Storage Gateway), on lui attribue un peu de stockage local (ou pas qu’un peu, si je me rappelle bien, dans le cas de Schneider c’était de l’ordre de quelques centaines de GB de tampon pour chaque passerelle), et elle servira de cache local, gérera la synchro, etc.
En fait, initialement, ça sert de passerelle locale au stockage du cloud, et permet ainsi de monter ces dernier en local via iSCSI. Accessoirement, le service de stockage dans le cloud derrière c’est le service S3 & volumes EBS, donc avec toutes les fonctionnalités de sauvegardes (fichiers), snapshots, réplications, … qui vont bien.
Donc voilà, déjà là, rien qu’en parlant de trucs « tout simples » comme du stockage, AWS arrive avec des solutions vraiment pas dégueu… À mille lieues de ce que peuvent nous proposer nos champions nationaux… (je sais, c’est mesquin)

2) Schneider guy

Venons-en à M. Marie, qui est un gars qui met les doigts dans le cambouis et ça se sent et c’est cool. J’ai malheureusement pris assez peu de notes, tout captivé que j’étais par l’exposé, mais je vais néanmoins essayer d’en donner un compte-rendu a-peu-près cohérent :

Le postulat de base, c’est que le réseau (à base de WAN MPLS avec QoS de bout en bout, garantie de bande passante, bref, un environnement totalement maîtrisé) reliant les différents datacenters de Schneider ne donne plus satisfaction (coût ? complexité ? je ne me souviens plus…). Schneider veut donc migrer sur une inter-connexion via le cloud d’AWS, donc un environnement beaucoup moins maîtrisé.

Les premiers tests à travers un accès naïf sans aucune optimisation ne sont pas très concluants : le ping est trop variable et important, ça ne va pas.
Première optimisation : utilisation de deux produits de Riverbed [edit 2016: la ressource pointée n’existe plus] côté AWS pour accélérer et alléger le trafic. Résultat : baisse significative de la consommation de bande passante (75% en moins tout de même !) et de meilleurs performances en terme de rapidité.
Mais ça ne suffit pas. Un peu nostalgique de son bon vieux MPLS tout de même bien pratique, Schneider décide d’investir dans du peering (ou appairage en bon français) entre différents opérateurs, ses datacenters et AWS, à base de fibre redondée 1G en veux-tu en voilà, bref il se construit une bonne toile bien vaste qui lui garantie débit, latence (10ms de ping au final), robustesse, indépendance vis-à-vis des opérateurs (sauf complot mondial), chance en amour et tout et tout.

Alors oui, c’est un peu décousu et ça ne parle pas beaucoup d’AWS… mais c’est parce qu’il faut bien avoir en tête que parmi les datacenters de Schneider, la plupart sont sur site,  mais l’un d’eux est dans le cloud d’AWS. Tous les services présentés plus haut sont exploités, et même plus (jusqu’aux services de niveau applicatifs genre messagerie d’entreprise si je me rappelle bien).
L’exposé était vraiment super intéressant mais visiblement un peu dense pour pouvoir en faire un retour solide 4 mois après…

Haute disponibilité

J’ai malheureusement raté une bonne partie du début et de la fin de ce talk, et en plus de ça c’était plus un exposé de plusieurs services d’AWS qu’un cas vraiment pratique avec des problématiques fines à résoudre.

L’idée globale est d’arrivé à une architecture qui assure une disponibilité maximale.
Ça passe d’abord par du stockage bien robuste : pour des fichiers statiques (comme du ouaibe), S3 résiste bien à la charge, surtout avec du CloudFront en façade pour le cache. Pour le reste, c’est à base de volumes EBS gérés par des instances EC2. On est dans la gamme des 4000 IO/s de base, mais on peut faire du load balancing avec ELB pour monter un peu jusqu’où on veut (sky’s the limit, tant qu’on paie !). En base de données, on peut utiliser RDS pour la sûreté (il fait de la réplication synchrone sans perte) ou DynamoDB pour la rapidité / scalabilité.
Le traitement se fait lui aussi sur des instances EC2 et est facilement scalable grâce à Hadoop.

Ce qui est intéressant surtout est l’utilisation relativement avancée de la fonction « Health Check » du service de load balancing ELB : on définit des tests à imposer aux différentes instances / zones, ainsi que les plans d’actions en cas de retour négatif. Typiquement, on se retrouve avec une zone fortement ralenti : paf on la réplique et on réparti le trafic entrant. Le frontal Web est tombé ? Paf on réveille le backup du site secondaire et on met à jour le routage DNS (Route 53) pour pointer sur le nouveau. C’est facile, c’est rapide, ça se fait tout seul : le rêve.

Sympa donc, mais un peu vu à l’arrache, on s’arrêtera là.

La conclusion de la fin

Journée pas perdue dans l’ensemble. Les talks de l’après-midi permettent réellement aux intervenants de faire parler la poudre, après ils le font ou pas, mais en l’occurrence je dois dire que l’ingénieur de Schneider, ainsi que son compère d’AWS (laissons-lui son mérite) ont réellement éveillé mon intérêt.

La conf du matin est cependant clairement la réunion d’auto-congratulation à destination des newbies d’AWS, inutile et ennuyeuse pour un ingénieur technique !

Globalement néanmoins, au vu de la dimension de l’offre de services d’AWS, je trouve qu’il gagnerait à faire un événement plus important encore. Je parle d’un point de vue de techos, quelque chose sur plusieurs jours peut-être, où on commence avec une présentation vraiment poussée et contextualisée de chacun des services, pour terminer avec des vues globales permettant de souligner les imbrications (bien léchées) entre les différents produits.
Je pense qu’une boîte de la dimension d’AWS pourrait se le permettre, mais c’est sûr qu’il est beaucoup plus rapide de vendre du cloud punchline et keyword à des décideurs qui l’imposeront ensuite à leurs équipes, plutôt que d’aller directement appâter la base des petites mains…
AWS a pour le moment choisi de rester dans l’entre-deux.