সফটওয়্যার টিমগুলো Fabric Workload Dev Kit-এর ক্ষেত্রে একই ধরনের ক্যাটাগরি ভুল করে থাকে। তারা এটিকে একটি পাবলিশিং পাইপলাইন, একটি সার্টিফিকেশন চেকলিস্ট এবং একটি পার্টনার পোর্টাল হিসেবে দেখে। অন্য কথায়, তারা এটিকে একটি মার্কেটপ্লেস হিসেবে দেখে। তারা কল্পনা করে এটি একটি add-in যা গ্রাহকরা তাদের Microsoft stack-এর সাথে ব্যবহার করার জন্য খুঁজে পায়, ডাউনলোড করে এবং চালায়।
এটি ভুল দৃষ্টিভঙ্গি। একটি Fabric workload কোনো আনুষঙ্গিক বিষয় (accessory) নয়। এটি একটি native surface। একবার ডেপ্লয় করার পর, আপনার অ্যাপ্লিকেশনটি Lakehouse, Power BI এবং Notebook-এর মতো একই শেলে (shell) অবস্থান করে। ওয়ার্কস্পেসের মধ্যে এটি নিজস্ব আইটেম টাইপ পায়। ব্যবহারকারী যখন "New" ক্লিক করেন, তখন এটি প্রদর্শিত হয়। আপনার UI Fabric chrome-এর ভেতরে রেন্ডার হয়, কোনো পপ-আউট ট্যাবে নয়। আপনার ফিচার সেট ঠিক সেখানেই থাকে যেখানে ডেটা টিমগুলো ইতিমধ্যে তাদের কাজের সময় ব্যয় করে। এটি কোনো ডিস্ট্রিবিউশন সাইডবার নয়। এটি Microsoft-এর ডেটা অপারেটিং সিস্টেমের প্রতি একটি কাঠামোগত প্রতিশ্রুতি। এটিকে যদি কেবল একটি লিস্টিং হিসেবে মূল্যায়ন করেন, তবে আপনি এমন একটি প্ল্যাটফর্মের ভেতরে আটকা পড়ে যেতে পারেন যা আপনার নিয়ন্ত্রণে নেই।
নেটিভ সুবিধা
যখন আপনি Fabric-এর জন্য তৈরি করেন, তখন আপনি হোস্ট এনভায়রনমেন্টের বিশ্বাস এবং প্রেক্ষাপট (context) উত্তরাধিকারসূত্রে পান। আপনার workload OneLake-তে read এবং write অ্যাক্সেস পায়, যার মানে হলো আপনার অ্যাপ্লিকেশনটি ডেটা ডজনখানেক ETL পাইপলাইনের মাধ্যমে কপি না করেই সরাসরি Delta tables কুয়েরি করতে পারে। Authentication প্রক্রিয়া Microsoft Entra ID-এর মাধ্যমে সম্পন্ন হয়, তাই আপনার অ্যাপ্লিকেশনটি সাইন-ইন করা ব্যবহারকারীর মতো কাজ করে। এখানে আলাদা কোনো ক্রেডেনশিয়াল ভল্ট পরিচালনা করার প্রয়োজন নেই, কোনো SSO ব্রিজ মেইনটেইন করতে হয় না এবং সিকিউরিটি টিমের জন্য ফিশিং-প্রবণ পাসওয়ার্ড প্রম্পটের কোনো দুশ্চিন্তা থাকে না।
টেকনিক্যাল হুকগুলোর মতোই অপারেশনাল গ্র্যাভিটি (operational gravity) অত্যন্ত গুরুত্বপূর্ণ। যেহেতু গ্রাহকের ডেটা তাদের নিজস্ব টেন্যান্টের (tenant) ভেতরেই থাকে, তাই আপনি সেই প্রকিউরমেন্ট থিয়েটার (procurement theater) এড়িয়ে যেতে পারেন যা বেশিরভাগ এন্টারপ্রাইজ SaaS ডিলকে নষ্ট করে দেয়। একজন CISO-কে ডেটা রেসিডেন্সি নিয়ে বিতর্ক করতে হয় না। একজন প্রকিউরমেন্ট অফিসারকে egress চার্জ মডেল করতে হয় না। আপনার সফটওয়্যারটি কেবল সেই দেয়ালের ভেতরে কাজ করে যা তারা ইতিমধ্যে মালিকানাধীন। নিয়ন্ত্রিত শিল্পে—যেমন হেলথকেয়ার নেটওয়ার্ক, আর্থিক পরিষেবা, সরকারি সংস্থা—বিক্রয়কারী ভেন্ডরদের জন্য এই একটি বৈশিষ্ট্য বারো সপ্তাহের সিকিউরিটি রিভিউকে মাত্র কয়েক দিনের আলোচনায় নামিয়ে আনতে পারে।
যেখানে ফাঁদগুলো লুকিয়ে থাকে
নেটিভ স্ট্যাটাসের সাথে নেটিভ ডিপেন্ডেন্সি আসে, এবং সেগুলো সীমাবদ্ধতা হিসেবে দেখা দিতে পারে।
প্রথমত, কম্পিউট ম্যাথ (compute math)-এর বিষয়টি রয়েছে। আপনার মার্জিন এখন Microsoft Capacity Units-এর ওপর নির্ভর করে। আপনার workload দ্বারা সম্পাদিত প্রতিটি অপারেশন সেই একই CU পুল ব্যবহার করে যা গ্রাহকের Spark jobs, Semantic models এবং Power BI refreshes পরিচালনা করে। যদি Microsoft মূল্য পরিবর্তন করে, বার্ন মাল্টিপ্লায়ার পরিবর্তন করে বা নতুন ক্যাপাসিটি টিয়ার চালু করে, তবে আপনার সম্মতি ছাড়াই আপনার ইউনিট ইকোনমিক্স (unit economics) পরিবর্তিত হয়ে যাবে। আপনি ইনফ্রাস্ট্রাকচার লেয়ার নিয়ন্ত্রণ করতে পারেন না, যার মানে আপনি এটি অপ্টিমাইজ করতে পারবেন না। আপনি কেবল এটি মডেল করতে পারেন এবং আশাবাদী হতে পারেন।
দ্বিতীয়ত, রোডম্যাপ ঝুঁকি (roadmap risk) বাস্তব। Microsoft-এর একটি সুপ্রতিষ্ঠিত ধরন রয়েছে—তারা দরকারী ভার্টিক্যাল ফিচারগুলো পর্যবেক্ষণ করে এবং তারপর সেগুলোর সমতুল্য হরিজন্টাল ফিচারগুলোকে কোর প্ল্যাটফর্মে অন্তর্ভুক্ত করে ফেলে। যদি আপনার ভ্যালু প্রপোজিশন সাধারণ ডেটা টাস্কের ওপর একটি পাতলা UI wrapper হয়, তবে আপনি এমন জমিতে ঘর তৈরি করছেন যা রেডমন্ড (Redmond) শেষ পর্যন্ত দাবি করতে পারে। একমাত্র প্রতিরক্ষা হলো গভীরতা (depth) এবং ডোমেইন স্পেসিফিসিটি (domain specificity)। সাধারণ ডেটা ক্লিনিং বা সাধারণ ভিজ্যুয়ালাইজেশন টুলগুলো সময়ের সাথে সাথে ঝুঁকির মুখে পড়বে। প্রোপাইটারি মেশিন লার্নিং মডেল, শিল্প-নির্দিষ্ট গণনা, বা কাস্টম টেলিমেট্রি স্কিমা জুড়ে কাজ করতে সক্ষম অবজারভেবিলিটি লজিক (observability logic) টিকে থাকার ভালো সম্ভাবনা রাখে।
তৃতীয়ত, ইঞ্জিনিয়ারিং প্রচেষ্টাকে প্রায়শই অবমূল্যায়ন করা হয়। কুইকস্টার্ট টিউটোরিয়াল এবং স্যাম্পল রিপোজিটরিগুলো দেখে মনে হতে পারে যে আপনি এক বিকেলেই একটি workload দাঁড় করিয়ে ফেলতে পারবেন। আপনি পারবেন, যদি আপনার লক্ষ্য কেবল একটি ডেমো দেখানো হয়। কিন্তু প্রোডাকশন ভিন্ন। আপনাকে সম্পূর্ণ ব্যাকএন্ড কন্ট্রাক্ট (backend contract) ইমপ্লিমেন্ট করতে হবে, আইটেম লাইফসাইকেল ইভেন্ট হ্যান্ডেল করতে হবে, আপনার কন্ট্রোল প্লেন এবং Fabric-এর মধ্যে স্টেট সিনক্রোনাইজেশন ম্যানেজ করতে হবে এবং ক্যাপাসিটি পজ (pause) বা রিকানেক্ট হওয়ার সময় দক্ষতার সাথে রিকভার করতে হবে। ব্যবহারকারী যে সারফেসটি স্পর্শ করেন তা সহজ হতে পারে, কিন্তু এর নিচের কন্ট্রাক্টটি মোটেও সহজ নয়।
এটি তৈরি করবেন, নাকি বাদ দেবেন?
সিদ্ধান্তটি আপনার ভ্যালু বা মান কোথা থেকে আসছে তার ওপর নির্ভর করা উচিত, Microsoft-এর ইকোসিস্টেমের প্রতি আপনার উৎসাহের ওপর নয়।
তৈরি করুন যদি আপনার পণ্যটি গ্রাহকের ডেটার যত কাছাকাছি থাকবে তত বেশি মূল্যবান হয়। অবজারভেবিলিটি প্ল্যাটফর্ম, শিল্প-নির্দিষ্ট অ্যানালিটিক্স ইঞ্জিন এবং গভর্নেন্স টুলস—সবই এখানে অন্তর্ভুক্ত। তৈরি করুন যদি আপনার ক্রেতারা ইতিমধ্যে Microsoft stack-এর গভীরে থাকেন এবং নতুন কোনো ভেন্ডর যুক্ত করার চেয়ে খরচ একীভূত করতে পছন্দ করেন। তৈরি করুন যদি আপনার ইন্টেলেকচুয়াল প্রপার্টি স্টোরেজ লেয়ারের উপরে থাকে—যেমন প্রোপাইটারি ডোমেইন লজিক, কাস্টম ML inference, বা ইউনিক এনরিচমেন্ট পাইপলাইন—কারণ এই IP-গুলো Microsoft-এর পক্ষে সাধারণভাবে রেপ্লিকেট করা কঠিন।
এড়িয়ে চলুন যদি আপনার ভ্যালু বা মূল্যের সাথে ডেটা লোকালিটির (data locality) কোনো সম্পর্ক না থাকে। একটি প্রজেক্ট ম্যানেজমেন্ট সুইট বা একটি জেনারেল-পারপাস API গেটওয়েকে ওয়ার্কস্পেসের (workspace) ভেতরে থাকার প্রয়োজন নেই। এড়িয়ে চলুন যদি আপনার টার্গেট কাস্টমাররা মাল্টি-ক্লাউড নিউট্রাল (multi-cloud neutral) হতে গর্ববোধ করেন; তাদের Fabric-এর ভেতরে ডেপ্লয় করতে বলা তাদের আর্কিটেকচারাল স্বাধীনতার সাথে আপস করা। এড়িয়ে চলুন যদি আপনার মার্জিন রক্ষা করার জন্য ইনফ্রাস্ট্রাকচার খরচের ওপর সূক্ষ্ম নিয়ন্ত্রণ (granular control) প্রয়োজন হয়। Microsoft-এর কম্পিউট ওপেক পুল (compute opaque pool) ভাড়া করা কস্ট ইঞ্জিনিয়ারিংয়ের (cost engineering) সাথে সামঞ্জস্যপূর্ণ নয়।
৯০ দিনের রিয়েলিটি চেক
এই তিন-পর্যায়ের পরীক্ষাটি না চালানো পর্যন্ত একটি পূর্ণাঙ্গ রোডম্যাপের প্রতিশ্রুতি দেবেন না।
১ থেকে ৩০ দিন: সবচেয়ে কঠিন অংশটির প্রোটোটাইপ তৈরি করুন। একটি থিন ভার্টিকাল স্লাইস (thin vertical slice) তৈরি করুন, তবে সেটি দেখতে খুব সুন্দর না হলেও চলবে, শুধু যেন বাস্তবসম্মত হয়। একটি আইটেম টাইপ বেছে নিন, 'create' এবং 'delete' ফিচারটি ইমপ্লিমেন্ট করুন এবং এমন একটি ইউজার ইন্টারঅ্যাকশন সম্পন্ন করুন যা প্রকৃতপক্ষে OneLake থেকে ডেটা পড়ে বা সেখানে ডেটা লেখে। লক্ষ্য কোনো সুন্দর স্ক্রিনশট নেওয়া নয়। লক্ষ্য হলো আপনার ব্যাকএন্ড এবং Fabric-এর লাইফসাইকেল কন্ট্রাক্টের (lifecycle contract) মধ্যে ঘর্ষণ বা বাধা (friction) পরিমাপ করা।
৩১ থেকে ৬০ দিন: লাইভ লোড দিয়ে খরচের মডেল তৈরি করুন। একটি ট্রায়াল ক্যাপাসিটি (trial capacity) চালু করুন এবং এর ওপর বাস্তবসম্মত লোড প্যাটার্ন চালিয়ে দেখুন। প্রতি ইউজার অ্যাকশনে কতটুকু CU বার্ন (burn) হচ্ছে তা পরিমাপ করুন। আপনার প্রত্যাশিত কনকারেন্সি (concurrency) অনুযায়ী এর পূর্বাভাস দিন। আপনার মার্জিন নিয়ে আন্দাজে কিছু বলবেন না। মনে রাখবেন যে ট্রায়াল ক্যাপাসিটিগুলো প্রায়শই পেইড ক্যাপাসিটির চেয়ে ভিন্নভাবে কাজ করে, তাই সীমানার ওপর চাপ (stress the boundary) দিয়ে পরীক্ষা করুন। যদি আপনার পাইলট স্কেলের তুলনায় দশ গুণ লোডে সংখ্যাগুলো ঠিক না থাকে, তবে প্রোডাকশনে সেগুলো ভেঙে পড়বে।
৬১ থেকে ৯০ দিন: ডিজাইন পার্টনারদের মাধ্যমে যাচাই করুন। এমন দুই বা তিনজন কাস্টমারকে আনুন যারা প্রকৃতপক্ষে Microsoft ব্যবহারকারী, কেবল আগ্রহ দেখানোর জন্য নয়। সুনির্দিষ্ট প্রশ্ন করুন। নেটিভ ডেপ্লয়মেন্ট কি তাদের সিকিউরিটি রিভিউয়ের সময় কমিয়ে দিয়েছে? তাদের টেন্যান্ট অ্যাডমিন কি একটি স্ট্যান্ডঅ্যালোন SaaS অ্যাপ্লিকেশনের চেয়ে এটি দ্রুত অনুমোদন করবেন? Fabric-এর ভেতরে থাকার ফলে কি আপনার টুলের জন্য তাদের বাজেট করার পদ্ধতিতে কোনো পরিবর্তন আসে? যদি উত্তরগুলো অস্পষ্ট হয়, তবে আপনি কেবল একটি মার্কেটিং ইন্টিগ্রেশন দেখছেন, কোনো ডিস্ট্রিবিউশন চ্যানেল নয়।
ইনফ্রাস্ট্রাকচার হয়ে ওঠা
এই প্ল্যাটফর্মের ভবিষ্যৎ মানুষের জন্য তৈরি ড্যাশবোর্ড নয়; বরং এটি হলো এজেন্ট (agents)। AI অর্কেস্ট্রেটররা (orchestrators) কোনো চার্ট সংগ্রহের জন্য আলাদা SaaS পোর্টালে লগ-ইন করবে না। তারা এমন ওয়ার্কলোড কল করবে যার ডেটা এস্টেটের (data estate) ওপর নেটিভ এবং অথেনটিকেটেড অ্যাক্সেস রয়েছে। আপনি যদি সঠিকভাবে তৈরি করেন, তবে আপনি সেই কম্পিউট লেয়ার (compute layer) হয়ে উঠবেন যা একটি এজেন্ট কল করে—কেবল মানুষের জন্য খোলা অন্য একটি ড্যাশবোর্ড হিসেবে নয়।
Fabric-কে যদি একটি মার্কেটপ্লেস হিসেবে বিবেচনা করেন, তবে আপনি শেষে একটি ব্যবহারযোগ্য উইজেট (disposable widget) হিসেবেই থেকে যাবেন। এটিকে গ্রাহকের ডেটা আর্কিটেকচারের কেন্দ্রে পৌঁছানোর একটি ডিস্ট্রিবিউশন চ্যানেল হিসেবে বিবেচনা করুন, এবং আপনি তাদের অপারেশনের সাথে এতটাই গভীরভাবে মিশে যাবেন যে সেখান থেকে বেরিয়ে আসা ব্যয়বহুল হয়ে পড়বে। সেই পথটি বেছে নিন যেখানে কেবল আপনার লগইন বক্স নয়, বরং আপনার লজিকও সেই ডেটা এস্টেটের অংশ হয়ে ওঠে।