वह एक प्रौद्योगिकी लागत जिसे आप माप नहीं रहे हैं—यदि आपने ऐसा किया तो इससे लाखों की बचत हो सकती है

क्लाउड पर जाने के साथ होने वाली सबसे बड़ी पारियों में से एक यह है कि हम प्रौद्योगिकी और अनुप्रयोगों के लिए भुगतान कैसे करते हैं। उद्योग ने ऑन-प्रिमाइसेस डेटा केंद्रों वाले सर्वर पर ऑल-यू-कैन-प्रोसेस से एक वेरिएबल, या यूटिलिटी कंप्यूट मॉडल पर स्विच किया है। हाल ही में एप्टियो के अनुसार रिपोर्ट, इसका मतलब यह है कि "क्लाउड खर्च के आकार को बदलने के लिए हर दिन टीम स्तर पर सूक्ष्म-अनुकूलन हो सकता है ... यह CapEx (पूंजीगत व्यय) के बजाय OpEx (परिचालन व्यय) की दुनिया है, पूरी तरह से बदल रहा है कि वित्त कैसे रिपोर्ट किया जाता है और प्रबंधित।

नतीजतन, खर्चों के लिए पारंपरिक खरीद मॉडल को बढ़ा दिया गया है, खर्च करने की शक्ति इंजीनियरों के हाथों में डाल दी गई है जो इन अनुप्रयोगों और बुनियादी ढांचे का विकास और प्रबंधन कर रहे हैं, इस बात पर बहुत कम ध्यान दिया जा रहा है कि परिचालन खर्चों में कंपनी की लागत क्या है। प्रौद्योगिकी खाइयों में काम करने वाला हर व्यक्ति आज अपने स्वामित्व के विशिष्ट क्षेत्र के लिए यहां और अभी पर केंद्रित है, यह सुनिश्चित करता है कि सिस्टम बिना किसी आउटेज के हर दिन चलता रहे। कोई नहीं सोच रहा: क्या हम वह कर सकते हैं जो हम तेजी से, बेहतर, स्मार्ट, यानी अनुप्रयोगों और प्रक्रियाओं के भीतर अधिक कुशलता से कर रहे हैं?

एप्टियो, नियोजन, बजट और पूर्वानुमान उद्देश्यों के लिए आईटी सेवाओं की लागत का आकलन और संचार करने के लिए डिज़ाइन किए गए सॉफ़्टवेयर के निर्माता, आगे इस स्थिति की गंभीर वास्तविकता का वर्णन करते हैं, "इंजीनियर क्लाउड के लिए वित्तीय प्रतिबद्धता बनाते हैं जो उनकी कंपनियों की निचली रेखा को प्रभावित करते हैं।" वित्त टीमें खर्च की गति और ग्रैन्युलैरिटी को बनाए रखने के लिए संघर्ष करती हैं।"

अधिकांश इंजीनियर अपने द्वारा लिखे जा रहे कोड को नियंत्रित या पूरी तरह से नहीं समझते हैं; वे उत्पादन में जो कुछ भी प्रचारित किया जाता है उसे चलाने के लिए केवल बुनियादी ढाँचे को जोड़ रहे हैं।

आपकी टीम द्वारा समर्थित सैकड़ों एप्लिकेशन या तकनीक के लिए आपके तकनीकी परिवेश की कुल लागत की गणना करना उद्योग में सामान्य प्रथा नहीं है। इसे बदलने की जरूरत है। (नोट: मैं रोबोटिक प्रोसेसिंग ऑटोमेशन-आरपीए के बारे में बात नहीं कर रहा हूं, डिजिटल कार्यों को स्वचालित करने के लिए बॉट्स का उपयोग कर रहा हूं।) मेरा दृष्टिकोण अनुप्रयोगों, कोड और प्रक्रियाओं की दक्षता पर केंद्रित है, स्वचालन के माध्यम से दक्षता पर नहीं।

कोड की कुल लागत को मापना क्यों महत्वपूर्ण है।

अनुप्रयोगों को व्यावसायिक उपयोगकर्ता के लिए प्रक्रियाओं को सरल बनाने के लिए डिज़ाइन किया गया है। किसी एप्लिकेशन को उत्तर प्रदान करने में बहुत सारे संसाधन और जटिलता लगती है, भले ही प्रतिक्रिया समय केवल कुछ सेकंड हो। अब, इसे अपने उद्यम में हजारों सर्वरों में प्रति सेकंड हजारों या लाखों एप्लिकेशन अनुरोधों से गुणा करें। बहुत कुछ साथ-साथ चलने से चीजों की पहुंच से बाहर होना आसान है, और यह लागत से भी संबंधित है। यदि किसी एप्लिकेशन को चलाने वाले सर्वर को तीन साल तक चलने वाला माना जाता है, लेकिन केवल इसलिए कि वे क्षमता से बाहर हैं - उस एप्लिकेशन की सही लागत क्या है? यह कुछ सीएफओ और अन्य लोगों को जानने की जरूरत है क्योंकि उनके पास बजट है जिसे पूरा करने की जरूरत है।

एक कुशल, स्वस्थ प्रणाली को एक अक्षम प्रणाली की तुलना में उसी वर्कलोड को संसाधित करने के लिए कम संसाधनों की आवश्यकता होती है। कोड अनुकूलन और भी संसाधनों को मुक्त करता है।

वस्तुतः किसी भी प्रणाली में कम से कम 30 से 40 प्रतिशत तक क्षमता युक्तिकरण का एहसास करने की क्षमता होती है और कोड-अनुकूलन लागत बचत का 20 से 80 प्रतिशत अतिरिक्त प्रदान कर सकता है।

इसका मतलब है कि क्लाउड और लाइसेंसिंग लागत को कम करते हुए समान वर्कलोड को छोटे सर्वर पर चलाया जा सकता है। इन बचतों का मूल्य केवल अल्पकालिक नहीं है, बल्कि समय की विस्तारित अवधि के रूप में है क्योंकि अधिकांश एप्लिकेशन अब 5 से 20 साल या उससे अधिक समय तक जीवित रहते हैं। यह केवल नीचे की रेखा की बात नहीं है, यह इस बात पर विचार है कि इस मुक्त पूंजी के साथ आज आगे के व्यापार केपीआई के लिए क्या किया जा सकता है।

20 वर्षों में कोड की कुल लागत की कल्पना करें और विचार करें: "क्या हम उस कोड को 20% अधिक कुशल बना सकते थे, और यदि ऐसा है, तो हम 20 वर्षों में कितना बचा सकते थे?"

फिर, बादल की ओर गति होती है और पे-एज-यू-गो बनाम सामने तक का भुगतान मॉडल जो डेटा सिस्टम को संचालित करने और बनाए रखने के लिए लागतों को तेजी से चला रहा है, हम उन्हें कैप्चर और विश्लेषण कर सकते हैं। एप्टियो की रिपोर्ट में इस बात पर प्रकाश डाला गया है कि जब क्लाउड सेवाओं की लागत में कोई पारदर्शिता नहीं होती है तो हर कोई कैसे हार जाता है:

• लागत दक्षता की थोड़ी समझ के साथ इंजीनियरिंग जरूरत से ज्यादा खर्च करती है।
• वित्त टीमें यह समझने के लिए संघर्ष करती हैं—और इसके साथ बनी रहती हैं—विकल्पों की मनमौजी संख्या पर क्या खर्च किया जा रहा है (अकेले AWS में लगभग 300,000 SKU और प्रति वर्ष अतिरिक्त हज़ारों नई सुविधाएँ हैं)।
• कितना खर्च किया जाएगा या प्राथमिकताओं को प्रभावित करने की क्षमता के बारे में नेतृत्व के पास पर्याप्त जानकारी नहीं है।
• अधिप्राप्ति अपने स्वयं के आउटसोर्सिंग में एक जानबूझकर भागीदार नहीं है।

बचत का अनुमान लगाते हुए, आपके पास होगा यदि आप कोड के एक टुकड़े को अनुकूलित करते हैं, इससे पहले कि यह आपके सिस्टम को अक्षम (सर्वोत्तम रूप से) बनाता है या आउटेज (सबसे खराब) का कारण बनता है, थोड़ी अधिक योजना और अंतर्दृष्टि लेता है। लेकिन यह आवश्यक है अगर हम विकास की वर्तमान दर के साथ रहना चाहते हैं जो व्यवसाय अनुभव कर रहे हैं।

अपने अगले लेख में, मैं इस बारे में बात करूँगा कि हम कोड की कुल लागत को कैसे माप सकते हैं, जिससे अक्षम प्रक्रियाओं पर अरबों की बचत होगी। क्या आप मेरे साथ हैं?