2008 : beaucoup de mouvement, très peu de certitudes

Difficile de savoir par quel bout prendre ce bilan. Je termine 2008 à Jacksonville, en Floride, après avoir commencé l’année au Québec chez Fujitsu. Après près de trois ans comme architecte-développeur, je viens d’arriver chez Taleo comme chef d’équipe. Je garde cette transition au niveau que je connais réellement : j’écoute, j’apprends les repères et je regarde comment le travail passe d’une personne à l’autre.

Les technologies de l’année peuvent être reliées par un même pipeline :

entrée mobile -> service Web -> logique multi-client -> base de données
                         |-> file de travail -> traitement CPU ou GPU
                         `-> logs, sauvegarde et surveillance

L’App Store a ouvert en juillet et le premier téléphone Android est arrivé à l’automne. Le téléphone devient un client logiciel qui peut disparaître du réseau ou voir son processus arrêté. Une opération mobile doit donc conserver son état, gérer un timeout et reconnaître une soumission répétée. Le serveur ne peut pas traiter chaque reconnexion comme une nouvelle commande.

Le SaaS place ensuite plusieurs organisations derrière la même version. Chaque requête doit établir le client à partir de l’identité, puis appliquer cette frontière dans les données, les files et les logs. La rapidité de livraison n’a aucune valeur si une requête sans tenant_id montre les données voisines.

Un exercice d’architecture pour 2009

Pour une fonction d’export, je dessinerais le trajet complet :

  1. le client demande l’export et reçoit un identifiant;
  2. l’application valide l’organisation et écrit une tâche dans une file;
  3. un worker lit les données de ce client seulement;
  4. il produit le fichier dans un stockage séparé;
  5. la surveillance mesure l’âge de la tâche;
  6. un lien temporaire permet au bon client de récupérer le résultat;
  7. une politique supprime le fichier après la période prévue.

Une panne du worker remet la tâche dans la file. Un identifiant d’opération évite deux exports. Un test tente l’identifiant avec un autre client. La sauvegarde protège les données sources; le fichier dérivé peut souvent être reconstruit. Ce petit scénario rassemble beaucoup plus de décisions que le bouton Exporter.

Le cloud change le moment où la capacité est obtenue. EC2 et S3 permettent de louer calcul et objets, mais l’instance reste une machine qui peut disparaître. La configuration doit être reproductible, les données importantes sortir du disque local et les clés être protégées. La facture à l’heure demande un inventaire, sinon les expériences oubliées s’accumulent.

Le GPU montre enfin qu’un composant spécialisé peut accélérer un travail très régulier. Il faut compter les transferts de mémoire, la précision et le pire temps, pas seulement une pointe théorique. Les recommandations rappellent la même discipline côté données : un score n’est aussi bon que les événements, les biais et la rétention qui le produisent.

Avec l’économie qui serre, je veux pouvoir expliquer pour chaque fonction sa donnée, sa frontière de sécurité, son mode de panne et son coût de reprise. Ce n’est pas une grande méthode inventée après quelques semaines comme chef d’équipe. C’est une façon très concrète de ne pas laisser les dépendances entre le mobile, le service et les opérations tomber entre les chaises.