Software Engineering का भविष्य SRE है

• Agentic coding के दौर में भी software engineer की मांग घटने के बजाय बढ़ने की संभावना है, और इसकी कुंजी code लिखना नहीं बल्कि service operations की क्षमता में है
• code लिखना हमेशा आसान हिस्सा था, असली मुश्किल लंबे समय तक system को स्थिर रूप से चलाते रहना है
• no-code और spreadsheet के उदाहरणों की तरह गैर-विशेषज्ञ भी tools बना सकते हैं, लेकिन maintenance और operations का बोझ आखिरकार professional engineering की मांग करता है
• उपयोगकर्ता software नहीं बल्कि service खरीदते हैं, और अच्छा software बिना दिखाई दिए काम करना चाहिए
• uptime, defect rate, recovery speed, security updates जैसी operational excellence भविष्य की प्रतिस्पर्धात्मक बढ़त का केंद्र है
• इन सभी जरूरतों को पूरा करने वाली भूमिका के रूप में SRE software engineering के केंद्र में आ रहा है

---

SRE सबसे ज्यादा hiring वाला role बनने की संभावना है

• जब code सस्ता हो जाता है, तो operational excellence जीतती है
• greenfield demo कोई भी बना सकता है, लेकिन service को स्थिर रूप से चलाने के लिए engineering capability चाहिए
• "हर कोई greenfield demo बनाना चाहता है, लेकिन कोई service चलाना नहीं चाहता"
• software engineering सिर्फ programming नहीं, बल्कि समय के साथ बदलते systems को manage करने का काम है

no-code और spreadsheet युग से मिली सीख

• accounting का काम संभालने वाले Joe ने हर हफ्ते 10 घंटे लेने वाले दोहराए जाने वाले काम को no-code tool और spreadsheet macro से 1 घंटे तक घटा दिया
• शुरुआत में नतीजे साफ़ तौर पर अच्छे थे, लेकिन समय बीतने पर complexity तेज़ी से बढ़ी
  • business environment में बदलाव, accounting rules में परिवर्तन, timezone और daylight saving time की समस्याएं जमा होती गईं
  • हर हफ्ते नए edge cases सामने आए और लगातार सुधार व संशोधन की जरूरत पड़ी
• आखिरकार Joe अपने बनाए system से बंधा हुआ रह गया
  • छुट्टी के दौरान भी उसे system की चिंता करनी पड़ती थी, और operations किसी दूसरे को सौंपना मुश्किल था
  • code चलाना और उसके परिणाम देखना ही चिंता और तनाव का कारण बन गया

Computer Disease

• Feynman द्वारा दिया गया यह विचार बताता है कि computer की समस्या यह है कि उसे बार-बार छेड़ते रहने का मन होता है
• automation अपने आप में मज़ेदार है, लेकिन जरूरत न होने वाले क्षेत्रों तक automation फैलाकर complexity बढ़ाने का जाल मौजूद है
• असली बोझ service operations में है
  • उसे स्थिर रूप से काम करते रहना सुनिश्चित करना
  • बड़े पैमाने के environment में बिना समस्या के scale करना
  • कई वर्षों तक लगातार manage करना
• service delivery में stability, reliability और continuity सबसे अहम हैं

operational excellence ही भविष्य क्यों है

• लोग software नहीं खरीदते, बल्कि अपनी समस्या हल करने वाली service को अपनाते हैं
• किसी को iCloud के अंदरूनी कामकाज से मतलब नहीं, वे बस चाहते हैं कि photos devices के बीच हमेशा अपने-आप sync हों
• Word, Notion, gDocs कैसे बने, यह महत्वपूर्ण नहीं; महत्वपूर्ण है विचारों को लिखने और साझा करने का अनुभव
• payment network की संरचना से ज्यादा महत्वपूर्ण यह है कि 7 डॉलर का matcha latte बिना दिक्कत pay हो जाए
• अच्छा software दिखाई नहीं देता (वह बिना उपस्थिति जताए स्वाभाविक रूप से काम करता है)

असली मुश्किल engineering चुनौतियां

• काम करने वाला demo बनाने वाले पहले 90% आसान हैं, बाकी 190% ही वास्तव में महत्वपूर्ण हैं
• operations के नज़रिए से पूछे जाने वाले सवाल:
  • uptime कितना है
  • defect होने की दर कितनी है
  • outage होने पर recover होने में कितना समय लगता है
  • क्या समस्या को उपयोगकर्ता के नोटिस करने से पहले detect किया जाता है
  • क्या upstream dependencies को manage किया जा सकता है
  • vendor समस्या होने पर क्या उपयोगकर्ता शिकायत से पहले उसका पता चल जाता है
  • उपयोगकर्ता द्वारा सुझाए गए विचार को लागू करने में कितना समय लगता है
  • क्या engineers को एक-दूसरे के systems तोड़ने से रोका जाता है
  • क्या ऐसा system है जिसमें engineer आगे बढ़ते रहें और app उलझे हुए ढेर में न बदल जाए
  • क्या ऐसा software संभाला जा सकता है जिसका आकार एक व्यक्ति के दिमाग में समा न सके
  • अगर 12 घंटे के time difference वाले timezone में engineer के सोते समय बड़ी समस्या हो जाए, तो क्या उपयोगकर्ता हार मानने से पहले उसे ठीक कर दिया जाता है
  • क्या अपनी outages और upstream outages दोनों से recover किया जा सकता है, और क्या महत्वपूर्ण data खोता है
  • क्या security updates लगातार लागू किए जा रहे हैं
  • क्या user data leak नहीं होता
  • क्या इस पर trust किया जा सकता है
  • क्या इस पर depend किया जा सकता है
  • क्या उस भरोसे के समर्थन में ठोस आधार है
  • क्या जरूरत पड़ने पर इस बात की कानूनी रूप से बाध्यकारी guarantee पर हस्ताक्षर किए जा सकते हैं कि software काम करेगा
• यही असली मुश्किल engineering समस्याएं हैं, और code लिखना सिर्फ आसान हिस्सा है

[alfenmage]

हाहाहा 90 190 हाहाहा

[roxie]

हाहाहाहाहाहा

[sudosudo]

क्या बात कर रहे हो

[skageektp]

अगर SRE क्या है, इसका भी साथ में विवरण होता तो और अच्छा होता।

[pseudojo]

कमेंट्स की प्रतिक्रिया lolllll, ऐसा लग रहा है जैसे मूल लेख से सिर्फ ज़रूरी हिस्से छाँटकर रखे गए हों~ अच्छी तरह पढ़ा, धन्यवाद

[bsh998]

AI विश्लेषण का नतीजा: बीप-बीप-बीप.. 95% संभावना है कि यह AI ब्लॉग है।