Le cloud: le juge de paix des architectures applicatives

Le cloud se veut une réponse  agile et souple à nos besoins en services informatiques.  Mais il se révèle aussi comme un élément structurant qui influence l'architecture des applications informatiques.

Prenons trois exemples:

Deux applications identiques

 Les applications A et B sont identiques en terme de fonctionnalité, du nombre d’utilisateur etc.
Pourtant chaque mois la facture du fournisseur du cloud sera pour l'application 'B' trois ou quatre fois plus chère que pour l'application 'A' : pourquoi ?.
L'utilisation du cloud n'est pas gratuite, le coût dépend de l'usage.  La réponse est simple: dans l'application 'A' la grande partie des traitements  est réalisée sur le poste client. La partie cloud ne sert qu'a délivrer une application complète qui ne fera appel au cloud que pour la récupération des données.
C'est l'utilisateur qui supporte une plus grande partie des coûts en utilisant la puissance de calcul de son poste.

Ce raisonnement est amplifié dans le cadre d'une entreprise qui utilise un cloud privé ou public: elle supporte un double coût: La partie cloud et la partie poste de travail. Cette dernière étant obligatoire: chaque employé est doté d'un poste de travail.

2eme exemple la scalabilité.

Le cloud est avant tout élastique. La puissance mise à la disposition doit pouvoir s'adapter (dans les deux sens) en fonction de la demande. Vous n’êtes pas face à un cloud s'il faut deux jours de délais pour obtenir une machine virtuelle supplémentaire. Au contraire , ces ajustements doivent pouvoir être administrés par des commandes à votre disposition.
Mais toutes les applications ne sont pas 'scalable' de la même manière. Si votre application utilise un serveur de session  (en base par exemple) l'ajout de serveur applicatif va se heurter à des problèmes de disponibilité des informations de session. Aussi, il est préférable que la session soit portée par le client afin de libérer la partie serveur d'une tache complexe et coûteuse.  Ce déport concerne   les traitements , le stockage coté client. Il est favorisé par l'utilisation d'architecture de type REST.
Sans état: Chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le client et le serveur.
https://fr.wikipedia.org/wiki/Representational_State_Transfer

3eme exemple: Les nouveaux terminaux: smartphone-tablette

Un des critères de qualité important pour une application pour les terminaux mobiles est la consommation électrique. Aussi , une application qui est obligée d'échanger en continu avec le serveur va  vider les batteries du terminal. Les applications voraces sont vite abandonnées par les utilisateurs. D'où l’émergence d'un type d'application qui embarque les traitements et une partie des données. L'application travaille de manière autonome et se synchronise de temps en temps avec votre cloud.
Ces application sont de type single-page application alias SPA en anglais
http://fr.wikipedia.org/wiki/Application_Web_Monopage

source :http://net.tutsplus.com/tutorials/javascript-ajax/important-considerations-when-building-single-page-web-apps/

En conclusion: toutes les applications ne sont pas taillées pour aller sur un cloud. Le choix d'une architecture applicative doit se conformer aux contraintes du cloud y compris dans sa logique de tarification: partager les coûts avec l'utilisateur en mutualisant la CPU et la mémoire.

Prochain épisode: dessine moi un cloud.

lazy evaluation avec ruby 2.0

Dans les nouveautés de Ruby 2.0 , une se distingue des autres : la lazy evaluation.
Cette fonctionnalité rapproche de plus en plus ruby du domaine des langages fonctionnels.

La présentation est disponible sur slideshare :

ruby 2.0 et lazy evaluation from eric german

Le code des exemples est le suivant:
La programmation fonctionnelle  favorise l'usage des générateurs ou des suites pour résoudre un certain type de probleme  (List comprehension - map/reduce) .

Avec le mode lazy , ruby est capable de retarder l'évaluation d'expression et mieux encore de le faire à la demande.

Le principal cas d'usage reste l'utilisation des streams (flux) appliquée à des besoins de diffusions de video ou de fichier sous la forme de chunk (tronçons). Ainsi Node.js dispose d'une api permettant de brancher des flux entres eux un peu à la façon de la commande 'pipe' sous unix.

Sortie dans les délais de Ruby version 2.0

Pour les 20 ans de la première version de Ruby, voici la version 2.0

Disponible ici.


Parmi les  nouveautés:

• Utilisation de paramètre nommé (clé - valeur) dans l'appel des méthodes.
• Prise en charge d'un vrai  mode 'lazy' dans les générateurs de séquence (enumerator) 
• Meilleur support de l'asynchronisme

Très bon travail de l'équipe de développement.

Retour vers le futur : les AGL

Je ne donne  plus qu'un seul cours aux futurs analystes: Les AGL.  Le déclin des  AGL restent pour moi un mystère comparable à la disparition 'brutale'  des dinosaures.
La présentation est ici :

Agl2012 from eric german

Les  années 80 - 90 : l'age d'or des AGL. 

Ils sont incontournables. Leur règne  repose sur l’omniprésence du COBOL dans l'informatique et de l'industrialisation basée sur la programmation structurée.  Sur 100 lignes de code COBOL , 20 lignes seulement contenaient la partie 'métier'  le reste étant des instructions destinées à insérer le programme dans son environnement.
Toute l'algorithmie  était exposée au sein du programme  sur un même listing.

La  programmation objet, l'avènement du langage JAVA, la généralisation des bases de données ont précipité le retrait des AGL.
L'utilisation du WEB comme support des applications métiers a achevé la mise au placard des AGL de cette génération. Ces architectures sont basées sur le design  MVC  : modèle-vue-controleur. Ce modèle impacte le traitement algorithmique des problèmes. L' intelligence des traitements est éparpillée dans les 4 coins de l'application et du framework. La devise  'diviser pour résoudre' de l'approche objet appliquée aux projets MVC aggrave encore plus cette dispersion.
Aussi les AGL classiques ont été mis au rebut en attendant la prochaine génération.

Le modèle économique.

Mais un des facteurs  moins connu, de la difficile percée des AGL,  est lié au modèle économique des sociétés de services  informatiques.Quand on veut augmenter la productivité d'un secteur, le choix peut se résumer à ceci :
Soit acheter des robot à des  fabriques  de robot pour augmenter la productivité: comme ceci:

Soit ajouter de la main d'oeuvre  sur des postes banalisés comme ceci:

Pour une société de service qu'est ce qui est le plus rentable, facile et  sûr  ? :  louer des prestataires.
Si le coût moyen d'un prestataire est de 1000 euro par jour, la SSII facturera 1000 X 20 jours = 20.000 euro par mois aux clients. Quel est le salaire du prestataire: prenons un jeune ingénieur à 3000 Euros par mois : la SSI va dépenser 3000 X 2 (les charges sociales) = 6000 euros.

Ce calcul est a rapprocher avec le coût d'un secteur recherche et développement capable de fabriquer un AGL qui s'adapte aux nouvelles technologies. Avec en plus un retour sur investissement très aléatoire.


Mais, on assiste actuellement au reveil des AGL avec deux approchent différentes.

Les AGL  basée sur la modélisation UML (exemple Blu age) .

 L'UML est maintenant mature, universel et maîtrisé. La toutefois la complexité demeure dans la maîtrise des design Pattern (modèle de conception) .
Dans les écoles d'ingénieur l'enseignement  de l'UML se fait en 10 jours: mais  l'UML ne remplace pas   la maîtrise des bases de l'algorithmie.

Ces AGL -UML  sont capablent de générer du code pour des cibles différentes (PC , tablette)etc .

Les AGL sous forme de DSL.

Les spécifications fonctionnelles.
Le facteur de réussite d'un projet repose en grande partie sur la qualité des spécifications fonctionnelles détaillées. Des DSL (langage de domaine métier ??)  permettent  à la Maîtrise d'ouvrage d'exprimer leurs règles de gestion avec les termes de leur métier. Des traducteurs automatiques vont transformer ces règles de gestion en langage informatique. Un exemple de cette méthode est le projet cucumber

La maîtrise d'ouvrage rédige ceci:

Le résultat sera sous la forme d'un test fonctionnel que le développeur devra résoudre.

Conclusion: les AGL sont de retour. Attention , ils ne sont pas des produits miracles. Le coût d'entrée est lourd avec le risque de se tromper de produit. Les AGL sont à utiliser avec des méthodes Agiles pour en tirer les meilleurs résultats et pour minimiser les risques.
C'est bon d’être vieux , le passé devient le futur .

Une astuce à connaitre pour utiliser le module d'upload formidable dans Express

Dans un post précédent, je présentai le module de téléchargement 'formidable' pour Node.js.
J'ai essayé d'utiliser ce module dans le framework Express.  Après quelques essais infructueux et des recherches sur le site stackoverflow, j'ai compris les raisons du dysfonctionnement: la juxtaposition de deux couches de traitement du formulaire d'upload.

La couche web d'express se présente comme ceci:

La ligne : express.bodyParser()  prend en charge la gestion des données du formulaire.

Aussi la syntaxe    form = new formidable.IncomingForm()  est redondante avec bodyParser.

Deux solutions  possibles:
Commenter la ligne express.bodyParser()  et utiliser new formidable.IncomingForm()   pour traiter le formulaire ou inversement , ne pas utiliser new formidable.IncomingForm() et traiter le formulaire avec les primitives d'Express.

Pour ma part je préfère utiliser les méthodes de Formidable car elles sont plus adaptées à la gestion d'un upload.

5 tendances pour 2013 #html5 #javascript

L"an dernier à la même époque , j'avais publié un post sur les 5 tendances à suivre pour l'année 2012.
Le post est ici 5 tendances pour 2012 #nodejs #html5 #javascript

Pour etre honnête dans ce type d’exercice , il convient avant tout de dresser un bilan.

Bilan 2012

En 2012 j’annonçais:

Tendance 1: De plus en plus de choses vont se faire en javascript coté client. HTML5 

je me mettrais la note de 18/20 sur ce premier item.

Tendance 2: amaigrissement des frameworks : 
Rails 4 n'est pas encore sorti. Django est sorti mais au cinema seulement.

note : 5/20

Tendance 3: Les entreprises vont continuer à investir dans les réseaux sociaux (Facebook pour ne pas le citer).

Note incontestable de 20/20

Tendance 4: Virage de Twitter

J'ai failli ne pas être bon sur ce coup là , mais en 2012 twitter a ajouter des tweet publicitaires et des nouvelles utilisations viennent compléter l'écosystème: exemple le jeu tweeria.com (lien vers mon personnage ici)

Note 12/20

Tendance 5: Les bases de données NoSQL

Là , il n'y a pas photo : note 15/20

Pour 2013 ....  

les 5 tendances à suivre sont ...........

Tendance 1 : encore plus de javascript, node.js . Avec une librairie qui commence a se détacher du lot
Backbone.js. Ce module permet d'ordonner son code javascript.

Tendance 2 : La valorisation des données (restitutions graphiques). Elles se font naturellement sur le client. La librairie qui revient le plus souvent dans les conversations: d3.js . Mais il ne faut pas oublier raphaeljs. Et pourquoi pas nvd3.js pour faire la synthèse des deux ?

Tendance 3: Les DSL creusent leur lit dans le sillon de javascript et CSS avec Coffeescript, LESS etc.
Un autre langage à suivre : LUA.  Ainsi le développeur doit devenir polyglotte.

Tendance 4: Le bigData avec le Nosql et l'opendata.   Dans ce domaine, un trio se distingue: Hadoop , mongoDB et D3.js pour la restitution.

Tendance 5:  des versions majeures pour Ruby (version 2.0) , Rails (version 4) et .. java 1.8 avec un gros défi pour java : démontrer qu'il est capable de s'adapter à l'elastic  cloud.

Car 2013 sera surtout  l'année du cloud facile....  (post à suivre)

A suivre cette année et RDV pour un bilan en 2014.



 

Un jeu de carte original

Un nouveau jeu de carte commence à connaitre un certain succès : Cards against Humanity.

Le principe du jeu est très simple: Les cartes noires sont les questions, les blanches les réponses.
Le but du jeu est de proposer les réponses les plus drôles  C'est le principe des 'cadavres exquis' adapté pour des cartes.

Exemples de questions: (cartes noires)

Il faut compléter les 'blancs' par les réponses tirées des cartes blanches.

Un kit du jeu  en francais est disponible ici.

A vous d'imprimer les cartes et de commencer une partie 'caustique'