Un serveur central héberge la partie serveur de l'application :
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 :
Avec une technologie en base de données classique il aurait fallu gérer :
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 :
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é). |
Technique‎ > ‎