AWS a IBM: Srovnání služeb IoT: 4 kroky

2024 Autor: John Day | [email protected]. Naposledy změněno: 2024-01-30 08:22

Dnes porovnáváme dva balíčky, které umožňují vyvíjet aplikace IoT z pohledu různých nabídek služeb.

Krok 1: Funkce jako služba

FaaS je kategorie cloudových služeb používaných k vybudování „bezserverové“architektury. FaaS umožňuje zákazníkům vyvíjet, provozovat a spravovat funkce aplikací bez budování a údržby infrastruktury.

Amazon nabízí AWS Lambda, IBM nabízí IBM Cloud Functions. Tyto služby jsou velmi podobné, nicméně Lambda byla první tohoto druhu. Pomocí FaaS můžete spouštět části kódu v cloudu a každá služba podporuje různé programovací jazyky.

IBM Cloud Functions: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# atd.), Any přes Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Any přes Runtime API

IBM podporuje více jazyků a pomocí dockeru lze snadno používat skripty napsané v jiných jazycích. To lze provést také pomocí Lambda, ale není to okamžité. Příklad si můžete přečíst zde:

Obě služby mají limity využití, hlásíme je v tabulce a zvýrazníme to nejlepší.

Cena je založena na GigaBytech za sekundu (RAM) s přidáním počtu požadavků na AWS Lambda. Každá služba má bezplatný plán a jsou téměř ekvivalentní. Jak vidíte, Lambda je o něco levnější pro GB/s, ale má náklady související s požadavky, které Cloud Functions nemá, takže náklady jsou obecně téměř stejné. Samozřejmě, pokud potřebujete spouštět úkoly, které zabírají paměť a používají málo požadavků, měli byste použít Lambda. Hlavní výhodou IBM Cloud Function je podle nás to, že její zásobník je open source. Je zcela založen na Apache OpenWhisk a může být také nasazen na soukromé infrastruktuře.

Krok 2: Strojové učení

Pole, kde zásobníky IBM a AWS nabízejí podobné služby, je oblast strojového učení: Amazon s jeho SageMaker a IBM s Watson Machine Learning. Tyto dvě služby jsou v mnoha aspektech velmi podobné: obě se prezentují jako nástroje, které pomáhají vědcům a vývojářům dat budovat, školit a poté nasadit do prostředí připraveného pro produkci jejich modely strojového učení, ale filozofie, kterou obě společnosti přijaly, se dost liší. Obě služby vám umožňují vybrat si mezi různými stupni ovládání modelů, které používáte. Ve Watson ML máte několik předdefinovaných modelů, které jsou již vyškolené k provádění některých velmi specifických úkolů: například pokud chcete rozpoznat, jaké objekty jsou na obrázku, stačí importovat model VisualRecognitionV3 a předat mu obrázek, který chtít analyzovat. Můžete také vytvořit „vlastní model“, ale ve Watson ML to většinou znamená vzít již postavený model a provést na něm školení, takže přizpůsobení je dosti omezené. Je důležité si uvědomit, že ani SageMaker ani Watson ML nejsou jediné způsoby, jak provádět strojové učení na hromádkách jejich vývojářů, jsou to jen služby, jejichž cílem je usnadnit vývojářům život. Platforma Watson ML také podporuje mnoho z nejpopulárnějších knihoven strojového učení, takže můžete dokonce postavit model od začátku pomocí knihoven PyTorch, Tensorflow nebo podobných. Buď tyto knihovny použijete přímo, nebo použijete předem připravené modely, neexistuje žádná střední cesta. Také Watson ML nepodporuje výběrovou knihovnu Amazonu, Apache MXNet, která místo toho má prvotřídní podporu v SageMaker.

Přístup Amazon SageMaker je, i když používá vestavěné možnosti, o něco nižší: spíše než vybírat z předem připravených modelů, umožňuje vám vybrat si z množství již implementovaných tréninkových algoritmů, které můžete použít při vytváření model tradičnějším způsobem. Pokud to nestačí, můžete také použít svůj vlastní algoritmus. Tento způsob práce určitě vyžaduje více znalostí o tom, jak se strojové učení provádí, ve srovnání s pouhým použitím trénovaného modelu ve Watson ML.

Na první pohled se může zdát, že Watson ML je „snadný a rychlý“způsob, přičemž Amazon SageMaker je ten složitější na nastavení. To z některých hledisek nemusí být úplně pravda, protože SageMaker je strukturován tak, aby vše běželo na notebooku Jupyter, zatímco pro stejné funkce ve Watson ML musíte z webového uživatelského rozhraní nastavit mnoho různých dílčích služeb. Předzpracování dat má také vyhrazené mezery ve službě IBM, zatímco SageMaker spoléhá na to, že to vše uděláte z kódu ve svém notebooku. To plus skutečnost, že notebooky Jupyter nejsou z hlediska softwarového inženýrství zrovna nejlepší volbou, může zabránit tomu, aby se SageMaker ve výrobě velmi dobře škáloval. Obě služby mají docela dobré a jednoduché mechanismy k nasazení vašeho modelu a zpřístupnění API pro něj ve vnějším světě.

Závěrem lze říci, že Watson ML si vede lépe v rozsáhlých projektech, kde notebooky Jupyter začínají ukazovat své limity a kde nepotřebujete velké přizpůsobení toho, co samotný model dělá. SageMaker je mnohem lepší, když potřebujete větší flexibilitu při definování algoritmů, ale při jeho používání musíte vzít v úvahu skutečnost, že se musíte spolehnout na notebooky Jupyter, které se ve výrobě nemusí dobře škálovat. Řešením by mohlo být co největší oddělení zbytku kódu od modelu, aby kód ve skutečných noteboocích nebyl příliš velký a mohli jsme lépe organizovat náš software v ostatních modulech, které používají pouze API našeho modelu.

Krok 3: Streamování dat a analytika

Služby streamování dat jsou zásadní pro zpracování a analýzu velkých toků dat v reálném čase. Tento tok může být z cloudu do zařízení uživatele, jako je streamování videa, nebo z uživatelů do cloudu, jako telemetrie IoT a údaje ze senzorů. Zejména ve druhém případě bychom mohli mít situaci, kdy jednotlivé zdroje nahrávají malá množství dat, ale když vezmeme v úvahu celkovou propustnost pocházející ze všech zařízení, spotřebovává značnou šířku pásma, a proto dává smysl používat službu specializovanou na zpracování takových toky dat. Bez přímého zpracování tohoto nepřetržitého toku bychom museli ukládat příchozí informace do dočasného úložiště a podruhé je zpracovávat pomocí nějakého výpočetního enginu. Problém tohoto posledního přístupu spočívá v tom, že bychom museli koordinovat více různých služeb, abychom dosáhli toho, co jedna služba toku dat již dělá sama, což zvyšuje složitost údržby a konfigurace aplikace. Ukládání do vyrovnávací paměti navíc může v zásadě způsobit, že naše aplikace již nebude v reálném čase, protože pro položku, která má být zpracována, je nutné, aby byly zpracovány také všechny ostatní položky, které před ní byly zpracovány, a přidání zásad priority do vyrovnávací paměti znovu, drasticky zvyšte složitost. Souhrnně lze říci, že služby streamování dat nabízejí zpracování datových toků v reálném čase se snadnou konfigurací a mohou poskytovat analýzu příchozích dat. Zde porovnáváme dvě hlavní streamovací služby zásobníku IBM a AWS, konkrétně IBM Streams a AWS Kinesis.

Začínáme s tím, že IBM i AWS nabízejí všechny základní funkce, které od streamovací služby můžeme chtít. Tyto funkce zahrnují prakticky nekonečnou rychlost zpracování, nízkou latenci a analýzu dat v reálném čase. Protože mluvíme o profesionálních službách, oba nabízejí nástroje pro nasazení a automatizaci na úrovni produkce.

Když mluvíme o analýze dat, obě služby ji nabízejí jako volitelnou, takže platíte pouze za to, zda ji potřebujete nebo ne. V případě Kinesis, kdy nepotřebujete analytiku, ale pouze zpracování toku dat, jsou ceny účtovány za zpracovaný GB místo doby zpracování, jako v případě IBM. Ceny za GB budou obecně levnější než ceny za čas, protože platíte pouze za příchozí provoz. Ve zbytku tohoto příspěvku budeme zvažovat jak IBM Streams, tak AWS Kinesis s povolenou funkcí analýzy dat.

Streams a Kinesis poskytují integraci s různými službami pro předběžné zpracování a filtrování příchozích dat před jejich předáním do datové analýzy, respektive s Apache Edgent a AWS Lambda. Přestože se tyto služby navzájem radikálně liší, budeme o nich diskutovat pouze z pohledu dvou streamovacích služeb. Zásadní rozdíl mezi nimi je v tom, že Apache Edgent se spouští na zařízení, zatímco AWS Lambda se spouští v cloudu. To přináší spoustu pro a proti: ze strany Lambda máme flexibilní a snadno použitelnou službu s bezproblémovou integrací s Kinesis, ale vyžaduje, aby byla data již nahrána do cloudu, čímž ztrácí na efektivitě a platí Kinesis také pro data, která budou nakonec vyřazena. Místo toho z Edgentní strany máme, že většina výpočtů se provádí na okraji sítě (tedy na zařízeních) před odesláním zbytečných dat do cloudu. Hlavní nevýhodou je, že Edgent je rozsáhlý framework, jehož nastavení může vyžadovat čas a jeho údržba může být složitá. Další rozdíl, který by mohl být relevantní při výběru platformy, je ten, že Edgent je plně open source, Lambda nikoli. To lze chápat jako profíka, protože mít přístup ke kódu, který vy nebo váš zákazník provedete, je vždy pozitivní věc, a to jak proti, protože mohou nastat situace, kdy potřebujete naléhavou podporu, kterou nelze poskytnout v všechna open source prostředí.

Dalšími funkcemi, které můžeme zmínit, je automatická škálovatelnost přidělených zdrojů od společnosti Kinesis. Hardware, který nabízí, je složen z několika paralelně běžících takzvaných Kinesis Processing Units (KPU), kde jeden KPU nabízí 1 vCore a 4 GB RAM. Jejich počet závisí na potřebách aplikace a jsou dynamicky a automaticky přidělovány (to, co platíte, je skutečně čas CPU krát počet KPU), nezapomeňte, že je zásadou Kinesis účtovat vám o jeden KPU více, pokud používáte Javu aplikace. IBM Streams místo toho neposkytuje tento druh flexibility, protože vám nabízí kontejner s pevným hardwarem, více podrobností, když mluvíme o cenách. Na druhou stranu je IBM Streams otevřenější než Kinesis, protože je připojen k síti WAN pomocí běžně používaných protokolů, jako je HTTP, MQTT a tak dále, zatímco Kinesis je pro ekosystém AWS uzavřený.

Jako konečné srovnání pojďme mluvit o cenách a dovolte mi říci, že IBM v tomto bodě nefunguje dobře. Konfigurovali jsme různá řešení pro tři různé kategorie (základní, špičkové, ultra špičkové) pro IBM i AWS a budeme porovnávat jejich cenu. V základní konfiguraci máme jeden AWS KPU, zmíněný dříve, proti řešení IBM se stejným hardwarem. Pro high-end máme 8 KPU, které běží paralelně pro Kinesis a 2 kontejnery vždy paralelně pro IBM, každý se 4 vCores a 12 GB RAM. IBM vždy nabízí v ultra-high-endu jeden kontejner se 16 vCory a 128 GB RAM, zatímco my jsme vynechali ekvivalentní řešení pro AWS, protože pokud nějaká aplikace vyžaduje toto velké množství RAM, nebylo možné jej spustit na různých KPU. Ceny, které uvádíme, jsou vyjádřeny v USD/měsíc s ohledem na používání 24/7. Pro základní konfiguraci máme pro IBM a AWS 164 $ a 490 $, pro high-end 1320 $ a 3500 $, pro ultra-high-end AWS není brán v úvahu a existuje pouze IBM s 6300 $. Z těchto výsledků vidíme, že Kinesis funguje lépe pro běžného uživatele až na podnikovou úroveň, zatímco postrádá možnosti přímo zpracovávat analýzu dat, která vyžaduje obrovské množství výpočetního výkonu. Kinesis poskytuje lepší poměr výkon/$ než IBM Streams, k čemuž přispívá také dynamické přidělování malých bloků prostředků pouze v případě potřeby, zatímco IBM vám nabízí pevný kontejner. Tímto způsobem, pokud je vaše pracovní zátěž charakterizována špičkami, jste u IBM nuceni nadhodnocovat potřeby své aplikace a konfigurovat řešení v nejhorším případě. IBM místo placení celého měsíce nabízí poplatky za hodiny, ale není automatizovaná jako Kinesis.

Krok 4: Architektura IoT

Konfigurace zařízení pro aws iot je v porovnání s ibm watson iot poměrně snadná. Protože v ibm watson iot je autentizace na zařízení s tokenem a jakmile token zobrazí, už se nikdy nezobrazí. Příchod k cenové části opět ibm watson iot je poměrně nákladný ve srovnání s aws iot. Cena v poplatcích za ibm watson se tedy odvíjí od zařízení, úložiště dat a datového provozu. Ale v aws iot můžeme částku zaplatit jednou a můžeme přidat další zařízení a data publikovaná ze zařízení a doručená do zařízení.

Začněte svým zařízením- ať už je to senzor, brána nebo něco jiného- a pomůžeme vám spojit se s cloudem.

Data vašeho zařízení jsou vždy zabezpečená, když se připojujete ke cloudu pomocí otevřeného, lehkého protokolu zpráv MGTT nebo HTTP. Pomocí protokolů a node-red můžeme naše zařízení propojit s platformou iot a přistupovat k živým i historickým datům.

Pomocí našich zabezpečených rozhraní API propojte své aplikace s daty z vašich zařízení.

Vytvářejte aplikace v rámci naší dané cloudové služby pro interpretaci dat.