انتخاب پایه فنی برای یک محصول جدید IoT اغلب فقط به عنوان یک تصمیم در مورد ابزارها دیده میشود. تیمها فریمورکها، سرویسهای ابری، کتابخانهها و سرعت توسعه را مقایسه میکنند و سپس چیزی را انتخاب میکنند که انعطافپذیرتر یا آشناتر به نظر برسد. اما در واقعیت، این تصمیم تقریباً همه چیزهای بعدی را شکل میدهد: محصول با چه سرعتی میتواند تکامل پیدا کند، هزینه عملیاتی آن چقدر خواهد بود، ارتقا دادنش چقدر ایمن است و آیا واقعاً میتواند از موفقیت خودش جان سالم به در ببرد.
این موضوع برای شرکتهایی که محصولات قابل استفاده مجدد میسازند (نه فقط پروژههای یکباره) خیلی مهمتر است. یک راهحل سفارشی برای یک مشتری، یک سیستم مانیتورینگ داخلی یا یک محصول تجاری IoT ممکن است همهشان داده دستگاه را دریافت کنند و داشبورد نمایش دهند، اما بعد از انتشار اولیه، زندگی خیلی متفاوتی خواهند داشت. تیمهای محصول باید به سالها فکر کنند، نه فقط به دموها؛ به تداوم عملیاتی فکر کنند، نه فقط به سرعت توسعه. اینجا دقیقاً همان جایی است که بحث رایج «open source در مقابل IoT platform» هم مهم میشود و هم اغلب اشتباه درک میشود.
در سطح کلی، این انتخاب معمولاً به صورت آزادی در مقابل ساختار قاببندی میشود. استکهای open-source حداکثر انعطافپذیری، دسترسی گسترده به استعدادها و کنترل کامل روی کدبیس را وعده میدهند. IoT platforms زمان ورود سریعتر به بازار، سرویسهای آماده و کاهش تلاش مهندسی را وعده میدهند. هر دو ادعا درست هستند، اما ناقص. تفاوتهای واقعی فقط وقتی سیستم بزرگ میشود، مشتریها زیاد میشوند و محصول از چیزی که شما اجرا میکنید به چیزی که باید مداوم عملیاتی کنید تبدیل میشود، آشکار میگردد.
یکی از دلایل سادهسازی بیش از حد این تصمیم این است که بسیاری از تیمها فرض میکنند معماری را میتوان بعد از MVP دوباره بررسی کرد. در عمل، آن لحظه تقریباً هیچوقت فرا نمیرسد. وقتی مشتری ظاهر میشود، قرارداد امضا میشود، یکپارچهسازیها مستقر میشوند و انتظارات آپتایم شکل میگیرند، دست زدن به هسته یک سیستم IoT تولیدی روزبهروز خطرناکتر میشود. میانبرهایی که در ابتدا گرفته میشوند، معمولاً به ویژگیهای دائمی معماری تبدیل میشوند؛ نه به خاطر بیدقتی تیمها، بلکه چون هزینه تغییر خیلی سریعتر از حد انتظار رشد میکند.
معیارهای مقایسه
یک مقایسه معنادار بین استکهای open-source و IoT platforms باید فراتر از سرعت توسعه اولیه برود. باید بررسی کند که هر رویکرد در طول چرخه عمر کامل یک محصول IoT چگونه رفتار میکند. چندین معیار همیشه وقتی تیمها این تصمیم را به صورت بررسی میکنند، ظاهر میشوند.
Time-to-PoC، time-to-MVP و time-to-market اغلب اولین ابعاد مورد بحث هستند. پلتفرمها به طور خاص برای فشرده کردن زمانهای اولیه طراحی شدهاند و بلوکهای آماده برای اتصال دستگاه، دریافت داده، تجسم و منطق پایه ارائه میدهند. استکهای open-source میتوانند به نتایج مشابه برسند، اما معمولاً به کار مهندسی بیشتری در ابتدا نیاز دارند. نکته مهم این است که این سود یا تأخیرهای اولیه در مقایسه با سالهای بعدی کوچک هستند. سرعت مهم است، اما نه تنها عامل و حتی نه عامل غالب برای محصولات بلندمدت.
منطق کاربردی و مدلسازی داده محور حیاتی دیگری است. سیستمهای IoT خیلی سریع پیچیده میشوند: دستگاهها تکامل پیدا میکنند، اسکیماهای داده تغییر میکنند، قوانین کسبوکار رشد میکنند و استثناها زیاد میشوند. نحوه نمایش، استفاده مجدد و تکامل منطق در طول زمان تأثیر مستقیمی روی قابلیت نگهداری دارد. برخی رویکردها روی انعطافپذیری کد-محور تأکید دارند، در حالی که دیگران مدلهای سطح بالاتر و انتزاعهای بصری را اجباری میکنند. این تریدآف نه بین «کد» و «بدون کد»، بلکه بین آزادی محلی و ثبات جهانی است.
مهندسی رابط کاربری اغلب در محصولات IoT دستکم گرفته میشود، به خصوص بخش مدیریتی. داشبوردهای رو به مشتری معمولاً بیشترین توجه را میگیرند، اما رابطهای داخلی برای مدیریت مستاجران، کاربران، نقشها، پیکربندیها، هشدارها و یکپارچهسازیها میتوانند در طول زمان تلاش توسعه قابل توجهی مصرف کنند. اینکه این رابطها باید از صفر ساخته شوند یا به طور طبیعی از معماری پایه پلتفرم بیرون بیایند، تأثیرات هزینهای بلندمدت دارد که در برنامهریزی اولیه به ندرت دیده میشود.
متصل به آن، مسئله multi-tenancy و محصولسازی است. ساخت راهحل برای یک مشتری نسبتاً ساده است. تبدیل آن راهحل به یک محصول تکرارپذیر که بتوان در مشتریان متعدد مستقر کرد، ارتقا داد و پشتیبانی کرد، چالش کاملاً متفاوتی است. Multi-tenancy روی همه چیز از ایزولاسیون داده و امنیت تا استراتژی استقرار و مدلهای قیمتگذاری تأثیر میگذارد. برخی معماریها آن را به عنوان یک نگرانی درجه یک میکنند؛ دیگران آن را به تدریج اضافه میکنند، اغلب به قیمت افزایش پیچیدگی عملیاتی.
Deployment، scaling و عملیات حوزه دیگری است که تفاوتها فقط با گذشت زمان آشکار میشوند. مقیاسپذیری سیستمهای IoT فقط مدیریت پیامهای بیشتر در ثانیه نیست. درباره مدیریت ناهمگونی است: انواع دستگاه بیشتر، پروتکلهای بیشتر، مستاجران بیشتر، محیطهای بیشتر و حالتهای شکست بیشتر. سؤال این نیست که آیا سیستم میتواند مقیاس شود، بلکه این است که چه کسی مسئولیت مداوم طراحی، عملیات و تکامل استراتژی مقیاسپذیری را بر عهده دارد.
Security، governance و compliance اغلب به صورت انتزاعی بحث میشوند، اما در دنیای واقعی معمولاً بیشترین تلاش عملیاتی را به خود اختصاص میدهند. محصولات IoT باید اعتبارها، کنترل دسترسی، قابلیت حسابرسی و مدیریت آسیبپذیری را در دورههای طولانی مدیریت کنند. در برخی رویکردها، این نگرانیها عمیقاً در پلتفرم جاسازی شده و به صورت مرکزی نگهداری میشوند. در دیگران، مسئولیت مداوم تیم محصول باقی میماند که باید آسیبپذیریها را ردیابی کند، وابستگیها را بهروزرسانی کند و ثبات در استقرارها را تضمین کند.
ملاحظات اقتصادی اغلب به هزینه لایسنس کاهش پیدا میکنند، اما این قاببندی تصویر بزرگتر را از دست میدهد. نرمافزار open-source ممکن است هزینههای اولیه قابل مشاهده را کاهش دهد، در حالی که پلتفرمها هزینه اشتراک صریح معرفی میکنند. اما در طول چرخه عمر کامل محصول، هزینهها اغلب از CAPEX اولیه به OPEX مداوم منتقل میشوند به شیوههایی که فوراً آشکار نیستند. زمان مهندسی، تلاش عملیاتی و مدیریت ریسک همه وزن اقتصادی دارند، حتی اگر در لیست قیمت ظاهر نشوند.
مدلهای پشتیبانی و دینامیک اکوسیستم هم نقش دارند. استکهای open-source از جوامع بزرگ و فعال و استخر وسیع توسعهدهندگان سود میبرند. پلتفرمها معمولاً جوامع کوچکتری دارند اما پشتیبانی پشتیباندار توسط فروشنده و مسیرهای ارتقای قابل پیشبینی را ترکیب میکنند. تریدآف نه فقط بین «جامعه» و «فروشنده»، بلکه بین روشهای مختلف توزیع مسئولیت و ریسک در طول زمان است.
درآمدزایی و انعطافپذیری قیمتگذاری لایه دیگری اضافه میکند. محصولات IoT اغلب مدلهای کسبوکار خود را با بلوغ تغییر میدهند و با اشتراک، قیمتگذاری مبتنی بر مصرف، سطوح ویژگی یا بستههای خاص عمودی آزمایش میکنند. اینکه این تغییرات نیاز به بازکاری معماری داشته باشند یا بتوانند به عنوان تصمیمات پیکربندی و سیاست مدیریت شوند، به شدت به طراحی اولیه سیستم بستگی دارد.
در نهایت، مسئله عملی دسترسی به توسعه برونسپاری وجود دارد. فناوریهای open-source پیدا کردن پیمانکاران و مقیاس تیم را آسانتر میکنند. رویکردهای مبتنی بر پلتفرم معمولاً به استخر کوچکتری از تخصص تخصصی تکیه دارند و اغلب آشنایی عمیقتر را به تعداد بیشتر ترجیح میدهند. این تفاوت میتواند روی استراتژی استخدام، انتخاب شریک و تحمل ریسک تأثیر بگذارد.
پس برنده کیست؟
هیچکدام از این معیارها به تنهایی انتخاب «درست» را تعیین نمیکند. آنچه مهم است نحوه تعامل آنها در طول زمان و ریسکهایی است که تیم حاضر به پذیرش آنهاست. برای برخی ابتکارات – به خصوص راهحلهای یکباره یا استقرارهای محدود – استکهای کلاسیک open-source همچنان انتخاب عالی هستند. برای دیگران، به خصوص راهحلهای صنعتی یا محصولات تجاری IoT با چرخه عمر طولانی و مشتریان زیاد، پلتفرمهای ساختاریافته میتوانند پیچیدگیهایی را جذب کنند که در غیر این صورت بار دائمی روی تیم محصول باقی میماند.
نسخه کامل این تحلیل، این معیارها را با جزئیات بررسی میکند و نشان میدهد هر رویکرد کجا میدرخشد و کجا هزینههای پنهان یا محدودیتهایی معرفی میکند. این تحلیل عمداً روی تفکر محصول بلندمدت متمرکز است نه راحتی توسعه کوتاهمدت.
منبع: iotforall