H-E-B में Enterprise Haskell को अपनाना और उसका संचालन

 (blog.haskell.org)
1 पॉइंट द्वारा GN⁺ 8 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 435 से अधिक स्टोर्स और लॉजिस्टिक्स सेंटर्स की सप्लाई चेन को आधुनिक बनाने की प्रक्रिया में Haskell अपनाया गया, और 8 साल बाद कई टीमें मिलकर लगभग 10 लाख लाइनों का कोड कोर प्रोडक्शन सिस्टम्स में चला रही हैं
  • Haskell रनटाइम एरर के प्रकारों को कम करता है और GHC-आधारित रिफैक्टरिंग व लेगेसी इंटीग्रेशन को सपोर्ट करता है, लेकिन SDK की कमी के कारण खुद मेंटेनेंस और उन्नत type features की जटिलता को स्वीकार करना पड़ता है
  • सफलता भाषा से ज़्यादा टीम की क्षमता और संस्कृति पर निर्भर रही; Haskell विशेषज्ञों के बिना टीमों में space leak और मुख्य डेवलपर्स के हटने की वजह से दो प्रोजेक्ट्स में अपनाना टिक नहीं पाया
  • GHC runtime कभी H-E-B के प्रोडक्शन आउटेज का कारण नहीं बना, और HLS, OpenTelemetry, profiling जैसे ecosystem सुधारों के साथ प्रोडक्शन Haskell एक प्रतिस्पर्धी विकल्प बन गया है
  • उन्नत features को छोटी लाइब्रेरी और स्पष्ट interfaces के पीछे सीमित रखना चाहिए, और testing, observability, तथा knowledge sharing साथ-साथ चलने चाहिए; coding agents के दौर में GHC की type validation और तेज़ feedback और भी महत्वपूर्ण हो जाती है

मेनफ्रेम आधुनिकीकरण की चुनौती

  • टेक्सास की सबसे बड़ी निजी कंपनी रिटेलर H-E-B के ग्राहकों के लिए यह ज़्यादा महत्वपूर्ण है कि स्टोर की शेल्फ़ पर सामान भरा हो, न कि अंदरूनी सिस्टम कैसे काम करते हैं
  • दशकों तक COBOL mainframe स्थिर रूप से चलता रहा, लेकिन पिछले 10 वर्षों में curbside pickup, home delivery, real-time inventory और in-store search जैसे tech-केंद्रित फीचर्स उभरे
  • 435 से अधिक स्टोर्स और उन्हें सपोर्ट करने वाले लॉजिस्टिक्स सेंटर्स तक सप्लाई चेन ऑपरेशन बढ़ने के साथ, मौजूदा कोर सिस्टम्स पर ऐसी माँगें आने लगीं जो उनके मूल डिज़ाइन दायरे से बाहर थीं
  • mainframe modernization की सबसे बड़ी कठिनाई कोड को cloud में ले जाना नहीं, बल्कि दशकों से legacy business logic में जमा संगठन-विशिष्ट ज्ञान को सुरक्षित रखना है
  • सैकड़ों टेबल्स वाले monolith को स्वायत्त इंजीनियरिंग टीमों के स्वामित्व वाले microservices में बाँटना तकनीकी और राजनीतिक दोनों रूप से बहुत बड़ा और महँगा काम है

Haskell अपनाना और संचालन का पैमाना

  • कंसल्टेंट्स ने कंपनी के सबसे बड़े mainframe application को बदलने वाले नए प्रोजेक्ट की साझा भाषा के रूप में Haskell का प्रस्ताव दिया
  • एक प्रयोग के रूप में शुरू हुआ काम आगे चलकर कई कोर सप्लाई-चेन प्रोडक्शन सिस्टम्स तक बढ़ गया
  • अपनाने के 8 साल बाद, अलग-अलग डोमेन्स की कई टीमें मिलकर लगभग 10 लाख लाइनों के Haskell कोड का रखरखाव कर रही हैं
  • लंबे समय तक प्रोडक्शन में चलाने से वास्तविक उपलब्धियों के साथ तकनीकी और संगठनात्मक कठिनाइयाँ भी सामने आईं

बिज़नेस में मिले फायदे

  • एंटरप्राइज़ को lazy evaluation, pure functions या immutable data अपने-आप में नहीं चाहिए, बल्कि ऐसा सिस्टम चाहिए जो अगले 40 साल तक null pointer exception के बिना और कम maintenance लागत पर चले — यानी अगली पीढ़ी के COBOL जैसा
  • Haskell applications imperative और dynamically typed programs में आम कई तरह की runtime errors को मूल रूप से हटा देते हैं
    • bugs पूरी तरह खत्म नहीं होते, लेकिन बची समस्याएँ null pointer exception या type confusion की जगह business logic errors पर केंद्रित हो जाती हैं
  • कई वर्षों तक चले strangler fig तरीके के legacy migration में GHC ने सुरक्षित refactoring को सपोर्ट किया
    • requirements बनते रहने के दौरान बार-बार बदलाव संभव हुआ, इसलिए waterfall के बजाय agile तरीके से migration किया जा सका
    • enterprise गलत दिशा में ठोस हो चुके परिणाम पर पहले से निवेश करने के बजाय क्रमिक रूप से परिणाम माप सकता है
  • Haskell parsers हज़ारों लाइनों वाले legacy formats, जैसे fixed-width IBM copybook, को सीधे contract के रूप में इस्तेमाल करने देते हैं
  • मजबूत foreign function interface (FFI) की मदद से केवल C libraries देने वाली मौजूदा सेवाओं के साथ भी इंटीग्रेशन किया जा सकता है
    • H-E-B ने simdjson C++, Oracle ODPI-C, और IBM MQ को wrap करने वाली Haskell libraries लिखीं

SDK की कमी और contract ownership

  • Haskell SDK कम होने पर ज़रूरी clients और integration code खुद बनाना और लगातार मेंटेन करना पड़ता है
  • बदले में contracts पर सीधा स्वामित्व मिलता है, vendor lock-in से बचाव होता है, और ऊपर वाले project maintainer के patch release का इंतज़ार नहीं करना पड़ता
  • H-E-B ने माना कि मुख्य dependencies के लिए यह लेन-देन पर्याप्त रूप से फायदेमंद है
  • coding agents Go libraries को Haskell में लाने जैसे mechanical काम अच्छे से कर सकते हैं, जिससे भाषाओं के बीच development speed का अंतर कम हो सकता है
    • लेकिन साधारण translation, यदि prompts पर्याप्त परिष्कृत न हों, तो Haskell type system के फायदों का पूरा उपयोग नहीं कर पाती

embedded DSL के ज़रिए बहुभाषी इंटीग्रेशन

  • Haskell embedded DSL(eDSL) के host language के रूप में मजबूत है
    • central team domain model या business logic को एक बार define करके, दूसरी टीमों द्वारा इस्तेमाल की जाने वाली भाषाओं के लिए type-safe code generate कर सकती है
    • दूसरी टीमें सीधे Haskell लिखे बिना भी उस सिस्टम के साथ integrate कर सकती हैं
  • Hydra Uber के graph data कार्य से विकसित open source DSL framework है
    • यह Haskell में bootstrap होता है और Java, Python, Scala आदि के semantically equivalent implementations generate करता है
    • shared test suite के ज़रिए भाषाओं के बीच implementation equivalence सुनिश्चित की जाती है
  • H-E-B ने संवेदनशील financial calculations को Haskell, TypeScript और Java टीमों के बीच साझा करने योग्य Haskell DSL का prototype बनाया
  • एक bidirectional JSON schema DSL भी बनाया गया
    • यह autodocodec जैसा है, लेकिन इसमें tagless final encoding का उपयोग होता है जिससे उपयोगकर्ता अपने type classes के ज़रिए core semantics को बढ़ा सकते हैं
    • यह schema versioning, documentation और OpenAPI generation, तथा regression और golden tests को मानकीकृत करता है
    • custom interpreters लिखकर JSON schema को PostgreSQL table definitions में बदला जा सकता है, या aeson को simdjson से बदलकर अतिरिक्त validation लागू की जा सकती है

भर्ती और इंजीनियरिंग संस्कृति

  • आधुनिक भाषाएँ भी Haskell से प्रभावित type safety, purity और concurrency features का बड़ा हिस्सा देती हैं, इसलिए असली अंतर उस engineering culture में है जिसे भाषा प्रोत्साहित करती है
  • Haskell ऐसे डेवलपर्स को आकर्षित करता है जो correctness और abstraction design को महत्व देते हैं
  • Haskell roles के लिए hiring उतनी कठिन नहीं थी जितनी management ने सोची थी
    • कुछ उम्मीदवार सप्लाई-चेन में खास रुचि न होने पर भी सिर्फ Haskell की वजह से आवेदन कर रहे थे

complexity budget की सीमाएँ

  • Haskell एक पुरानी भाषा है और इसमें कई कमियाँ हैं, इसलिए नवीनतम GHC releases के साथ बने रहना महत्वपूर्ण है
  • टीम में विशेषज्ञ न हो तो भाषा की एक कमी पूरे प्रोजेक्ट में फैल सकती है
  • शुरुआत में अनुभवी consultants ने language extensions और custom operators के अत्यधिक उपयोग को रोकने के लिए guardrails बनाए
  • GHC2021 और GHC2024 language editions से पहले, हर टीम अपना default extension set खुद manage करती थी
    • यह नए शामिल होने वालों के लिए सीखने योग्य भाषा-क्षेत्र को सीमित करने वाले complexity budget की तरह काम करता था
  • dependencies खुद भी complexity budget खर्च करती हैं, इसलिए संगठन-स्तर पर इन्हें लागू करना आसान नहीं है
    • servant API को type-level DSL के रूप में व्यक्त करता है, और custom combinator extensions के साथ type family तथा कठिन errors आते हैं
    • haxl concurrent work को batch करने के लिए सभी data sources को result type से indexed GADT के रूप में model करता है
  • जैसे-जैसे डेवलपर्स अधिक अनुभवी होते हैं, GADT, type family, generic, tagless final, arrow, free structure, higher-kinded data type patterns लाने का आकर्षण बढ़ता है
    • जब पहले से जटिल business domain के ऊपर ऐसे concepts जोड़ दिए जाते हैं, तो आसान maintenance का वादा कमज़ोर पड़ सकता है
    • ecosystem से परिचित होने के साथ advanced features धीरे-धीरे बढ़ते हैं, इसलिए complexity में वृद्धि देर से दिखाई दे सकती है

boring Haskell के संचालन सिद्धांत

  • संगठन स्तर पर boring Haskell को प्रोत्साहित करना आसान है, लेकिन उसे लागू कराना कठिन
  • यदि advanced Haskell को उचित interfaces के पीछे encapsulate किया जाए, तो उसका प्रभाव-क्षेत्र घटाया जा सकता है और complexity budget को कुछ विशेषज्ञों द्वारा संभाली जाने वाली छोटी libraries तक सीमित किया जा सकता है
  • भाषा-स्तर की जटिलता सिर्फ Haskell की समस्या नहीं है, लेकिन Haskell में उपलब्ध advanced tools की रेंज विशेष रूप से बड़ी है
  • कोड की lines या token usage से अधिक, अगली GHC upgrade में कितना कोड टूटता है, यह Haskell project की complexity को बेहतर दिखाता है

टिक नहीं पाए दो प्रोजेक्ट्स

  • Haskell एक टीम को सशक्त बना सकता है, लेकिन दूसरी टीम के लिए बाधा भी बन सकता है; H-E-B में भी अलग-अलग कारणों से दो प्रोजेक्ट्स में यह टिक नहीं पाया
  • पहले मामले में Haskell अनुभव के बिना अनुभवी डेवलपर्स ने दूसरी टीम के project template और conventions का पालन किया, लेकिन space leak के कारण पूरा प्रोग्राम रुक गया
    • मजबूत Haskell डेवलपर के मार्गदर्शन के बिना यह एक समस्या ही प्रोजेक्ट रोकने तक पहुँच गई
  • दूसरे मामले में Haskell का समर्थन करने वाले और application बनाने वाले इंजीनियर्स प्राथमिकताओं के बदलने से दूसरे प्रोजेक्ट्स पर चले गए
    • यह भाषा से असंबंधित कारण था
  • दोनों टीमों के पास मौजूदा technologies पर लौटने का विकल्प था और उन्हें यक़ीन नहीं था कि Haskell productivity बढ़ाता है
  • अगर Spring Boot template जैसा आसान escape hatch हो, तो मुश्किल space leak को आखिर तक diagnose करने की प्रेरणा कम हो सकती है
  • LLMs के पूरे codebase को mechanical रूप से translate कर पाने से rewrite के विकल्प और व्यापक हो गए हैं
  • दीर्घकालिक सुरक्षा चतुर, दोबारा लिखना कठिन कोड नहीं, बल्कि ऐसी टीम है जो Haskell को बनाए रखना चाहती हो

प्रोडक्शन आउटेज और निदान

  • Haskell अपनाने वाली टीमों में भी कई गंभीर समस्याएँ आईं
  • GHC runtime कभी H-E-B के प्रोडक्शन आउटेज की जड़ नहीं बना
  • steady-state throughput और memory usage, H-E-B workloads में पर्याप्त रूप से प्रतिस्पर्धी थे; समस्या वाले मामले सामान्य नहीं बल्कि अपवाद थे
  • इंजीनियर्स ने segmentation fault core dumps, garbage collection metrics, और heap profiles ट्रैक करके समस्याएँ सुलझाईं
  • मजबूत type system को आधार बनाकर test coverage की बलि नहीं देनी चाहिए
  • Haskell applications में साधारण error classes compile चरण में ही हट जाती हैं, इसलिए chaos engineering से वास्तविक logic और resource failures अधिक सीधे सामने लाए जा सकते हैं

बदले हुए डेवलपमेंट tools और ecosystem

  • शुरुआती सिस्टम्स GHC 8.2 पर शुरू हुए थे, और उस समय लोकप्रिय platforms के API clients और SDKs का अधिकांश हिस्सा खुद लिखना पड़ता था
  • Haskell Language Server मौजूद नहीं था, GHCup अभी-अभी आया था, और runtime profiling भी कठिन थी
  • Java IDEs के आदी डेवलपर्स को Haskell tooling environment असुविधाजनक लगा, और H-E-B ने VS Code users के लिए Debug Adapter Protocol support के विकास को sponsor भी किया
  • आज प्रोडक्शन-ग्रेड Haskell development सिर्फ संभव ही नहीं, बल्कि प्रतिस्पर्धी स्तर तक विकसित हो चुका है
  • development tools में HLS, ghcid, ghciwatch, static-ls, tricorder, और editor plugins शामिल हैं
    • कुछ टीमें समृद्ध GHCi-केंद्रित development के लिए GHC plugins इस्तेमाल करती हैं, और कुछ VS Code तथा HLS का उपयोग करती हैं
    • इससे डेवलपर्स अपनी पसंद के tools चुन सकते हैं
  • observability के लिए hs-opentelemetry और opentelemetry-auto का उपयोग होता है
    • opentelemetry-auto एक GHC plugin है जो Haskell functions में OTel spans अपने-आप जोड़ता है
    • यह Java और Python की तुलना में भी समान instrumentation environment दे सकता है

प्रोडक्शन libraries और runtime सुधार

  • सेवाएँ warp, aeson, attoparsec, stm, conduit, servant, orville-postgresql जैसी libraries इस्तेमाल करती हैं
  • ecosystem में ज़रूरी फीचर न होने पर अपनी libraries बनाई जाती हैं
    • arbiter H-E-B के काम से निकला transaction-आधारित PostgreSQL work queue है और अभी प्रोडक्शन में चल रहा है
  • GHC runtime diagnostics, compiler performance, eventlog streaming जैसे monitoring features, और exception annotations में सुधार कर रहा है
  • GHC 9.2 में info table profiling आने के बाद space leak को लेकर चिंता काफ़ी कम हुई

आंतरिक समुदाय और ज्ञान का वितरण

  • H-E-B internal libraries को महत्वपूर्ण मानता है और डेवलपर्स को internal projects तथा open source projects दोनों में योगदान देने के लिए प्रोत्साहित करता है
  • कई वर्षों से हर दो हफ्ते Haskell meetup चलाया जाता है, जहाँ इंजीनियर्स अपनी खोजें साझा करते हैं और दूसरों को सिखाते हैं
  • enterprise संगठन में silos कम करने के लिए टीमों के बीच ideas और patterns का आदान-प्रदान होना चाहिए
  • जब अधिक इंजीनियर्स codebase को पढ़ते और उसका ownership लेते हैं, तो किसी एक व्यक्ति के जाने से प्रोजेक्ट पर पड़ने वाला bus factor risk कम किया जा सकता है

advanced features की अनुमति का मानदंड

  • ढीले default rules रखे जाते हैं, लेकिन complexity budget कहाँ खर्च होगा इसका अंतिम निर्णय tech leads लेते हैं
  • अगर stored personally identifiable information(PII) को encrypt करना ज़रूरी है, तो संवेदनशील data leakage को runtime incident के बजाय compile error बना देने वाली type-level guarantees निवेश के लायक हो सकती हैं
  • trees-that-grow pattern से चार API contracts को एक करना, type family के ज़रिए external schema छिपाने जितना मूल्यवान नहीं भी हो सकता है
  • boring Haskell type-level programming या advanced GHC features पर प्रतिबंध नहीं लगाता; यह सिद्धांत-आधारित conventions तय करता है और उनसे हटने की लागत का आकलन करता है
  • एक मुख्य convention है: “दूर बैठी किसी चीज़ का अप्रत्याशित प्रभाव नहीं”
    • TemplateHaskell code generation और Generic-आधारित serialization logic से बचा जाता है
    • boilerplate सीधे लिखा जाता है ताकि प्रोग्रामर को व्यवहार स्पष्ट रूप से दिखे
    • quasiquoter या Generically के ज़रिए deriving को पूरी तरह प्रतिबंधित नहीं किया जाता
  • जब web form में type-level state machine लागू की जाए, या जहाँ सामान्य ADT पर्याप्त हो वहाँ GADT इस्तेमाल किया जाए, तब स्वस्थ संदेह और टीम-स्तरीय प्रतिवाद ज़रूरी हैं
  • advanced Haskell libraries और production applications दोनों में मौजूद है, लेकिन प्रयोग की सीमा तय रहनी चाहिए
  • काम और तकनीकी खेल के बीच संतुलन बनाने की प्रक्रिया में ही वास्तविक engineering होती है

आगे का Haskell और coding agents

  • कई वर्षों तक GHC इस्तेमाल करते हुए कुछ bugs मिले और report भी किए गए, लेकिन ऐसे मुद्दे नहीं आए जिन्होंने काम ठप कर दिया हो
  • प्रोडक्शन incidents दुर्लभ रहे, और type errors या runtime से कहीं अधिक मामले business logic से जुड़े थे
  • coding agents द्वारा लिखे गए कोड का हिस्सा बढ़ने के साथ bottleneck code writing से validation की ओर खिसक रहा है
  • GHC का type system इंसानों को सुरक्षित refactoring में मदद करता है, और साथ ही agents द्वारा hallucination से बने कोड को execution से पहले अस्वीकार करने वाला तेज़ feedback loop देता है
  • उद्योग में Haskell की संभावनाएँ बढ़ाने के लिए वास्तविक प्रोडक्शन success stories और अधिक साझा की जानी चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 8 시간 전
Lobste.rs की राय

  • टेक्सास के बाहर शायद लोग इसे उतना न जानते हों, लेकिन H-E-B टेक्सास की एक प्रतीकात्मक संस्था है, जिसका आकार और प्रभाव ऐसा है कि उसे राज्य सरकार के एक और विभाग जैसा कहा जा सकता है
    कई स्टोर्स में tortilla बनाने की सुविधा है, और बड़े पैमाने पर बनने वाले उत्पादों के हिसाब से उनकी गुणवत्ता भी शानदार है। ऊपर से वे Haskell भी इस्तेमाल करते हैं

    • इसका नाम संस्थापक परिवार Howard Butt के initials H.B. से आया है। Wegmans, Hannaford Market, Walmart की तरह संस्थापक के नाम पर भी रखा जा सकता था, लेकिन शुक्र है कि उसका नाम Buttmart नहीं रखा गया
    • सोच रहा हूँ क्या यह किसी स्थानीय Costco जैसा है

  • यह बात सच में चौंकाने वाली है कि H-E-B जैसी कंपनी ने COBOL को बदलने के लिए Haskell चुना
    एक तरफ वे कहते हैं कि coding agents Go libraries को Haskell में लगभग मशीन की तरह port कर सकते हैं, जिससे development speed का अंतर कम हो गया है; लेकिन तुरंत यह भी मान लेते हैं कि चतुर prompts के बिना type system का पूरा फायदा नहीं उठाया जा सकता — ये दोनों बातें मिलकर एक तरह का विरोधाभास दिखाती हैं
    दूसरी ओर, क्योंकि मामूली errors compile चरण में ही हट जाते हैं, इसलिए chaos engineering के जरिए infra failures डाले जाने पर dynamic typed languages वाले शोर की जगह असली logic/resource errors सामने आते हैं; Haskell पर विचार करने की यह सबसे ठोस वजह लगती है

    • H-E-B के पास Walmart जैसी ही काफी बड़ी और अच्छी प्रतिष्ठा वाली engineering organization है, इसलिए यह पूरी तरह हैरान करने वाली बात नहीं है। San Antonio मुख्यालय में काम करने से हिचकने वाले software talent को आकर्षित करने के लिए वे Austin में software-केंद्रित office भी चलाते हैं

  • पिछले हफ्ते मैंने Bazel में isolated Haskell build सेटअप करने की कोशिश की, लेकिन कोई तुरंत इस्तेमाल लायक समाधान नहीं मिला
    rules_haskell डिफ़ॉल्ट रूप से isolated नहीं लगता, और आम तरीका शायद nixpkgs पर काफी निर्भर है। लगता है Haskell system C++ linker पर निर्भर करता है; समझ नहीं आ रहा कि क्या अभी वास्तविक स्थिति यही है या मैं कोई दूसरा विकल्प मिस कर रहा हूँ