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.

bat-recrutement

Le processus de recrutement dans les équipes de R&D d’Antidot

Le recrutement est un processus difficile dans lequel il n’existe pas vraiment de méthode scientifique ou de recette à suivre pour être sûr de ne pas se tromper. Il est pourtant important que nous puissions déterminer si vous pourrez relever les défis qui vous seront proposés une fois formé à nos outils.

De son côté, le candidat cherche souvent des réponses à des questions telles que :

  • Le poste qu’on vous propose est il à la hauteur de ses attentes ?
  • L’environnement de travail proposé et ses futurs collègues forment-ils un écosystème riche dans lequel il va à la fois pouvoir partager ses connaissances et en développer de nouvelles ?

Depuis plus de 15 ans les équipes d’Antidot peaufinent le processus de recrutement afin d’être capables d’avoir une intime conviction sur l’adéquation de chaque candidat aux postes proposés. En cas de doute, nous préférons écarter une bonne candidature, plutôt que de proposer un poste à quelqu’un en risquant d’aboutir à un échec en début de collaboration. Nous refusons d’attendre la période d’essai pour vérifier les compétences de nos nouveaux employés.

Les collaborateurs d’Antidot travaillent tous en confiance avec beaucoup d’autonomie et de responsabilités. Quand nous faisons une offre à quelqu’un, c’est que nous pensons que toutes les conditions sont remplies pour que la collaboration se passe bien.

Pour cela, lors du processus de recrutement, nous vous ferons échanger avec le plus de personnes possibles (futurs collègues et responsables) dans une grande variété de contextes afin de tenter d’établir une cartographie à 360° de votre profil. Réciproquement vous aurez une vision claire du poste à pourvoir et de nos méthodes de travail.

Si vous postulez à un poste dans la R&D d’Antidot, vous suivrez ce parcours avec nous. Si vous franchissez toutes les étapes nous aurons le plaisir de vous faire une offre de collaboration.

Sélection préliminaire

Dès réception de votre dossier, le manager en charge du recrutement, assisté éventuellement d’autres collaborateurs, fait une première étude de votre lettre de motivation et de votre CV.

Nous cherchons dans cette étape à vérifier que vous êtes intéressé, voire passionné, par les postes que nous proposons. Nous cherchons moins à vérifier que vous maitrisez toutes les technologies attendues qu’à nous assurer que vous avez une bonne culture du domaine, l’envie d’apprendre et de travailler avec nous pendant le plus longtemps possible.

Un dossier clair, synthétique et bien rédigé constitue un atout lors de cette étape.

Si le manager détecte du potentiel dans votre candidature, il vous contacte pour planifier un premier entretien téléphonique.

Entretien téléphonique

Un premier contact, d’une durée d’environ 30 minutes, est mené par le futur responsable hiérarchique direct du candidat, parfois accompagné d’un expert du métier (développeur web, rédacteur technique, ingénieur système…).

C’est l’occasion pour vous d’en savoir plus sur Antidot et le poste à pourvoir ; n’hésitez pas à poser des questions.

Les éléments recherchés lors de cette étape sont :

  • Esprit de synthèse
  • Clarté de l’expression
  • Bonne connaissance des éléments présentés dans le dossier de candidature
  • Intérêt pour le poste et le domaine d’activité

Il arrive qu’un entretien ne suffise pas à évaluer précisément votre candidature ; dans ce cas un second entretien avec d’autres interlocuteurs vous est rapidement proposé.

Si nous pensons que votre candidature présente suffisamment de points forts, nous vous convoquerons pour une journée de tests et d’entretiens.

Journée de tests et d’entretiens

Cette journée a lieu sur site, dans nos locaux de Lambesc, à proximité d’Aix en Provence.

L’objectif de cette étape est de vous faire rencontrer un maximum de personnes et de vous confronter à des tests représentatifs du travail quotidien qui vous attend si vous travaillez chez nous. Après l’accueil autour d’un café de bienvenue, les tests commencent :

  • Si vous postulez pour un poste de développeur, vous coderez sous la supervision de nos ingénieurs expérimentés dans un ou plusieurs langages mis en avant dans votre CV.
  • Si vous candidatez à un poste d’Ingénieur système, vous aurez à résoudre des problématiques représentatives de la production.
  • Si vous êtes rédacteur technique, vous produirez des documents structurés …

La journée sera interrompue à quelques occasions :

  • Antidot vous invitera à partager un repas avec vos futurs collègues. Vous pourrez alors faire plus ample connaissance et discuter de sujets en rapport avec le poste … ou de tout autre chose : vos passions, vos hobbies…
  • L’entretien d’équipe où vous rencontrerez les membres de votre future équipe.
  • Les entretiens avec vos futurs managers.

A l’issue de cette journée nous ferons ensemble un point sur votre candidature, le résultat des tests, votre perception d’Antidot et notre retour sur votre prestation. Ce dernier entretien sera l’occasion d’aborder les modalités pratiques de collaboration. Vous pourrez également aborder tout point que vous souhaiteriez détailler.

L’objectif de la journée est d’apporter des réponses aux questions suivantes:

  • Maîtrisez vous les éléments technologiques mis en avant dans votre dossier ?
  • Avez vous la capacité d’apprendre, d’échanger avec nos équipes ?
  • Que faites vous quand vous ne savez pas résoudre un problème ?
  • Que faites vous quand nous vous suggérons une approche alternative ?
  • Votre personnalité vous permettra-t-elle de vous intégrer au sein de nos équipes ?

De votre côté, après avoir travaillé au sein de nos équipes pendant une journée entière, vous aurez une bonne idée du travail quotidien chez Antidot, des relations entre les collaborateurs. Désormais informé précisément du poste à pourvoir, vous pourrez ainsi valider votre envie de relever avec nous les défis quotidiens inhérents à la production de logiciels de qualité.

Épilogue

Quelques jours après cette journée de tests, nous reviendrons vers vous.

Si tout s’est bien déroulé nous vous ferons une offre de collaboration. Nous espèrerons alors que, séduit par notre culture et par le poste, vous l’accepterez. Ce qui permettra à Antidot de compter un collaborateur passionné de plus !

equipe-levier