सॉफ्टवेअर टीम्स Fabric Workload Dev Kit कडे पाहताना वारंवार एकच 'कॅटेगरी एरर' (वर्ग चूक) करतात. त्यांना यात एक पब्लिशिंग पाईपलाईन, सर्टिफिकेशन चेकलिस्ट आणि पार्टनर पोर्टल दिसते. दुसऱ्या शब्दांत, त्यांना यात एक 'मार्केटप्लेस' दिसते. त्यांना वाटते की हे एक असे 'ॲड-इन' आहे जे ग्राहक त्यांच्या Microsoft स्टॅकसोबत शोधू शकतात, डाउनलोड करू शकतात आणि वापरू शकतात.
हा दृष्टिकोन चुकीचा आहे. Fabric वर्कलोड हे कोणतेही 'ॲक्सेसरी' (साधन) नाही. ते एक 'नेटिव्ह सरफेस' (मूळ पृष्ठभाग) आहे. एकदा तैनात (deploy) केल्यानंतर, तुमचे ॲप्लिकेशन Lakehouse, Power BI आणि Notebook च्या अगदी त्याच शेलमध्ये राहते. वर्कस्पेसमध्ये त्याला स्वतःचा स्वतंत्र 'आयटम टाईप' मिळतो. जेव्हा वापरकर्ता "New" वर क्लिक करतो, तेव्हा ते तिथे दिसते. तुमचे UI 'Fabric chrome' मध्ये रेंडर होते, कोणत्याही पॉप-आउट टॅबमध्ये नाही. तुमचे फिचर सेट नेमके तिथेच असते जिथे डेटा टीम्स आधीच त्यांचे कामाचे तास घालवतात. हे केवळ वितरणासाठी असलेले एखादे 'साइडबार' नाही. हे Microsoft च्या डेटा ऑपरेटिंग सिस्टमप्रती असलेले एक संरचनात्मक वचनबद्धता (structural commitment) आहे. जर तुम्ही याकडे केवळ एक 'लिस्टिंग' म्हणून पाहिले, तर तुम्ही अशा प्लॅटफॉर्ममध्ये अडकू शकता ज्यावर तुमचे नियंत्रण नाही.
नेटिव्ह ॲडव्हान्टेज (The Native Advantage)
जेव्हा तुम्ही Fabric साठी काही तयार करता, तेव्हा तुम्हाला होस्ट एन्व्हायरनमेंटचा विश्वास आणि संदर्भ (context) आपोआप मिळतो. तुमच्या वर्कलोडला OneLake वर वाचण्याचा (read) आणि लिहिण्याचा (write) अधिकार मिळतो, याचा अर्थ असा की तुमचे ॲप्लिकेशन डझनभर ETL पाईपलाईन्सद्वारे डेटा कॉपी न करता थेट Delta टेबल्सवर क्वेरी करू शकते. ऑथेंटिकेशन Microsoft Entra ID द्वारे होते, त्यामुळे तुमचे ॲप्लिकेशन साइन-इन केलेल्या वापरकर्त्याप्रमाणेच काम करते. व्यवस्थापित करण्यासाठी कोणताही वेगळा क्रेडेंशियल व्हॉल्ट नाही, मेंटेन करण्यासाठी कोणताही SSO ब्रिज नाही आणि सुरक्षा टीमला काळजी वाटेल असे कोणताही फिशिंग-संभाव्य पासवर्ड प्रॉम्प्ट नाही.
तांत्रिक जोडण्यांइतकीच 'ऑपरेशनल ग्रॅविटी' (कार्यात्मक गुरुत्वाकर्षण) देखील महत्त्वाची आहे. ग्राहकाचा डेटा त्यांच्या स्वतःच्या टेनंटमध्येच राहिल्यामुळे, तुम्ही बहुतांश एंटरप्राइझ SaaS डील रद्द करणाऱ्या 'प्रोक्युअरमेंट थिएटर' (खरेदी प्रक्रियेतील अनावश्यक नाट्य/अडथळे) टाळू शकता. CISO ला डेटा रेसिडेन्सीबाबत वाद घालण्याची गरज पडत नाही. खरेदी अधिकाऱ्याला (procurement officer) एग्रेस चार्जेसचे (egress charges) मॉडेलिंग करण्याची गरज नसते. तुमचे सॉफ्टवेअर केवळ अशा भिंतींच्या आत काम करते ज्या त्यांच्या मालकीच्या आहेत. आरोग्य सेवा, वित्तीय सेवा, सरकारी संस्था यांसारख्या नियंत्रित उद्योगांमध्ये विक्री करणाऱ्या विक्रेत्यांसाठी, हे एक वैशिष्ट्य १२ आठवड्यांची सुरक्षा तपासणी केवळ काही दिवसांच्या चर्चेत बदलू शकते.
सापळे कुठे दडलेले आहेत (Where the Traps Hide)
नेटिव्ह स्टेटससोबत नेटिव्ह डिपेंडन्सीज (अवलंबित्व) देखील येतात आणि त्या मर्यादांमध्ये रूपांतरित होऊ शकतात.
पहिले म्हणजे, 'कम्प्युट मॅथ' (compute math). तुमचे नफा आता Microsoft Capacity Units (CUs) वर अवलंबून आहे. तुमचा वर्कलोड केलेली प्रत्येक क्रिया त्याच CU च्या पूलचा वापर करते जो ग्राहकाचे Spark जॉब्स, Semantic मॉडेल्स आणि Power BI रिफ्रेश चालवण्यासाठी वापरला जातो. जर Microsoft ने किंमतींमध्ये बदल केला, बर्न मल्टिप्लायर्स बदलले किंवा नवीन कॅपॅसिटी टियर्स आणले, तर तुमच्या संमतीशिवाय तुमच्या युनिट इकॉनॉमिक्समध्ये बदल होईल. तुमचे इन्फ्रास्ट्रक्चर लेयर तुमच्या नियंत्रणात नाही, याचा अर्थ तुम्ही ते ऑप्टिमाइझ करू शकत नाही. तुम्ही फक्त त्याचे मॉडेलिंग करू शकता आणि आशा करू शकता.
दुसरे म्हणजे, रोडमॅपचा धोका वास्तविक आहे. उपयुक्त व्हर्टिकल फिचर्सचे निरीक्षण करणे आणि नंतर त्यांचे क्षैतिज (horizontal) समकक्ष भाग मूळ प्लॅटफॉर्ममध्ये समाविष्ट करणे, ही Microsoft ची एक well-documented पद्धत आहे. जर तुमचे व्हॅल्यू प्रपोझिशन सामान्य डेटा टास्कसाठी केवळ एक पातळ UI रॅपर असेल, तर तुम्ही अशा जमिनीवर बांधकाम करत आहात ज्यावर रेडमंड (Redmond) भविष्यात दावा करू शकते. तुमचे एकमेव संरक्षण म्हणजे खोली (depth) आणि डोमेन विशिष्टता (domain specificity) आहे. सामान्य डेटा क्लीनिंग किंवा साधी व्हिज्युअलायझेशन टूल्स एका टिकिंग क्लॉकच्या (वेळेच्या दबावाखाली) समोर आहेत. प्रोप्रायटरी मशीन लर्निंग मॉडेल्स, उद्योग-विशिष्ट गणना किंवा कस्टम टेलिमेट्री स्कीमावर आधारित ऑब्झर्व्हेबिलिटी लॉजिक यांना अपरिहार्य राहण्याची अधिक संधी आहे.
तिसरे म्हणजे, इंजिनिअरिंग प्रयत्नांचा नेहमी कमी अंदाज लावला जातो. क्विकस्टार्ट ट्युटोरियल्स आणि सॅम्पल रिपॉझिटरीजमुळे असे वाटते की तुम्ही एका दुपारी वर्कलोड तयार करू शकता. जर तुमचे ध्येय केवळ डेमो दाखवणे असेल, तर तुम्ही ते करू शकता. पण प्रोडक्शन वेगळे आहे. तुम्हाला पूर्ण बॅकएंड कॉन्ट्रॅक्ट लागू करावे लागेल, आयटम लाइफसायकल इव्हेंट्स हाताळावे लागतील, तुमच्या कंट्रोल प्लेन आणि Fabric च्या दरम्यान स्टेट सिंक्रोनाइझेशन व्यवस्थापित करावे लागेल आणि कॅपॅसिटी पॉज किंवा रीकनेक्ट झाल्यावर सुरळीतपणे रिकव्हर व्हावे लागेल. वापरकर्ता ज्या पृष्ठभागाला स्पर्श करतो तो साधा असू शकतो, परंतु त्याखालील कॉन्ट्रॅक्ट तसे नाही.
बनवा, की सोडून द्या? (Build It, or Skip It?)
निर्णय तुमच्या मूल्याचा उगम कोठे आहे यावर आधारित असावा, Microsoft च्या इकोसिस्टमबद्दलच्या तुमच्या उत्साहावर नाही.
बनवा (Build) जर तुमचे उत्पादन ग्राहकाच्या डेटाच्या जितके जवळ असेल तितके अधिक मौल्यवान होत असेल तर. ऑब्झर्व्हेबिलिटी प्लॅटफॉर्म्स, उद्योग-विशिष्ट ॲनालिटिक्स इंजिन्स आणि गव्हर्नन्स टूल्स या सर्वांसाठी हे लागू होते. जर तुमचे खरेदीदार आधीच Microsoft स्टॅकचा सखोल वापर करत असतील आणि नवीन विक्रेता जोडण्याऐवजी खर्च एकत्रित करण्यास प्राधान्य देत असतील, तर बनवा. जर तुमची बौद्धिक संपदा (Intellectual Property) स्टोरेज लेयरच्या वर असेल—जसे की प्रोप्रायटरी डोमेन लॉजिक, कस्टम ML इन्फरन्स किंवा युनिक एनरिचमेंट पाईपलाईन्स—तर बनवा, कारण ती IP Microsoft साठी सामान्य स्वरूपात तयार करणे कठीण आहे.
वगळा जर तुमच्या मूल्याचा डेटा लोकॅलिटीशी (data locality) काहीही संबंध नसेल. प्रोजेक्ट मॅनेजमेंट सूट किंवा जनरल-पर्पज API गेटवेला वर्कस्पेसच्या आत राहण्याची गरज नसते. जर तुमचे लक्ष्यित ग्राहक मल्टी-क्लाउड न्यूट्रल असण्यावर अभिमान बाळगत असतील, तर हे वगळा; त्यांना Fabric मध्ये डिप्लॉय करण्यास सांगणे त्यांच्या आर्किटेक्चरल स्वातंत्र्याशी तडजोड करण्यासारखे आहे. जर तुम्हाला मार्जिन सुरक्षित ठेवण्यासाठी इन्फ्रास्ट्रक्चर खर्चावर सूक्ष्म नियंत्रण हवे असेल, तर हे वगळा. Microsoft चा कॉम्प्युट ओपेक पूल भाड्याने घेणे हे कॉस्ट इंजिनिअरिंगच्या दृष्टीने सुसंगत नाही.
९० दिवसांची वास्तववादी तपासणी (Reality Check)
जोपर्यंत तुम्ही हा तीन टप्प्यांतील प्रयोग पूर्ण करत नाही, तोपर्यंत पूर्ण रोडमॅपसाठी वचनबद्ध होऊ नका.
दिवस १ ते ३०: सर्वात कठीण भागाचा प्रोटोटाइप तयार करा. एक 'थिन व्हर्टिकल स्लाईस' तयार करा, पण तो साध्या आणि वास्तववादी स्वरूपात असावा. एक आयटम प्रकार निवडा, 'create' आणि 'delete' कार्यान्वित करा आणि OneLake मधून डेटा वाचण्यासाठी किंवा लिहिण्यासाठी एक युजर इंटरअॅक्शन करा. ध्येय एखादा सुंदर स्क्रीनशॉट घेणे हे नाही. ध्येय तुमच्या बॅकएंड आणि Fabric च्या लाइफसायकल कॉन्ट्रॅक्टमधील घर्षण (friction) मोजणे हे आहे.
दिवस ३१ ते ६०: प्रत्यक्ष वापराद्वारे खर्चाचे मॉडेलिंग करा. एक ट्रायल कॅपॅसिटी सुरू करा आणि त्यावर वास्तववादी लोड पॅटर्न चालवून पहा. प्रत्येक युजर ॲक्शनसाठी होणारा CU बर्न मोजा. तुमच्या अपेक्षित कन्करन्सीनुसार त्याचा अंदाज घ्या. तुमच्या मार्जिनचा अंदाज लावू नका. लक्षात ठेवा की ट्रायल कॅपॅसिटी अनेकदा पेड कॅपॅसिटीपेक्षा वेगळी वागते, त्यामुळे मर्यादेची (boundary) कडक चाचणी घ्या. जर तुमचे आकडे तुमच्या पायलट स्केलच्या दहापट वाढल्यावर टिकले नाहीत, तर ते प्रोडक्शनमध्ये कोलमडतील.
दिवस ६१ ते ९०: डिझाइन पार्टनर्ससोबत पडताळणी करा. असे दोन किंवा तीन ग्राहक निवडा जे खरोखर Microsoft वापरतात, केवळ चौकस करणारे (tire-kickers) नाहीत. त्यांना नेमके प्रश्न विचारा. नेटिव्ह डिप्लॉयमेंटमुळे त्यांच्या सिक्युरिटी रिव्ह्यूचा वेळ कमी झाला का? त्यांच्या टेनंट ॲडमिनने एखाद्या स्वतंत्र SaaS ॲप्लिकेशनपेक्षा याला लवकर मंजुरी दिली का? Fabric च्या आत असल्यामुळे तुमच्या टूलसाठी ते बजेट ठरवण्याच्या पद्धतीत काही बदल झाला का? जर उत्तरे अस्पष्ट असतील, तर तुम्ही केवळ मार्केटिंग इंटिग्रेशनकडे पाहत आहात, डिस्ट्रिब्युशन चॅनेलकडे नाही.
इन्फ्रास्ट्रक्चर बनणे
या प्लॅटफॉर्मचे भविष्य मानवी डॅशबोर्ड्समध्ये नाही, तर एजंट्समध्ये आहे. AI ऑर्केस्ट्रेटर्स चार्ट मिळवण्यासाठी स्वतंत्र SaaS पोर्टल्समध्ये लॉग इन करणार नाहीत. ते अशा वर्कलोड्सना कॉल करतील ज्यांना डेटा इस्टेटचा नेटिव्ह आणि ऑथेंटिकेटेड ॲक्सेस आहे. जर तुम्ही योग्य प्रकारे बांधले, तर तुम्ही एक 'कॉम्प्युट लेयर' बनाल ज्याला एजंट कॉल करेल—केवळ मानवाने उघडायचा आणखी एक डॅशबोर्ड नाही.
Fabric ला केवळ एक मार्केटप्लेस समजा, तर तुम्ही एक 'डिस्पोजेबल विजेट' म्हणून संपून जाल. याउलट, ग्राहकाच्या डेटा आर्किटेक्चरच्या केंद्रस्थानी एक डिस्ट्रिब्युशन चॅनेल म्हणून याचा वापर करा, आणि तुम्ही त्यांच्या ऑपरेशन्समध्ये इतके खोलवर रुजून जाल की तिथून बाहेर पडणे महाग पडेल. असा मार्ग निवडा जिथे केवळ तुमचा 'लॉगिन बॉक्स' नाही, तर तुमचे 'लॉजिक' देखील त्या डेटा इस्टेटचा भाग बनेल.