AWS och IBM: en jämförelse av IoT -tjänster: 4 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:44

Idag jämför vi två staplar som gör det möjligt att utveckla IoT -applikationer med tanke på olika tjänsteerbjudanden.

Steg 1: Funktioner som en tjänst

FaaS är en kategori av molntjänster som används för att bygga en "serverlös" arkitektur. FaaS låter kunderna utveckla, köra och hantera applikationsfunktioner utan att bygga och underhålla infrastrukturen.

Amazon erbjuder AWS Lambda, IBM erbjuder IBM Cloud -funktioner. Dessa tjänster är ganska lika, men Lambda var den första av detta slag. Med FaaS kan du köra kodbitar i molnet och varje tjänst stöder olika programmeringsspråk.

IBM Cloud -funktioner: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# etc.), Alla via Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Any via Runtime API

IBM stöder fler språk och med docker är det lätt att använda skript skrivet på andra språk. Detta kan också göras med Lambda men det är inte omedelbart. Du kan läsa ett exempel här:

Båda tjänsterna har användningsbegränsningar, vi rapporterar dem i en tabell och markerar de bästa.

Priset är baserat på GigaBytes per sekunder (RAM) med tillägget av antalet förfrågningar för AWS Lambda. Varje tjänst har en gratis plan och de är nästan likvärdiga. Som du kan se är Lambda lite billigare för GB/s men det har en kostnad relaterad till förfrågningar som Cloud Functions inte har så kostnaden är nästan densamma i allmänhet. Naturligtvis, om du behöver köra uppgifter som äter minne och använder få förfrågningar bör du använda Lambda. Enligt vår mening är den största fördelen med IBM Cloud Function att dess stack är öppen källkod. Den är helt baserad på Apache OpenWhisk och kan också distribueras på en privat infrastruktur.

Steg 2: Maskininlärning

Ett område där IBM- och AWS -staplarna erbjuder liknande tjänster är maskininlärning: Amazon med sin SageMaker och IBM med Watson Machine Learning. De två tjänsterna är på många aspekter mycket lika: båda presenterar sig som verktyg för att hjälpa datavetenskapare och utvecklare att bygga, utbilda och sedan distribuera sina maskininlärningsmodeller i produktionsförberedda miljöer, men de filosofier de två företagen anammar varierar ganska mycket. Båda tjänsterna låter dig välja mellan olika grader av kontroll på de modeller du använder. I Watson ML har du några inbyggda modeller som redan är utbildade för att utföra några mycket specifika uppgifter: till exempel, om du vill känna igen vilka objekt som finns i en bild importerar du bara VisualRecognitionV3-modellen och skickar till den bilden du vill analysera. Du kan också bygga en "anpassad modell", men i Watson ML betyder det mestadels att ta en redan byggd modell och träna den, så anpassningen är ganska begränsad. Det är dock viktigt att notera att varken SageMaker eller Watson ML är de enda sätten att göra maskininlärning på deras utvecklares staplar, det är bara tjänster som syftar till att göra utvecklarnas liv enklare. Watson ML -plattformen stöder också många av de mest populära maskininlärningsbiblioteken, så att du till och med kan bygga en modell från grunden med PyTorch, Tensorflow eller liknande bibliotek. Antingen använder du dessa bibliotek direkt, eller använder de färdiga modellerna, det finns ingen mellanväg. Watson ML stöder inte Amazons valbibliotek, Apache MXNet, som istället har förstklassigt stöd i SageMaker.

Amazon SageMakers tillvägagångssätt, även när du använder inbyggda alternativ, är lite mer låg: istället för att välja mellan färdiga modeller kan du välja bland en mängd redan implementerade träningsalgoritmer som du kan använda när du bygger dina modell på ett mer traditionellt sätt. Om dessa inte räcker kan du också använda din egen algoritm. Detta sätt att göra saker kräver verkligen mer kunskap om hur maskininlärning görs jämfört med att bara använda en utbildad modell i Watson ML.

Vid en första anblick kan det tyckas att Watson ML är det "enkla och snabba" sättet, där Amazon SageMaker är den mer komplexa att sätta upp. Detta är kanske inte helt sant ur vissa synvinklar, eftersom SageMaker är strukturerad för att få allt att köras på en Jupyter Notebook, medan du för samma funktioner i Watson ML måste konfigurera många olika sub-tjänster från webbgränssnittet. Förbehandlingen av data har också dedikerade utrymmen på IBM -tjänsten medan SageMaker förlitar sig på att du gör allt från kod i din anteckningsbok. Detta plus det faktum att Jupyter -bärbara datorer inte precis är det bästa valet ur programvaruteknisk synvinkel, kan hindra SageMaker från att skala mycket bra i produktionen. Båda tjänsterna har ganska bra och enkla mekanismer för att distribuera din modell och göra API: er för den tillgängliga i omvärlden.

Sammanfattningsvis presterar Watson ML bättre i stora projekt där Jupyter -anteckningsböckerna börjar visa sina gränser, och där du inte behöver mycket anpassning i vad själva modellen gör. SageMaker är mycket bättre när du behöver mer flexibilitet när du definierar algoritmerna, men när du använder den måste du ta hänsyn till det faktum att du måste lita på Jupyter Notebooks, som kanske inte är så bra i produktionen. En lösning kan vara att koppla bort resten av koden från modellen så mycket som möjligt, så att koden i själva bärbara datorer inte blir för stor och vi bättre kan organisera vår programvara i de andra modulerna som bara använder modellens API.

Steg 3: Dataströmning och analys

Dataströmningstjänster är avgörande för att hantera och analysera stora dataflöden i realtid. Detta flöde kan vara från molnet till användarnas enhet, som en videoströmning, eller från användarna till molnet, som IoT -telemetri och sensoravläsningar. Särskilt i det andra fallet kan vi ha en situation där enstaka källor laddar upp små mängder data, men när vi överväger den totala genomströmningen, som kommer från alla enheter, förbrukar den avsevärd bandbredd, så det är vettigt att använda en tjänst specialiserad för att hantera sådana dataflöden. Utan att hantera detta kontinuerliga flöde direkt, skulle vi behöva buffra inkommande information till en tillfällig lagring och vid en andra gång bearbeta den med någon beräkningsmotor. Problemet med detta sista tillvägagångssätt är att vi måste samordna fler olika tjänster för att uppnå vad en enda dataströmtjänst redan gör ensam, vilket ökar komplexiteten i programmets underhåll och konfiguration. Dessutom kan buffringen i princip göra att vår ansökan inte längre är i realtid, eftersom för att en artikel ska bearbetas är det nödvändigt att alla andra objekt innan den också ska bearbetas, och att lägga till prioritetspolicyer till bufferten, igen, öka komplexiteten drastiskt. Sammanfattningsvis erbjuder dataströmningstjänster dataflödeshantering i realtid, med en enkel konfiguration och kan tillhandahålla analys av inkommande data. Här jämför vi de två viktigaste streamingtjänsterna för IBM- och AWS -stacken, nämligen IBM Streams och AWS Kinesis.

Vi börjar med att notera att alla grundläggande funktioner som vi kanske vill ha från en streamingtjänst erbjuds av både IBM och AWS. Dessa funktioner inkluderar praktiskt taget oändlig bearbetningshastighet, låg latens och dataanalys i realtid. Eftersom vi pratar om professionella tjänster erbjuder de båda produktionsverktyg för distribution och automatisering.

På tal om dataanalys erbjuder båda tjänsterna det som tillval, så att du bara kan betala oavsett om du behöver det eller inte. När det gäller Kinesis, när du inte behöver analys utan bara dataflödeshantering, debiteras priserna per GB bearbetat istället för behandlingstid, som i IBM -fallet. Prissättningen per GB blir i allmänhet billigare än prissättningen per gång, eftersom du bara betalar för den inkommande trafiken. För resten av detta inlägg kommer vi att överväga både IBM Streams och AWS Kinesis med dataanalysfunktionen aktiverad.

Strömmar och Kinesis tillhandahåller integration med olika tjänster för förbehandling och filtrering av inkommande data innan de skickas till dataanalys, respektive med Apache Edgent och AWS Lambda. Även om dessa tjänster är radikalt olika varandra, kommer vi att diskutera dem endast från de två streamingtjänsterna. Den grundläggande skillnaden mellan de två är att Apache Edgent kör på enheten, medan AWS Lambda körs på molnet. Detta ger många fördelar och nackdelar: från Lambda-sidan har vi en flexibel och lättanvänd tjänst med en sömlös integration med Kinesis, men det kräver att data redan laddas upp till molnet, vilket förlorar effektivitet och betalar Kinesis också för data som så småningom kommer att kasseras. Från Edgent -sidan har vi i stället att det mesta av beräkningen är klar, ja, vid kanten av nätverket (alltså på enheterna) innan vi laddar upp värdelös data till molnet. Den största nackdelen är att Edgent är ett stort ramverk, vilket kan kräva tid att installera och kan vara komplext att underhålla. En annan skillnad som kan vara relevant i valet av en plattform är att Edgent är helt öppen källkod, Lambda inte. Detta kan ses både som ett proffs, eftersom det alltid är positivt att ha tillgång till koden som du eller din kund kommer att köra, både som en nackdel, eftersom det kan finnas situationer där du behöver akut support som inte kan tillhandahållas i alla miljöer med öppen källkod.

Andra funktioner som vi kan nämna är Kinesis automatiska skalbarhet av de tilldelade resurserna. Maskinvaran som den erbjuder består faktiskt av ett antal så kallade Kinesis Processing Units (KPU: er) som körs parallellt, där en KPU erbjuder 1 vCore och 4 GB RAM. Deras antal beror på applikationens behov och tilldelas dynamiskt och automatiskt (vad du betalar är verkligen cpu -tiden gånger antalet KPU), kom bara ihåg att det är en Kinesis -policy att debitera dig en KPU mer om du använder en Java Ansökan. IBM Streams ger istället inte denna typ av flexibilitet, och erbjuder dig en behållare med fast hårdvara, mer information när vi pratar om prissättning. Å andra sidan är IBM Streams mer öppet än Kinesis, eftersom det gränssnitt till WAN via vanliga använda protokoll, som HTTP, MQTT och så vidare, medan Kinesis är stängd för AWS -ekosystemet.

Som slutlig jämförelse låt oss prata om prissättning, och låt mig berätta att IBM inte fungerar bra på denna punkt. Vi har konfigurerat olika lösningar för tre olika kategorier (basic, high-end, ultra-high-end) för både IBM och AWS, och vi kommer att jämföra deras pris. I grundkonfigurationen har vi en AWS KPU, som nämnts tidigare, mot en IBM -lösning med samma hårdvara. För high-end har vi 8 KPU: er som är parallella för Kinesis och 2 behållare alltid parallella för IBM, var och en med 4 vCores och 12 GB RAM. Alltid erbjuder IBM en ultrabehållare i ultra-high-end en enda behållare med 16 vCores och 128 GB RAM, medan vi utelämnade en likvärdig lösning för AWS, eftersom om en applikation kräver denna stora mängd RAM kan det inte vara möjligt att köra den på olika KPU: er. De priser vi rapporterar uttrycks i $/månad med tanke på en användning dygnet runt. För den grundläggande konfigurationen vi har för IBM respektive AWS 164 $ respektive 490 $, för high-end 1320 $ och 3500 $, för ultra-high-end AWS beaktas inte och det finns bara IBM med 6300 $. Av dessa resultat kan vi se att Kinesis fungerar bättre för den dagliga användaren upp till företagsnivå, medan det saknar alternativ för att direkt hantera dataanalys som kräver enorm mängd datorkraft. Kinesis levererar bättre prestanda/$ förhållande än IBM Streams, även hjälpt av dynamisk tilldelning av små resursblock endast vid behov, medan IBM erbjuder dig en fast behållare. På detta sätt, om din arbetsbelastning kännetecknas av toppar, med IBM tvingas du överskatta dina applikationsbehov och konfigurera en lösning i värsta fall. IBM erbjuder timavgifter istället för att betala hela månaden, men det är inte automatiserat som Kinesis.

Steg 4: IoT -arkitektur

Konfigurationen för enheter för aws iot är ganska lätt jämfört med ibm watson iot. Eftersom ibm watson iot är autentiseringen per enhet med token och när den visar token kommer den aldrig att visas igen. Kommer att prissätta del igen ibm watson iot är ganska dyrt jämfört med aws iot. Så priset i ibm watson iot -avgifter är baserat på per enhet, datalagring, datatrafik. Men i aws iot kan vi betala beloppet en gång och vi kan lägga till fler enheter och data som publiceras från enheter och levereras till enheter.

Börja med din enhet- oavsett om det är en sensor, gateway eller något annat- och låt oss hjälpa dig att ansluta till molnet.

Din enhetsdata är alltid säker när du ansluter till molnet med öppna, lätta MGTT -meddelandeprotokoll eller HTTP. Med hjälp av protokoll och noderöd kan vi ansluta vår enhet till iot-plattformen och få tillgång till levande och historisk data.

Använd våra säkra API: er för att ansluta dina appar med data från dina enheter.

Skapa applikationer inom vår givna molntjänst för att tolka data.