تیمهای نرمافزاری مدام مرتکب یک خطای دستهبندی مشابه هنگام بررسی Fabric Workload Dev Kit میشوند. آنها یک خط لوله انتشار، یک چکلیست گواهینامه و یک پورتال شرکا را میبینند. به عبارت دیگر، آنها یک بازارچه (marketplace) را میبینند. آنها یک افزونه (add-in) را تصور میکنند که مشتریان آن را کشف، دانلود و در کنار پشته (stack) مایکروسافت خود اجرا میکنند.
این دیدگاه اشتباه است. یک Fabric workload یک وسیله جانبی نیست، بلکه یک سطح بومی (native surface) است. پس از استقرار، اپلیکیشن شما درون همان پوستهای زندگی میکند که Lakehouse، Power BI و Notebook در آن قرار دارند. این اپلیکیشن در فضای کاری (workspace) خود نوع آیتم (item type) مخصوص به خود را دارد. وقتی کاربر روی "New" کلیک میکند، اپلیکیشن شما ظاهر میشود. رابط کاربری (UI) شما در قالب اصلی Fabric رندر میشود، نه در یک تب جداگانه. مجموعه ویژگیهای شما دقیقاً همان جایی قرار میگیرد که تیمهای داده ساعات کاری خود را در آن میگذرانند. این یک نوار کناری برای توزیع نیست؛ بلکه یک تعهد ساختاری به سیستمعامل دادهی Microsoft است. اگر آن را صرفاً به عنوان یک لیستینگ (listing) ارزیابی کنید، ممکن است خود را در پلتفرمی بیابید که کنترلی بر آن ندارید.
مزیت بومی
وقتی برای Fabric میسازید، اعتماد و کانتکست (context) محیط میزبان را به ارث میبرید. workload شما به OneLake دسترسی خواندن و نوشتن دارد، به این معنی که اپلیکیشن شما میتواند مستقیماً جداول Delta را بدون کپی کردن دادهها از طریق دهها خط لوله ETL، کوئری بگیرد. فرآیند احراز هویت از طریق Microsoft Entra ID انجام میشود، بنابراین اپلیکیشن شما به عنوان همان کاربرِ وارد شده (signed-in user) عمل میکند. دیگر نیازی به مدیریت یک خزانه اعتبارنامهی مجزا، حفظ یک پل SSO یا نگرانی تیم امنیتی از اعلانهای رمز عبور مستعد فیشینگ نیست.
اهمیت عملیاتی به اندازه قلابهای فنی حائز اهمیت است. از آنجایی که دادههای مشتری در محیط (tenant) خودشان باقی میماند، شما از فرآیندهای پیچیده و نمایشی خرید (procurement theater) که اکثر قراردادهای SaaS سازمانی را از بین میبرد، عبور میکنید. یک CISO نیازی به بحث درباره اقامت دادهها (data residency) ندارد. یک افسر تدارکات نیازی به مدلسازی هزینههای خروج داده (egress charges) ندارد. نرمافزار شما صرفاً در حصارهایی عمل میکند که آنها از قبل مالک آن هستند. برای فروشندگانی که به صنایع تحت نظارت — مانند شبکههای مراقبتهای بهداشتی، خدمات مالی و آژانسهای دولتی — میفروشند، همین یک ویژگی میتواند یک بررسی امنیتی دوازده هفتهای را به گفتگویی تبدیل کند که تنها چند روز طول میکشد.
تلهها کجا پنهان شدهاند
وضعیت بومی بودن با وابستگیهای بومی همراه است و این وابستگیها میتوانند به محدودیت تبدیل شوند.
اول، بحث محاسبات (compute math) مطرح است. حاشیه سود شما اکنون به Microsoft Capacity Units وابسته است. هر عملیاتی که workload شما انجام میدهد، از همان استخر CUs استفاده میکند که وظایف Spark، مدلهای Semantic و بازنشانیهای (refreshes) Power BI مشتری را تغذیه میکند. اگر Microsoft قیمتها را تنظیم کند، ضرایب مصرف را تغییر دهد یا سطوح ظرفیت جدیدی معرفی کند، اقتصاد واحد (unit economics) شما بدون رضایت شما تغییر میکند. شما لایه زیرساخت را کنترل نمیکنید، به این معنی که نمیتوانید آن را بهینه کنید؛ تنها میتوانید آن را مدلسازی کنید و امیدوار باشید.
دوم، ریسک نقشه راه (roadmap risk) واقعی است. Microsoft الگوی مستندی دارد: ویژگیهای عمودی (vertical) مفید را مشاهده میکند و سپس معادلهای افقی (horizontal) آنها را در هسته اصلی پلتفرم ادغام میکند. اگر ارزش پیشنهادی شما صرفاً یک پوشش رابط کاربری (UI wrapper) نازک روی وظایف رایج داده باشد، در حال ساختن چیزی روی زمینی هستید که Redmond ممکن است در نهایت آن را تصاحب کند. تنها دفاع شما، «عمق» و «تخصصی بودن در حوزه» است. ابزارهای عمومی پاکسازی داده یا ابزارهای ساده بصریسازی با یک ساعت شنی روبرو هستند. مدلهای یادگیری ماشین اختصاصی، محاسبات خاص صنعت، یا منطق مشاهدهپذیری (observability) که بر اساس طرحهای تلهمتری سفارشی استدلال میکند، شانس بیشتری برای ضروری باقی ماندن دارند.
سوم، تلاش مهندسی معمولاً دستکم گرفته میشود. آموزشهای شروع سریع (quickstart) و مخازن نمونه باعث میشوند به نظر برسد که میتوانید یک workload را در یک بعدازظهر راهاندازی کنید. اگر هدف شما فقط یک دمو باشد، بله، میتوانید. اما محیط عملیاتی (production) متفاوت است. شما باید قرارداد کامل بکاند (backend contract) را پیادهسازی کنید، رویدادهای چرخه حیات آیتم را مدیریت کنید، همگامسازی وضعیت بین صفحه کنترل (control plane) خود و Fabric را مدیریت کنید و در صورت توقف یا اتصال مجدد ظرفیت، به شکلی صحیح بازیابی شوید. سطحی که کاربر لمس میکند ممکن است ساده باشد، اما قرارداد زیرین آن ساده نیست.
بسازید یا بیخیال شوید؟
این تصمیم باید بر اساس منشأ ارزش شما باشد، نه اشتیاق شما برای اکوسیستم Microsoft.
بسازید اگر محصول شما هرچه به دادههای مشتری نزدیکتر باشد، ارزشمندتر میشود. پلتفرمهای مشاهدهپذیری (observability)، موتورهای تحلیلی خاص صنعت و ابزارهای حاکمیت (governance) همگی در این دسته قرار میگیرند. اگر خریداران شما در حال حاضر عمیقاً در پشته Microsoft هستند و ترجیح میدهند هزینههای خود را تجمیع کنند تا اینکه فروشنده دیگری را اضافه کنند، بسازید. اگر مالکیت معنوی (IP) شما بالاتر از لایه ذخیرهسازی قرار دارد — مانند منطق اختصاصی حوزه، استنتاج ML سفارشی یا خط لولههای غنیسازی منحصربهفرد — بسازید، زیرا بازسازی آن IP به صورت عمومی برای Microsoft دشوار است.
صرفنظر کنید اگر ارزش پیشنهادی شما ربطی به محلی بودن دادهها (data locality) ندارد. یک مجموعه مدیریت پروژه یا یک API gateway همهمنظوره نیازی ندارد که درون یک workspace مستقر شود. اگر مشتریان هدف شما به بیطرف بودن نسبت به ابرهای مختلف (multi-cloud neutral) افتخار میکنند، از این کار صرفنظر کنید؛ درخواست از آنها برای استقرار در Fabric، استقلال معماری آنها را به خطر میاندازد. اگر برای محافظت از حاشیه سود خود، به کنترل دقیق بر هزینههای زیرساخت نیاز دارید، از این کار صرفنظر کنید. اجاره کردن استخر محاسباتی مبهم (opaque pool) مایکروسافت با مهندسی هزینه سازگار نیست.
بررسی واقعبینانه ۹۰ روزه
تا زمانی که این آزمایش سهمرحلهای را اجرا نکردهاید، متعهد به یک نقشه راه کامل نشوید.
روزهای ۱ تا ۳۰: نمونهسازی سختترین بخش. یک برش عمودی باریک (thin vertical slice) بسازید، اما آن را زشت و صادقانه رها کنید. یک نوع آیتم را انتخاب کنید، قابلیت ایجاد و حذف را پیادهسازی کنید و یک تعامل کاربر را انجام دهید که واقعاً از OneLake میخواند یا در آن مینویسد. هدف، گرفتن یک اسکرینشات زیبا نیست. هدف، اندازهگیری اصطکاک بین بکاند شما و قرارداد چرخه حیات Fabric است.
روزهای ۳۱ تا ۶۰: مدلسازی هزینهها با شرایط واقعی. یک ظرفیت آزمایشی (trial capacity) راه اندازی کنید و الگوهای بارگذاری واقعبینانه را روی آن اجرا کنید. میزان مصرف CU را به ازای هر اقدام کاربر اندازهگیری کنید. آن را به میزان همزمانی (concurrency) مورد انتظار خود تعمیم دهید. حاشیه سود خود را حدس نزنید. به یاد داشته باشید که ظرفیتهای آزمایشی اغلب با ظرفیتهای پولی متفاوت عمل میکنند، بنابراین مرزها را تحت فشار قرار دهید. اگر اعداد در ده برابر مقیاس آزمایشی شما ثابت نماندند، در محیط عملیاتی (production) از هم میپاشند.
روزهای ۶۱ تا ۹۰: اعتبارسنجی با شرکای طراحی. دو یا سه مشتری بیاورید که واقعاً از زیرساختهای مایکروسافت استفاده میکنند، نه کسانی که فقط وقتگذرانی میکنند. سوالات دقیق و هدفمند بپرسید. آیا استقرار بومی (native deployment) بررسیهای امنیتی آنها را کوتاهتر کرد؟ آیا مدیر مستأجر (tenant admin) آنها این را سریعتر از یک اپلیکیشن SaaS مستقل تایید میکند؟ آیا قرار گرفتن در داخل Fabric، نحوه بودجهبندی آنها برای ابزار شما را تغییر میدهد؟ اگر پاسخها مبهم یا ضعیف بودند، شما با یک ادغام بازاریابی روبرو هستید، نه یک کانال توزیع.
تبدیل شدن به زیرساخت
آینده این پلتفرم داشبوردهای انسانی نیست؛ بلکه عاملها (agents) هستند. ارکستراتورهای هوش مصنوعی برای دریافت یک نمودار، وارد پورتالهای SaaS مستقل نخواهند شد. آنها بارگذاریهای کاری (workloads) را فراخوانی میکنند که دسترسی بومی و احراز شده به داراییهای دادهای (data estate) دارند. اگر درست ساختید، شما به لایه محاسباتی تبدیل میشوید که یک عامل آن را فراخوانی میکند—نه فقط داشبورد دیگری که یک انسان باز میکند.
اگر با Fabric مانند یک بازارچه (marketplace) رفتار کنید، در نهایت به یک ویجت مصرفی تبدیل خواهید شد. اگر با آن به عنوان یک کانال توزیع به قلب معماری دادههای مشتری رفتار کنید، چنان عمیق در عملیات آنها ادغام میشوید که ترک کردن آن هزینهبر خواهد بود. مسیری را انتخاب کنید که در آن منطق شما، و نه فقط کادر ورود (login box) شما، بخشی از داراییهای دادهای (estate) شود.