மென்பொருள் குழுக்கள் Fabric Workload Dev Kit-ஐப் பார்க்கும்போது ஒரே மாதிரியான வகைப்பாட்டுப் பிழையை (category error) மீண்டும் மீண்டும் செய்கிறார்கள். அவர்கள் ஒரு வெளியீட்டுப் பாதை (publishing pipeline), சான்றிதழ் சரிபார்ப்புப் பட்டியல் (certification checklist) மற்றும் ஒரு கூட்டாளர் போர்ட்டலை (partner portal) மட்டுமே பார்க்கிறார்கள். வேறு வார்த்தைகளில் கூறுவதானால், அவர்கள் ஒரு சந்தையை (marketplace) பார்க்கிறார்கள். வாடிக்கையாளர்கள் தங்களது Microsoft stack உடன் இணைந்து கண்டறிந்து, பதிவிறக்கம் செய்து இயக்கும் ஒரு add-in ஆக இதை அவர்கள் கற்பனை செய்கிறார்கள்.
அது தவறான பார்வை. ஒரு Fabric workload என்பது ஒரு துணைப்பொருள் (accessory) அல்ல. அது ஒரு இயல்பான மேற்பரப்பு (native surface). ஒருமுறை வரிசைப்படுத்தப்பட்டதும் (deployed), உங்கள் பயன்பாடு Lakehouse, Power BI மற்றும் Notebook ஆகியவற்றுடன் ஒரே கட்டமைப்பிற்குள் (shell) வாழும். இது workspace-இல் தனக்கென ஒரு item type-ஐப் பெறுகிறது. ஒரு பயனர் "New" என்பதைக் கிளிக் செய்யும்போது இது தோன்றும். உங்கள் UI, Fabric chrome-க்குள் இயங்கும், தனியாகத் தோன்றும் ஒரு tab-இல் அல்ல. உங்கள் அம்சங்கள் (feature set) தரவுக் குழுக்கள் ஏற்கனவே தங்கள் வேலை நேரத்தைச் செலவிடும் இடத்திலேயே அமைகின்றன. இது ஒரு விநியோகத் துணைப் பக்கம் (distribution sidebar) அல்ல. இது Microsoft-இன் தரவு இயங்குதளத்திற்கான (data operating system) ஒரு கட்டமைப்பு ரீதியான அர்ப்பணிப்பு. இதை ஒரு பட்டியலாக (listing) மட்டும் நீங்கள் மதிப்பீடு செய்தால், நீங்கள் கட்டுப்படுத்த முடியாத ஒரு தளத்திற்குள் சிக்கிக்கொள்ளக்கூடும்.
இயல்பான சாதகம் (The Native Advantage)
நீங்கள் Fabric-க்காக உருவாக்கும்போது, அந்தத் தளத்தின் நம்பகத்தன்மையையும் சூழலையும் (context) நீங்கள் பெறுகிறீர்கள். உங்கள் workload, OneLake-க்கு வாசிப்பு மற்றும் எழுத்து அணுகலைப் (read and write access) பெறுகிறது, இதன் பொருள் உங்கள் பயன்பாடு ஒரு டஜன் ETL pipelines மூலம் தரவை நகலெடுக்காமல் நேரடியாக Delta tables-களைக் கோர (query) முடியும். Authentication, Microsoft Entra ID வழியாக நடைபெறுவதால், உங்கள் பயன்பாடு உள்நுழைந்த பயனராகச் செயல்படும். நிர்வகிக்கத் தனிப்பயன் கடவுச்சொல் களஞ்சியம் (credential vault) தேவையில்லை, பராமரிக்க SSO bridge தேவையில்லை, மேலும் பாதுகாப்புத் குழுவினர் கவலைப்பட வேண்டிய phishing-க்கு வாய்ப்புள்ள கடவுச்சொல் கோரிக்கைகளும் (password prompts) இருக்காது.
தொழில்நுட்பத் தொடர்புகளைப் போலவே, செயல்பாட்டு ஈர்ப்பு விசையும் (operational gravity) முக்கியமானது. வாடிக்கையாளரின் தரவு அவர்களின் சொந்த tenant-க்குள்ளேயே இருப்பதால், பெரும்பாலான நிறுவன SaaS ஒப்பந்தங்களைக் முடக்கும் தேவையற்ற கொள்முதல் நடைமுறைகளை (procurement theater) நீங்கள் தவிர்க்கலாம். ஒரு CISO தரவு இருப்பிடத்தைப் (data residency) பற்றி விவாதிக்க வேண்டிய அவசியமில்லை. ஒரு கொள்முதல் அதிகாரி egress கட்டணங்களைக் கணக்கிட வேண்டிய அவசியமில்லை. உங்கள் மென்பொருள் அவர்கள் ஏற்கனவே வைத்திருக்கும் எல்லைகளுக்குள்ளேயே இயங்குகிறது. ஒழுங்குமுறைப்படுத்தப்பட்ட தொழில்துறைகளுக்கு (regulated industries)—மருத்துவ நெட்வொர்க்குகள், நிதிச் சேவைகள், அரசு முகமைகள்—விற்பனை செய்யும் விற்பனையாளர்களுக்கு, இந்த ஒற்றைப் பண்பு பன்னிரண்டு வார பாதுகாப்பு ஆய்வை சில நாட்களுக்குள் முடிக்கும் உரையாடலாக மாற்றும்.
பொறிகள் எங்கே ஒளிந்துள்ளன
இயல்பான அந்தத் தகுதியுடன் (Native status), இயல்பான சார்புகளும் (native dependencies) வருகின்றன, அவை கட்டுப்பாடுகளாக மாறக்கூடும்.
முதலாவதாக, கணக்கீட்டுத் toán (compute math) உள்ளது. உங்கள் லாப வரம்பு (margins) இப்போது Microsoft Capacity Units-ஐச் சார்ந்திருக்கிறது. உங்கள் workload செய்யும் ஒவ்வொரு செயல்பாடும், வாடிக்கையாளரின் Spark jobs, Semantic models மற்றும் Power BI refreshes ஆகியவற்றுக்குத் தேவையான அதே CU தொகுப்பையே பயன்படுத்துகிறது. Microsoft விலையை மாற்றினாலோ, burn multipliers-ஐ மாற்றினாலோ அல்லது புதிய capacity tiers-களை அறிமுகப்படுத்தினாலோ, உங்கள் பொருளாதாரக் கணக்கீடுகள் (unit economics) உங்கள் அனுமதியின்றி மாறும். உங்களால் உள்கட்டமைப்பு அடுக்கைக் (infrastructure layer) கட்டுப்படுத்த முடியாது, அதாவது அதை உங்களால் மேம்படுத்த (optimize) முடியாது. உங்களால் அதை மாதிரியாகக் (model) கணிக்க மட்டுமே முடியும், அது சிறப்பாக அமையும் என்று நம்பしか முடியாது.
இரண்டாவதாக, சாலை வரைபட அபாயம் (roadmap risk) உண்மையானது. பயனுள்ள செங்குத்து அம்சங்களைக் (vertical features) கவனித்து, பின்னர் அவற்றின் கிடைமட்டத் (horizontal) இணையான அம்சங்களை மையத் தளத்திலேயே இணைக்கும் முறையை Microsoft பின்பற்றி வருகிறது. உங்கள் மதிப்பு முன்மொழிவு (value proposition) பொதுவான தரவுப் பணிகளுக்கான ஒரு மெல்லிய UI wrapper ஆக இருந்தால், நீங்கள் Redmond நிறுவனம் இறுதியில் உரிமை கோரக்கூடிய நிலத்தில் கட்டியெழுப்பிக் கொண்டிருக்கிறீர்கள் என்று அர்த்தம். ஆழம் மற்றும் துறை சார்ந்த தனித்தன்மை (domain specificity) மட்டுமே இதற்கான ஒரே தற்காப்பு முறைகள். பொதுவான தரவுச் சுத்திகரிப்பு (data cleaning) அல்லது எளிய காட்சிப்படுத்தல் (visualization) கருவிகள் காலாவதியாகும் நிலையில் உள்ளன. தனித்துவமான machine learning மாதிரிகள், துறை சார்ந்த கணக்கீடுகள் அல்லது தனிப்பயன் telemetry schemas மூலம் செயல்படும் observability logic ஆகியவை நிலைத்திருக்க அதிக வாய்ப்புள்ளது.
மூன்றாவதாக, பொறியியல் முயற்சி (engineering effort) வழக்கமாகத் தவறாக மதிப்பிடப்படுகிறது. Quickstart பயிற்சிகள் மற்றும் மாதிரி களஞ்சியங்கள் (sample repositories) ஒரு மதியத்திற்குள் ஒரு workload-ஐ உருவாக்கிவிடலாம் என்று தோன்றச் செய்யலாம். ஒரு டெமோ (demo) செய்வதாக இருந்தால் அது சாத்தியமே. ஆனால் உற்பத்திச் சூழல் (production) வேறுபட்டது. நீங்கள் முழுமையான backend contract-ஐச் செயல்படுத்த வேண்டும், item lifecycle நிகழ்வுகளைக் கையாள வேண்டும், உங்கள் control plane மற்றும் Fabric-க்கு இடையிலான state synchronization-ஐ நிர்வகிக்க வேண்டும், மேலும் capacity நிறுத்தப்படும்போதோ அல்லது மீண்டும் இணைக்கப்படும்போதோ முறையாகச் செயல்பட வேண்டும். பயனர் தொடும் மேற்பரப்பு எளிமையாக இருக்கலாம், ஆனால் அதன் அடியில் உள்ள ஒப்பந்தம் (contract) எளிதல்ல.
உருவாக்குவதா அல்லது தவிர்ப்பதா?
இந்த முடிவு Microsoft-இன் ecosystem மீதான உங்கள் ஆர்வத்தைப் பொறுத்தது அல்ல, உங்கள் மதிப்பு எங்கிருந்து உருவாகிறது என்பதைப் பொறுத்தது.
உருவாக்குங்கள், உங்கள் தயாரிப்பு வாடிக்கையாளரின் தரவிற்கு எவ்வளவு நெருக்கமாக இருக்கிறதோ அவ்வளவு மதிப்புமிக்கதாக மாறினால். Observability platforms, துறை சார்ந்த analytics engines மற்றும் governance கருவிகள் அனைத்தும் இதற்குப் பொருந்தும். உங்கள் வாடிக்கையாளர்கள் ஏற்கனவே Microsoft stack-இல் ஆழமாகப் பயணிப்பவர்கள் மற்றும் மற்றொரு விற்பனையாளரைச் சேர்ப்பதை விடத் தங்களது செலவுகளை ஒருங்கிணைக்க விரும்பினால் உருவாக்குங்கள். உங்கள் அறிவுசார் சொத்து (intellectual property) storage layer-க்கு மேலே இருந்தால்—அதாவது தனித்துவமான domain logic, custom ML inference அல்லது தனித்துவமான enrichment pipelines—அதை உருவாக்குங்கள்; ஏனெனில் அந்த IP-யை Microsoft பொதுவான முறையில் நகலெடுப்பது கடினம்.
தவிர்க்கவும் - உங்கள் மதிப்பு தரவு இருப்பிடத்துடன் (data locality) தொடர்பில்லாதது என்றால். ஒரு திட்ட மேலாண்மை தொகுப்பு (project management suite) அல்லது பொதுவான API கேட்வே ஒரு workspace-க்குள் இருக்க வேண்டிய அவசியமில்லை. உங்கள் இலக்கு வாடிக்கையாளர்கள் மல்டி-கிளவுட் நடுநிலைத்தன்மையைக் (multi-cloud neutral) கொண்டிருப்பதில் பெருமைப்படுபவர்கள் என்றால், இதைத் தவிர்க்கவும்; Fabric-க்குள் செயல்படுமாறு (deploy) அவர்களைக் கேட்பது அவர்களின் கட்டமைப்பு சுதந்திரத்தைப் (architectural independence) பாதிக்கும். உங்கள் லாப வரம்பைப் பாதுகாக்கக் கட்டமைப்புச் செலவுகள் (infrastructure costs) மீது நுட்பமான கட்டுப்பாடு தேவைப்பட்டால், இதைத் தவிர்க்கவும். Microsoft-இன் compute opaque pool-ஐ வாடகைக்கு எடுப்பது செலவு பொறியியலுடன் (cost engineering) ஒத்துப்போகாது.
90-நாள் யதார்த்தச் சோதனை
இந்த மூன்று கட்ட சோதனையைச் செய்து முடிக்கும் வரை முழுமையான திட்ட வரைபடத்திற்கு (roadmap) உறுதியளிக்க வேண்டாம்.
நாட்கள் 1 முதல் 30 வரை: கடினமான பகுதியை முன்மாதிரியாக (Prototype) உருவாக்குங்கள். ஒரு சிறிய செங்குத்துத் துண்டை (thin vertical slice) உருவாக்குங்கள், ஆனால் அது பார்ப்பதற்கு அழகாக இருக்க வேண்டிய அவசியமில்லை, உண்மையாக இருக்க வேண்டும். ஒரு வகை உருப்படியைத் (item type) தேர்ந்தெடுத்து, அதை உருவாக்குதல் (create) மற்றும் நீக்குதல் (delete) ஆகியவற்றைச் செயல்படுத்தி, OneLake-லிருந்து தரவைப் படிக்க அல்லது எழுதக்கூடிய ஒரு பயனர் தொடர்பைச் (user interaction) செய்து பாருங்கள். இதன் நோக்கம் ஒரு அழகான ஸ்கிரீன்ஷாட்டை எடுப்பது அல்ல. உங்கள் பேக்எண்ட் (backend) மற்றும் Fabric-இன் லைஃப்சைக்கிள் ஒப்பந்தத்திற்கு (lifecycle contract) இடையிலான உராய்வை அளவிடுவதே இதன் நோக்கமாகும்.
நாட்கள் 31 முதல் 60 வரை: நேரடிச் சூழலில் செலவுகளைக் கணக்கிடுங்கள். ஒரு சோதனைத் திறனை (trial capacity) உருவாக்கி, அதன் மீது யதார்த்தமான பணிச் சுமைகளை (load patterns)ச் செலுத்திப் பாருங்கள். ஒவ்வொரு பயனர் செயல்பாட்டிற்கும் எவ்வளவு CU செலவாகிறது என்பதை அளவிடுங்கள். உங்கள் எதிர்பார்க்கப்படும் ஒரே நேரத்தில் செயல்படும் பயனர்களின் எண்ணிக்கைக்கு (concurrency) ஏற்ப அதை விரிவுபடுத்திப் பாருங்கள். உங்கள் லாப வரம்புகளைக் (margins) guesswork மூலம் கணிக்க வேண்டாம். சோதனைத் திறன்கள் (trial capacities) பெரும்பாலும் கட்டணத் திறன்களிலிருந்து மாறுபட்ட முறையில் செயல்படும் என்பதை நினைவில் கொள்ளுங்கள், எனவே அதன் எல்லைகளைச் சோதித்துப் பாருங்கள். உங்கள் முன்னோடி அளவை விட (pilot scale) பத்து மடங்கு அதிக அளவில் இந்த எண்கள் நிலைக்கவில்லை என்றால், அவை தயாரிப்புச் சூழலில் (production) தோல்வியடையும்.
நாட்கள் 61 முதல் 90 வரை: வடிவமைப்புப் பங்காளிகளுடன் (design partners) சரிபார்க்கவும். வெறும் ஆர்வத்திற்காக மட்டும் அணுகாமல், உண்மையாகவே Microsoft சேவைகளைப் பயன்படுத்தும் இரண்டு அல்லது மூன்று வாடிக்கையாளர்களைக் கொண்டு வாருங்கள். நேரடியான கேள்விகளைக் கேளுங்கள். இயல்பான பயன்பாடு (native deployment) அவர்களின் பாதுகாப்பு ஆய்வை (security review) குறைத்ததா? ஒரு தனித்துவமான SaaS பயன்பாட்டை விட அவர்களின் டெனன்ட் அட்மின் (tenant admin) இதை விரைவாக அங்கீகரிப்பாரா? Fabric-க்குள் இருப்பது உங்கள் கருவிக்கான அவர்களது பட்ஜெட் ஒதுக்கீட்டை மாற்றியதா? பதில்கள் தெளிவற்றதாக இருந்தால், நீங்கள் ஒரு விநியோகச் சேனலை (distribution channel) உருவாக்கவில்லை, மாறாக ஒரு சந்தைப்படுத்தல் ஒருங்கிணைப்பை (marketing integration) மட்டுமே பார்க்கிறீர்கள் என்று அர்த்தம்.
உள்கட்டமைப்பாக மாறுதல்
இந்தத் தளத்தின் எதிர்காலம் மனிதர்களுக்கான டேஷ்போர்டுகள் (dashboards) அல்ல. அது ஏஜெண்டுகள் (agents). AI ஒருங்கிணைப்பாளர்கள் (orchestrators) ஒரு வரைபடத்தைப் பெற தனித்துவமான SaaS போர்ட்டல்களில் லாக்-இன் செய்ய மாட்டார்கள். அவர்கள் தரவுச் சொத்துக்களுக்கு (data estate) இயல்பான, அங்கீகரிக்கப்பட்ட அணுகல் கொண்ட பணிச் சுமைகளை (workloads) அழைப்பார்கள். நீங்கள் சரியாகக் கட்டமைத்தால், ஒரு ஏஜெண்ட் அழைக்கும் கணக்கீட்டு அடுக்காக (compute layer) நீங்கள் மாறுவீர்கள்—மனிதர்கள் திறக்கும் மற்றொரு டேஷ்போர்டாக மட்டும் அல்ல.
Fabric-ஐ ஒரு சந்தையாக (marketplace) மட்டும் கருதினால், நீங்கள் ஒரு எளிதில் மாற்றக்கூடிய சிறிய கருவியாக (disposable widget) மாறிவிடுவீர்கள். அதை வாடிக்கையாளரின் தரவுக் கட்டமைப்பின் (data architecture) மையப்பகுதிக்குச் செல்லும் ஒரு விநியோகச் சேனலாகக் கருதினால், நீங்கள் அவர்களின் செயல்பாடுகளில் ஆழமாகப் பதிந்துவிடுவீர்கள், இதனால் அங்கிருந்து வெளியேறுவது அவர்களுக்குச் செலவு மிகுந்ததாக மாறும். உங்கள் லாகின் பாக்ஸ் (login box) மட்டுமல்லாமல், உங்கள் லாஜிக் (logic) கூட அந்தத் தரவுச் சொத்தின் (estate) ஒரு பகுதியாக மாறும் பாதையைத் தேர்ந்தெடுங்கள்.