AWS og IBM: en sammenligning av IoT -tjenester: 4 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

I dag sammenligner vi to stabler som gjør det mulig å utvikle IoT -applikasjoner med tanke på forskjellige tjenestetilbud.

Trinn 1: Funksjoner som en tjeneste

FaaS er en kategori skytjenester som brukes til å bygge en "serverløs" arkitektur. FaaS lar kundene utvikle, kjøre og administrere applikasjonsfunksjoner uten å bygge og vedlikeholde infrastrukturen.

Amazon tilbyr AWS Lambda, IBM tilbyr IBM Cloud Functions. Disse tjenestene er ganske like, men Lambda var den første av denne typen. Ved å bruke FaaS kan du kjøre kodebiter i skyen, og hver tjeneste støtter forskjellige programmeringsspråk.

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

IBM støtter flere språk og med docker er det enkelt å bruke skript skrevet på andre språk. Dette kan også gjøres med Lambda, men det er ikke umiddelbart. Du kan lese et eksempel her:

Begge tjenestene har bruksgrenser, vi rapporterer dem i en tabell og markerer de beste.

Prisen er basert på GigaBytes per sekunder (RAM) med tillegg av antall forespørsler for AWS Lambda. Hver tjeneste har en gratis plan og de er nesten likeverdige. Som du kan se er Lambda litt billigere for GB/s, men det har en kostnad knyttet til forespørsler som Cloud Functions ikke har, så kostnaden er nesten den samme generelt. Selvfølgelig, hvis du trenger å kjøre oppgaver som spiser minne og bruker få forespørsler, bør du bruke Lambda. Etter vår mening er hovedfordelen med IBM Cloud Function at stabelen er åpen kildekode. Den er helt basert på Apache OpenWhisk og kan også distribueres på en privat infrastruktur.

Trinn 2: Maskinlæring

Et felt der IBM og AWS -stablene tilbyr lignende tjenester, er maskinlæring: Amazon med sin SageMaker og IBM med Watson Machine Learning. De to tjenestene er på mange aspekter veldig like: begge presenterer seg som verktøy for å hjelpe dataforskere og utviklere med å bygge, trene og deretter distribuere maskinlæringsmodeller i produksjonsklare miljøer, men filosofiene de to selskapene tar i bruk varierer ganske mye. Begge tjenestene lar deg velge mellom forskjellige grader av kontroll på modellene du bruker. I Watson ML har du noen innebygde modeller som allerede er opplært til å gjøre noen helt spesifikke oppgaver: for eksempel, hvis du vil gjenkjenne hvilke objekter som er tilstede i et bilde, importerer du bare VisualRecognitionV3-modellen og sender til den bildet du ønsker å analysere. Du kan også bygge en "tilpasset modell", men i Watson ML betyr dette stort sett å ta en allerede bygget modell og trene på den, så tilpasningen er ganske begrenset. Det er imidlertid viktig å legge merke til at verken SageMaker eller Watson ML er de eneste måtene å gjøre maskinlæring på utviklernes stabler, det er bare tjenester som tar sikte på å gjøre utviklernes liv lettere. Watson ML -plattformen støtter også mange av de mest populære maskinlæringsbibliotekene, slik at du til og med kan bygge en modell fra bunnen av med PyTorch, Tensorflow eller lignende biblioteker. Du bruker enten disse bibliotekene direkte, eller bruker de ferdiglagde modellene, det er ingen mellomting. Også Watson ML støtter ikke Amazons valgbibliotek, Apache MXNet, som i stedet har førsteklasses støtte i SageMaker.

Amazon SageMakers tilnærming, selv når du bruker innebygde alternativer, er litt mer lavt: I stedet for å velge mellom ferdiglagde modeller, lar du deg velge fra en mengde allerede implementerte treningsalgoritmer, som du kan bruke når du bygger dine modell på en mer tradisjonell måte. Hvis disse ikke er nok, kan du også bruke din egen algoritme. Denne måten å gjøre ting på krever absolutt mer kunnskap om hvordan maskinlæring utføres i forhold til bare å bruke en opplært modell i Watson ML.

Ved første øyekast kan det virke som om Watson ML er den "enkle og raske" måten, med Amazon SageMaker som er den mer komplekse å sette opp. Dette er kanskje ikke helt sant fra noen synspunkter, ettersom SageMaker er strukturert for å få alt til å kjøre på en Jupyter Notebook, mens du for de samme funksjonene i Watson ML må konfigurere mange forskjellige undertjenester fra webgrensesnittet. Forhåndsbehandlingen av dataene har også dedikerte mellomrom på IBM -tjenesten, mens SageMaker er avhengig av at du gjør alt fra kode i notatblokken. Dette pluss det faktum at Jupyter bærbare datamaskiner ikke akkurat er det beste valget fra et programvareteknisk synspunkt, kan forhindre SageMaker i å skalere veldig godt i produksjonen. Begge tjenestene har ganske gode og enkle mekanismer for å distribuere modellen din og gjøre APIer for den tilgjengelig i omverdenen.

Avslutningsvis fungerer Watson ML bedre i store prosjekter der Jupyter -notatbøkene begynner å vise sine grenser, og hvor du ikke trenger mye tilpasning i hva modellen selv gjør. SageMaker er mye bedre når du trenger mer fleksibilitet i definisjonen av algoritmene, men når du bruker den, må du ta hensyn til det faktum at du må stole på Jupyter Notebooks, som kanskje ikke skaleres godt i produksjonen. En løsning kan være å koble resten av koden fra modellen så mye som mulig, slik at koden i de faktiske notatbøkene ikke blir for stor og vi bedre kan organisere programvaren vår i de andre modulene som bare bruker modellens API.

Trinn 3: Datastrømming og analyse

Datastrømmetjenester er avgjørende for å håndtere og analysere store datastrømmer i sanntid. Denne flyten kan være fra skyen til brukernes enhet, for eksempel en videostreaming, eller fra brukerne til skyen, som IoT -telemetri og sensoravlesninger. Spesielt i det andre tilfellet kan vi ha en situasjon der enkeltkilder laster opp små mengder data, men når vi vurderer den totale gjennomstrømningen, som kommer fra alle enhetene, bruker den betydelig båndbredde, og derfor er det fornuftig å bruke en spesialisert tjeneste for å håndtere slike datastrømmer. Uten å håndtere denne kontinuerlige flyten direkte, ville vi måtte buffer innkommende informasjon til en midlertidig lagring og i andre gang behandle den med en beregningsmotor. Problemet med denne siste tilnærmingen er at vi måtte koordinere flere forskjellige tjenester for å oppnå det en enkelt datastrømmetjeneste allerede gjør alene, noe som øker kompleksiteten i applikasjonens vedlikehold og konfigurasjon. I tillegg kan bufferen i prinsippet gjøre at søknaden vår ikke lenger er i sanntid, siden for at en vare skal behandles er det nødvendig at alle de andre elementene før den også skal behandles, og å legge til prioritetspolicyer i bufferen, igjen, øker kompleksiteten drastisk. Oppsummering, datastrømmetjenester tilbyr håndtering av datastrøm i sanntid, med en enkel konfigurasjon, og kan gi analyse av innkommende data. Her sammenligner vi de to viktigste streamingtjenestene til IBM- og AWS -stakken, nemlig IBM Streams og AWS Kinesis.

Vi starter med å merke at alle de grunnleggende funksjonene vi måtte ønske fra en strømmetjeneste tilbys av både IBM og AWS. Disse funksjonene inkluderer praktisk talt uendelig behandlingshastighet, lav ventetid og dataanalyse i sanntid. Siden vi snakker om profesjonelle tjenester, tilbyr de begge produksjonsverktøy for distribusjon og automatisering.

Når vi snakker om dataanalyse, tilbyr begge tjenestene det som valgfritt, slik at du bare må betale enten du trenger det eller ikke. Når det gjelder Kinesis, når du ikke trenger analyse, men bare databehandling, belastes prisene per GB behandlet i stedet for behandlingstid, som i IBM -saken. Prisen per GB vil generelt være billigere enn prisen per gang, siden du bare betaler for innkommende trafikk. For resten av dette innlegget vil vi vurdere både IBM Streams og AWS Kinesis med dataanalysefunksjonen aktivert.

Streams og Kinesis gir integrasjon med forskjellige tjenester for forhåndsbehandling og filtrering av innkommende data før de overføres til dataanalyse, henholdsvis med Apache Edgent og AWS Lambda. Selv om disse tjenestene er radikalt forskjellige fra hverandre, vil vi bare diskutere dem fra synspunktet til de to strømmetjenestene. Den grunnleggende forskjellen mellom de to er at Apache Edgent kjører på enheten, mens AWS Lambda kjører på skyen. Dette gir mange fordeler og ulemper: fra Lambda-siden har vi en fleksibel og brukervennlig tjeneste med en sømløs integrasjon med Kinesis, men det krever at dataene allerede er lastet opp til skyen, og dermed mister effektivitet og betaler Kinesis også for dataene som til slutt vil bli kastet. Fra Edgent -siden har vi i stedet at det meste av beregningen er gjort, vel, på kanten av nettverket (altså på enhetene) før vi laster opp ubrukelige data til skyen. Den største ulempen er at Edgent er et stort rammeverk, som kan ta tid å sette opp og kan være komplisert å vedlikeholde. En annen forskjell som kan være relevant ved valg av plattform, er at Edgent er fullt åpen kildekode, ikke Lambda. Dette kan ses både som en proff, siden det å ha tilgang til koden som du eller kunden din vil utføre alltid er en positiv ting, både som en ulempe, fordi det kan være situasjoner der du trenger akutt støtte som ikke kan gis i alle open source -miljøer.

Andre funksjoner som vi kan nevne er Kinesis automatiske skalerbarhet av de tildelte ressursene. Maskinvaren den tilbyr består faktisk av en rekke såkalte Kinesis Processing Units (KPUer) som kjører parallelt, hvor en KPU tilbyr 1 vCore og 4 GB RAM. Antallet deres avhenger av programmets behov og tildeles dynamisk og automatisk (det du betaler er faktisk CPU -tiden ganger antallet KPU -er), bare husk at det er en Kinesis -policy å belaste deg en KPU mer hvis du bruker en Java applikasjon. IBM Streams gir i stedet ikke denne typen fleksibilitet, og tilbyr deg en beholder med fast maskinvare, flere detaljer når vi snakker om priser. På den annen side er IBM Streams mer åpen enn Kinesis, siden det grensesnitt til WAN via vanlige brukte protokoller, som HTTP, MQTT og så videre, mens Kinesis er stengt for AWS -økosystemet.

Som siste sammenligning, la oss snakke om priser, og la meg fortelle at IBM ikke fungerer bra på dette punktet. Vi har konfigurert forskjellige løsninger for tre forskjellige kategorier (grunnleggende, high-end, ultra-high-end) for både IBM og AWS, og vi skal sammenligne prisen. I den grunnleggende konfigurasjonen har vi en AWS KPU, nevnt tidligere, mot en IBM -løsning med samme maskinvare. For high-end har vi 8 KPUer som kjører parallelt for Kinesis og 2 containere alltid parallelt for IBM, hver med 4 vCores og 12 GB RAM. Alltid tilbyr IBM i ultra-high-end en enkelt beholder med 16 vCores og 128 GB RAM, mens vi utelot en tilsvarende løsning for AWS, siden hvis noen applikasjoner krever denne store mengden RAM, kan det ikke være mulig å kjøre den på forskjellige KPUer. Prisene vi rapporterer er uttrykt i $/måned med tanke på bruk døgnet rundt. For den grunnleggende konfigurasjonen vi har for henholdsvis IBM og AWS 164 $ og 490 $, for high-end 1320 $ og 3500 $, for ultra-high-end AWS blir ikke vurdert, og det er bare IBM med 6300 $. Fra disse resultatene kan vi se at Kinesis fungerer bedre for den daglige brukeren opp til bedriftsnivå, mens den mangler alternativer for å håndtere dataanalyse direkte som krever enorm mengde datakraft. Kinesis gir bedre ytelse/$ -forhold enn IBM Streams, også hjulpet av dynamisk tildeling av små ressursblokker bare når det er nødvendig, mens IBM tilbyr deg en fast beholder. På denne måten, hvis arbeidsmengden din er preget av topper, må du med IBM overvurdere applikasjonsbehovet og konfigurere en løsning i verste fall. IBM tilbyr timegebyrer i stedet for å betale hele måneden, men den er ikke automatisert som Kinesis.

Trinn 4: IoT -arkitektur

Konfigurasjonen for enheter for aws iot er ganske enkel sammenlignet med ibm watson iot. Fordi ibm watson iot er autentiseringen per enhet med token, og når den viser tokenet, vil den aldri vises igjen. Kommer til å prissette en del igjen ibm watson iot er ganske kostbart sammenlignet med aws iot. Så prisen i ibm watson iot -avgifter er basert på per enhet, datalagring, datatrafikk. Men i aws iot kan vi betale beløpet en gang, og vi kan legge til flere enheter og data publisert fra enheter og levert til enheter.

Start med enheten din- enten det er en sensor, gateway eller noe annet- og la oss hjelpe deg med å koble til skyen.

Enhetsdataene dine er alltid sikre når du kobler deg til nettskyen ved hjelp av åpen, lett MGTT -meldingsprotokoll eller HTTP. Ved hjelp av protokoller og node-rød kan vi koble enheten vår med iot-plattformen og få tilgang til levende og historiske data.

Bruk våre sikre APIer for å koble appene dine til data fra enhetene dine.

Lag applikasjoner innenfor vår gitte skytjeneste for å tolke data.