Après plusieurs mois de développement et un retard à l’allumage, la nouvelle architecture est désormais en production sur tous les comptes depuis quelques jours

Ce billet ne rentrera pas dans les détails techniques de cette nouvelle architecture, pour la simple et bonne raison que j’ai donné une conférence abordant largement le sujet aux DjangoCong. Cette dernière sera disponible sous peu en vidéo – nous l’annoncerons sur le blog – et permettra alors aux curieux d’en savoir plus sur l’envers du décor.

Concrètement, cette architecture ajoute une souplesse qui va nous permettre, au fil des semaines et des mois prochains, de considérablement étoffer les fonctionnalités que nous proposons. Dans un premier temps, vous bénéficiez déjà d’un ajout important : vous avez désormais accès aux logs d’erreur et d’accès en temps réel. Deux fichiers, error.log et access.log, sont accessibles dans ~/admin/log/.

Si les logs d’accès sont un petit bonus, les logs d’erreur sont en revanche une avancée considérable : vous pourrez désormais savoir plus précisément pourquoi votre application ne démarre pas, sans avoir à nous solliciter (mais nous restons bien entendu à votre disposition, cela ne change évidemment pas).

Mais le meilleur reste à venir, et les vraies nouveautés arriveront progressivement. Le support du SSL, par exemple, qui est déjà disponible en beta (ceux qui en ont un besoin urgent peuvent nous contacter). Le support de nouvelles technologies, également (WSGI, Passenger, langages exotiques comme Erlang ou OCaml, etc.).

Nous avons profité du passage à cette nouvelle architecture pour mettre à jour le serveur HTTP principal. Cela signifie de meilleures performances, mais aussi la suppression du redémarrage régulier de vos applications, ce qui entrainait un temps de latence désagréable au premier accès.

Dernière évolution récente, sans rapport avec la nouvelle architecture HTTP : les mails sont désormais stockés sur un serveur à part, autonome. Cela veut dire qu’il y a une totale étanchéité entre nos services HTTP et mail : si un serveur HTTP devait avoir un souci, cela n’impacterait plus les mails comme c’était le cas jusqu’à présent. Par ailleurs, les lenteurs qui pouvaient être visibles en IMAP devraient être éliminées.

Ces évolutions sont un véritable tournant dans l’histoire (technique) d’alwaysdata. Nous avons commencé à y réfléchir dès 2008, et le développement a mobilisé toutes nos ressources au cours des derniers mois. Maintenant que cela est derrière nous, nous allons vraiment pouvoir vous (et nous) régaler avec des fonctionnalités concrètes.

Un grand merci, enfin, à tous ceux qui nous ont aidés : en participant au beta-test, en remontant des bugs parfois obscurs, ou tout simplement en se montant patients et confiants. Champagne¹ !

¹ avec modération.