AWS և IBM. IoT ծառայությունների համեմատություն. 4 քայլ

2024 Հեղինակ: John Day | [email protected]. Վերջին փոփոխված: 2024-01-30 09:48

Այսօր մենք համեմատում ենք երկու կույտ, որոնք հնարավորություն են տալիս զարգացնել 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- ն ավելի շատ լեզուներ է աջակցում, իսկ docker- ով հեշտ է օգտագործել այլ լեզուներով գրված սցենարներ: Դա կարելի է անել նաև Լամբդայի հետ, բայց դա անմիջապես չէ: Օրինակ կարող եք կարդալ այստեղ ՝

Երկու ծառայություններն էլ օգտագործման սահմանափակումներ ունեն, մենք դրանք հայտնում ենք աղյուսակում և ընդգծում լավագույնը:

Գինը հիմնված է GigaBytes վայրկյանում (RAM) `AWS Lambda- ի համար պահանջների քանակի հավելումով: Յուրաքանչյուր ծառայություն ունի անվճար ծրագիր, և դրանք գրեթե համարժեք են: Ինչպես տեսնում եք, Lambda- ն GB/s- ի համար մի փոքր ավելի էժան է, բայց այն ունի ծախսեր ՝ կապված այն հարցումների հետ, որոնք Cloud գործառույթները չունեն, ուստի ընդհանուր առմամբ ծախսերը գրեթե նույնն են: Իհարկե, եթե ձեզ անհրաժեշտ է առաջադրանքներ կատարել, որոնք ուտում են հիշողություն և օգտագործում են քիչ պահանջներ, ապա պետք է օգտագործեք Lambda- ն: Մեր կարծիքով, 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- ը չի աջակցում Amazon- ի ընտրած գրադարանը ՝ 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: Տվյալների հոսք և վերլուծություն

Տվյալների հոսքի ծառայությունները վճռորոշ նշանակություն ունեն իրական ժամանակում տվյալների մեծ հոսքերի մշակման և վերլուծման գործում: Այս հոսքը կարող է լինել ամպից դեպի օգտվողների սարք, ինչպես վիդեո հոսք, կամ օգտվողներից դեպի ամպ, ինչպես IoT հեռաչափությունը և սենսորների ընթերցումները: Հատկապես երկրորդ դեպքում, մենք կարող ենք ունենալ մի իրավիճակ, երբ առանձին աղբյուրները փոքր քանակությամբ տվյալներ են վերբեռնում, բայց երբ հաշվի առնենք ընդհանուր թողունակությունը, որը գալիս է բոլոր սարքերից, այն զգալի թողունակություն է սպառում, ուստի իմաստ ունի օգտագործել այդպիսի ծառայությունների համար մասնագիտացված ծառայություն: տվյալների հոսքեր: Առանց այս շարունակական հոսքի անմիջական մշակման, մենք ստիպված կլինենք մուտքային տեղեկատվությունը բուֆերացնել ժամանակավոր պահեստավորման մեջ և երկրորդ անգամ այն մշակել որոշ հաշվարկային շարժիչով: Այս վերջին մոտեցման խնդիրն այն է, որ մենք ստիպված կլինենք համակարգել ավելի տարբեր ծառայություններ `հասնելու այն, ինչ տվյալների հոսքի մեկ ծառայությունն արդեն միայնակ է անում ՝ մեծացնելով հավելվածի սպասարկման և կազմաձևման բարդությունը: Բացի այդ, բուֆերացումը սկզբունքորեն կարող է մեր դիմումն այլևս իրական ժամանակում չդարձնել, քանի որ ապրանքի մշակման համար անհրաժեշտ է, որ դրանից առաջ մնացած բոլոր տարրերը նույնպես մշակվեն, և բուֆերին գերակայության քաղաքականություն ավելացնելը կարող է կրկին, կտրուկ բարձրացնել բարդությունը: Ամփոփելով ՝ տվյալների հոսքային ծառայություններն առաջարկում են տվյալների հոսքի կառավարում իրական ժամանակում ՝ հեշտ կազմաձևմամբ և կարող են վերլուծություն տրամադրել մուտքային տվյալների վերաբերյալ: Այստեղ մենք համեմատում ենք IBM- ի և AWS կույտի երկու հիմնական հոսքային ծառայությունները ՝ IBM Streams- ը և AWS Kinesis- ը:

Մենք սկսում ենք նշելով, որ բոլոր հիմնական հնարավորությունները, որոնք մենք կարող ենք ցանկանալ հոսքային ծառայությունից, առաջարկվում են ինչպես IBM- ի, այնպես էլ AWS- ի կողմից: Այս հատկանիշները ներառում են գործնականում անսահմանափակ մշակման արագություն, ցածր ուշացում և տվյալների իրական ժամանակի վերլուծություն: Քանի որ մենք խոսում ենք մասնագիտական ծառայությունների մասին, նրանք երկուսն էլ առաջարկում են արտադրության դասի գործիքներ տեղակայման և ավտոմատացման համար:

Խոսելով տվյալների վերլուծության մասին ՝ երկու ծառայություններն էլ այն առաջարկում են որպես ընտրովի ՝ ստիպելով ձեզ վճարել միայն անհրաժեշտության դեպքում, թե ոչ: Kinesis- ի դեպքում, երբ ձեզ անհրաժեշտ չեն վերլուծություններ, այլ պարզապես տվյալների հոսքի կառավարում, գները գանձվում են մշակված GB- ի դիմաց ՝ մշակման ժամանակի փոխարեն, ինչպես IBM- ի դեպքում: Մեկ ԳԲ -ի գինը, ընդհանուր առմամբ, ավելի էժան կլինի, քան մեկ գինը, քանի որ դուք վճարում եք միայն մուտքային տրաֆիկի համար: Այս գրառման մնացած մասի համար մենք հաշվի կառնենք թե IBM Streams- ը և թե AWS Kinesis- ը ՝ տվյալների վերլուծության հնարավորությունը միացված:

Streams- ը և Kinesis- ը ապահովում են տարբեր ծառայությունների ինտեգրում մուտքային տվյալները նախապես մշակելու և զտելու համար, նախքան դրանք փոխանցել տվյալների վերլուծությանը, համապատասխանաբար Apache Edgent- ին և AWS Lambda- ին: Թեև այս ծառայություններն արմատապես տարբերվում են մեկը մյուսից, մենք դրանք կքննարկենք միայն երկու հոսքային ծառայությունների տեսանկյունից: Երկուսի միջև հիմնարար տարբերությունն այն է, որ Apache Edgent- ը կատարում է սարքը, մինչդեռ AWS Lambda- ն կատարում է ամպի վրա: Սա բերում է բազմաթիվ դրական և բացասական կողմեր. տվյալների համար, որոնք ի վերջո կհեռացվեն: Փոխարենը, Edgent- ի կողմից, մենք ունենք, որ հաշվարկների մեծ մասն արված է, լավ, ցանցի եզրին (այսպիսով ՝ սարքերում) նախքան ամպի վրա անիմաստ տվյալներ բեռնելը: Հիմնական թերությունն այն է, որ Edgent- ը մեծ շրջանակ է, որի ստեղծման համար կարող է ժամանակ պահանջվել, իսկ պահպանման համար `բարդ: Մեկ այլ տարբերություն, որը կարող է տեղին լինել հարթակի ընտրության հարցում, այն է, որ Edgent- ը լիովին բաց կոդ է, իսկ Lambda- ն ՝ ոչ: Սա կարող է դիտվել և՛ որպես պրոֆեսիոնալ, քանի որ այն կոդը, որը դուք կամ ձեր հաճախորդը կկատարեք, միշտ դրական է, և՛ որպես բացասական, քանի որ կարող են լինել իրավիճակներ, երբ անհապաղ աջակցության կարիք ունեք, որը հնարավոր չէ տրամադրել բաց կոդով բոլոր միջավայրերը:

Այլ առանձնահատկություններ, որոնք մենք կարող ենք նշել, դա հատկացված ռեսուրսների Kinesis- ի ավտոմատ մասշտաբայնությունն է: Իրոք, նրա առաջարկած սարքավորումները կազմված են մի շարք այսպես կոչված Kinesis Processing Units (KPU) զուգահեռ աշխատող համակարգերից, որտեղ մեկ KPU- ն առաջարկում է 1 vCore և 4 ԳԲ օպերատիվ հիշողություն: Նրանց թիվը կախված է հայտի կարիքներից և դինամիկորեն և ավտոմատ կերպով բաշխվում են (այն, ինչ դուք վճարում եք, իրոք, CPU- ի ժամանակը բազմապատկում է KPU- ների թիվը), պարզապես հիշեք, որ Kinesis- ի քաղաքականությունն է ձեզանից մեկ KPU- ով ավելի գանձելը, եթե օգտագործում եք Java դիմում. Փոխարենը, IBM Streams- ը չի տալիս այսպիսի ճկունություն ՝ առաջարկելով ձեզ ֆիքսված ապարատով տարա, ավելի շատ մանրամասներ, երբ մենք խոսում ենք գնագոյացման մասին: Մյուս կողմից, IBM Streams- ը ավելի բաց է, քան Kinesis- ը, քանի որ այն WAN- ին միանում է սովորական օգտագործված արձանագրությունների միջոցով, ինչպես HTTP, MQTT և այլն, մինչդեռ Kinesis- ը փակ է AWS էկոհամակարգի համար:

Որպես վերջնական համեմատություն, եկեք խոսենք գնագոյացման մասին, և թույլ տվեք ասել, որ IBM- ն այս հարցում հիանալի չի աշխատում: Մենք կարգավորել ենք տարբեր լուծումներ երեք տարբեր կատեգորիաների համար (հիմնական, բարձրակարգ, ծայրահեղ բարձրակարգ) ինչպես IBM- ի, այնպես էլ AWS- ի համար, և մենք պատրաստվում ենք համեմատել դրանց գինը: Հիմնական կազմաձևում մենք ունենք մեկ AWS KPU, որը նշվեց ավելի վաղ ՝ նույն սարքավորումով IBM լուծման դիմաց: Բարձրակարգի համար մենք ունենք 8 KPU, որոնք աշխատում են Kinesis- ի համար զուգահեռ, իսկ IBM- ի համար միշտ 2 կոնտեյներ ՝ յուրաքանչյուրը 4 vCore- ով և 12 ԳԲ օպերատիվ հիշողությամբ: Միշտ IBM- ն ծայրահեղ բարձրակարգում առաջարկում է 16 վկոր և 128 ԳԲ օպերատիվ հիշողություն ունեցող մեկ տարա, մինչդեռ մենք բաց ենք թողել AWS- ի համարժեք լուծումը, քանի որ եթե որոշ ծրագրեր պահանջում են այսքան մեծ RAM, հնարավոր չէ այն տարբեր 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- ի միջոցով: Արձանագրությունների և node-red- ի օգնությամբ մենք կարող ենք մեր սարքը միացնել iot հարթակին և կարող ենք մուտք գործել կենդանի և պատմական տվյալներ:

Օգտագործեք մեր ապահով API- ները `ձեր ծրագրերը ձեր սարքերի տվյալների հետ կապելու համար:

Ստեղծեք ծրագրեր մեր տրված ամպային ծառայության մեջ ՝ տվյալները մեկնաբանելու համար: