AWS და IBM: IoT სერვისების შედარება: 4 ნაბიჯი

2024 ავტორი: John Day | [email protected]. ბოლოს შეცვლილი: 2024-01-30 10:18

დღეს ჩვენ ვადარებთ ორ დასტს, რაც შესაძლებელს ხდის IoT პროგრამების შემუშავებას სხვადასხვა სერვისის შეთავაზებების თვალსაზრისით.

ნაბიჯი 1: ფუნქციონირებს როგორც სერვისი

FaaS არის ღრუბლოვანი სერვისების კატეგორია, რომელიც გამოიყენება "უსადენო" არქიტექტურის შესაქმნელად. FaaS მომხმარებელს საშუალებას აძლევს განავითარონ, გაუშვან და მართონ პროგრამის ფუნქციონირება ინფრასტრუქტურის მშენებლობისა და შენარჩუნების გარეშე.

Amazon გთავაზობთ AWS Lambda, IBM გთავაზობთ IBM Cloud ფუნქციებს. ეს მომსახურება საკმაოდ მსგავსია, თუმცა ლამბდა იყო პირველი ამ სახის. 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 Runtime API– ის საშუალებით

IBM მხარს უჭერს მეტ ენას და დოკერის საშუალებით ადვილია სხვა ენებზე დაწერილი სკრიპტების გამოყენება. ეს ასევე შეიძლება გაკეთდეს ლამბდაზე, მაგრამ ეს არ არის დაუყოვნებლივ. თქვენ შეგიძლიათ წაიკითხოთ მაგალითი აქ:

ორივე სერვისს აქვს გამოყენების ლიმიტი, ჩვენ ვაცნობთ მათ ცხრილში და გამოვყოფთ საუკეთესოს.

ფასი ემყარება გიგაბიტს წამში (RAM) AWS Lambda– ს მოთხოვნათა რაოდენობის დამატებით. თითოეულ სერვისს აქვს უფასო გეგმა და ისინი თითქმის ექვივალენტურია. როგორც ხედავთ ლამბდა GB/s– ზე ოდნავ იაფია, მაგრამ მას აქვს ხარჯები, რომლებიც დაკავშირებულია იმ მოთხოვნებთან, რომლებიც Cloud– ის ფუნქციებს არ გააჩნიათ, ამიტომ ღირებულება თითქმის იგივეა ზოგადად. რა თქმა უნდა, თუ თქვენ გჭირდებათ ამოცანების გაშვება, რომლებიც მეხსიერებას ჭამს და იყენებს რამდენიმე მოთხოვნას, თქვენ უნდა გამოიყენოთ ლამბდა. ჩვენი აზრით, IBM Cloud Function– ის მთავარი უპირატესობა ის არის, რომ მისი სტეკი ღია წყაროა. ის მთლიანად ეფუძნება Apache OpenWhisk- ს და ასევე შეიძლება განთავსდეს კერძო ინფრასტრუქტურაზე.

ნაბიჯი 2: მანქანათმცოდნეობა

სფერო, სადაც IBM და AWS სტეკები გვთავაზობენ მსგავს სერვისებს არის მანქანათმცოდნეობა: Amazon თავისი SageMaker- ით და IBM Watson Machine Learning– ით. ეს ორი სერვისი ძალიან ჰგავს ერთმანეთს: ორივე წარმოადგენს ინსტრუმენტს, რომელიც დაეხმარება მონაცემთა მეცნიერებს და დეველოპერებს, შექმნან, გაწვრთნან და შემდეგ განათავსონ წარმოებისათვის მზად გარემოში მანქანათმცოდნეობის მოდელები, მაგრამ ფილოსოფია, რომელსაც ორი კომპანია იღებს, საკმაოდ განსხვავდება. ორივე სერვისი გაძლევთ არჩევანის გაკეთების სხვადასხვა ხარისხს თქვენს მიერ გამოყენებულ მოდელებზე. Watson ML– ში თქვენ გაქვთ ჩაშენებული მოდელები, რომლებიც უკვე გაწვრთნილია ძალიან კონკრეტული ამოცანების შესასრულებლად: მაგალითად, თუ გსურთ ამოიცნოთ რა ობიექტებია სურათზე, თქვენ უბრალოდ შემოიტანთ VisualRecognitionV3 მოდელს და გადასცემთ მას სურათს გაანალიზება მინდა თქვენ ასევე შეგიძლიათ ააწყოთ „პერსონალური მოდელი“, მაგრამ Watson ML– ში ეს ძირითადად ნიშნავს უკვე აგებული მოდელის აღებას და მასზე ჩვენი ტრენინგის ჩატარებას, ამიტომ პერსონალიზაცია საკმაოდ შეზღუდულია. მნიშვნელოვანია აღინიშნოს, რომ არც SageMaker და არც Watson ML არ არიან მანქანების სწავლების ერთადერთი გზა დეველოპერების სტეკზე, ისინი მხოლოდ სერვისებია, რომლებიც მიზნად ისახავს დეველოპერების ცხოვრების გამარტივებას. Watson ML პლატფორმა ასევე მხარს უჭერს მანქანების სწავლების ბევრ ყველაზე პოპულარულ ბიბლიოთეკას, ასე რომ თქვენ შეგიძლიათ ააწყოთ მოდელი ნულიდან PyTorch, Tensorflow ან მსგავსი ბიბლიოთეკით. თქვენ ან პირდაპირ იყენებთ ამ ბიბლიოთეკებს, ან იყენებთ წინასწარ დამზადებულ მოდელებს, შუალედი არ არსებობს. ასევე Watson ML არ უჭერს მხარს ამაზონის ბიბლიოთეკას, Apache MXNet, რომელსაც აქვს პირველი კლასის მხარდაჭერა SageMaker– ში.

Amazon SageMaker– ის მიდგომა, თუნდაც ჩაშენებული პარამეტრების გამოყენებისას, ცოტა უფრო დაბალი დონეა: იმის ნაცვლად, რომ არჩევანის გაკეთება წინასწარ დამზადებული მოდელებიდან, ის გაძლევთ საშუალებას აირჩიოთ უკვე დანერგილი სასწავლო ალგორითმების უხვი, რომელიც შეგიძლიათ გამოიყენოთ თქვენი მშენებლობისას მოდელი უფრო ტრადიციული გზით. თუ ეს არ არის საკმარისი, ასევე შეგიძლიათ გამოიყენოთ თქვენი საკუთარი ალგორითმი. პერსონალის გაკეთების ეს გზა, რა თქმა უნდა, მოითხოვს მეტ ცოდნას იმის შესახებ, თუ როგორ ხდება მანქანათმცოდნეობა, შედარებით უბრალოდ გაწვრთნილი მოდელის გამოყენებით Watson ML.

ერთი შეხედვით შეიძლება ჩანდეს, რომ Watson ML არის "მარტივი და სწრაფი" გზა, ამაზონი SageMaker კი ყველაზე რთული. ეს შეიძლება არ იყოს მთლიანი სიმართლე ზოგიერთი თვალსაზრისით, რადგან SageMaker არის სტრუქტურირებული იმისათვის, რომ ყველაფერი გაუშვას Jupyter Notebook– ზე, ხოლო Watson ML– ის ერთიდაიგივე მახასიათებლებისთვის თქვენ უნდა შექმნათ მრავალი განსხვავებული ქვე – სერვისი ვებ – ინტერფეისიდან. მონაცემთა წინასწარ დამუშავებას ასევე აქვს გამოყოფილი ადგილები IBM სერვისზე, ხოლო SageMaker ეყრდნობა თქვენ ამას ყველაფერს აკეთებთ თქვენს ნოუთბუქში არსებული კოდიდან. ამას დამატებული ის ფაქტი, რომ Jupyter ნოუთბუქები არ არის ზუსტად საუკეთესო არჩევანი პროგრამული უზრუნველყოფის ინჟინერიის თვალსაზრისით, შეიძლება ხელი შეუშალოს SageMaker– ს წარმოების ძალიან კარგად გაფართოებაში. ორივე სერვისს აქვს საკმაოდ კარგი და მარტივი მექანიზმები თქვენი მოდელის განსახორციელებლად და მისთვის API– ების გასაკეთებლად გარე სამყაროში.

დასასრულს, Watson ML უკეთესად ასრულებს უზარმაზარ პროექტებს, სადაც Jupyter– ის ნოუთბუქები იწყებენ თავიანთი შეზღუდვების ჩვენებას და სადაც თქვენ არ გჭირდებათ ბევრი პერსონალიზაცია იმაში, რასაც თავად მოდელი აკეთებს. SageMaker ბევრად უკეთესია, როდესაც თქვენ გჭირდებათ მეტი მოქნილობა ალგორითმების განსაზღვრისას, მაგრამ მისი გამოყენებისას თქვენ უნდა გაითვალისწინოთ ის ფაქტი, რომ თქვენ უნდა დაეყრდნოთ Jupyter ნოუთბუქებს, რომლებიც შესაძლოა არ იყოს კარგად წარმოებული. გამოსავალი შეიძლება იყოს მოდელისგან დანარჩენი კოდის მაქსიმალურად გათიშვა, ისე რომ რეალურ ნოუთბუქებში კოდი არ გახდეს ძალიან დიდი და ჩვენ უკეთ მოვაწყოთ ჩვენი პროგრამული უზრუნველყოფა სხვა მოდულებში, რომლებიც უბრალოდ იყენებენ ჩვენი მოდელის API- ს რა

ნაბიჯი 3: მონაცემთა ნაკადი და ანალიზი

მონაცემთა ნაკადის სერვისები გადამწყვეტია მონაცემთა დიდი ნაკადების რეალურ დროში დამუშავებისა და ანალიზისათვის. ეს ნაკადი შეიძლება იყოს ღრუბლიდან მომხმარებლების მოწყობილობამდე, როგორც ვიდეოს სტრიმინგი, ან მომხმარებლებიდან ღრუბელში, როგორიცაა IoT ტელემეტრია და სენსორების კითხვა. განსაკუთრებით მეორე შემთხვევაში, ჩვენ შეგვიძლია გვქონდეს სიტუაცია, როდესაც ცალკეული წყაროები ატვირთავს მცირე რაოდენობის მონაცემებს, მაგრამ როდესაც გავითვალისწინებთ საერთო გამტარუნარიანობას, რომელიც მოდის ყველა მოწყობილობიდან, ის მოიხმარს მნიშვნელოვან გამტარობას, ამიტომ აზრი აქვს ამ სერვისის სპეციალიზირებული სერვისის გამოყენებას მონაცემთა ნაკადები. ამ უწყვეტი ნაკადის პირდაპირ გატარების გარეშე, ჩვენ მოგვიწევს შემომავალი ინფორმაციის ბუფერირება დროებით შენახვაში და მეორედ მისი დამუშავება გამოთვლითი ძრავით. ამ უკანასკნელი მიდგომის პრობლემა იმაში მდგომარეობს, რომ ჩვენ მოგვიწევს უფრო განსხვავებული სერვისების კოორდინირება, რათა მივაღწიოთ იმას, რასაც მონაცემთა ერთი ნაკადის სერვისი უკვე აკეთებს მარტო, რაც გაზრდის პროგრამის შენარჩუნებისა და კონფიგურაციის სირთულეს. გარდა ამისა, ბუფერულმა შეიძლება პრინციპულად გახადოს ჩვენი აპლიკაცია რეალურ დროში, ვინაიდან ერთეულის დამუშავებისათვის აუცილებელია, რომ მანამდე ყველა სხვა ერთეული ასევე დამუშავდეს და ბუფერზე უპირატესობის პოლიტიკის დამატება კვლავ, მკვეთრად გაზარდოს სირთულე. შეჯამებით, მონაცემთა ნაკადის სერვისები გვთავაზობენ მონაცემთა ნაკადის დამუშავებას რეალურ დროში, მარტივი კონფიგურაციით და შეუძლიათ გაანალიზონ შემომავალი მონაცემები. აქ ჩვენ შევადარებთ IBM და AWS დასტის ორ ძირითად ნაკადის სერვისს, კერძოდ IBM Streams და AWS Kinesis.

ჩვენ ვიწყებთ იმის აღნიშვნით, რომ ყველა ძირითად მახასიათებელს, რაც შეიძლება გვსურდეს სტრიმინგის სერვისიდან, შემოთავაზებულია როგორც IBM- ის, ასევე AWS- ის მიერ. ეს მახასიათებლები მოიცავს პრაქტიკულად უსასრულო დამუშავების სიჩქარეს, დაბალ შეყოვნებას და მონაცემთა რეალურ დროში ანალიზს. ვინაიდან ჩვენ ვსაუბრობთ პროფესიონალურ სერვისებზე, ისინი ორივე გვთავაზობენ წარმოების ხარისხის ინსტრუმენტებს განლაგების და ავტომატიზაციისათვის.

მონაცემთა ანალიტიკაზე საუბრისას, ორივე სერვისი გვთავაზობს მას სურვილისამებრ, რის გამოც თქვენ იხდით მხოლოდ იმას, გჭირდებათ ეს თუ არა. Kinesis– ის შემთხვევაში, როდესაც თქვენ არ გჭირდებათ ანალიტიკა, არამედ მხოლოდ მონაცემთა ნაკადის დამუშავება, ფასები იანგარიშება GB– ზე დამუშავებული დროის ნაცვლად დამუშავების დროის ნაცვლად, როგორც IBM– ის შემთხვევაში. GB– ის ფასი ზოგადად უფრო იაფი იქნება, ვიდრე ფასი, რადგან თქვენ იხდით მხოლოდ შემომავალ ტრაფიკს. ამ პოსტის დანარჩენ ნაწილში ჩვენ განვიხილავთ როგორც IBM Streams- ს, ასევე AWS Kinesis- ს მონაცემთა ანალიზის ფუნქციის ჩართვით.

Streams და Kinesis უზრუნველყოფენ სხვადასხვა სერვისებთან ინტეგრაციას მონაცემების წინასწარი დამუშავებისა და გაფილტვრისათვის მონაცემთა ანალიზში გადატანამდე, შესაბამისად Apache Edgent და AWS Lambda. მიუხედავად იმისა, რომ ეს სერვისები რადიკალურად განსხვავდება ერთმანეთისგან, ჩვენ მათ განვიხილავთ მხოლოდ ორი ნაკადის სერვისის თვალსაზრისით. ორს შორის ფუნდამენტური განსხვავება ისაა, რომ Apache Edgent ასრულებს მოწყობილობას, ხოლო AWS Lambda მუშაობს ღრუბელზე. ამას მოაქვს ბევრი დადებითი და უარყოფითი მხარე: ლამბდას მხრიდან ჩვენ გვაქვს მოქნილი და ადვილად გამოსაყენებელი სერვისი, Kinesis– თან შეუფერხებელი ინტეგრაციით, მაგრამ ის მოითხოვს მონაცემების უკვე ღრუბელში ატვირთვას, რითაც კარგავს ეფექტურობას და ანაზღაურებს ასევე Kinesis– ს იმ მონაცემებისთვის, რომლებიც საბოლოოდ გაუქმდება. სამაგიეროდ, ედგენტის მხრიდან, ჩვენ გვაქვს, რომ გამოთვლების უმეტესი ნაწილი კეთდება, კარგად, ქსელის პირას (ამდენად მოწყობილობებზე) ღრუბელზე უსარგებლო მონაცემების ატვირთვამდე. მთავარი მინუსი ის არის, რომ Edgent არის დიდი ჩარჩო, რომლის შექმნასაც შეიძლება დრო დასჭირდეს და მისი შენარჩუნება რთული იყოს. კიდევ ერთი განსხვავება, რომელიც შეიძლება იყოს აქტუალური პლატფორმის არჩევისას არის ის, რომ ედგენტი არის სრულად ღია წყარო, ლამბდა არა. ეს შეიძლება ჩაითვალოს როგორც პროფესიონალმა, ვინაიდან იმ კოდზე წვდომა, რომელსაც თქვენ ან თქვენი მომხმარებელი შეასრულებთ, ყოველთვის პოზიტიურია, როგორც უკუჩვენება, რადგან შეიძლება არსებობდეს სიტუაციები, როდესაც თქვენ გჭირდებათ სასწრაფო დახმარება, რომლის უზრუნველყოფაც შეუძლებელია ყველა ღია კოდის გარემო.

სხვა მახასიათებლები, რაც ჩვენ შეგვიძლია აღვნიშნოთ, არის Kinesis– ის გამოყოფილი რესურსების ავტომატური მასშტაბურობა. მართლაც, მის მიერ შემოთავაზებული აპარატურა შედგება რიგი ეგრეთწოდებული Kinesis Processing Units (KPU) პარალელურად გაშვებული, სადაც ერთი KPU გთავაზობთ 1 vCore და 4 GB ოპერატიული მეხსიერებას. მათი რიცხვი დამოკიდებულია პროგრამის მოთხოვნილებებზე და არის დინამიურად და ავტომატურად განაწილებული (რასაც თქვენ იხდით მართლაც cpu დროს KPU– ების რაოდენობაზე), უბრალოდ გახსოვდეთ, რომ Kinesis– ის პოლიტიკაა ერთი KPU– ით დაგიჯდებათ თუ Java- ს იყენებთ განაცხადი სამაგიეროდ, IBM Streams არ იძლევა ამგვარ მოქნილობას, შემოგთავაზებთ კონტეინერს ფიქსირებული ტექნიკით, უფრო მეტ დეტალებს, როდესაც ჩვენ ვსაუბრობთ ფასებზე. მეორეს მხრივ, IBM Streams უფრო ღიაა ვიდრე Kinesis, ვინაიდან ის WAN– ს უერთდება საერთო გამოყენებული პროტოკოლების საშუალებით, როგორიცაა HTTP, MQTT და ასე შემდეგ, ხოლო Kinesis დახურულია AWS ეკოსისტემისთვის.

როგორც საბოლოო შედარება, მოდით ვისაუბროთ ფასებზე და ნება მომეცით გითხრათ, რომ IBM არ მუშაობს კარგად ამ საკითხში. ჩვენ დავაყენეთ განსხვავებული გადაწყვეტილებები სამი განსხვავებული კატეგორიისთვის (ძირითადი, მაღალი დონის, ულტრა მაღალი დონის) როგორც IBM- ისთვის, ასევე AWS– ისთვის და ჩვენ ვაპირებთ შევადაროთ მათი ფასი. ძირითად კონფიგურაციაში ჩვენ გვაქვს ერთი AWS KPU, რომელიც ზემოთ აღვნიშნეთ, IBM გადაწყვეტის საწინააღმდეგოდ იგივე აპარატურით. მაღალი დონისთვის ჩვენ გვაქვს 8 KPU, რომელიც მუშაობს პარალელურად Kinesis– ისთვის და 2 კონტეინერი ყოველთვის პარალელურად IBM– ისთვის, თითოეულს 4 vCore და 12 GB ოპერატიული მეხსიერება. ყოველთვის IBM გთავაზობთ ულტრა მაღალი დონის ერთ კონტეინერს 16 vCore და 128 GB ოპერატიული მეხსიერებით, ხოლო ჩვენ გამოვტოვეთ AWS– ის ექვივალენტური გადაწყვეტა, რადგან თუ რაიმე პროგრამა მოითხოვს ამხელა ოპერატიული მეხსიერებას, შეუძლებელია მისი სხვადასხვა KPU– ზე გაშვება რა ჩვენ მიერ მოწოდებული ფასები გამოხატულია $/თვეში 24/7 გამოყენების გათვალისწინებით. ძირითადი კონფიგურაციისთვის ჩვენ გვაქვს IBM და AWS შესაბამისად 164 $ და 490 $, ძვირადღირებული 1320 $ და 3500 $, ულტრა მაღალი დონის AWS არ განიხილება და არსებობს მხოლოდ IBM 6300 $ -ით. ამ შედეგებიდან ჩვენ შეგვიძლია დავინახოთ, რომ Kinesis უკეთესად მუშაობს ყოველდღიური მომხმარებლისთვის საწარმოს დონეზე, მაშინ როდესაც მას არ გააჩნია მონაცემთა ანალიზის უშუალო დამუშავების პარამეტრები, რაც მოითხოვს უზარმაზარ გამომთვლელ ძალას. Kinesis აწვდის უკეთეს მაჩვენებელს/$ თანაფარდობას ვიდრე IBM Streams, ასევე მცირე რესურსების ბლოკების დინამიური გამოყოფით მხოლოდ საჭიროების შემთხვევაში, ხოლო IBM გთავაზობთ ფიქსირებულ კონტეინერს. ამგვარად, თუ თქვენი დატვირთვა ხასიათდება პიკებით, IBM– ით თქვენ იძულებული გახდებით გადაჭარბებულად შეაფასოთ თქვენი განაცხადის მოთხოვნილებები და უარეს შემთხვევაში სცადოთ გამოსავალი. IBM გთავაზობთ საათის საფასურს მთლიანი თვის გადახდის ნაცვლად, მაგრამ ის არ არის ავტომატიზირებული, როგორც Kinesis.

ნაბიჯი 4: IoT არქიტექტურა

Aws iot მოწყობილობების კონფიგურაცია საკმაოდ ადვილია ibm watson iot– თან შედარებით. იმის გამო, რომ ibm watson iot ავტორიზაცია ხდება თითოეული მოწყობილობის ნიშნით და მას შემდეგ რაც ის აჩვენებს მას აღარასოდეს გამოჩნდება. ფასების ნაწილის მოსვლა კვლავ ibm watson iot საკმაოდ ძვირი ღირს aws iot– თან შედარებით. ამრიგად, ibm watson iot– ის ფასი განისაზღვრება თითო მოწყობილობის, მონაცემთა შენახვის, მონაცემთა ტრაფიკის მიხედვით. მაგრამ aws iot– ში ჩვენ შეგვიძლია გადავიხადოთ თანხა ერთხელ და შეგვიძლია დავამატოთ მეტი მოწყობილობა და მონაცემები, რომლებიც გამოქვეყნებულია მოწყობილობიდან და მიეწოდება მოწყობილობებს.

დაიწყეთ თქვენი მოწყობილობით- იქნება ეს სენსორი, კარიბჭე თუ სხვა რამ- და მოდით დაგეხმაროთ ღრუბელთან დაკავშირებაში.

თქვენი მოწყობილობის მონაცემები ყოველთვის დაცულია, როდესაც ღრუბელს დაუკავშირდებით ღია, მსუბუქი MGTT შეტყობინებების პროტოკოლის ან HTTP გამოყენებით. პროტოკოლებისა და წითელი კვანძების საშუალებით ჩვენ შეგვიძლია დავუკავშიროთ ჩვენი მოწყობილობა iot პლატფორმას და შევძლოთ წვდომა ცოცხალ და ისტორიულ მონაცემებზე.

გამოიყენეთ ჩვენი უსაფრთხო API პროგრამები თქვენი მოწყობილობების მონაცემებთან დასაკავშირებლად.

შექმენით პროგრამები ჩვენს მოცემულ ღრუბლოვან სერვისში მონაცემების ინტერპრეტაციისთვის.