L’ergonomie, la vraie !

Pour moi, c’est ça la vraie ergonomie : commencer à travailler sans connaître une fonctionnalité du logiciel, que celui-ci la fasse apparaître en reconnaissant le travail que vous cherchez à accomplir et que le résultat soit immédiatement celui voulu.

Excel dans ses fonctionnalités d’aide à la transformation de données

Trop fort, Excel (copyright Thomas G. :-))

Posted in Data | Leave a comment

MVP 2016 !

C’est reparti pour un an Sourire

Résultat de recherche d'images pour "logo mvp microsoft"

Fier d’avoir été désigné MVP pour la 6ème année consécutive !

Posted in Uncategorized | Tagged | Leave a comment

Azure Container Service pour les grands débutants

Grande nouvelle pour les amateurs de Docker la semaine passée, à savoir la disponibilité générale de l’offre Azure Container Service, qui vous permet de déléguer au cloud de Microsoft toute la tringlerie sous-jacente à Docker, et vous occuper uniquement de la partie applicative.

En gros, tout ce qui est de l’infra, vous oubliez, à savoir :

  • tout le hardware, bien évidemment puisque c’est du cloud ;
  • l’installation du démon Docker ;
  • la gestion du cluster ;
  • le paramétrage de Swarm ;
  • etc.

Azure Container Service s’occupe de tout cela, et pour mettre en ligne une application que vous avez créée sous forme de conteneurs, il ne vous reste plus qu’à pointer votre client Docker sur le service (par une variable d’environnement), et lancer un docker run ou un docker-compose up ! Pour les gens comme moi qui sont plus à l’aise sur le soft applicatif que sur l’installation de serveurs logiciels et leur paramétrage avec des contraintes réseau, il s’agit vraiment d’une bénédiction Sourire.

Pourquoi cet article ?

Le sujet est tout neuf et la documentation de Microsoft sur le sujet est très bien, mais il manque malheureusement quelques petits détails qui font que, pour un débutant complet, ça peut vite bloquer. Même si on a bien compris les concepts et qu’on connait les outils, il n’est pas toujours évident de savoir comment adapter l’exemple à notre besoin à nous, parce qu’il manque juste la petite phrase ou la capture qui vous indique où trouver l’information dont vous avez besoin.

Le but de cet article est de combler ces petits manques. Je vais donc reprendre le déroulé d’installation d’un cluster ACS, en renvoyant à la doc pour tout ce qui est parfaitement expliqué dedans, mais en me permettant des rajouts sur les quelques infos que j’ai pris un peu de temps à trouver.

Création du cluster

Une fois connecté sur le portail Azure, quand vous cliquez sur “Nouveau” et que vous lancez une recherche sur “Azure Container Service” comme indiqué dans la documentation, vous vous retrouvez avec beaucoup plus d’options que ce qui est indiqué. En particulier, il y a ce qui semble être des instances prédéfinies, dont la séparation en “test / production / large” – du coup – n’est pas du tout expliquée.

Le mieux est de rester sur la toute première option de la liste :

image

Quand vous arrivez à la première page de paramétrage, quelques indications supplémentaires ne font pas de mal. Tout d’abord, le User name est celui qui sera utilisé pour se connecter au service de cluster Docker que nous sommes en train de créer.

Ensuite, pour la clé publique, c’est sûr que c’est quelque chose de facile quand on est administrateur… Mais vu que l’utilité de Docker (enfin, de mon point de vue), est justement que des développeurs puissent déployer leurs applications de manière simple, un petit rappel ne fera pas de mal pour créer un certificat sous Windows, surtout que les liens auxquels la doc renvoie sont très complexes pour pas grand chose.

Donc, téléchargez d’abord PuttyGen (en faisant attention de ne pas télécharger ça n’importe où, bien sûr), puis cliquez sur le bouton Generate de l’interface, qui vous demandera alors de bouger la souris pour créer de l’entropie. Quand c’est terminé, vous voilà avec le contenu qui nous intéresse, et présélectionné en plus pour vous faciliter le travail :

image

Vous pouvez alors simplement copier le contenu et le coller dans l’interface Azure. N’oubliez pas de sauvegarder la clé privée (bouton Save private key). Si vous êtes juste en phase de test et que vous n’avez besoin que d’un niveau de sécurité limité, vous pouvez ignorer l’avertissement sur l’absence de mot de passe pour protéger le certificat, ce qui vous évitera de le retaper à chaque connexion du moment que vous êtes sur une machine sûre.

Pour le groupe de ressources, je vous conseille fortement d’en créer un dédié, car le processus va créer tellement de ressources que si on ne les regroupe pas, ou pire qu’on les mélange avec d’autres, ça va vite virer à la pétaudière… Enfin, je garde exprès l’emplacement Europe occidentale pour montrer un peu plus loin une autre limite de la documentation. Au final, l’étape 1 est remplie :

image

A l’étape 2, on part sur du Swarm plutôt que le choix DC/OS par défaut. Ensuite, à l’étape 3, pensez bien à voir les choix supplémentaires pour les machines. Si c’est juste pour tester le fonctionnement avec plusieurs agents (après tout, c’est bien pour de la distribution qu’on fait ça), augmentez le nombre mis à 1 par défaut, et profitez-en pour utiliser des machines un peu plus petites que celles proposées, de façon que ça coûte moins cher :

image

Si vous cliquez sur le lien Afficher tout à droite, vous aurez même accès à des instances de machines encore plus petites, ce qui peut être mieux pour le budget si vous ne faites que des essais. Après cela, les étapes supplémentaires sont juste des confirmations, et on peut lancer la création du cluster, qui va prendre quelques minutes.

Mise en place du tunnel SSH

Pour la suite, nous allons passer sur une VM avec un Ubuntu, vu que c’est quand même beaucoup plus courant d’utiliser le client Docker depuis un Linux. La première chose à mettre en place est le tunnel SSH pour accéder au système de gestion (management) du cluster.

Tout d’abord, il nous faut récupérer le fichier .pem depuis la clé que nous avons créée auparavant. Si elle ne l’est plus, il faut revenir la charger dans Putty avec le bouton Load puis utiliser la fonction Export OpenSSH key dans le menu Conversions et fournir un nom avec l’extension .pem. Le fichier sera alors posé sur le répertoire courant de la VM Linux.

La documentation donne une partie de la ligne de commande, mais oublie quelques points qu’il est pourtant nécessaire de préciser :

  1. Au lieu d’installer le certificat, il est possible de simplement passer la clé par l’option –i (on lui donne alors juste le chemin du fichier .pem créé juste avant).
  2. Le nom à utiliser avant l’arobase est le nom d’utilisateur, donc si on l’a changé dans l’étape 1, il ne faut pas oublier de le modifier dans la commande également.
  3. La première partie de l’URL est composée du préfixe DNS choisi à l’étape 3 (dernière zone dans la capture correspondante plus haut) suivi de la chaîne mgmt.
  4. La documentation ne donne pas les codes à utiliser pour les régions Azure. Dans l’exemple, il y a japaneast, donc on pourrait en déduire que la zone Europe occidentale est codée par europewest, mais c’est bien westeurope qu’il faut utiliser.
  5. Enfin, attention car on est habitué à cloudapp.net, mais le domaine à utiliser est cloudapp.azure.com.

Une astuce que ne précise pas non plus la documentation est qu’on peut retrouver ceci dans le portail Azure. Pour cela, commencez par choisir le groupe de ressource créé (nom donné à la première étape), et localisez l’icone correspondant à un service et commençant par swarm-master-ip (dans la capture ci-dessous, la dernière ligne).

image

Une fois cette entrée sélectionnée, on peut facilement retrouver le nom complet à utiliser en allant dans les paramètres et en choisissant Propriétés :

image

Une dernière astuce est de rajouter l’option –vvv pour avoir le maximum de retours d’information de la commande SSH (mode verbose). Dans notre exemple, cela donnerait :

ssh -vvv -i ~/AzureContainerService.pem -L 2375:localhost:2375 -N azureuser@acsjpgmgmt.westeurope.cloudapp.azure.com -p 2200

Une dernière chose : la commande ne rend pas la main. On peut croire qu’elle ne fait rien quand on n’est pas en mode verbose, mais dans le cas contraire, on voit bien à la fin la phrase Entering interactive session, et le tunnel SSH sera ouvert tant qu’on n’entre pas un signal de terminaison avec le raccourci CTRL+C.

Le plus simple est alors de lancer un second terminal pour la suite.

Accès au cluster

Le reste est très simple donc la documentation ne manque rien :

export DOCKER_HOST=:2375

A part qu’une fois qu’on a lancé un docker run sur ce démon, il est nécessaire pour voir le résultat dans un navigateur de savoir où trouver l’URL de base, ce qui n’est pas évident dans la doc…

Là encore, on peut retrouver ce qu’il faut dans le portail Azure, en prenant dans la liste du groupe de ressources celle commençant par swarm-agent-ip et correspondant à l’icone des services :

image

En allant dans les propriétés (ou même directement dans le premier panneau qui reprend les paramètres essentiels), on retrouve l’adresse d’exposition du cluster :

image

Autre chose : inutile de se casser la tête à chercher où ouvrir les ports dans le cas d’un service de conteneurs, les principaux sont ouverts par défaut, comme le décrit la documentation :

Azure Container Service configured for Swarm showing agents and masters.

En espérant que ces quelques précisions aideront quelques uns à mettre en place plus vite un cluster Docker !

Posted in Retours | Tagged | Leave a comment

Structurer et analyser des comptes bancaires avec Trifacta Wrangler

This article is also published in english on Trifacta’s blog

Explications

Je viens juste de finir l’écriture d’un livre sur l’Open Data, dans lequel je montre
comment chercher la donnée, puis la nettoyer, l’analyser et la mettre en forme. Afin
que le livre ne soit pas trop rébarbatif, ni pour le lecteur ni pour moi-même pour
l’écrire, je me suis fait un plaisir de tester plein d’outils divers et variés. Il reste bien
sûr de l’Excel et du QlikView, mais je suis tombé sur un outil que je ne connaissais
pas avant, et qui est vraiment top pour ce qui est du traitement des données non
structurées.

Il s’agit de Trifacta Wrangler, et je vous assure que c’est très différent de tout ce qu’on
a l’habitude de voir dans les outils de BI. Tout d’abord, l’ergonomie a été poussée
dans ses derniers retranchements. L’outil propose des suggestions sur les données. Je
suis en général réticent à ce genre d’approche, qui vise rarement juste, mais je dois
avouer que j’ai été bluffé par les capacités de Trifacta Wrangler.

Il se trouve que le projet est issu d’un projet de recherche de Stanford University,
mené par les docteurs Joe Hellerstein et Jeffrey Heer avec leur doctorant Sean
Kandel, et précisément avec le but de monter un système de suggestions probant. Au
final, le démonstrateur est extrêmement intuitif et permet d’atteindre des résultats
très rapidement, car il propose, à chaque action, des suggestions qui montrent le
résultat final si on applique cette proposition. Bref, l’utilisateur a un retour visuel
immédiat sur les choix possibles.

Depuis ce démonstrateur, Joe, Jeff et Sean ont lancé la société Trifacta afin de
continuer leur travail sur un outil que n’importe quel utilisateur sera capable
d’utiliser. En plus de ceci, Trifacta Wrangler est pensé dès le début pour distribuer les
calculs sur des machines séparées. On peut donc vraiment dire qu’il associe une
grande simplicité avec une puissance impressionnante.

En plus du livre sur l’Open Data, je me suis retrouvé à utiliser Trifacta Wrangler pour
débrouiller mes comptes bancaires. Il y a quelques semaines, je me suis rendu compte que mes impôts avaient beaucoup augmenté, et je voulais savoir si, sur les
dernières années, mes revenus avaient augmenté plus vite ou moins vite. J’avais une
idée en gros, mais mes fichiers de comptes ne sont pas correctement catégorisés, et
des raccourcis font qu’ils ne sont pas immédiatement analysables. Au final, je
souhaitais savoir quelle était la part des impôts, des dépenses de loisirs, de celles qui
sont incompressibles. Egalement, comme j’ai quelques revenus issus de location et de
mes livres et vidéos, je voulais savoir comment ça participait à la balance au fur et à
mesure du temps (ce n’est pas un scoop, mais au cas où vous ne le sauriez pas, non, la
littérature informatique ne fait pas vivre).

La démo

L’article contenant beaucoup de captures d’écran, il était trop gros pour une publication par XML-RPC sur mon WordPress, donc le voici sous forme de PDF à télécharger :

Article en PDF

Conclusion

Wrangler est un outil vraiment top que j’ai eu plaisir à découvrir. Il est très ludique et
ergonomique, comme j’espère vous l’avoir montré dans ce blog. Sur un prochain
article, je ferai peut-être voir le pendant de ceci côté puissance, où Wrangler semble
très bon avec la possibilité de paralléliser des analyses (ce qui explique pourquoi, par
exemple, il est nécessaire lors de duplication de valeurs précédentes de spécifier
quelle colonne donne l’ordonnancement des lignes, comme ce qui se fait dans Power
Query, par exemple). Et si vous voulez plus d’exemples, restez à l’écoute de ce site car
l’annonce du bouquin sur l’analyse de données Open Data ne devrait pas tarder…

Posted in Uncategorized | Leave a comment

Evènement Microsoft Extend à Paris, les 11 et 12 mai

Microsoft ouvre une conférence décrite comme “crowd-conferencing” (c’est-à-dire que c’est le public qui aura une part de vote pour les sessions qui seront présentées). Au menu, Office, Machine Learning, Cortana Analytics Suite, Power BI et SQL Server, et des intervenants qui viennent de Microsoft Corp à Seattle (http://www.interopevents.com/paris2016#paris2016-speakers).

image

Et c’est ouvert à tous, pas qu’aux MVP !

Posted in Uncategorized | Tagged | Leave a comment

Journée des interfaces naturelles sur le Campus Microsoft

Pour les veinards qui sont sur Paris, Microsoft organise le 11/12 une journée avec du Kinect, du projet Oxford, du Cortana, de l’IoT, etc.

Au programme, 4 MVPs qui vont vous faire découvrir tout ça ! Et peut-être que Microsoft aura amené un Hololens ? Pretty please Sourire

Pour s’inscrire, c’est ici : https://msevents.microsoft.com/CUI/EventDetail.aspx?CR_CC=200708369&EventID=1032691529&Culture=fr-FR&community=0

Posted in Uncategorized | Tagged | Leave a comment

Carina de Rackspace : un Docker Swarm en ligne

Imaginons que vous souhaitiez utiliser un cluster de machines pour déployer vos conteneurs Docker, en faisant en sorte que ces machines apparaissent comme une seule machine hôte Docker. Vous pouvez bien sûr monter ce genre de configuration chez vous avec des machines physiques ou virtuelles, mais le plus simple, à l’ère du cloud, est de tout simplement laisser des pros s’occuper de toute la tringlerie et pointer sur un hôte multi-machines, avec le réseau déjà paramétré ainsi que tout ce qui est compliqué (gestion des ressources, scaling, etc.)

C’est ce que propose Rackspace avec le produit Carina, qui est actuellement en beta, et gratuit. Pour tester un peu ce dont il retourne, commencez par vous créer un compte sur https://app.getcarina.com/app/login et connectez-vous :

image

Créez ensuite un cluster en cliquant sur “Add cluster” dans la fenêtre qui s’affiche, et renseignez l’identifiant et si vous souhaitez qu’il passe automatiquement à l’échelle :

image

De retour au panneau de contrôle, avisez le cluster nouvellement créé et cliquez sur GetAccess :

image

Le fichier téléchargé contient le nécessaire pour que vous vous connectiez sur votre cluster. Dans un shell Linux, lancez le fichier docker.env pour qu’il configure les variables d’environnement nécessaires :

DIR=$( cd “$( dirname “${BASH_SOURCE[0]}” )” && pwd )
export DOCKER_HOST=tcp://172.99.79.150:2376
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=$DIR

export DOCKER_VERSION=1.8.3

Attention à bien lancer le fichier avec la commande “source docker.env” ou en utilisant “.” à la place, car si vous exécutez simplement, un nouveau shell sera lancé et les variables ne seront pas modifiées dans le shell courant. A propos, ne vous inquiétez pas pour votre installation locale de Docker : seul le shell en cours prendra ces modifications.

On voit d’ailleurs, si on lance une autre fenêtre de shell que les informations sur Docker correspondent à une installation locale :

jpg@Ubuntu1410:~$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18

Go version (server): go1.4.2
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64

Alors que dans la fenêtre dans laquelle vous avez activé docker.env, les informations sont légèrement différentes (pour la partie serveur, en tout cas, car la partie cliente utilisée est celle locale) :

jpg@Ubuntu1410:~/carina/TestJPG$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: swarm/0.4.0
Server API version: 1.16
Go version (server): go1.4.2
Git commit (server): d647d82
OS/Arch (server): linux/amd64

Attention, vous devez avoir une version du client Docker assez récente pour que Carina soit pilotable correctement.

A partir de là, toutes les commandes Docker que vous lancerez auront pour effet la création de conteneurs ou le chargement d’images sur le cluster distant. Imaginons par exemple que vous démarriez un serveur Nginx avec une commande comme :

docker run -d -p 80:80 –name web nginx

L’adresse d’exposition ne sera alors plus votre machine locale, mais une machine publique sur internet dont vous pouvez retrouver l’adresse par exemple en lançant docker ps ou docker port :

jpg@Ubuntu1410:~/carina/TestJPG$ docker port web
80/tcp -> 172.99.79.150:80

A partir de là, il ne reste qu’à explorer la doc de Carina pour voir comment passer à l’échelle, gérer les volumes, etc. (d’après ce que j’ai pu en voir pour l’instant, elle est apparemment très bien faite), mais globalement, l’idée fondamentale est là : vous pilotez par l’API locale un hôte Docker distant, et multi-machines.

Attention, il s’agit d’une version beta sans aucune garantie de stabilité. Le site de Carina recommande d’ailleurs de passer le mode de gestion d’échec en “always retry” pour relancer les conteneurs tombés le cas échéant.

J’espère que le programme beta restera suffisamment longtemps gratuit pour que je puisse continuer mes tests et écrire quelques autres retours au-delà de cet article introductif…

Posted in Uncategorized | Tagged | Leave a comment

De la philosophie en programmation ?

En écrivant le blog précédent, qui finit par une recommandation de conceptualisation, je me suis rappelé d’une interview de Frédéric Lordon (philosophe et économiste passionnant à lire et à entendre) sur Arrêt sur Images. Il y citait Deleuze expliquant que la science procède par fonctions, alors que la philosophie procède par concepts (voir cette vidéo, à 5’55’’) :

image

Est-ce à dire que, comme Frédéric Lordon éprouve le besoin de convoquer Spinoza pour parler d’économie, nous aurions avons besoin de philosophie pour correctement conceptualiser les métiers que nous modélisons en informatique ? Je pense que oui, et je vais juste citer un exemple pratique sur lequel la philosophie m’a aidé de manière tout à fait pratique à lever une erreur de programmation.

Dans le livre “Sur les épaules de Darwin”, de Jean-Claude Ameisen, il est expliqué que le présent n’existe pas. Dans son style philosophique à la fois poétique et très scientifique, l’auteur convoque la mécanique quantique et la psychologie pour démontrer que la notion de présent est purement intellectuelle, et ne correspond à aucune réalité physique.

Il se trouve que cette réflexion rejoint parfaitement les travaux récents effectués sur un des logiciels dont je supervise la conception. Ce logiciel réalise des simulations budgétaires et jusqu’à maintenant, il fonctionnait de manière discrète, c’est-à-dire comme dans Excel, avec une modélisation du temps par colonne. Ainsi, nous avions des modèles financiers dans lequel le présent pouvait parfois correspondre à une année :

image

Malheureusement, il se trouve que certains sous-modèles financiers étaient calculés en mois, donc avec une représentation du présent différente :

image

Ceci pose des problèmes car il est difficile d’aligner les valeurs. Dans le sens d’une plus grande périodicité, c’est simple, il suffit de cumuler. Mais dans l’autre sens, comment faire : tout lisser uniformément ? La plupart des fois, ça ne correspond pas du tout à la réalité. De plus, cette définition du présent nous amenait à des représentations complexes, comme par exemple :

image

Non seulement le tableau est moins facile à lire, mais en plus, les lignes ne peuvent plus nécessairement être totalisées de la même manière.

Alors que si on reprend l’analyse philosophique d’Ameisen, et qu’on part du principe que le présent n’a d’existence que conceptuelle mais pas dans la physique, on tombe sur un modèle qui est beaucoup plus propre, où le présent n’est que la limite symbolique entre deux périodes seulement, qui sont le passé et le futur. Or, cette représentation est beaucoup plus propre au final, car elle permet de ne pas se soucier de la périodicité dans laquelle on discrétise pour représenter le présent :

image

Elle possède également l’avantage de pouvoir s’adapter à n’importe quelle périodicité, même la plus fine (pour de la trésorerie, au jour près, mais dans d’autres usages, nanoseconde si nécessaire). Bref, il s’agit d’une VRAIE conception du temps, et pas d’une représentation moyennement adaptée aux usages car trop rapidement posée.

Et si on pousse plus loin la conceptualisation, il faut d’ailleurs se poser la question de comment on pose cette ligne de présent ? Est-ce le moment où une personne analyse le budget ? Est-ce la date de valeur qu’on cherche à représenter dans le budget ? On peut tout-à-fait imaginer une personne regardant le 3 mars le budget tel qu’il se trouvait le 15 décembre de l’an passé, etc. Bref, encore de quoi philosopher sur ce qu’est vraiment le présent… s’il existe !

Posted in Uncategorized | Tagged | 4 Comments

Silo or not silo ?

Après avoir lu de nombreux articles sur les problèmes des silos dans l’informatique (je ne vais pas faire la liste) ainsi qu’un article très intéressant car prenant à rebrousse-poil les précédents (article d’Hank Marquis) et quelques commentaires associés (ici et ), je vais essayer d’apporter mon humble pierre à l’édifice, en tentant de formaliser QUAND les silos sont mauvais et QUAND ils ont du bon.

L’idée est d’appuyer l’opinion d’Hank Marquis avec des retours d’expérience, et de participer ainsi à contredire les Docteur Follamour de l’architecture informatique qui pensent que détruire un SI pour le reconstruire “proprement” est une hypothèse envisageable dans la vraie vie.

Le bon silo et le mauvais silo

Les silos sont bons quand ils séparent des applications informatiques qui n’ont rien à voir, par exemple une application de gestion de fabrication et une application de paie :

image

Inutile en effet de mélanger les choux et les carottes : une étanchéité “physique” permettra de ne pas risquer que les problèmes de l’un n’affecte l’autre (ex : plus de place sur un serveur de base de données commun, ou un changement de version des documents générés pour la bureautique, j’en passe et des meilleurs)

Les silos sont mauvais lorsqu’ils conduisent à de la duplication de données, par exemple si une application gère des bénéficiaires de subventions et l’autre des destinataires de courriers, car il y a de bonnes chances que ce soient des mêmes personnes qu’ils s’agissent (même si chaque application aura bien sûr ses spécificités de traitement des personnes, voire ses propres données complémentaires) :

image

Les problèmes sont là aussi multiples : duplication des commandes de modification des enregistrements, risque de ne pas avoir la même adresse pour le même tiers dans les deux silos, etc. La duplication des données dans les SI industriels est une des principales causes de perte économique.

Première approche d’interop

La réponse des EAI et ETL étaient de relier les silos par des mécanismes informatiques d’échange de données automatisés. Cela fonctionne assez bien quand il n’y a que deux ou trois silos avec des formats différents :

image

Mais les EAI posent le problème d’un Single Point Of Failure (en tant que point central, s’il dysfonctionne, tout le système est hors service). De plus, passé 4 à 5 silos échangeant de la donnée, on perd plus de temps à synchroniser techniquement qu’à travailler réellement sur le métier des applications, et on recrée dans l’EAI le plat de spaghetti dont on cherchait à se débarrasser dans le SI :

image

Approche d’interop plus moderne

La solution est de passer à des architectures orientés services, et de ressortir dans notre exemple un référentiel des personnes :

image

Mais, et j’en reviens à l’article de Hank Marquis, en mettant en place ce référentiel, il est important qu’il soit complètement autonome et le plus indépendant possible des autres métiers qui le consomment… bref que lui-même se comporte comme un silo !

image

Et là normalement, vous me dites que je suis en train de me contredire car on retombe sur de l’EAI, avec des transformations dans tous les sens. En fait, non, car il y a le second effet kisskool : la centralisation, si elle est accompagnée d’une normalisation des échanges, permet de ne placer des connecteurs de médiation que sur les logiciels ne la supportant pas encore, et d’avoir une grammaire commune pour chaque entité du SI :

image

C’est typiquement dans ce cadre que des approches de type ESB s’épanouissent : connecteurs de médiation au standard Entreprise Integration Pattern, asynchronisme pour lisser les effets de la centralisation sur la performance, robustesse de livraison des messages pour contrebalancer la complexité dûe à l’augmentation des acteurs sont trois des responsabilités d’un bon ESB. Et un bon ESB est un allié précieux dans la mise en œuvre d’une architecture SOA, même s’il est appelé à s’effacer progressivement devant des API web standards (architecture WOA).

image

Attention aux cas particuliers

Est-ce à dire que tout doit être découpé et que chaque silo doit communiquer avec les autres ? Comme d’habitude, tout est affaire de juste mesure, et il y a des cas particulier. Imaginons par exemple le cas d’un SI RH. Il existe effectivement un peu de redondance entre les personnes en tant que salariés et les personnes en tant que bénéficiaires d’une bourse, par exemple leur patronyme ou leur adresse :

image

Et pourtant, est-ce que cela a du sens de dire que les agents d’une collectivité qui attribue des bourses doivent pouvoir espionner le salaire de leur collègue parce qu’il a demandé une bourse pour son enfant ? Bien évidemment que non. Si on creuse un peu plus ce concept de personne, nous nous rendons compte que les deux applications ne traitent pas réellement de la même chose. La gestion de bourses traite des personnes en tant que bénéficiaires (l’élève ou l’étudiant) ou mandataire (ses parents ou tuteurs qui reçoivent l’argent tant que le bénéficiaire n’est pas majeur), tandis que la gestion de paie traite des personnes en tant que salariés :

image

L’enseignement de ceci est qu’il est essentiel pour atteindre une bonne décomposition informatique des services d’avoir approfondi fortement la conceptualisation du métier. Par expérience professionnelle, je peux citer plusieurs cas où un défaut de conceptualisation a amené à des modifications d’applications se comptant en dizaines, voire centaines, de jours hommes. Juste pour donner une idée du niveau nécessaire à atteindre, continuons justement sur les “personnes”. Un concept que tout un chacun comprend, car il appartient à notre vie de tous les jours. Pourtant, sauriez-vous clairement définir la différence conceptuelle entre un individu, une personne, un tiers moral ou un tiers physique ?

Bref, comme toujours en informatique, on en revient à la compréhension du domaine métier. C’est le principe du Domain Driven Design de baser la conception informatique sur une grammaire partagée et décrivant de manière non ambigüe le métier ciblé. Souvent, cette compréhension du métier passe par son expression la plus pure, à savoir la loi. Pour l’exemple ci-dessus, c’est la règlementation qui donnera les règles de gestion des tiers (un exemple parmi tant d’autres : un tiers peut être moral et physique à la fois lorsqu’il agit en tant qu’auto-entrepreneur). Et pour revenir à la gestion des bourses, la loi dit que l’attributeur d’une bourse a droit de connaitre les ressources financières du demandeur. Evidemment, cela donne une idée du salaire du demandeur (ou du tuteur éventuel), mais ces deux informations restent conceptuellement différentes, et il n’y a donc pas de problème à garder la seconde dans un silo étanche, hors de portée de l’attributeur.

Conclusion

Ce ne sont pas les silos qui posent problème en soi. Comme dit Hank Marquis, l’étanchéité et la claire séparation des responsabilités sont des points importants. Le problème apparait lorsque les silos doivent communiquer. La première approche, trop rustique, consistant à détruire les silos, revient à jeter le bébé (la séparation des responsabilités) avec l’eau du bain (la difficulté à faire interopérer). Il faut, pour garder les deux avantages, faire l’effort de contractualiser les échanges entre les silos. Ainsi, chacun reste indépendant, tout en évitant la duplication de données qui est un problème aussi important que le manque de séparation claire des responsabilités.

Au final, si vous êtes architecte SI, ne vous imaginez pas qu’une architecture SOA relève de la technique et des services web ou de la conception technique d’API. Au contraire, votre travail principal pour atteindre une architecture de services propres est de travailler sur les contrats d’interopération. Pour cela, les normes (iCal, vCard, ebXML, CMIS, et des centaines d’autres) sont à votre disposition et en leur absence, votre boulot principal est de décrire précisément le métier ainsi que de contractualiser sa représentation technique, à savoir un format qui servira de pivot dans tous le SI.

Votre meilleur allié pour cette tâche de conceptualisation et de standardisation est l’approche Domain Driven Design avec son concept de Bounded Context, et en particulier le bouquin fondamental d’Evans.

Un bonus, et une question

Un cadeau pour finir : la vidéo de la présentation de DDD par Eric Evans sur InfoQ. Et une question pour alimenter le débat (et les commentaires) : pour vous, la notion de Bounded Context est-elle assimilable à celle de silo dans le cas d’une architecture microservices, où tous les silos ont été découpés au maximum du raisonnable pour le métier ?

Posted in Uncategorized | Tagged | Leave a comment

Du NLP au programme, vraiment ?

Un retour sur un article qui m’a fait réagir : http://tcz.hu/the-future-of-programmers

L’idée est en gros de dire que la prochaine révolution industrielle va supprimer les métiers de docteurs et de conducteurs de véhicules, et que nous autres programmeurs seront les prochains, mais que nous aurons l’honneur de participer à cette destruction de métier en créant les logiciels qui vont nous remplacer.

L’auteur utilise ensuite comme illustration de son propos le fait qu’un programme est désormais capable d’analyser une règle métier écrite en texte, et de décomposer ce langage naturel en une arborescence de sujets, de conditions et d’actions. Il utilise pour cela un excellent exemple graphique, que je me permets de recopier de son article (source citée plus haut) :

nlp2.png

Jusque là, on est dans de la démonstration logique. Mais le saut à la conclusion est un peu abrupt : “How difficult is it to translate this into a computer program now?”. Ben, justement… c’est ça qui est difficile, et pas le reste. Parce que découper un texte correctement formaté en atomes reconnaissables et appliquer des actions dessus, c’est ce que font les moteurs de règles depuis 15 ans déjà !

Or, ce qui fait un “programme”, c’est justement tout ce qu’il y a autour et qui est incommensurablement plus difficile :

  • Tenir compte des règles non exprimées (tout client d’un éditeur de logiciel commence toujours par lui dire que son métier est simple… jusqu’à ce qu’on l’analyse ensemble et qu’il réalise que son métier est complexe, et qu’il ne lui apparait comme simple que parce que son expérience fait qu’il réalise inconsciemment 90% des tâches).
  • Tenir compte de règles floues.
  • Réfléchir au parcours ergonomique pour les utilisateurs.
  • Savoir régler les problèmes indirectement liés au programme : robustesse, sécurité, performance, etc.
  • Penser en termes holistiques, c’est-à-dire pas seulement au programme en lui-même comme silo étanche, mais en tant que bloc communiquant d’un Système d’Information. La valeur est désormais plus dans les interconnexions que dans les atomes du SI.

Au passage, c’est d’ailleurs pour cela qu’il est incomplet que dire que la data vaut de l’or : tant qu’elle reste dans son programme d’origine, elle n’en a pas, et n’en acquiert que lorsqu’elle est partagée, d’où l’importance économique de l’Open Data. Vous ne croyiez tout de même pas que l’Etat publiait de la donnée ouverte juste pour des raisons de transparence envers les citoyens ? Sourire

Bref, quand on me montrera un programme qui est capable d’analyser les conversations d’un comité de vingt personnes et d’en sortir une norme de communication informatique qui traite tous les cas d’usage évoqués, je reconnaitrai que le métier de développeur est mort. Mais je pense que je le serai bien avant…

Posted in Retours | Leave a comment