Gestion de cache et péremption des données

Je suis actuellement en train de travailler sur une couche d’abstraction de données (pour améliorer celle de mon framework afin de la rendre plus transparente). J’ai buté sur un problème assez classique, que je vais partager avec vous car cela pourrait vous intéresser. Ma couche d’accès aux données sert habituellement…

Lire la suite

Plus loin que la simplicité : la rusticité

J’ai déjà parlé du concept de simplicité sur ce blog. J’espère que tout le monde est convaincu des avantages que cela procure à tous les niveaux :

  • Une interface simple sera plus facile à comprendre et à utiliser ; elle sera plus ergonomique.
  • Un code simple sera plus facile à corriger et à faire évoluer ; il sera plus facile à maintenir.
  • Une procédure ou une méthode sera adoptée d’autant plus rapidement qu’elle sera simple à appréhender et facile à mémoriser.

Nous sommes d’accord, le «simple», c’est bien. Et comme d’habitude, c’est aussi le moment de dire que le «simpliste», ce n’est pas bien. Faire quelque chose de simpliste, c’est lorsqu’on recherche la simplicité aveugle ; quand on confond «en faire moins» avec «en faire le moins». Il faut parfois complexifier un peu un programme pour en simplifier l’ergonomie. Ou faire des concessions sur la simplicité d’une procédure si cela peut en augmenter l’efficacité.

Bref. Ce dont je veux vous parler aujourd’hui, c’est du concept de rusticité.

L’un des fondements du travail d’informaticien, c’est d’aimer la technologie, de se passionner pour l’avant-garde du high-tech, de chercher à connaître les technos du futur. C’est ainsi qu’on cherchera à mettre en œuvre des concepts ou des briques logicielles (ou matérielles) que nous ne maîtrisons pas forcément, pour le plaisir d’apprendre à les utiliser. Souvenez-vous ce que je disais sur la R&D : il ne faut pas confondre développement et veille technologique.

Sans aller jusqu’à faire de la recherche alors qu’on devrait faire du développement, on peut conduire nos choix en se laissant porter par des effets de mode. Quel est la techno «hype» du moment ? Quels sont les derniers «buzzwords» à connaître ?

En entreprise, les facteurs qui conduisent à un choix technologique sont multiples. La stabilité et la pérennité sont très importants. Ils le sont souvent plus que la performance ou le coût.
Ajoutez cela à la simplicité, et vous aboutissez à la «rusticité».

Une techno rustique, c’est quoi ?

Attention à ne pas comprendre de travers ce que j’essaye d’expliquer. Je ne suis pas en train de dire qu’il faut systématiquement utiliser des technologies antédiluviennes, au nom de leur rusticité. Moi je parle de “rusticité high-tech”, si je puis dire 🙂

Prenons un exemple au sujet des langages de programmation :

  1. Coder un site web en Fortran, ce n’est pas rustique, c’est débile. Votre site sera difficile à maintenir, vous aurez du mal à trouver des développeurs Web compétents dans ce langage, vous n’aurez aucun gain de performance par rapport à d’autres langages, et il vous manquera l’accès à un certain nombre de librairies très utiles.
  2. Par contre, une application de calcul scientifique distribuée sur un cluster pourra être codée en Fortran. C’est un choix très répandu : C’est un langage sans allocation dynamique, donc qui s’optimise très bien sur les architectures distribuées ; de nombreux scientifiques continuent à maintenir du code écrit en Fortran il y a 30 ans, sans avoir objectivement besoin de changer de langage ; réutiliser ce code est une bonne idée.

Un exemple concernant l’innovation fonctionnelle :

FineFS, système de fichiers redondé

J’ai lancé depuis quelques temps un projet dans mon entreprise, que nous venons de publier sous licence libre. Il s’agit d’un système de fichiers répliqué du nom de FineFS.

Je vais en parler ici parce qu’il s’agit d’un projet intéressant d’un point de vue technique, sur lequel les esprits imaginatifs peuvent venir s’éclater avec nous. Mais aussi parce qu’à travers ce projet, je veux vous présenter l’univers des systèmes répartis/distribués/redondés et des bases de données à très haute disponibilité – que tout directeur technique doit connaître un minimum.

Présentation du projet

Le but de ce projet est de faciliter la création de cluster-disque. Lorsque vous avez plusieurs serveurs qui doivent accéder aux mêmes fichiers, il est toujours délicat de mettre en place une architecture satisfaisante sans dépenser des sommes folles. Et pourtant, la moindre infrastructure Web présente plusieurs serveurs frontaux, qui doivent délivrer des contenus (images, vidéos, musiques) communs. Sans compter que ces différents serveurs doivent aussi pouvoir enregistrer de nouveaux fichiers, qui doivent être accessibles à toutes les autres machines.

Il existe plusieurs moyens de mettre des fichiers à dispositions de plusieurs serveurs :

  • Installer un NAS, c’est-à-dire un serveur de fichiers. Mais si ce serveur tombe en panne, plus aucun fichier n’est accessible.
  • Installer un SAN, qui prend souvent la forme d’une baie de stockage redondée. Mais les prix de ce genre d’installation grimpent très vite.
  • Utiliser un service externe, comme Amazon S3, qui prend en charge les aspects complexes de la gestion des fichiers. C’est souvent une solution satisfaisante pour du Web, mais qui peut induire des latences dans les accès aux fichiers, et des coûts inutiles.
  • Mettre en place un système de fichiers réparti, redondé et/ou distribué.

C’est dans cette dernière catégorie que se place FineFS. Il existe déjà des solutions qui s’emploient à résoudre ce besoin, qu’on peut répartir en 5 groupes :

Gestion de sources, versions de logiciels

Lorsqu’on développe un logiciel, il est absolument nécessaire d’utiliser un outil de gestion de sources. Évidemment, il serait possible de stocker ses fichiers dans un répertoire. Mais si vous voulez travailler sérieusement, vous aurez besoin de stocker les différentes versions de vos sources, pour suivre leur évolution au fil du temps ; et si vous travaillez à plusieurs sur le même projet, cela devient impossible.

Les logiciels de gestion de sources permettent à plusieurs personnes de travailler sur les mêmes fichiers, chacun dans leur coin, puis de tout rassembler pour obtenir une version continuellement à jour des sources. Ils apportent des fonctions permettant de définir des versions globales. Il existe un grand nombre de ces systèmes :

  • Les ancêtres RCS et CVS ont laissé la place à Subversion, qui offre des fonctionnalités supplémentaires bien appréciables. Ce sont des systèmes centralisés faciles à appréhender et à installer, et sont sous licence libre.
  • De nouveaux système sont apparus, basés sur un modèle décentralisé. Parmi ceux-ci, ont peut noter que les plus connus dans le monde de l’open-source sont Bazaar (sponsorisé par Canonical, à l’origine de la distribution Linux Ubuntu), Git (utilisé pour le noyau Linux) et Mercurial.
  • Du côté des logiciels propriétaires, les plus connus sont Visual SourceSafe de Microsoft et BitKeeper (qui a été utilisé pour le noyau Linux jusqu’en 2005).

Je vais vous présenter l’utilisation de ces outils, en utilisant l’exemple de Subversion (SVN en abrégé) car c’est le système de plus répandu et celui que j’utilise ; mais ces concepts sont toujours valables.

Principes généraux

Gestion basique

A la base, les sources d’un projet sont disponibles sur la branche principale (trunk). Les développeurs y récupèrent les sources (checkout) sur leur propre environnement de travail, et y ajoutent leurs versions modifiées (commit).

SVN - checkout - commit

Pas d’intégrisme technologique

J’ai rencontré trop souvent des situations où mes interlocuteurs prenaient leurs goûts personnels pour de grandes vérités technologiques. Cela m’aurait systématiquement amusé, si je n’avais pas vu trop de mauvais choix résulter de ce genre de comportement.

On a tous entendu ce genre de réflexions :

  • « PHP c’est juste bon pour faire des pages perso », venant d’un ingénieur JEE.
  • « Perl, c’est pour prototyper un logiciel avant de le coder pour de vrai », entendu chez un codeur C/Unix.
  • « DotNet, c’est une copie de Java, c’est forcément moins bien », d’un autre ingénieur JEE.
  • « MySQL ce n’est pas une base de données sérieuse », assuré par un DBA Oracle.
  • « Bah, pourquoi vous utilisez Linux ? », par un candidat à un stage habitué à Windows.
  • « Ubuntu, c’est nul, je préfère Debian », par un autre candidat.
  • « Avec la base de données et le serveur Web sur des machines différentes, on ralentit le site », par un développeur expérimenté.

On peut apporter des réponses intelligentes à toutes ces remarques :

  • Si Yahoo, Facebook et Wikipedia sont codés en PHP, c’est parce que ce sont des sites perso, hein ?
  • Pour la plupart des développements, le Perl est plus rapide à développer, avec des performances plus qu’acceptables.
  • Les développeurs qui prennent le temps de mettre le nez dans DotNet semblent dire que c’est une très bonne plate-forme.
  • Wikipedia utilise plusieurs bases MySQL, qui fonctionnent conjointement de manière très performante.
  • La vraie question est plutôt « Pourquoi utiliser Windows ? ».
  • Avec de l’Ubuntu Serveur sur les serveurs, et de l’Ubuntu Desktop sur les postes de développement, on s’assure d’avoir une plate-forme unifiée.
  • Vous imaginez que Google tourne sur une seule machine ?

Faire un choix structurant

Nous avons tous des préférences. Je me sens bien sous Linux, à coder en C et en PHP. C’est ce qui correspond à mes goûts et mes choix. Je peux l’expliquer de manière factuelle, mais il y a aussi des raisons inexplicables.

Prestation interne ou externe ?

Quand on doit choisir un outil informatique, l’une des questions que l’on doit se poser assez rapidement concerne le choix entre un outil interne à l’entreprise ou l’utilisation d’une prestation externe.

Quand je parle d’outil interne, je ne parle pas de développement réalisé en interne (même si ce cas existe bel et bien), mais des logiciels que l’on peut installer sur des machines propres à l’entreprise. Les prestations externes concernent les services qui sont disponibles à distance, souvent en SaaS (software as a service). Cela peut s’appliquer à un grand nombre de choses :

  • La gestion des emails. Votre entreprise doit-elle posséder son propre serveur SMTP, ou bien allez-vous passer par GMail/Hotmail/YahooMail ?
  • La gestion de document. Faut-il installer un serveur de fichiers interne, ou pouvez-vous vous reposer sur Google Doc/Zoho Docs ?
  • La gestion de projet. Est-il préférable d’utiliser une solution autonome, ou une plate-forme collaborative hébergée chez un prestataire ?

La prestation externe

L’utilisation d’un prestataire extérieur offre plusieurs aspects très pratiques :

  • Le service est disponible de partout (dans le cas de logiciels disponibles sur le Web). C’est très utile quand on a des collaborateurs disséminés géographiquement.
  • Le coût est limité. Les services d’email sont gratuits pour la plupart, et les offres logicielles payantes (gestion de projet, CRM, …) coûtent habituellement moins cher que la location d’un serveur.
  • La qualité du service est très bonne. Ces prestataires doivent gérer un très grand nombre d’utilisateurs, et mettent en place des architectures matérielles et logicielles prévues pour tenir la charge. Des équipes administrent ces services 24h/24, ce qui évite d’avoir à le faire soi-même.

L’installation interne

D’un autre côté, l’installation de logiciels en interne possède aussi de gros avantages :