- Scott Hanselman के podcast में Stack Overflow की Engineering Director Roberta Arcoverde के interview का सारांश
- 8 साल पहले software engineer के रूप में शामिल हुईं, फिर staff engineer (tech lead) बनीं, और इस साल की शुरुआत में manager की भूमिका में pivot किया
S: Engineering Director बनने के बाद क्या बदला?
- R: अब मैं लोगों को manage करती हूँ। उनके career को manage करना, उनकी growth में मदद करना। साथ ही हमारे आगे बढ़ने की strategic vision पर भी ध्यान देना।
software architecture को देखना कि क्या हम growth की दिशा में बढ़ रहे हैं, क्या यह PR हमें सिर्फ अभी नहीं बल्कि अगले 3 साल में वहाँ ले जा रही है जहाँ हम पहुँचना चाहते हैं — इन बातों पर लगातार नज़र रखती हूँ.
- S: यानी अब आप थोड़ा ज़्यादा long-term planning और उसी हिसाब से काम करती हैं, ताकि technology में बदलाव से चौंकना न पड़े।
- R: बिल्कुल। और अब बहुत ज़्यादा 1-on-1 meetings भी करती हूँ।
- S: अभी Microsoft में भी review season चल रहा है, और कई दिनों तक सिर्फ 1-on-1 meetings और evaluations ही चलते रहते हैं। हर समय meetings करना थोड़ा बोरिंग हो जाता है — क्या refresh होने के लिए आप code भी देखती हैं?
- R: हाँ, मैं code देखती हूँ। मेरा बहुत मज़बूत मानना है कि मेरे जैसे frontline managers को भी हर दिन code लिखना चाहिए। मुझे लगता है कि इससे व्यक्तिगत रूप से technical edge बनाए रखने में मदद मिलती है।
यह junior engineers को mentor करने में भी मदद करता है, और senior engineers द्वारा सुझाए गए बदलावों के असर का मूल्यांकन करने में भी।
अगर आप लगातार code लिखते रहें और देखते रहें कि software कहाँ जा रहा है, तो बड़े redesign के समय आप सही सवाल पूछ पाते हैं, जिससे वे सबसे अच्छा परिणाम दे सकें।
S: Stack Overflow की architecture कैसी है?
- R: Stack Overflow थोड़ा अलग है, खासकर 2008 के आसपास शुरू हुई दूसरी बड़ी sites की तुलना में।
- हमारे पास अभी 14 साल पुराना codebase है,
- हम अपने data center में on-prem machines पर चलते हैं।
- हम कभी cloud पर नहीं गए।
- यह एक monolithic application भी है। इसे services या microservices में नहीं बाँटा गया है।
- हमारे पास एक multi-tenant web app भी है। यह .NET आधारित है और 9 web servers पर single app के रूप में चलती है।
- यह IIS पर चलती है, और एक server प्रति सेकंड 6,000 requests संभालता है। (मासिक 2 अरब PV)
- S: IIS का उपयोग Apache, NGINX, Kubernetes वगैरह के आने के बाद काफी कम हो गया है। आप उस दिशा में जा सकते थे — क्या कुछ चीज़ें थीं जिन्हें आपने जानबूझकर ignore किया? और क्या कुछ ऐसा था जिसे आपने सोचा कि यह SO के लिए ज़रूरी है?
- R: हमने उनमें से बहुत-सी चीज़ों को ignore किया। सबसे हाल की चीज़ें microservices और Kubernetes से जुड़ी लगभग सब कुछ थीं।
उन्हें ignore करने की सबसे बड़ी वजह SO की सबसे मज़बूत development philosophy है।
हम हमेशा इस सवाल से शुरू करते हैं: "आप कौन-सी समस्या हल करने की कोशिश कर रहे हैं?"
ऐसे tools जिन समस्याओं को हल करना चाहते हैं, वे हमारी समस्या नहीं थीं।
उदाहरण के लिए, monolith से microservices या services में जाना अक्सर teams को बाँटकर scale करने के लिए किया जाता है।
ताकि कई teams एक ही project पर बिना टकराव के काम कर सकें, जल्दी deploy कर सकें, वगैरह।
लेकिन fast deploy हमारे लिए समस्या नहीं थी। SO दिन में कई बार deploy होता है, सिर्फ 4 मिनट में, और अगर दिक्कत हो तो कुछ ही मिनटों में rollback भी किया जा सकता है।
अभी हमारा lead time या merge होने में लगने वाला समय बहुत अच्छा है, और यह कोई दर्दनाक प्रक्रिया नहीं है।
करीब 50 engineers Q&A platform पर काम कर रहे हैं।
- R: 2014 में हम 10 लोग थे, और तब सभी के लिए पूरे codebase को समझना आसान था।
अब नए engineers की onboarding मुश्किल होती जा रही है।
कभी न कभी हम कुछ modules को अलग कर सकते हैं, और dedicated teams उन्हें देखेंगी, बिना पूरे code को समझे।
लेकिन अभी हम वहाँ तक नहीं पहुँचे हैं। हम अभी उस समस्या से नहीं जूझ रहे, और हम pragmatists हैं।
दूसरी architecture details
- 2-layer cache (memory और web server)
- साथ में कई SQL Server machines: 1.5TB RAM, जिससे पूरे DB का 1/3 हिस्सा RAM में तेज़ी से accessible है
→ मुझे लगता है कि cloud में इस तरह का setup सस्ते में चलाना मुश्किल होगा
- question pages को cache नहीं किया जाता। hit rate सबसे ज़्यादा होने से 80% traffic वहीं जाता है, लेकिन...
→ पहले Redis से cache करने की कोशिश की थी, लेकिन hit/miss cache rate बहुत अच्छा नहीं था
- अभी page rendering time लगभग 20ms है
- StackExchange भी उसी server setup पर multi-tenant रूप में चलता है। एक application सभी 200 sites को संभालता है
→ यानी सिर्फ एक application deploy करने से सब जगह लागू हो जाता है
- HAProxy के नीचे rolling build किया जाता है
7 टिप्पणियां
ओह….
haproxyसे rolling build करने वाला हिस्सा काफ़ी प्रभावशाली है, लेकिन यह कैसे implement किया गया है, यह जानने की जिज्ञासा है।मैंने पॉडकास्ट स्क्रिप्ट पढ़ी, लेकिन लगता है कि
haproxyके इस्तेमाल वाले हिस्से का बस संक्षेप में ज़िक्र करके आगे बढ़ गए। बातचीत जिस तरह health check की बात और काफ़ी monitoring कर रहे हैं, इस ओर जुड़ती है, उससे लगता है कि उन्होंने इसे खुद अच्छी तरह बनाकर चला रखा है… बस कुछ ऐसा ही लगता है ^^;"4 मिनट में deploy" कैसे करते हैं, यह जानने की जिज्ञासा है।
मैंने भी पिछली कंपनी में 4TB RAM सर्वर / 8TB RAM सर्वर चलाए हैं। सेटअप लागत बेशक बहुत ज़्यादा थी, लेकिन सच कहूँ तो कभी नहीं लगा कि उस स्पेक को cloud से बदला जा सकता है।
लगता तो ऐसा ही है।
सारांश के लिए धन्यवाद।
कई बातें प्रभावशाली हैं।
काफी लंबा इंटरव्यू है, इसलिए बीच-बीच में उसका सारांश दिया गया है. पूरा सुनते हुए स्क्रिप्ट भी देखें!
स्क्रिप्ट: https://app.podscribe.ai/episode/83433649