AWS و IBM: مقایسه خدمات اینترنت اشیا: 4 مرحله

2024 نویسنده: John Day | [email protected]. آخرین اصلاح شده: 2024-01-30 08:55

امروز ما دو پشته را مقایسه می کنیم که امکان توسعه برنامه های اینترنت اشیا را از نظر ارائه خدمات مختلف فراهم می کند.

مرحله 1: عملکردها به عنوان یک سرویس

FaaS یک دسته از سرویس های ابری است که برای ایجاد معماری "بدون سرور" استفاده می شود. FaaS به مشتریان امکان می دهد بدون ایجاد و نگهداری زیرساخت ها ، عملکردهای برنامه را توسعه ، اجرا و مدیریت کنند.

آمازون AWS Lambda ، IBM عملکردهای ابری IBM را ارائه می دهد. این خدمات کاملاً مشابه هستند ، اما Lambda اولین سرویس از این نوع بود. با استفاده از FaaS می توانید قطعات کد را در ابر اجرا کنید و هر سرویس از زبان های برنامه نویسی مختلف پشتیبانی می کند.

عملکردهای IBM Cloud: JavaScript ، Swift ، Java ، Go ، Php ، Python ، Ruby ، . NET (C# F# و غیره) ، از طریق Docker AWS Lambda: JavaScript ، Java ، C# ، F# ، Go ، Python ، Ruby ، PowerShell ، Any از طریق API زمان اجرا

IBM از زبانهای بیشتری پشتیبانی می کند و استفاده از docker به آسانی از اسکریپت هایی است که به زبان های دیگر نوشته شده است. این کار را می توان با لامبدا نیز انجام داد ، اما فوری نیست. می توانید یک مثال را در اینجا بخوانید:

هر دو سرویس محدودیت استفاده دارند ، ما آنها را در یک جدول گزارش می دهیم و بهترین ها را برجسته می کنیم.

قیمت بر اساس گیگابایت در ثانیه (RAM) با اضافه شدن تعداد درخواست ها برای AWS Lambda است. هر سرویس دارای یک برنامه رایگان است و تقریباً معادل هستند. همانطور که می بینید Lambda برای GB/s کمی ارزان تر است ، اما هزینه آن مربوط به درخواست هایی است که عملکردهای Cloud ندارند ، بنابراین هزینه آن تقریباً یکسان است. البته ، اگر شما نیاز به اجرای کارهایی دارید که حافظه می خورد و از درخواست های کمی استفاده می کند ، باید از Lambda استفاده کنید. به نظر ما مزیت اصلی IBM Cloud Function منبع باز بودن آن است. این برنامه کاملاً بر اساس Apache OpenWhisk است و می تواند در زیرساخت های خصوصی نیز مستقر شود.

مرحله 2: یادگیری ماشین

زمینه ای که پشته های IBM و AWS خدمات مشابهی را ارائه می دهند ، یادگیری ماشین است: آمازون با SageMaker و IBM با یادگیری ماشین Watson. این دو سرویس از جنبه های مختلف بسیار شبیه به هم هستند: هر دو خود را به عنوان ابزاری برای کمک به دانشمندان و توسعه دهندگان داده ها در ایجاد ، آموزش و سپس به کارگیری در محیط های آماده تولید مدلهای یادگیری ماشین خود معرفی می کنند ، اما فلسفه هایی که این دو شرکت اتخاذ می کنند بسیار متفاوت است. هر دو سرویس به شما امکان می دهند بین درجه های مختلف کنترل بر روی مدل هایی که استفاده می کنید ، انتخاب کنید. در Watson ML ، شما چند مدل داخلی دارید که قبلاً برای انجام کارهای بسیار خاص آموزش دیده اند: به عنوان مثال ، اگر می خواهید اشیاء موجود در یک تصویر را تشخیص دهید ، فقط مدل VisualRecognitionV3 را وارد کرده و تصویر خود را به آن منتقل کنید. می خواهم تجزیه و تحلیل کنم شما همچنین می توانید یک "مدل سفارشی" بسازید ، اما در Watson ML این بیشتر به معنای گرفتن یک مدل ساخته شده و آموزش ما بر روی آن است ، بنابراین سفارشی سازی بسیار محدود است. توجه به این نکته مهم است که نه SageMaker و نه Watson ML تنها روشهای یادگیری ماشینی بر روی دسته توسعه دهندگان نیستند ، آنها فقط خدماتی هستند که زندگی سهولت برنامه نویسان را آسان تر می کنند. پلت فرم Watson ML همچنین از بسیاری از مشهورترین کتابخانه های یادگیری ماشین پشتیبانی می کند ، بنابراین حتی می توانید با PyTorch ، Tensorflow یا کتابخانه های مشابه از ابتدا یک مدل بسازید. شما یا مستقیماً از آن کتابخانه ها استفاده می کنید ، یا از مدل های از پیش ساخته شده استفاده می کنید ، هیچ حد وسطی وجود ندارد. همچنین Watson ML از کتابخانه انتخابی آمازون ، Apache MXNet پشتیبانی نمی کند ، که در عوض از پشتیبانی درجه یک در SageMaker برخوردار است.

رویکرد Amazon SageMaker ، حتی در هنگام استفاده از گزینه های داخلی ، کمی پایین تر است: به جای اینکه شما را از بین مدل های از پیش انتخاب شده انتخاب کنید ، به شما امکان می دهد از بین الگوریتم های آموزشی که قبلاً اجرا شده اند ، انتخاب کنید ، که می توانید هنگام ساختن آنها از آنها استفاده کنید. مدل سازی به شیوه ای سنتی تر اگر این موارد کافی نیستند ، می توانید از الگوریتم شخصی خود نیز استفاده کنید. این روش انجام امور مطمئناً در مقایسه با استفاده از یک مدل آموزش دیده در Watson ML ، دانش بیشتری در مورد نحوه یادگیری ماشین نیاز دارد.

در نگاه اول ممکن است به نظر برسد که Watson ML راه "آسان و سریع" است و راه اندازی Amazon SageMaker پیچیده تر است. این ممکن است از نظر برخی موارد کاملاً درست نباشد ، زیرا SageMaker طوری طراحی شده است که همه چیز را در یک Jupyter Notebook اجرا کند ، در حالی که برای ویژگی های یکسان در Watson ML شما باید بسیاری از زیر سرویس های مختلف را از طریق UI وب راه اندازی کنید. پیش پردازش داده ها همچنین دارای فضاهای اختصاصی در سرویس IBM است در حالی که SageMaker متکی است که همه این کارها را از روی کد در نوت بوک خود انجام می دهید. این نکته به علاوه این واقعیت که نوت بوک های Jupyter از نظر مهندسی نرم افزار دقیقاً بهترین انتخاب نیستند ، ممکن است از مقیاس پذیری بسیار خوب SageMaker در تولید جلوگیری کند. هر دو سرویس دارای مکانیسم های بسیار خوب و ساده ای هستند تا مدل شما را به کار گیرند و API های آن را در دنیای خارج در دسترس قرار دهند.

در پایان ، Watson ML در پروژه های عظیمی که نوت بوک های Jupyter محدودیت های خود را نشان می دهند بهتر عمل می کند و در مواردی که خود مدل نیاز به سفارشی سازی چندانی ندارد. SageMaker هنگامی که در تعریف الگوریتم ها به انعطاف پذیری بیشتری نیاز دارید ، بسیار بهتر است ، اما هنگام استفاده از آن باید این واقعیت را در نظر بگیرید که باید به Jupyter Notebooks اعتماد کنید ، زیرا ممکن است در تولید مقیاس خوبی نداشته باشد. یک راه حل می تواند این باشد که بقیه کد را تا حد امکان از مدل جدا کنید ، به طوری که کد در نوت بوک های واقعی زیاد بزرگ نشود و ما بتوانیم نرم افزار خود را در سایر ماژول هایی که فقط از API مدل ما استفاده می کنند ، بهتر سازماندهی کنیم. به

مرحله 3: جریان داده ها و تجزیه و تحلیل

خدمات جریان داده در مدیریت و تجزیه و تحلیل جریانهای بزرگ داده در زمان واقعی بسیار مهم است. این جریان می تواند از ابر به دستگاه کاربران ، مانند پخش ویدئو ، یا از کاربران به ابر ، مانند تله متری اینترنت اشیا و خوانش سنسور باشد. به خصوص در مورد دوم ، ما می توانیم شرایطی را داشته باشیم که منابع منفرد حجم کمی از داده ها را بارگذاری می کنند ، اما هنگامی که توان کلی را که از همه دستگاه ها به دست می آید در نظر بگیریم ، پهنای باند قابل توجهی را مصرف می کند ، بنابراین منطقی است که از خدمات تخصصی برای رسیدگی به این موارد استفاده کنیم. جریان داده ها بدون مدیریت مستقیم این جریان پیوسته ، ما باید اطلاعات ورودی را به یک ذخیره موقت و در بار دوم با موتور محاسباتی پردازش کنیم. مشکل این رویکرد آخر این است که ما باید خدمات متفاوت تری را برای دستیابی به کاری که یک سرویس جریان داده به تنهایی انجام می دهد ، هماهنگ کنیم و پیچیدگی نگهداری و پیکربندی برنامه را افزایش دهیم. علاوه بر این ، بافر کردن در اصل می تواند باعث شود برنامه ما دیگر در زمان واقعی نباشد ، زیرا برای پردازش یک مورد لازم است که همه موارد دیگر قبل از آن نیز پردازش شوند ، و افزودن سیاست های اولویت به بافر می تواند دوباره ، پیچیدگی را به شدت افزایش دهد. به طور خلاصه ، خدمات جریان داده ، جریان داده ها را در زمان واقعی و با پیکربندی آسان ارائه می دهد و می تواند تجزیه و تحلیل داده های ورودی را ارائه دهد. در اینجا ما دو سرویس اصلی جریان IBM و AWS stack یعنی IBM Streams و AWS Kinesis را با هم مقایسه می کنیم.

ما با توجه به این نکته شروع می کنیم که همه ویژگی های اساسی که ممکن است از یک سرویس پخش بخواهیم ، هم IBM و هم AWS ارائه می دهند. این ویژگی ها شامل سرعت پردازش بی نهایت ، تأخیر کم و تجزیه و تحلیل داده های زمان واقعی است. از آنجا که ما در مورد خدمات حرفه ای صحبت می کنیم ، هر دو ابزار درجه تولید برای استقرار و اتوماسیون را ارائه می دهند.

در مورد تجزیه و تحلیل داده ها ، هر دو سرویس آن را به صورت اختیاری ارائه می دهند ، و شما را مجبور می کند که تنها به نیاز خود یا عدم نیاز به پرداخت هزینه بپردازید. در مورد Kinesis ، هنگامی که نیازی به تجزیه و تحلیل ندارید ، بلکه فقط به مدیریت جریان داده ها نیاز دارید ، قیمت ها به ازای هر GB پردازش شده به جای زمان پردازش ، مانند مورد IBM ، محاسبه می شود. قیمت هر گیگابایت به طور کلی ارزان تر از قیمت هر زمان خواهد بود ، زیرا شما فقط هزینه ترافیک ورودی را پرداخت می کنید. در بقیه این پست ما هر دو IBM Streams و AWS Kinesis را با ویژگی تجزیه و تحلیل داده ها فعال در نظر می گیریم.

Streams و Kinesis با خدمات مختلف برای پیش پردازش و فیلتر کردن داده های ورودی قبل از ارسال آنها به تجزیه و تحلیل داده ها ، به ترتیب با Apache Edgent و AWS Lambda ، ادغام می شوند. در حالی که این سرویس ها تفاوت اساسی با یکدیگر دارند ، ما فقط از نظر دو سرویس پخش کننده در مورد آنها صحبت خواهیم کرد. تفاوت اساسی بین این دو این است که Apache Edgent روی دستگاه اجرا می شود ، در حالی که AWS Lambda روی ابر اجرا می شود. این مزایا و معایب زیادی را به همراه دارد: از طرف Lambda ما یک سرویس انعطاف پذیر و آسان برای استفاده با یکپارچگی یکپارچه با Kinesis داریم ، اما مستلزم آن است که داده ها از قبل روی ابر بارگذاری شوند ، بنابراین در کارایی از دست رفته و به Kinesis نیز پرداخت می شود. برای داده هایی که در نهایت حذف می شوند. در عوض ، از طرف Edgent ، ما می دانیم که بیشتر محاسبات قبل از بارگذاری داده های بی فایده در ابر ، به خوبی ، در لبه شبکه (بنابراین در دستگاه ها) انجام شده است. اشکال اصلی این است که Edgent یک چارچوب بزرگ است ، که ممکن است زمان ببرد و نگهداری آن پیچیده باشد. تفاوت دیگری که می تواند در انتخاب یک پلتفرم مهم باشد این است که Edgent کاملاً متن باز است ، Lambda نیست. این می تواند هم به عنوان یک حرفه ای در نظر گرفته شود ، زیرا دسترسی به کدی که شما یا مشتری شما اجرا می کنید همیشه یک نکته مثبت است ، هر دو به عنوان یک نتیجه منفی ، زیرا ممکن است شرایطی وجود داشته باشد که شما نیاز به پشتیبانی فوری دارید که در آن ارائه نمی شود. همه محیط های منبع باز

سایر ویژگی هایی که می توانیم به آنها اشاره کنیم مقیاس پذیری خودکار Kinesis از منابع اختصاص یافته است. در واقع ، سخت افزاری که ارائه می دهد متشکل از تعدادی از واحدهای پردازش Kinesis (KPU) است که به طور موازی کار می کنند ، جایی که یک KPU 1 vCore و 4 گیگابایت RAM ارائه می دهد. تعداد آنها بستگی به نیازهای برنامه دارد و بصورت پویا و خودکار تخصیص داده می شود (آنچه که شما پرداخت می کنید در واقع زمان پردازنده بر تعداد KPU است) ، فقط به یاد داشته باشید که اگر از جاوا استفاده می کنید ، یک KPU بیشتر از شما اخذ می شود. کاربرد. در عوض ، IBM Streams این نوع انعطاف پذیری را ارائه نمی دهد ، هنگامی که در مورد قیمت صحبت می کنیم ، یک ظرف با سخت افزار ثابت را به شما ارائه می دهد. از سوی دیگر ، IBM Streams بازتر از Kinesis است ، زیرا از طریق پروتکل های متداول مانند HTTP ، MQTT و غیره به WAN متصل می شود ، در حالی که Kinesis به اکوسیستم AWS بسته است.

به عنوان مقایسه نهایی ، بیایید در مورد قیمت صحبت کنیم ، و بگذارید بگویم که IBM در این زمینه عالی کار نمی کند. ما راه حل های متفاوتی را برای سه دسته مختلف (اصلی ، سطح بالا ، فوق العاده بالا) برای IBM و AWS پیکربندی کرده ایم و قصد داریم قیمت آنها را مقایسه کنیم. در پیکربندی اولیه ، ما یک AWS KPU داریم که قبلاً ذکر شد ، در برابر راه حل IBM با سخت افزار مشابه. برای رده بالا ما 8 KPU در Kinesis موازی و 2 کانتینر همیشه در موازی برای IBM ، هر کدام دارای 4 vCore و 12 گیگابایت RAM است. همیشه IBM در بالاترین سطح یک کانتینر واحد با 16 vCore و 128 گیگابایت RAM ارائه می دهد ، در حالی که ما یک راه حل معادل برای AWS را حذف کرده ایم ، زیرا اگر برخی از برنامه ها به این مقدار RAM نیاز داشته باشند ، نمی توان آن را روی KPU های مختلف اجرا کرد. به قیمت هایی که گزارش می دهیم با توجه به استفاده 24 ساعته و 7 روزه به دلار بیان می شود. برای پیکربندی اولیه ای که برای IBM و AWS به ترتیب 164 $ و 490 $ ، برای 1320 $ و 3500 $ پیشرفته ، برای AWS فوق العاده بالا در نظر گرفته نشده است و تنها IBM با 6300 $ وجود دارد. از این نتایج می توان دریافت که Kinesis برای کاربران روزمره تا سطح سازمانی بهتر عمل می کند ، در حالی که فاقد گزینه هایی برای مدیریت مستقیم تجزیه و تحلیل داده ها است که به مقدار زیادی از قدرت محاسباتی نیاز دارد. Kinesis نسبت به IBM Streams نسبت عملکرد/$ بهتری ارائه می دهد ، همچنین با تخصیص پویا بلوک های منابع کوچک تنها در صورت نیاز ، در حالی که IBM یک ظرف ثابت به شما ارائه می دهد. به این ترتیب ، اگر بار کاری شما با اوج مشخص شود ، با IBM شما مجبور می شوید نیازهای برنامه خود را بیش از حد ارزیابی کنید و در بدترین حالت راه حلی را پیکربندی کنید. IBM به جای پرداخت ماه کامل هزینه ساعاتی را ارائه می دهد ، اما به عنوان Kinesis خودکار نیست.

مرحله 4: معماری اینترنت اشیا

پیکربندی دستگاه ها برای aws iot در مقایسه با ibm watson iot بسیار آسان است. زیرا در ibm watson iot احراز هویت به ازای هر دستگاه با توکن انجام می شود و پس از نمایش توکن دیگر هرگز نمایش داده نمی شود. دوباره به قسمت قیمت گذاری ibm watson iot در مقایسه با aws iot بسیار هزینه بر است. بنابراین ، قیمت اتهامات ibm watson iot بر اساس هر دستگاه ، ذخیره داده ، ترافیک داده ها تعیین می شود. اما در aws iot می توانیم مبلغ را یک بار پرداخت کنیم و می توانیم دستگاه ها و داده های بیشتری را که از دستگاه ها منتشر شده و به دستگاه ها تحویل داده می شوند ، اضافه کنیم.

با دستگاه خود شروع کنید- خواه سنسور باشد ، خواه دروازه یا چیز دیگری- و به ما کمک کنید تا با ابر ارتباط برقرار کنید.

وقتی با استفاده از پروتکل باز و سبک پیام رسانی MGTT یا HTTP به ابر متصل می شوید ، اطلاعات دستگاه شما همیشه ایمن است. با کمک پروتکل ها و node-red می توانیم دستگاه خود را با پلتفرم iot متصل کرده و به داده های زنده و تاریخی دسترسی داشته باشیم.

از API های امن ما برای اتصال برنامه های خود به داده های دستگاه های خود استفاده کنید.

برای تفسیر داده ها ، برنامه هایی را در سرویس ابری ما ایجاد کنید.