- Résumé de l’interview de Roberta Arcoverde, directrice de l’ingénierie chez Stack Overflow, dans le podcast de Scott Hanselman
- Entrée il y a 8 ans comme software engineer, devenue staff engineer (tech lead), puis réorientée vers un poste de management au début de cette année
S : Qu’est-ce qui a changé en devenant directrice de l’ingénierie ?
- R : Je gère désormais des personnes. Je gère les carrières, j’aide les gens à progresser. J’ai aussi une vision stratégique de la direction à prendre
Je veille en continu à l’architecture logicielle, à vérifier qu’elle évolue dans le bon sens pour la croissance, et que ce PR nous rapproche de l’endroit où nous voulons être dans 3 ans, pas seulement de l’objectif immédiat
- S : Donc vous planifiez et agissez avec une perspective plus long terme, pour ne pas être prise au dépourvu par les évolutions technologiques.
- R : Exactement. Et je fais aussi davantage de réunions en 1:1.
- S : Chez Microsoft aussi, c’est la saison des évaluations en ce moment, donc pendant quelques jours, on enchaîne les 1:1 et les reviews. À force de ne faire que des réunions, ça devient lassant ; pour vous changer les idées, vous allez encore regarder du code ?
- R : Oui, je regarde du code. Je crois fermement que même un manager de proximité comme moi devrait écrire du code chaque jour. Je pense que ça aide personnellement à rester techniquement à niveau.
Cela aide aussi à mentor-er les ingénieurs juniors, et à évaluer l’impact des changements proposés par les ingénieurs seniors.
En continuant à écrire du code et à voir vers quoi le logiciel évolue, on peut poser les bonnes questions pour les aider à obtenir le meilleur résultat lorsqu’il y a une grande refonte.
S : À quoi ressemble l’architecture de Stack Overflow ?
- R : Stack Overflow est un peu atypique, surtout comparé à d’autres grands sites lancés en 2008.
- Nous avons aujourd’hui une base de code vieille de 14 ans,
- nous tournons dans notre propre datacenter sur des machines on-prem.
- Nous ne sommes jamais passés au cloud.
- C’est aussi une application monolithique. Nous ne l’avons pas découpée en services ou en microservices.
- Nous avons aussi une web app multitenant. Basée sur .NET, elle tourne comme une application unique sur 9 serveurs web.
- Elle fonctionne sur IIS, et un seul serveur traite 6 000 requêtes par seconde. (2 milliards de pages vues par mois)
- S : Beaucoup d’instances IIS ont disparu avec la montée d’Apache, de NGINX, de Kubernetes, etc. Vous auriez pu aller dans cette direction ; y a-t-il des choses que vous avez volontairement ignorées ? Et au contraire, des choses dont vous vous êtes dit : ça, il nous le faut pour SO ?
- R : Nous avons ignoré beaucoup de ces tendances. Les plus récentes concernent tout ce qui touche aux microservices et à Kubernetes.
La principale raison est la philosophie de développement la plus forte chez SO.
Nous commençons toujours par cette question : « Quel problème essayons-nous de résoudre ? »
Les problèmes que ces outils cherchent à résoudre ne correspondent pas à ceux que nous rencontrons.
Par exemple, migrer d’un monolithe vers des microservices ou des services, c’est souvent pour pouvoir faire évoluer l’organisation en divisant les équipes.
Cela permet à plusieurs équipes de travailler sur le même projet sans se bloquer mutuellement, et de déployer rapidement, entre autres.
Le déploiement rapide n’a jamais été un problème pour nous. SO déploie plusieurs fois par jour, en 4 minutes, et s’il y a un problème, on peut revenir en arrière rapidement en quelques minutes.
Aujourd’hui, notre lead time ou le temps nécessaire pour merger sont excellents, et ce n’est pas douloureux.
Environ 50 ingénieurs développent la plateforme de Q&A
- R : En 2014, ils n’étaient que 10, et il était facile pour tout le monde de comprendre l’ensemble de la base de code.
Aujourd’hui, l’onboarding des nouveaux ingénieurs devient plus difficile.
Un jour, nous pourrions finir par extraire certains modules, avec des équipes dédiées qui les prennent en charge sans avoir à comprendre tout le code.
Mais nous n’en sommes pas encore là. Nous ne rencontrons pas encore ce problème, et nous sommes pragmatiques.
Autres éléments d’architecture
- Cache à 2 niveaux (mémoire et serveur web)
- Plusieurs SQL Server également : avec 1,5 To de RAM, un tiers de toute la base de données est accessible rapidement en mémoire
→ Cela semble être une configuration très coûteuse, difficile à obtenir à bon prix dans le cloud
- La page des questions n’est pas mise en cache. C’est pourtant celle qui a le plus fort taux de consultation, avec 80 % du trafic qui y va, mais…
→ Ils avaient autrefois essayé de la mettre en cache avec Redis, mais le taux de hit/miss n’était pas très bon
- Le temps de rendu d’une page est actuellement d’environ 20 ms
- StackExchange fonctionne lui aussi en multitenant sur les mêmes serveurs. Une seule application gère les 200 sites
→ Autrement dit, un seul déploiement d’application s’applique à l’ensemble
- Rolling build sous HAProxy
7 commentaires
Oh oh…. La partie sur le rolling build avec
haproxyest impressionnante, mais je me demande comment c’est implémenté.J’ai lu la transcription du podcast, et j’ai l’impression que la partie utilisant
haproxyest évoquée très brièvement avant de passer à autre chose. Vu que la discussion enchaîne surtout sur les health checks et le fait qu’ils fassent beaucoup de monitoring, j’ai l’impression qu’ils ont simplement bien construit leur propre solution… ^^;Je me demande comment ils font pour déployer « en 4 minutes ».
Moi aussi, dans mon entreprise précédente, j’ai exploité des serveurs avec 4 To et 8 To de RAM ; le coût de mise en place était bien sûr énorme, mais je n’ai vraiment jamais eu l’impression qu’on pourrait remplacer ce type de configuration par le cloud.
C’est vrai, sans doute.
Merci pour le résumé.
Il y a beaucoup d’aspects impressionnants.
L’interview est assez longue, donc je l’ai résumée par endroits. Écoutez l’intégralité en vous référant à la transcription !
Transcription : https://app.podscribe.ai/episode/83433649