- Zusammenfassung eines Interviews mit Roberta Arcoverde, Director of Engineering bei Stack Overflow, aus Scott Hanselmans Podcast
- Sie ist vor 8 Jahren als Softwareingenieurin eingestiegen, wurde Staff Engineer (Tech Lead) und ist Anfang dieses Jahres in eine Managementrolle gewechselt
S: Was hat sich verändert, seit Sie Director of Engineering sind?
- R: Ich manage jetzt Menschen. Ich kümmere mich um ihre Laufbahnen und helfe ihnen beim Wachstum. Außerdem habe ich eine strategische Vision dafür, wohin wir gehen sollten.
Ich schaue mir auch die Softwarearchitektur an und achte kontinuierlich darauf, ob wir uns in eine Richtung bewegen, die Wachstum ermöglicht – also nicht nur im Hinblick auf diesen PR, sondern darauf, ob er uns dorthin bringt, wo wir in den nächsten 3 Jahren sein wollen.
- S: Sie planen und handeln also stärker langfristig, damit technologische Veränderungen Sie nicht überraschen.
- R: Genau. Und ich führe viel mehr 1-on-1-Gespräche.
- S: Bei uns bei Microsoft ist auch gerade Review-Saison, deshalb habe ich tagelang nur 1-on-1s und Bewertungen. Es ist nicht besonders spannend, ständig nur in Meetings zu sein – schauen Sie sich zur Abwechslung auch mal Code an?
- R: Ja, ich schaue mir Code an. Ich bin fest davon überzeugt, dass auch Frontline-Manager wie ich jeden Tag Code schreiben sollten. Ich glaube, das hilft mir persönlich dabei, technisch fit zu bleiben.
Das hilft auch beim Mentoring von Junior Engineers und dabei, die Auswirkungen von Änderungen zu bewerten, die Senior Engineers vorschlagen.
Wenn man weiterhin Code schreibt und verfolgt, wohin sich die Software entwickelt, kann man auch bei größeren Redesigns die „richtigen Fragen“ stellen, damit das Team zum bestmöglichen Ergebnis kommt.
S: Wie sieht die Architektur von Stack Overflow aus?
- R: Stack Overflow ist etwas ungewöhnlich, besonders im Vergleich zu anderen großen Sites, die 2008 gestartet sind.
- Wir haben heute eine 14 Jahre alte Codebasis,
- und wir betreiben sie in unserem eigenen Rechenzentrum auf On-Prem-Maschinen.
- Wir sind nie in die Cloud gegangen.
- Es ist außerdem eine monolithische Anwendung. Wir haben sie nicht in Services oder Microservices aufgeteilt.
- Wir haben auch eine mandantenfähige Web-App. Sie basiert auf .NET und läuft als einzelne App auf 9 Webservern.
- Sie läuft auf IIS, und ein einzelner Server verarbeitet 6.000 Requests pro Sekunde. (2 Milliarden PV pro Monat)
- S: Mit dem Aufstieg von Apache, NGINX und Kubernetes sind viele IIS-Installationen verschwunden. Sie hätten auch in diese Richtung gehen können – gibt es Dinge, die Sie bewusst ignoriert haben? Und was haben Sie als etwas betrachtet, das Stack Overflow wirklich braucht?
- R: Vieles davon haben wir ignoriert. Am jüngsten betrifft das alles rund um Microservices und Kubernetes.
Der wichtigste Grund dafür ist eine der stärksten Entwicklungsphilosophien bei Stack Overflow.
Wir beginnen immer mit der Frage: „Welches Problem versuchen wir zu lösen?“
Die Tools dieser Art lösen keine Probleme, mit denen wir tatsächlich konfrontiert sind.
Zum Beispiel dient die Migration von einem Monolithen zu Microservices oder Services oft dazu, Teams aufzuspalten und besser skalieren zu können.
So können mehrere Teams am selben Projekt arbeiten, ohne sich gegenseitig zu behindern, und schneller deployen.
Schnelles Deployen war für uns aber nie ein Problem. Stack Overflow wird mehrmals täglich in 4 Minuten deployt, und falls es Probleme gibt, können wir in wenigen Minuten wieder zurückrollen.
Unsere aktuelle Lead Time bzw. die Zeit bis zum Merge ist hervorragend und kein schmerzhafter Prozess.
Etwa 50 Engineers entwickeln derzeit an der Q&A-Plattform.
- R: 2014 waren es 10, und damals war es leicht, dass alle die gesamte Codebasis verstanden.
Inzwischen wird das Onboarding neuer Engineers zwar schwieriger.
Irgendwann könnten wir bestimmte Module abtrennen, sodass dedizierte Teams sie betreuen und nicht mehr den gesamten Code verstehen müssen.
Aber so weit sind wir noch nicht. Dieses Problem haben wir noch nicht, und wir sind Pragmatiker.
Weitere Architekturdetails
- Cache mit 2 Ebenen (Arbeitsspeicher und Webserver)
- Außerdem mehrere SQL-Server: Mit 1,5 TB RAM kann auf ein Drittel der gesamten Datenbank schnell direkt im Speicher zugegriffen werden
→ Ich denke, das ist eine sehr teure Konfiguration, die sich in der Cloud nur schwer günstig betreiben ließe
- Die Fragenseite wird nicht gecacht. Sie hat zwar die höchste Trefferquote und zieht 80 % des Traffics an, aber...
→ Früher wurde versucht, sie mit Redis zu cachen, doch die Hit/Miss-Cache-Rate war nicht besonders gut
- Die aktuelle Seiten-Renderzeit liegt bei etwa 20 ms
- StackExchange wird ebenfalls mandantenfähig auf denselben Servern betrieben. Eine einzige Anwendung bedient alle 200 Sites
→ Das heißt, ein einziges Deployment gilt sofort für alle
- Rolling Builds unter HAProxy
7 Kommentare
Oh, oh … Der Teil, dass sie mit
haproxyRolling Builds machen, ist beeindruckend; ich frage mich, wie sie das umsetzen.Ich habe das Podcast-Skript gelesen, und der Teil zur Nutzung von haproxy wird nur kurz erwähnt und wirkt eher so, als würde man einfach darüber hinweggehen. Da das Gespräch dann zu Health Checks und umfangreichem Monitoring übergeht, scheint es wohl so zu sein, dass sie das selbst gut aufgebaut haben … ungefähr so, denke ich ^^;
Ich frage mich, wie man „Deployment in 4 Minuten“ umsetzt.
Ich habe bei meinem früheren Unternehmen auch Server mit 4 TB RAM und 8 TB RAM betrieben. Die Aufbaukosten waren natürlich enorm, aber ich hatte eindeutig nicht den Eindruck, dass sich diese Spezifikationen einfach durch die Cloud ersetzen ließen.
Das dürfte wohl so sein.
Danke für die Zusammenfassung.
Es gibt viele beeindruckende Punkte.
Es ist ein ziemlich langes Interview, daher habe ich zwischendurch immer wieder Zusammenfassungen eingefügt. Hören Sie sich die gesamte Folge an und nutzen Sie dabei das Skript als Referenz!
Skript: https://app.podscribe.ai/episode/83433649