AWS и IBM: Сравнение на IoT услуги: 4 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:52

Днес сравняваме два стека, които дават възможност за разработване на IoT приложения от гледна точка на различни оферти за услуги.

Стъпка 1: Функционира като услуга

FaaS е категория облачни услуги, използвани за изграждане на „без сървър“архитектура. FaaS позволява на клиентите да разработват, изпълняват и управляват функционалности на приложения, без да изграждат и поддържат инфраструктурата.

Amazon предлага AWS Lambda, IBM предлага IBM Cloud Functions. Тези услуги са доста сходни, но 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 е лесен за използване скриптове, написани на други езици. Това може да се направи и с Lambda, но не е незабавно. Можете да прочетете пример тук:

И двете услуги имат ограничения за използване, ние ги отчитаме в таблица и подчертаваме най -добрите.

Цената се основава на GigaBytes за секунди (RAM) с добавяне на броя заявки за AWS Lambda. Всяка услуга има безплатен план и те са почти еквивалентни. Както можете да видите, Lambda е малко по -евтино за GB/s, но има цена, свързана с заявки, които Cloud Functions няма, така че цената е почти същата като цяло. Разбира се, ако трябва да изпълнявате задачи, които изяждат памет и използват малко заявки, трябва да използвате 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 трябва да настроите много различни под-услуги от уеб потребителския интерфейс. Предварителната обработка на данните също има специални пространства в услугата на 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. Ценообразуването на GB ще бъде обикновено по -евтино от ценообразуването за време, тъй като плащате само за входящия трафик. За останалата част от тази публикация ще разгледаме IBM Streams и AWS Kinesis с активирана функция за анализ на данни.

Потоците и Kinesis осигуряват интеграция с различни услуги за предварителна обработка и филтриране на входящите данни, преди да ги предадат на анализ на данни, съответно с Apache Edgent и AWS Lambda. Въпреки че тези услуги са коренно различни една от друга, ние ще ги обсъдим само от гледна точка на двете стрийминг услуги. Основната разлика между двете е, че Apache Edgent се изпълнява на устройството, докато AWS Lambda се изпълнява в облака. Това носи много плюсове и минуси: от страна на Lambda имаме гъвкава и лесна за използване услуга с безпроблемна интеграция с Kinesis, но тя изисква данните вече да бъдат качени в облака, като по този начин губи ефективност и плаща също Kinesis за данните, които в крайна сметка ще бъдат изхвърлени. От страна на Edgent вместо това имаме, че по -голямата част от изчисленията се извършват, добре, на ръба на мрежата (по този начин на устройствата), преди да качите безполезни данни в облака. Основният недостатък е, че Edgent е голяма рамка, която може да изисква време за настройка и може да бъде сложна за поддръжка. Друга разлика, която би могла да бъде от значение при избора на платформа, е, че Edgent е изцяло с отворен код, а Lambda - не. Това може да се разглежда и като професионалист, тъй като достъпът до кода, който вие или вашият клиент ще изпълнявате, винаги е положително нещо, и двете като минус, защото може да има ситуации, в които имате нужда от спешна поддръжка, която не може да бъде предоставена в всички среди с отворен код.

Други характеристики, които можем да споменем, е автоматичното мащабиране на разпределените ресурси на Kinesis. Всъщност хардуерът, който предлага, се състои от редица така наречени Kinesis Processing Units (KPU), работещи паралелно, където един KPU предлага 1 vCore и 4GB RAM. Техният брой зависи от нуждите на приложението и се разпределят динамично и автоматично (това, което плащате, е времето на процесора умножено по броя на 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 vCores и 12GB RAM. Винаги IBM предлага в свръхвисокия клас един контейнер с 16 vCores и 128 GB RAM, докато пропуснахме еквивалентно решение за 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, за да свържете вашите приложения с данни от вашите устройства.

Създавайте приложения в рамките на предоставената ни облачна услуга за интерпретиране на данни.