devops chez Antidot

DevOps, kesako ?

Le terme DevOps est apparu il y’a environ une dizaine d’années et est largement utilisé dans de nombreuses fiches de poste (dont la mienne) mais il reste encore flou aujourd’hui. Je vais donc essayer de me lancer dans une définition ; ou du moins dans la définition que nous en faisons chez Antidot.

Origine du mot DevOps

nuage de mot devopsDevOps vient de la contraction de 2 termes anglais « development » « operation* ( *exploitation en français) ». Cela part du postulat qu’il y’a donc deux mondes, celui des développeurs donnant vie à un produit, et celui des administrateurs système qui l’opère dans le Datacenter.

Avec l’apparition des méthodes agiles, ce postulat est mis à mal, et le terme DevOps fait son apparition en proposant le trait d’union entre ces deux mondes. Le « DevOps engineer » n’est plus un simple admin, mais s’oriente plus vers un développeur qui aurait pleinement conscience des ressources requises par son produit, et saurait comment l’opérer efficacement dans un espace de production car il en connaît toutes les ficelles. Cette double compétence permet une grande réactivité, et est un atout non négligeable dans un procès de déploiement continu ou d’intégration continue.

Et Antidot alors ?

Antidot est un éditeur logiciel spécialisé dans la transformation et l’enrichissement de données, aussi, la société propose plusieurs produits qui utilisent une architecture assez complexe. C’est là qu’une approche DevOps est intéressante, voir indispensable pour opérer un Datacenter en perpétuelle évolution.

En effet, le marché fait que nous avons régulièrement besoin d’ajouter/réinstaller de nombreuses machines. Amazon avec AWS fait ça très bien, mais nous préférons opérer nous-même 95% de notre Datacenter (5% étant quand même chez AWS). Nous voulons avoir la même souplesse qu’AWS en termes de mise à disposition de machines, pour cela nous utilisons divers outils qui nécessitent des compétences en développement comme Puppet (ruby)/Ansible (python)/FAI (bash) ou encore Docker et LXC pour la virtualisation. Aujourd’hui une installation complète d’une machine pour notre DC (comprendre avec compte UNIX, produit installé « Up & Running ») prend moins de 10 mins pour une machine bare-métal, moins de 5 minutes pour un container LXC et quelques secondes pour un container sous docker.

Même si cette partie utilise des compétences de DEV, elle reste très orientée, OPS. Ce n’est pas le seul besoin que nous avons chez Antidot, comme je l’évoquais un peu plus haut, nous avons besoin de réduire et d’automatiser au maximum le passage en production de chaque ligne de code* (*de chaque commit)  produite par nos développeurs « de souche ». Il a fallu repenser toute la chaine de livraison/test de notre solution.

devops chez Antidot

Ce besoin est résolu avec la mise en place d’une architecture basée sur les fonctionnalités offertes par docker et gitlabCI. Ainsi, un développeur peut à loisir développer dans une branche git sur son propre poste, chaque commit déclenche l’instanciation d’un environnement virtualisé complet à l’image de notre production, afin d’y effectuer une série de tests. Une fois tous les tests passés, le commit est automatiquement mergé/fusionné dans la branche principale de notre produit, et une nouvelle version est livrée, prête à être installé en production. A chaque étape, une notification est envoyée au développeur (dans une room Hipchat) lui permettant un retour « temps réel ». Il va de soi que le déploiement vers l’environnement de production est également automatisé, ce qui ne veut pas dire automatique. Nous préférons garder le contrôle sur le moment où nous déployons en un clic vers tout notre parc de production. A titre d’exemple, avant cette automatisation, une mise à jour de production pouvait prendre plus d’une journée à un de nos administrateur système pour tout le parc, elle a été réduite à 20 secondes pour appeler la commande et à 20/30 minutes pour son exécution (temps incompressible d’arrêt et de redémarrage des services sur tout notre parc de production).

Le monitoring en Devops

Le monitoring est egalement opéré en mode DevOps. Chez Antidot, nous utilisons principalement Shinken. Shinken utlise une liste de « hosts » et de « probes » statique. Avec notre Datacenter devenu dynamique, il a fallut ecrire une bibliotheque capable de découvrir tous les hosts provenant de notre inventaire (GLPI) et de leur appliquer les bonnes sondes metier en fonction de certain critères/tags. Grace a cette bibliotheque écrite en Python, nous pouvons par exemple ajouter une machine dans un cluster Mongo (Kickstart + playbook Ansible), le monitoring arrive automatiquement avec uniquement les  psondes necessaire.

schema devops

Le « devops » chez Antidot ne consiste pas à réinventer la roue, mais à utiliser une multitude d’outils/de standard open source (ou non), et de créer le « liant » entre tous ces outils afin de ne pas avoir à répéter deux fois une même action (là ce sont mes origines Corses qui parlent). D’aucun diront* (* les mauvaises langues) que c’est une sorte de fainéantise poussé à l’extrême, afin de simplifier ses tâches. Je préfère dire que c’est plus une façon de se débarrasser des tâches ingrates/répétitives en créant une architecture « vivante » et « dynamique », et surtout plus intéressante, piloté d’une main de maitre 🙂

C’est un défi que nous aimons relever et qui nous permet de nous tenir au fait des nouvelles technologies. A ce titre, si tu es comme nous et que tu souhaites faire de cette philosophie devops ton quotidien, je rappelle qu’Antidot recrute un Administrateur DevOps, n’hésite pas à nous contacter, toute proposition sera étudiée.

Article rédigé par Yann Finidori

Antidot à la Web Intelligence Summer School

WISS 2015
La Web Intelligence Summer School 2015 a eu lieu du 31 août au 4 septembre à l’Université de Saint Étienne.

La thématique cette édition 2015 était « Répondre à des questions avec le Web » :

  • Publication de données web : données liées Linked Data,  normes et techniques du web sémantique / web des données
  • Comprendre et analyser une question en langage naturel : NLP / traitement du langage naturel
  • Trouver des données pour répondre à la question et à justifier la réponse : intégration / curation / extraction de données
  • Présenter les réponses : représentation graphique et  visuelle

Vous trouverez ici le programme complet de la Web Intelligence Summer School.

Membre de l’équipe Recherche d’Antidot, Ludovic Samper y a donné mardi 1er septembre de 10h30 à 12h30 un cours de 2 heures sur les techniques d’apprentissage automatique – machine learning. Il y a parlé plus spécifiquement de classification supervisée utilisant scikit-learn, et détaillé certains algorithmes comme NB  – Naïve Bayesian, classification naïve bayésienne – et SVM – Support Vector Machine, machine à vecteurs de support.

Résultats de différents classifieurs avec scikit-learn – cliquez sur l’image pour l’agrandir

Si vous n’avez pas pu y assister, en voici le contenu (en anglais) :


This is all the materials for the course:

The tutorial is about supervised classification of text documents. I’ve presented some classical algorithms (Multinomial Naïve Bayes, Support Vector Machine) and the maths behind. To illustrate the course, I used scikit-learn library and the 20newsgroups dataset.

The slides are here:

[slideshare id=52252432&doc=wiss-ml-150831140716-lva1-app6892]

And you’ll find here the code I shown using iPython notebook:


 

Partenaires de cet événement :

Université Jean Monnet Laboratoire Hubert Curien École des Mines de Saint Étienne Telecom Saint Étienne CNRS Bonn Universität Fraunhofer Institut

Continuous integration, Continuous delivery, Continuous deployment : où en est-on chez Antidot ?

L’équipe Delivery a la responsabilité de la mise en place des outils et des process de l’équipe technique chez Antidot. Dans ce cadre, elle développe puis opère les chaînes d’intégration continues de nos produits logiciels.

Je me propose de vous faire un retour d’expérience basé sur notre pratique.

De quoi parle t-on ?

L’intégration continue (continuous integration dans la littérature anglo-saxonne) implique que les développements logiciels sont régulièrement intégrés sur une branche commune sur laquelle sont automatiquement déroulées toutes les étapes de compilation et de validation.

La livraison continue (continuous delivery) est la suite logique de l’intégration continue : elle implique qu’à chaque moment on est « prêt à livrer » une version. La sortie de l’intégration continue devient donc le livrable attendu.

Le déploiement continu (continuous deployment) représente le Graal des équipes DevOps : chaque commit, s’il n’introduit pas de régression, finit automagiquement en prod.

(source IamOnDemand)

Continuous Integration

Depuis 5 ans, nous avons mis en place des chaines d’intégration continues, de plus en plus complètes.

A ce jour, chaque commit dans git sur une des branches de référence déclenche séquentiellement :

  • La compilation et les tests smalls,
  • le packaging (.deb et .rpm) et la création de dépôts dédiés à la validation,
  • des tests dits « medium » puis des tests dits « larges ».

Les dénominations de tests « small », « mediums » et tests « larges » viennent de l’excellent livre « How Google tests software », dont vous trouverez ici un résumé en français et qui propose une classification des tests en small, medium et large.

  • Un test small valide une unique fonction, avec une granularité très fine
  • Un test medium implique un ensemble de « modules » qui collaborent pour réaliser une fonction
  • Un test large implique le système entier.

Les problèmes que nous avons rencontrés lors de la mise en place de ces chaines d’intégration continue tournent autour de deux thèmes :

  • L’instabilité chronique des chaines,
  • Le temps d’exécution de ces chaines.

La solution au premier point réside dans l’analyse systématique des erreurs pour essayer d’en éliminer les causes racines. Je pense qu’on pourrait faire un article entier (et d’ailleurs je le ferai peut être) sur toutes les raisons, bonnes ou mauvaises, qui font qu’une chaine d’intégration continue est instable.

Pour le second point, nous n’avons pas à ce jour de solution satisfaisante : après avoir facilité l’écriture de tests, mis en place des outils pour les jouer automatiquement, réussi à convaincre tout le monde de l’intérêt de produire un maximum de tests, nous sommes aujourd’hui confrontés au problème de l’adhésion de tous à ces principes, et donc nos suites de tests augmentent et leurs temps d’exécution s’allongent.

D’aucuns diront que c’est un problème de riche, mais il faudra assez rapidement que nous nous attaquions à ce problème.

Continuous Delivery && Continuous Deployment

Les chaines d’intégration continue installent toutes les nuits la meilleure version disponible (RC pour « Release Candidate ») dans un environnement simulant la production.

À tout instant, une version est donc prête à livrer, et en ce sens nous respectons le Continuous Delivery.

En pratique, nous livrons une version toute les semaines et chacune de ces versions est mise en production.

Qu’est ce que signifie livrer pour nous ?

  • positionner un numéro de version sur un SHA-1 git,
  • communiquer sur la disponibilité de cette version (mail, tweet),
  • communiquer (Release Notes) sur le contenu fonctionnel de la version : nouvelles fonctionnalités, corrections de bugs…
  • mettre à disposition des paquets dans un dépôt stable.

Pourquoi doit on livrer ?

La question peut surprendre, mais dans un monde où une part significative des développements est exploitée en mode Cloud, la notion de numéro de version peu avoir un coté archaïque. Si l’on applique à la lettre les principes du Continuous Deployment, la version en production est la dernière qui a passée toutes les validations, et la notion de livraison telle que décrite ci dessus s’estompe.

Pour autant, nous ne somme pas prêt à abandonner la notion de livraison car en plus d’opérer notre propre solution dans notre datacenter, nous livrons aussi  nos logiciels en licence et nous fournissons notre plateforme à des partenaires qui construisent des solutions par dessus.

Dans ces deux derniers cas, les clients peuvent attendre des fonctionnalités ou des corrections de défauts, qui doivent être corrélées à des versions.

Le Delivery Train

La pratique de livrer systématiquement toutes les semaines la meilleure version possible (la dernière ayant passée avec succès tous les tests disponibles) est inspirée du « Delivery train » prôné par Spotify. Par ailleurs, c’est un premier pas vers le « Continuous Deployment ».

Avant la mise en place du Delivery Train :

  • la livraison d’une version, son périmètre fonctionnel, sa date de sortie était le résultat d’âpres négociations entre développeurs et chefs de projet, arbitrées par l’équipe Delivery.

Depuis la mise en place du Delivery Train, la livraison est systématique le vendredi et cela a :

  • enlevé du travail inutile et chronophage de négociation de date et de contenu,
  • rassuré tout le monde : si on rate un créneau pour une correction, le suivant n’est jamais que dans une semaine dans le pire des cas,
  • fortement amélioré l’automatisation du mécanisme de livraison : ce sont les effets bénéfiques du classique : « if it hurts, do it more often » cher à toutes les pratiques d’automatisation
  • et donc bien évidemment, facilité le non respect de la règle : en cas d’urgence (bug critique…), nous relivrons immédiatement. Et les gains en automatisation du processus de livraison facilitent cette livraison supplémentaire.

Continuous Deployment

Antidot ne fait donc pas aujourd’hui de Continuous Deployment. Mais un des effets bénéfiques du Delivery Train est que l’on y va doucement mais sûrement, poussés par le train.

En effet, la mise à disposition toutes les semaines d’une nouvelle version, nous a poussé à essayer de la mettre en production dans la foulée.

Nous sommes à nouveau dans un mode « if it hurts do it more often » :

  • nous avons mis à plat les processus de mise en production,
  • nous avons systématisé un calendrier,
  • nous sommes actuellement en train de travailler à rendre ce process aussi automatique que possible.

À moyen terme notre objectif sera donc une livraison hebdomadaire de version et le déploiement automatique de cette version sur notre production.

Je ne sais pas dire aujourd’hui si nous irons vers le Continuous Deployment au sens strict de la définition. Je dirais que nous n’en n’avons jamais été aussi près, et je vous en reparlerai dans quelques mois, lorsque nos objectifs moyens termes seront atteints.

Références :

Ship It Day Antidot – première édition !

Les 19 et 20 mars derniers se tenait le premier « Ship It Day » dans les locaux de la R&D d’Antidot à Lambesc (13).

Le Ship … quoi ?

A l’origine initié par la société Atlassian, le Ship It Day est une opportunité donnée aux employés de travailler en 24 heures sur un projet de leur choix, en rapport avec le produit et l’activité de l’entreprise, en vue de le livrer à l’issue de la journée, avec une seule règle : « Pas de règles ! ».

Cette manifestation est une occasion pour l’entreprise de promouvoir l’innovation en mettant différentes équipes en concurrence. Oui, mais dans quel but ?

La raison est simple : qui n’a jamais entendu ce genre de remarques à la machine à café ?

« Ce serait vraiment pratique que cet outil permette de faire ça, ça et puis aussi ça »

« Je ne comprends pas, ce produit là ne se vend pas autant qu’on aimerait »

« Pfff, je ne me souviens jamais comment fonctionne cette appli… en même temps elle n’est pas vraiment intuitive ! »

En effet, pendant le Ship It Day, ces équipes vont enfin pouvoir développer ce plugin qui manque depuis si longtemps, repenser une fonctionnalité que personne n’utilise, redessiner une interface, etc.

Or le pilotage quotidien de ces équipes, la pression liée aux cycles de développements dans le respect scrupuleux de la roadmap ne permet guère de laisser parler la créativité des collaborateurs…

Pourquoi c’est cool ?

ShipItDayLe Ship It Day est avant tout une aventure humaine, ludique, faisant de l’évènement un vecteur d’émulation très fort. Cela permet de faire une pause dans le train-train quotidien, tout en avançant rapidement sur des projets, au final relativement aboutis.

C’est également l’occasion pour les collaborateurs, en sortant du cadre de travail habituel, de travailler et d’échanger avec des personnes qu’ils n’ont pas toujours l’habitude de côtoyer. Une réelle synergie inter-équipes se crée alors dans une ambiance très conviviale.

Enfin, certains prototypes réalisés au cours du Ship It Day pourront devenir des fonctionnalités du Produit, qui, une fois industrialisées, seront déployées en production.

Une première chez Antidot ?

Antidot est cependant coutumier du fait, puisqu’il s’agit en réalité du troisième évènement de ce type en trois ans, avec deux précédentes éditions sous la forme de “Hackathon”. À deux reprises déjà, il s’agissait de proposer un prototype destiné à faire avancer le Produit, réalisé à l’issue d’un marathon de développement d’une semaine,.

Néanmoins, bien que suscitant un réel intérêt au sein des équipes de développement, la durée pour ces hackathons s’est finalement avérée trop longue pour pouvoir les maintenir et les renouveler à un rythme régulier.

Cette année, la société a donc adopté le format Ship It, plus court, pouvant ainsi être reconduit régulièrement.

Comment ça marche ?

Le Ship it se déroule en plusieurs phases :

J – 2 mois : Lancement

La date à laquelle aura lieu le Ship It est annoncée aux collaborateurs.

J – 1 mois : Ship It order

Les collaborateurs peuvent proposer des projets. Il n’y a pas de contraintes sur le nombre de projets soumis par personne, ni sur le thème sur lequel ils vont participer.

Un projet peut même être proposé 5 min avant le début du Ship It Day, le jour J.

J – 1 semaine : Brown bag

Les personnes porteuses d’un ou plusieurs projets et ayant besoin d’autres collaborateurs peuvent, uniquement s’ils le souhaitent, présenter leur projet à l’ensemble de la société afin de recruter et constituer leur équipe.

Jour J :

Chaque équipe annonce le thème de son projet et la composition de l’équipe

Le concours débute un jeudi matin à 11 h pour se terminer le lendemain à la même heure.

Durant ces 24 h, ce sont les managers qui se chargent de l’intendance : pauses avec café / gâteaux / bonbons, pizza party le soir, petit déjeuner le matin, etc.

C’est une occasion unique de pouvoir se faire servir une bière par son manager !  😉

Les équipes constituées préparent ensuite des démonstrations de 5 min sur leurs prototypes, en vue de les présenter à l’ensemble de la société. Une fois les démonstrations terminées, l’ensemble des collaborateurs peut voter pour élire le projet vainqueur du Ship It Day. S’en suit alors une « party » digne de ce nom, afin de célébrer les vainqueurs et l’ensemble des participants à l’évènement.

A quand le prochain?

KeepCalmShipItAprès cette première édition fin mars, la prochaine est prévue les 18 et 19 juin prochains. Au total, ce seront donc quatre Ship It Day qui seront organisés par an, au rythme d’un par trimestre.

Lors du Ship It Day du mois de mars, entre les collaborateurs sur les pistes de ski, en déplacement professionnel ou tout simplement indisponibles, les projets ont principalement été réalisés par les équipes de la R&D.

Mais le Ship It Day a bien évidemment vocation à faire interagir le maximum de collaborateurs, quelles que soient leurs équipes de rattachement : chefs de projet, staff marketing, support client, etc. Nul doute que la prochaine édition verra encore plus de collaborateurs dans les équipes engagées.

Vivement la prochaine édition !

Et vous, dans votre entreprise, ça se passe comment le Ship It Day ? 🙂

P.S. : si notre approche autour des Ship It Days ou des brown bags vous intéresse et si vous êtes tenté de nous rejoindre cela tombe bien, on recrute ! Et pour ne rien vous cacher, nous avons expliqué sur ce blog comment se déroule le processus de recrutement à la R&D d’Antidot.

Architecture multi-tenant, une fausse bonne idée ?

Chez Antidot, nous avons une équipe R&D qui rassemble des développeurs de profils assez variés. Le terme de « développeur » ne doit pas être pris dans un sens réducteur, car ce sont des hommes et des femmes passionnés par leur métier, et qui non seulement codent bien des logiciels complexes mais qui, en plus, sont capables de prendre du recul sur leur métier et s’intéressent à l’évolution des technologies de l’informatique et de l’Internet, qu’elles impactent directement leur activité ou pas.

Aujourd’hui, nous avons choisi de partager sur le blog Antidot un billet écrit par Benoît Sautel, l’un de ces ingénieurs, qui partage depuis plus d’un an ses idées de « développeur passionné », comme il se définit lui-même, sur son blog « Fier de coder ».


 

Les concepts de Software as a Service ou de Cloud Computing sont de plus en plus répandus dans l’informatique d’aujourd’hui. Cela a pour conséquence que les éditeur de ogiciel ne vendent plus directement un logiciel mais le service que rend leur logiciel. Cette nouvelle façon de déployer du logiciel a changé la donne dans la façon dont sont conçus ces mêmes logiciels.

Vers un déploiement simplifié

Les architectures multi-tenant (multi-entités ou multi-locataires en français) ont vocation à faire en sorte qu’un logiciel soit capable de gérer un certain nombre de clients en une seule installation. Au lieu d’installer le logiciel une fois pour chaque client, ce dernier est capable de créer des environnement virtuels distincts pour chaque client de sorte à ce que de l’extérieur les autres environnements ne soient pas du tout visibles. En fin de compte, le logiciel répond lui-même aux problématiques de déploiement.

Dans le contexte d’un prestataire de service qui souhaite vendre son service à différents clients, l’architecture multi-tenant semble être la réponse évidente. Il suffit de déployer le logiciel une fois et de créer autant d’environnements que nécessaire, et le tour est joué. L’administration d’un tel système est, du coup, relativement simple.

Au prix d’une grande complexité dans le code

Je travaille en ce moment sur une application web basée sur une architecture multi-tenant. Et clairement ce type d’architecture a un coût dans le développement. Ce coût étant principalement dû à la complexité engendrée. C’est la raison pour laquelle je m’interroge à ce sujet.

Pour assurer l’isolation et l’indépendance des différentes instances, il me semble assez important de séparer les données de chaque instance dans une base de données dédiée. C’est une meilleure garantie de l’indépendance des données, mais c’est également pratique lorsqu’il s’agit de récupérer les données d’une instance pour transférer l’instance sur un autre serveur.

Tout cela implique qu’il n’est pas possible de considérer la base de données comme unique. On ne peut donc pas y accéder via un singleton dont on délègue d’ailleurs volontiers la gestion à notre outil de gestion de dépendances. Le connecteur à la base de données n’est plus un singleton, ce qui signifie que tous les composants qui s’en servent ne peuvent plus non plus être des singletons. D’ailleurs, la configuration du logiciel ne peut plus être non plus un singleton puisqu’il y en a une par instance. Bref, la perte de cette unicité limite très franchement le gain apporté par les outils et principalement ceux qui se chargent de l’injection de dépendance. Un peu comme si on retournait dans le passé.

Le code métier a bien souvent besoin de connaître sur quelle instance il travaille. Un objet représentant l’instance actuelle est ainsi passé en paramètre de la plupart des appels métier. La complexité de l’ensemble du code augmente ainsi fatalement et la testabilité prend du plomb dans l’aile. Difficile de faire du code simple dans une telle architecture.

De plus, une architecture multi-tenant ouvre une nouvelle gamme de risques de sécurité. Il n’est en effet pas envisageable qu’on puisse accéder à des données d’un autre environnement et encore moins de pouvoir les modifier. Pourtant, c’est le même code sur la même machine qui va gérer l’ensemble des environnements. Le risque est bien présent.

SaaS et architecture multi-tenant sont-ils vraiment compatibles ?

L’architecture multi-tenant a de nombreuses qualités quand il s’agit d’exploiter le logiciel en Software as a Service. Le logiciel sait nativement gérer lui-même l’ensemble des instances. Mais cela implique des contraintes auxquelles on ne pense pas forcément au départ.

Lors d’une mise à jour, si une régression est introduite, elle affectera immédiatement l’ensemble des clients. C’est un risque qu’il faut accepter de prendre, mais il peut être largement réduit en travaillant sur la qualité du logiciel. De la même façon, il est préférable de mettre à jour un logiciel à un moment où il est peu utilisé. Un logiciel multi-tenant implique de mettre tout le système à jour en même temps. Si les clients sont localisés un peu partout dans le monde, il est difficile de trouver un moment où tout le monde dort.

En général, un logiciel en SaaS est régulièrement mis à jour et évolue au fur et à mesure. Dans certains cas c’est tout à fait acceptable, si on considère par exemple que le service fourni par le logiciel se présente sous la forme de web services dont la rétrocompatibilité est assurée, les clients n’ont pas de raison de ne pas accepter les mises à jour. C’est davantage problématique quand le produit se présente sous la forme d’une interface graphique qui évolue régulièrement. Certains clients refusent catégoriquement que leur instance évolue et donc soit mise à jour.

Une architecture multi-tenant ne permet pas de mettre à jour certaines instances et pas d’autres. Il faut alors créer différentes installations du logiciel, chacun sur une version donnée. Et si on n’a pas de chance et qu’on n’arrive pas à trouver un petit nombre de versions pour satisfaire tout le monde, on se retrouve vite à déployer chaque client dans une installation distincte. Et là on a tout perdu. On a payé le surcoût lié à la complexité d’une telle architecture et on ne peut pas en profiter. Pire encore, on se retrouve à devoir quand même gérer une multitude d’installations, précisément ce qu’on souhaitait éviter au début.

Dev ou Ops ?

Se demander si les architectures multi-tenant sont pertinentes revient finalement à se demander où nous devons placer le curseur entre les parties Dev et Ops.

Dans les débuts de l’informatique, la moindre machine coûtait tellement cher qu’il était important d’optimiser chaque ligne de code assembleur des programmes de façon à économiser la moindre instruction processeur. Un gros investissement dans le développement des logiciels était nécessaire pour qu’ils soient capables de tourner sur des machines coûtant un prix raisonnable.

Mais, depuis ce temps-là, le monde de l’informatique a beaucoup changé. Les machines coûtent de moins en moins cher alors que leur puissance augmente, les réseaux se sont énormément développés, si bien qu’on n’achète même plus nous-même les machines mais qu’on paie un service d’hébergement (Infrastructure as a Service).

La virtualisation est venue ajouter une nouvelle dimension dans l’hébergement. Aujourd’hui, Docker est en passe de révolutionner une nouvelle fois ce domaine. On parle de plus en plus de Platform as a Service.

Tout cela est possible parce que le prix du matériel baisse sans cesse alors que sa puissance augmente. L’outillage s’est également adapté à ces changements et il est maintenant possible de gérer un parc de machines de manière quasiment automatique.

En parallèle de cette évolution en terme de technique, l’informatique est également de plus en plus populaire et même omniprésente. Mais le nombre de développeurs n’augmente pas aussi vite. Et jusqu’à nouvel ordre, il n’existe pas vraiment d’outils permettant d’automatiser le travail du développeur. Et heureusement pour nous !

Le curseur entre Dev et Ops s’éloigne petit à petit du développement. Il n’a jamais été aussi facile de déployer et d’exploiter du logiciel en masse (et ça sera certainement encore plus simple dans le futur).

Quel est le bon choix ?

Si la tendance actuelle se poursuit dans la même direction (ce qui me semble tout à fait probable), le déploiement sera de plus en plus automatisé et coûtera de moins en moins cher. Il me semble donc que dans le futur les architectures multi-tenant seront de moins en moins intéressantes.

Mais dès aujourd’hui, il me semble que le choix de partir sur une architecture multi-tenant n’est plus une évidence. Le logiciel en lui-même doit-il porter toutes les contraintes liées à son déploiement et la complexité qui va avec ? Grâce aux évolution des outils de déploiement, il est maintenant tout à fait possible de mettre en place en parallèle du logiciel une infrastructure de déploiement automatisée associée qui se charge de gérer ses différentes instanciations avec à chaque fois une configuration et une version bien précise. Ne vaut-il pas mieux développer deux systèmes distincts pour ne pas accumuler toute la complexité au même endroit ? Cela permet d’avoir à la fois un logiciel simple et toute la souplesse nécessaire au niveau du déploiement et de la gestion des différentes versions. N’est-ce finalement pas le moyen d’avoir le beurre et l’argent du beurre ?

L’image d’en-tête provient de Flickr.


Retrouvez les autres billets de Benoît sur son blog.

Et si vous avez envie de travailler chez Antidot, regardez les postes à pourvoir et écrivez-nous !

Chez Antidot, on a adopté les « brown bags ». Et chez vous ?

Il y a quelques années, lors d’une conférence Mix-IT, j’ai entendu parler des initiatives de Brown Bag Seminar. L’idée est d’inviter quelqu’un dans votre entreprise pour qu’il vous présente un sujet et pour le remercier, vous lui offrez son déjeuner. J’ai trouvé l’idée géniale, je voulais ça chez nous !

Mais retour sur terre, notre centre de R&D est situé à Lambesc, et des baggers dans le coin, il n’y en a pas des masses ! Attention, Lambesc, c’est génial ! On joue à la pétanque, on se fait des BBQ, on part courir ou faire du VTT dans la nature en 30 secondes depuis nos locaux, on n’a aucun bouchon sur la route (il faut tout de même se méfier des sangliers) mais pour trouver des personnes qui ont des sujets techniques qui pourraient nous intéresser… ce n’est pas Paris.

Alors comment faire ?

Saison 1 : Video Brown Bag

Le Web regorge de vidéos présentant les sujets qui nous intéressent. Plutôt que tous les regarder dans notre coin, pourquoi ne pas nous regrouper pour les regarder ensemble ? L’idée est lancée. Je crée un UserVoice pour rassembler les idées de tout le monde, on vote et on regarde chaque lundi midi la plus populaire. C’est une période sympa où nous avons entre autres découvert Gradle, Ceylon, OAuth 2, Play Framework… mais le côté vidéo n’est pas assez convivial et l’initiative commence à s’essouffler. En bon agiliste, je me dis « rétrospective, prise d’information et action », il faut faire de vraies présentations avec un présentateur physiquement présent.

Saison 2 : Home Made Brown Bag

Toujours la même question : où trouver des personnes capables de présenter des sujets tech qui peuvent intéresser du monde chez nous ? Et une nouvelle révélation ! L’idée révolutionnaire que l’on n’attendait pas : une personne qui travaille déjà chez nous !

Sur notre site de Lambesc nous avons des profils très différents ; depuis ceux qui sont fan du noyau Linux jusqu’à ceux qui adorent le CSS, en passant par C++, Python, Java, GWT, Javascript, Puppet, Jenkins, CMake et j’en oublie beaucoup. Convaincu de mon idée, je lance la saison 2, j’assure moi même le premier épisode : une présentation sur Tribal Leadership. Nous avons ensuite une présentation sur DITA, une sur Java 8 mais très vite (beaucoup plus vite), nouvel essoufflement. Du coup, rétrospective, prise d’information…

Trois causes principales :

  • le midi, c’est sympa de se faire un resto : ben oui, on est en France quand même.
  • le midi, on fait de la pétanque, du foot, du basket, on va courir, nager, on joue à des jeux de société… et il n’y a que 5 midis par semaine pour tout caler.
  • ça nécessite de préparer des slides.

Saison 3 : Home Made Brown Bag without Brown Bag aka « Weekly Dev »

Devant mon désarroi sur l’échec des Brown Bags, mon directeur technique me dit : « Et si on le faisait tous les mercredis de 11h30 à midi » ? Au début je me dis que c’est n’importe quoi, je ne vais pas manger à 11h30, c’est bien trop tôt. Mais tentons !

L’idée est simple : chaque mercredi, toujours à la même heure, toujours au même endroit, des personnes convergent de leurs postes respectifs et se rassemblent. On se regarde tous et on se pose cette question existentielle : « Qui a un sujet à présenter ? ».

Au début, quelques personnes trouvent des sujets. Mais même s’il y a des personnes qui aiment expliquer, il y a aussi des personnes plus réservées. Nous avons de nouveau atteint le jour où nous n’avions plus d’idée de sujet. Alors je tente la question inverse : « Qui aimerait qu’une autre personne ici lui présente un sujet ? » et c’est l’avalanche d’idées. Tout le monde est très curieux des domaines connus par d’autres.

Et depuis ce jour, les mercredis se succèdent avec des sujets complètement disparates et toujours passionnants. J’apprends des choses sur l’architecture des processeurs multi-coeurs, sur le protocole HTTP2 fraîchement sorti, sur la difficulté d’écrire un handler de signal en C, sur la mise en place d’un LogStash, sur l’architecture nécessaire à faire tourner un cluster Cassandra… Il y a aussi les fois où nous présentons ce que nous avons mis en place techniquement dans notre produit sans avoir à tenir un discours compréhensible par un non développeur car on est entre nous, les passionnés du code.

Enfin, par effet de bord, le Weekly Dev casse les murs entre les équipes, permet d’échanger, de débattre, de polliniser et nous permet de mieux nous connaître les uns les autres, et finalement, c’est ce que je préfère !

source : Dilbert, by Scott Adams

P.S. : si vous êtes tenté de nous rejoindre cela tombe bien, on recrute ! Et pour que vous sachiez comment se passent les recrutements à la R&D d’Antidot, nous avons expliqué tout le processus.

Faire et Savoir-faire

En informatique, Faire n’est pas compliqué.

C’est le Savoir-faire qui est long et difficile à acquérir.

La preuve ? Demandez à un informaticien de développer quelque chose qui va lui prendre disons 10 jours. Une fois le travail terminé, effacez tous les fichiers (on va plutôt dire que le serveur les a perdus et que la sauvegarde ne marchait pas…). Demandez-lui de recommencer. Eh bien, il le fera en 5 ou 6 jours tout au plus et le résultat sera meilleur que la première fois. Faire n’est donc pas compliqué.

En revanche, le coût d’acquisition des Savoir-faire informatiques a explosé ces dernières années avec la multiplication et la complexification des technologies.

Le bon vieux programme Basic des années 80 pour afficher des caractères sur un écran 80×24 n’est plus. Les programmes d’aujourd’hui sont incroyablement complexes : ils doivent fonctionner sur le Web comme sur mobile, pour des centaines d’utilisateurs, avec des performances et des fonctionnalités toujours plus riches. La diversité des compétences mises en œuvre explose littéralement. Qui maitrise aujourd’hui toutes les technologies et les savoir-faire nécessaires ? Si bien qu’à l’instar du bâtiment, le secteur informatique possède aujourd’hui ses corps de métier : ergonomes, graphistes, architectes, développeurs système ou réseau, algorithmiciens, développeurs Java ou C++ ou .Net ou PHP ou…

Et tout cela ne va guère en s’améliorant. Les environnements de développement et les plate-formes logicielles peinent à suivre le rythme et à réduire cette complexité. Si bien que dès qu’un projet implique un peu d’informatique, il faut mobiliser et inclure dans l’équipe des compétences technologiques fortes et seules des personnes ayant des compétences en programmation peuvent participer.

Prenons le cas du tout récent Big Data : certains, comme Harper Reed qui fut directeur technologique de la campagne électorale de Barack Obama, n’hésitent pas à dire que le Big Data c’est de « la connerie ». Sans aller jusque là, reconnaissons que le buzzword est désormais partout, et qu’il sert souvent d’alibi à des fournisseurs de matériel et de logiciel qui veulent renouveler à bon compte le marketing parfois essoufflé leurs offres. Pour autant,  il y a de l’or à tirer des données des entreprises, pour peu qu’on sache les faire parler, les analyser, les valoriser et les consolider avec des données externes afin de les contextualiser. qui peut faire ça ? Les « Data Scientists » nous dit-on. Une race nouvelle, hybride, possédant des compétences en statistiques et en informatique, avec une sensibilité avancée pour les données et une compréhension des enjeux métier. Mais existent-t-ils vraiment ? Il semblerait que non à lire 01net Entreprises (« Il y a urgence à enseigner le Big Data !« ) ou ITPro (« Le Big Data freiné par une offre complexe et une pénurie de compétence« ).

Source : wikibook « Data Science: An introduction »
Le fond du problème, c’est que les plateformes logicielles proposées sont trop complexes et exigent encore trop de mobiliser des compétences informatiques et techniques. Tout ça dans un contexte où les profils informatiques se font de plus en plus rares. Il faut arriver au point où la complexité technologique disparaît et où les solutions sont exploitables par des gens ayant avant tout des compétences métier et non des compétences technologiques. Un peu comme avec un iPhone : simple à utiliser et pourtant bourré d’innovation et de technologie.

C’est en ayant en tête ce contexte, et ces enjeux critiques d’agilité et de productivité, que nous concevons nos solutions logicielles chez Antidot.

Prenez l’exemple de notre solution d’analyse et d’intégration des données AIF  – Information Factory  : nous l’avons pensée et conçue de telle façon que vous pouvez construire des chaînes de traitement de données particulièrement avancées qui vont capter, nettoyer, sémantiser, classer, géotagger, enrichir, lier… des données sans nécessiter aucune connaissance en programmation.

Et notre plus grande fierté c’est de voir des projets incroyables réalisés par des gens du métier, sans compétence en développement.

Car finalement les meilleures technologies sont celles qui savent se faire oublier.

 

Au-delà du buzz et de la polémique sur Qwant

Je ne reviendrai pas ici sur le buzz et la polémique qui ont entouré le lancement en fin de semaine dernière de Qwant, un nouveau méta-moteur de recherche.

Je souhaite néanmoins vous faire part de l’opinion qui prévaut chez Antidot après cette affaire : il est vraiment regrettable que tous les médias, y compris les professionnels de l’IT, aient cédé à la facilité de faire de Qwant le nouveau  « Google français« . C’est un vrai souci pour les éditeurs de logiciels professionnels présents sur ce segment de marché : même quand on ne leur parle pas de Google et qu’on ne s’y compare pas, dès lors qu’il s’agit de technologies de moteurs de recherche les médias en reviennent au géant de Mountain View.

Antidot aussi en a fait l’expérience il n’y a pas longtemps avec cet article d’avril 2012 du Progrès de Lyon titré : « Fabrice Lacroix a bien failli créer le Google lyonnais » que vous pouvez lire en ligne ici et dont vous trouvez la reproduction ci-dessous.

Le Progrès 10 avril 2012

Si vous vous intéressez aux méta-moteurs et agrégateurs de recherches, je vous invite vivement à essayer le service Pickanewshttp://www.pickanews.com – un « moteur de veille » français disponible pour plusieurs langues et pays européens. Pickanews facilite la veille média sur une marque, une personne, un mot-clé et apporte un tableau de bord très riche qui permet de mesurer l’impact médiatique d’une marque ou d’une personne, en visualisant son évolution dans le temps, et avec la possibilité de le comparer à d’autres :

Pickanews dashboard

Pickanews utilise des technologies avancées de « speech to text » pour trouver des mots-clés prononcés dans des journaux d’info TV ou des émissions de radio. Avec en parallèle la recherche des ces mots-clés sur le web et les réseaux sociaux ainsi que dans toute la presse écrite, grand public et professionnelle, qui est numérisée et OCRisée chaque matin puisque c’est le métier de base du groupe PressIndex , acteur historique de la « pige presse » qui a créé Pickanews il y a 2 ans.

Pickanews lecteur audio

Le « speech to text » n’est évidemment pas parfait mais cela rend un vrai service. Vous pouvez consulter un exemple de veille effectuée avec Pickanews sur la marque « Qwant«  :

Pickanews-Qwant

Pickanews tire pleinement avantage des logiciels Antidot Information Factory, Antidot Finder Suite et Antidot Collaboration Services proposés par Antidot : ces solution sont fait leurs preuves, car c’est depuis 1999 que nous développons des technologies de moteurs de recherche et des solutions de valorisation de l’information et de navigation dans les données. Ces solutions sont aujourd’hui mises en œuvre avec succès par plus d’une centaine de clients de profils très divers, parmi lesquels figurent notamment TF1, Le Point, LexisNexis, Le Moniteur, Service-Public.fr, DecathlonPecheur.com, Discounteo, Oreca Store et bien d’autres que je ne peux tous citer et que je remercie de leur confiance.

Vous trouverez des explications techniques sur le service Pickanews sur cette page de notre site web et dans ce document PDF de 3 pages.

Et si vous avez un projet de moteur de recherche interne à votre entreprise,  ou de moteur de recherche pour votre site web, nous sommes à votre disposition pour vous apporter le meilleur de notre expertise et de nos technoogies !

 

Antidot publie la version 0.9.9 de db2triples

À la veille de WWW2012, la conférence mondiale consacrée aux technologies du web dont Antidot est un des sponsors, nous mettons à disposition de la communauté Open Source la version 0.9.9  de la bibliothèque db2triples. Cette nouvelle version apporte des évolutions majeures concernant le support des Candidate Recommendations des standards R2RML et Direct Mapping publiées le 23 février 2012 par le W3C.

R2RML et Direct Mapping : Candidate Recommendations du 23/02/2012

Parmi les améliorations figurent donc le support natif de MySQL et PostGreSQL ainsi que d’autres bases de données SQL via des pilotes JDBC, la gestion des types binaires (encodage base64), la prise en compte des caractères de langue spéciaux ainsi que le typage implicite des données et leur conversion selon la norme XML Schema du W3C, la gestion des formes canoniques des littéraux en fonction de leur type et de la casse des identifiants SQL. Pour la liste complète des évolutions, se reporter à la Release Note.

Le Linked Data opérationnel en entreprise

Cette nouvelle version de db2triples constitue une avancée majeure pour le web sémantique, et particulièrement pour la réalisation de projets exploitant les standards du Linked Data en entreprise. En effet, les technologies R2RML et Direct Mapping supportées par db2triples fournissent une réponse standardisée à la problématique de transformation des données relationnelles en graphes RDF pour le chargement automatique d’entrepôts.

Ainsi db2triples s’avère particulièrement intéressant dans le cadre de projet Open Data ou Linked Data nécessitant la publication dans le web des données d’informations vivantes, bien plus facilement réexploitables que la mise en ligne de fichiers Excel ou PDF dont la réutilisation automatique est complexe, voire impossible.

Mise à jour le 24 juillet 2012 : db2triples est pleinement compatible avec le Working Draft du 29 mai 2012 des recommandations R2RML et DirectMapping : en effet, db2triples a passé avec succès les tests de conformité édictés par le groupe de travail RDB2RDF du W3C. Du coup ce composant logiciel, fourni en Open Source, figure dans la liste des implémentations validées  par l’organisme international de normalisation du web. Plus d’information dans notre communiqué de presse diffusé ce jour, en français et en anglais.

Documation 2012 : AFS@Enterprise et Linked Enterprise Data

Linked Enterprise Data

Retrouvez-nous mercredi 21 et jeudi 22 mars sur le salon Documation 2012, stand E16 : vous y découvrirez AFS@Enterprise et le Linked Enterprise Data.

Et si vous ne pouvez pas venir à Documation mais souhaitez en savoir plus sur le Linked Enterprise Data, dites-le nous ici :

[contact-form subject= »Demande depuis le blog Antidot » to= »[email protected] »] [contact-field label= »Nom » type= »name » required= »true » /] [contact-field label= »Société ou Organisation » type= »text » required= »true » /] [contact-field label= »E-mail » type= »email » required= »true » /] [contact-field label= »Site web » type= »url » /] [contact-field label= »Précisez votre demande » type= »textarea » required= »true » /] [/contact-form]