AWS и IBM: сравнение служб Интернета вещей: 4 шага

2024 Автор: John Day | [email protected]. Последнее изменение: 2024-01-30 11:51

Сегодня мы сравниваем два стека, которые позволяют разрабатывать приложения IoT с точки зрения различных предложений услуг.

Шаг 1. Функции как услуга

FaaS - это категория облачных сервисов, используемых для построения «бессерверной» архитектуры. FaaS позволяет клиентам разрабатывать, запускать и управлять функциями приложений без создания и обслуживания инфраструктуры.

Amazon предлагает AWS Lambda, IBM предлагает IBM Cloud Functions. Эти сервисы очень похожи, однако Lambda была первой из них. Используя FaaS, вы можете запускать фрагменты кода в облаке, и каждая служба поддерживает разные языки программирования.

Облачные функции IBM: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # и т. Д.), Любой через Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, любой через Runtime API

IBM поддерживает больше языков, а с помощью Docker легко использовать сценарии, написанные на других языках. Это можно сделать и с помощью Lambda, но не сразу. Вы можете прочитать пример здесь:

У обоих сервисов есть ограничения на использование, мы указываем их в таблице и выделяем лучшие.

Цена основана на гигабайтах в секунду (ОЗУ) с добавлением количества запросов к AWS Lambda. У каждого сервиса есть бесплатный план, и они почти эквивалентны. Как видите, Lambda немного дешевле для гигабайт / с, но у нее есть стоимость, связанная с запросами, которых нет в 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. Потоковая передача данных и аналитика

Службы потоковой передачи данных имеют решающее значение для обработки и анализа больших потоков данных в реальном времени. Этот поток может передаваться из облака на устройство пользователя, например потоковая передача видео, или от пользователей в облако, например, телеметрия Интернета вещей и показания датчиков. В частности, во втором случае у нас может возникнуть ситуация, когда отдельные источники загружают небольшие объемы данных, но когда мы рассматриваем общую пропускную способность, поступающую со всех устройств, она потребляет значительную полосу пропускания, поэтому имеет смысл использовать службу, специализированную для обработки таких данных. потоки данных. Без непосредственной обработки этого непрерывного потока нам пришлось бы буферизовать входящую информацию во временное хранилище и во второй раз обработать ее с помощью некоторого вычислительного механизма. Проблема этого последнего подхода состоит в том, что нам придется координировать больше различных сервисов, чтобы достичь того, что уже делает один сервис потока данных, увеличивая сложность обслуживания и настройки приложения. Кроме того, буферизация в принципе может сделать наше приложение более не работающим в режиме реального времени, поскольку для обработки элемента необходимо, чтобы все остальные элементы до него также обрабатывались, а добавление политик приоритета в буфер может, опять же,, резко увеличивают сложность. Подводя итог, можно сказать, что службы потоковой передачи данных предлагают обработку потоков данных в режиме реального времени с простой конфигурацией и могут предоставлять аналитику по входящим данным. Здесь мы сравниваем два основных потоковых сервиса стека IBM и AWS, а именно IBM Streams и AWS Kinesis.

Начнем с того, что отметим, что все основные функции, которые могут потребоваться от потокового сервиса, предлагаются как IBM, так и AWS. Эти функции включают практически бесконечную скорость обработки, низкую задержку и аналитику данных в реальном времени. Поскольку мы говорим о профессиональных услугах, они оба предлагают инструменты производственного уровня для развертывания и автоматизации.

Говоря об аналитике данных, обе службы предлагают ее как необязательную, заставляя вас платить только в зависимости от того, нужно вам это или нет. В случае Kinesis, когда вам не нужна аналитика, а нужна только обработка потока данных, цены взимаются за обработанный ГБ, а не за время обработки, как в случае с 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 виртуальное ядро и 4 ГБ ОЗУ. Их количество зависит от потребностей приложения и распределяется динамически и автоматически (вы действительно платите за время процессора, умноженное на количество KPU), просто помните, что политика Kinesis - взимать с вас на один KPU больше, если вы используете Java. заявление. IBM Streams, напротив, не обеспечивает такой гибкости, предлагая вам контейнер с фиксированным оборудованием, подробнее, когда мы говорим о ценах. С другой стороны, IBM Streams более открыта, чем Kinesis, поскольку она взаимодействует с WAN через распространенные протоколы, такие как HTTP, MQTT и т. Д., В то время как Kinesis закрыт для экосистемы AWS.

В качестве последнего сравнения давайте поговорим о ценах и позвольте мне сказать, что IBM не очень хорошо работает в этом вопросе. Мы настроили разные решения для трех разных категорий (базовые, высокопроизводительные, сверхвысокие) как для IBM, так и для AWS, и мы собираемся сравнить их цену. В базовой конфигурации у нас есть один AWS KPU, упомянутый ранее, против решения IBM с таким же оборудованием. Для high-end у нас есть 8 работающих KPU параллельно для Kinesis и 2 контейнера всегда параллельно для IBM, каждый с 4 виртуальными ядрами и 12 ГБ ОЗУ. IBM всегда предлагает в сверхвысоком уровне один контейнер с 16 виртуальными ядрами и 128 ГБ ОЗУ, в то время как мы опускали эквивалентное решение для AWS, поскольку, если для какого-то приложения требуется такой большой объем ОЗУ, его невозможно запустить на разных KPU.. Цены, которые мы сообщаем, выражены в долларах США в месяц с учетом использования в режиме 24/7. Для базовой конфигурации у нас есть для IBM и AWS соответственно 164 $ и 490 $, для high-end 1320 $ и 3500 $, для ультра-high-end 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, чтобы связать свои приложения с данными с ваших устройств.

Создавайте приложения в рамках нашей облачной службы для интерпретации данных.