Technique‎ > ‎

Architecture Technique d'ensemble

Un serveur central héberge la partie serveur de l'application :
  • ce n'est pas un simple serveur Web mais un ensemble gérant à la fois le service Web, la logique serveur de l'application et l'accès à un "DataStore" où sont stockées les données. Il utilise la technologie Google AppEngine (Java) et est hébergé sur des serveurs de Google. L'application bénéficie de ressources partagées, non dédiées à l'application, et est totalement gérée sans action de notre part ;

  • le DataStore est lié à la même technologie : ce n'est pas une base de données relationnelle "classique" : aucune ressouce n'est spécifique à l'application, la gestion de sécurité, relance, etc. et son administration sont assurées par l'hébergeur sur des ressources globales communes aux applications qu'il héberge ;

  • une page Web annexe en PHP hébergée sur un de nos sites (1&1) ne sert qu'à transférer des e-mails calculés par le serveur d'application vers les mailers utilisés par alterconsos (gandi.net et 1and1 pour l'instant).
La partie "interface utilisateur" de l'application est écrite en HTML5 / Javascript et s'exécute sous tous les navigateurs (pas trop anciens), sur tous les types de postes supportant du Web (PCs, Macs, smartphones, tablettes).


Justifications des choix techniques

Google AppEngine pour le serveur central
Il y a plusieurs composants techniques dans une infrastructure de serveur et le premier critère de choix a été l'absence totale d'administration quotidienne. Sécurité, archivage, arrêt, relance etc. ces tâches sont automatiquement gérées par cet environnement. Le nombre de serveurs effectifs actifs varie de 0 à N (mais N = 1 au vu de la charge d'alterconsos) et jamais nous n'avons à intervenir pour surveiller, relancer, bref administrer ces serveurs ... situation idéale pour des bénévoles n'ayant pas d'équipe technique à disposition pour faire ça.
Les autres environnements sur le marché n'offrent pas ce type de "non administration" et habituellement il faut a minima gérer un serveur d'application ET une base de données.

Gratuité en raison de la faible charge de calcul
Sur les environnements classiques sur le nuage, il y a toujours un minimum de perception de l'hébergeur, même en cas de traffic nul ou faible, puisque des ressources sont réservées pour chaque application.
La technologie AppEngine ne déclenche de facturation qu'au delà d'un certain niveau de consommation de ressources. Ceci est possible parce qu'aucune ressource technique dédiée n'est mobilisée, l'effort "commercial" de Google ne lui coûte rien, bien moins qu'un compte e-mail.
Pour l'instant notre consommation est loin des quotas déclenchant une facturation, sauf sur un point : l'envoi d'e-mail est payant dès que le nombre d'adresses dépasse 100 (en tout), ce qui est notre cas. C'est la raison pour laquelle l'envoi d'e-mails est sous-traitée à une simple page en PHP sur un autre serveur d'un autre hébergeur (1&1) ... d'un de nos comptes. Bref pour l'application Alterconsos c'est gratuit.
Il n'aurait pas été scandaleux ni coûteux de payer a minima notre hébergement : en phase de prototype c'était toutefois un souci (carte bancaire, etc.).
Cette option commerciale permet à Google d'intéresser les développeurs à réaliser des prototypes facilement en entreprise et en particulier offre aux startups la possibilité de monter des services applicatifs sans faire d'avance de fond d'infrastructure : quand les projets deviennent opérationnels à plus grand échelle, la facturation est dans l'ordre de grandeur du marché. Quand les projets personnels, associatifs ou d'intérêt local restent modestes, ils n'atteignent jamais le seuil de facturation ... mais ne consomment pas grand chose et restent une charge marginale.
Le code développé correspond à environ 15000 lignes de Java pour moitié peu trivial. Le code est assez sûr : le Java est un langage très contrôlé, les classes un peu délicates n'évoluent pas ou peu, celles de logique applicative sont beaucoup plus simples et leur test ne présente pas de difficulté ni de combinatoire trop importante.


Le DataStore 
Il s'utilise depuis AppEngine.
Les très grandes applications d'aujourd'hui utilisent des stockages de données qui ne sont plus des bases de données relationnelles classiques en raison de leur volume mais aussi parce qu'il y est impossible d'y gérer une description de schéma de données : ces stockages sont des "bases sans schéma".
Certes le volume de données utilisé pour l'application alterconosos est ridicule : l'absence de schéma est toutefois un avantage décisif :
  • l'application peut évoluer au cours du temps sans jamais avoir à subir de reconstruction ;
  • elle est plus simple à écrire et les programmes par la force des choses sont toujours en phase avec la structure des données ;
  • les données sont stockées sur plusieurs lieux différents : le DataStore résiste aux défaillances et destructions temporaires (ou non) de sites ;
  • c'est l'hébergeur qui gère tout ça sans intervention de notre part. En fait celà fait partie de son infrastructure à lui pour d'autres besoins, le DataStore de AppEngine venant profiter d'investissements faits pour leur coeur de métier.
La disponibilité annoncée correspond à moins d'un quart d'heure d'indisponibilité par an : difficile à vérifier mais plausible.
Avec une technologie en base de données classique il aurait fallu gérer :
  • l'arrêt, relance, changement de palier technique du SGBD ;
  • l'évolution des schémas et leur test souvent en interrompant l'application ;
  • la migration des données d'une structure à une autre autre ;
  • la sauvegarde périodique et la restauration éventuelles des données à distance.
Bref ceci requiert une surveillance et une administration continue qui n'est guère la bienvenue pour des bénévoles qui ne sont pas payés pour assurer cette tâche sans intérêt.


La page "serveur de mail" hébergée chez 1&1
Le code représente 100 lignes de PHP et est probablement fiable ... parce qu'il n'y a presque rien dedans.
Dans le serveur d'application il a été développé une alerte e-mail par le serveur AppEngine qui envoie un mail à l'administrateur de l'application quand la page du serveur de mails n'est pas accessible (ce mail d'alerte NE PASSE PAS lui-même par le serveur de mail ... puisqu'il sert à indiquer que l'autre est justement HS !).
En gros ça marche. En cas de défaillance il faut relancer le lendemain et les mails hebdomadaires ont quelques heures de retard.
A noter que ce n'est pas parce que mailer a accepté d'envoyer un mail que celui-ci arrivera à destination ! Il s'en coince beaucoup dans les tuyaux et on le sait pas toujours.
De manière générale l'envoi plus ou moins massifs de mail est un service compliqué, très sécurisé et surveillé, assuré par des prestataires non gratuits et dans tous les cas un peu difficile à administrer.


L'application qui tourne dans le navigateur
C'est une application HTML5 / CSS-3 écrite en Javascript. Le code HTML des vues est généré à la volée par le Javascript et utilise aujourd'hui la bibliothèque JQuery (mais sa dépendance en est assez faible).
C'est du standard standard !
Le code représente 15000 lignes de Javascript (plus 7000 écrites et remplacées).
Le code contient probablement pas mal de bugs car c'est difficile à tester :
  • les navigateurs supportés ne réagissent pas exactement de la même façon et souvent encore différemment selon leur propre version ;
  • ça tourne sous des OS différents, plusieurs Windows, plusieurs MacOS, des Linux, des iOs et des Androïd d'âges variés : autant de raisons d'obtenir des rendus différents. Difficile de savoir d'avance ce qui va poser problème où ;
  • le Javascript est un langage hyper tolérant à l'écriture ... mais il réserve les erreurs pour l'exécution et sans permettre de se prémunir contre l'explosion de la combinatoire. Les régressions sont nombreuses, corriger du code quelque part génère facilement un problème ailleurs sans qu'on puisse facilement le détecter avant exécution ni l'anticiper ;
  • l'interactivité est par nature difficile à tester : il est impossible d'anticiper ce sur quoi va décider un utilisateur de cliquer, l'ordre, la vitesse et la fréquence des actions est imprévisible ;
  • le code est dépendant de l'ordre dans lequel les événements arrivent : telle séquence qui marche bien sur un poste rapide peut boguer sur un lent parce que la séquence d'arrivée des événements n'est pas celle imaginée et testée.
Heureusement les bugs (plus fréquents) de l'application d'interface n'ont quasiment jamais d'impact sur la consistence des données enregistrées alors que les bugs se produisant sur la partie serveur peuvent dégrader la qualité des données mais sont des bugs très rares.


Conclusions
L'effort de développement global a représenté environ 300 jours temps plein pour la version V1 prototype et environ 50 pour la version V2 de l'interface : ça peut sembler beaucoup mais quand on se livre à des estimations du temps bénévole passé par les Alterconsos et du non bénévole passés par les producteurs sur la seule activité de distribution en circuit court on tombe sur des chiffres annuels très supérieurs.

Le choix des hébergeurs n'est pas libre car tous n'offrent pas la même nature de service : en réalité on choisit une technologie de développement et parfois LE prestataire qui l'offre.
Des technologies plus anciennes sont certes proposées par plusieurs prestataires mais elles exigent un effort au fil de l'eau de surveillance et d'administration et un effort de développement supérieur, soit un degré de masochisme supérieur : de plus ces offres sont toujours payantes, même pour un taux d'utilisation limité. Les offres n'ayant pas ces contraintes ne sont pour l'instant disponibles que chez de très grands acteurs (Google, Amazon) et en général payantes. Un prestatiare fraçais offrira-t-il un jour des services voisins ? Peut-être que oui mais ça ne s'annonce pas à court terme, peut-être que non comme beaucoup de prestations high-tech.

Qu'en est-il de la sécurité vis à vis des écoutes ?
Il n'y a pas que la NSA pour écouter le traffic. Tous ceux qui ont un provider de compte e-mail gratuit ont signé dans des conditions de vente que le provider en question peut s'en servir à des fins de recueil d'information. Et ces informations c'est chacun qui les donne en clair dans nos mails et qui alimentons le business de ces offres "gratuites".
Les données stockées dans la DataStore ne sont pas lues par l'hébergeur : il s'y engage, non par grandeur d'âme mais en raison de l'impossibilité de les exploiter par des robots. Elles sont en binaire et leur signification ésotérique. L'effort requis pour les interpréter serait un travail humain au cas par cas qui n'aurait aucune rentabilté. Non la NSA n'écoute probablement vos variations de commandes de saucissions.
Par prudence toutefois vos mots de passe ne sont pas stockés en clair, de sorte que les administrateurs de l'application ne puissent pas les lire (ils n'ont pas les moyens de la NSA pour les casser ... à supposer qu'elle-même sache casser un SHA-1 ce qui est peu probable). Lire aussi Mots de passe, clés d'accès en un clic.

Le code souce est libre sous license GNU GPL V3 (quant à savoir ce qui différencie cette licence des autres). Voir la rubique Contact et demander à Daniel Sportès les URLS des repository où les sources sont archivés ainsi que celles des quelques notes techniques d'administration et de design (ou chercher les vous-mêmes sur le Web, ce n'est pas caché).