AWS og IBM: en sammenligning af IoT -tjenester: 4 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:28

I dag sammenligner vi to stakke, der gør det muligt at udvikle IoT -applikationer under hensyn til forskellige servicetilbud.

Trin 1: Funktioner som en tjeneste

FaaS er en kategori af cloudtjenester, der bruges til at opbygge en "serverløs" arkitektur. FaaS giver kunderne mulighed for at udvikle, køre og administrere applikationsfunktioner uden at opbygge og vedligeholde infrastrukturen.

Amazon tilbyder AWS Lambda, IBM tilbyder IBM Cloud -funktioner. Disse tjenester er ret ens, men Lambda var den første af denne art. Ved hjælp af FaaS kan du køre stykker kode i skyen, og hver service understøtter forskellige programmeringssprog.

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

IBM Understøtter flere sprog og med docker er det let at bruge scripts skrevet på andre sprog. Dette kan også gøres med Lambda, men det er ikke umiddelbart. Du kan læse et eksempel her:

Begge tjenester har brugsbegrænsninger, vi rapporterer dem i en tabel og fremhæver de bedste.

Prisen er baseret på GigaBytes per sekund (RAM) med tilføjelse af antallet af anmodninger om AWS Lambda. Hver service har en gratis plan, og de er næsten ækvivalente. Som du kan se, er Lambda lidt billigere for GB/s, men det har en pris forbundet med anmodninger, som Cloud Functions ikke har, så omkostningerne er næsten de samme generelt. Selvfølgelig, hvis du skal køre opgaver, der spiser hukommelse og bruger få anmodninger, skal du bruge Lambda. Efter vores mening er den største fordel ved IBM Cloud Function, at dens stak er open source. Det er fuldstændigt baseret på Apache OpenWhisk og kan også implementeres på en privat infrastruktur.

Trin 2: Maskinlæring

Et felt, hvor IBM- og AWS -stakken tilbyder lignende tjenester, er maskinlæring: Amazon med sin SageMaker og IBM med Watson Machine Learning. De to tjenester er på mange aspekter meget ens: begge præsenterer sig selv som værktøjer til at hjælpe dataforskere og udviklere med at opbygge, træne og derefter implementere deres maskinlæringsmodeller i produktionsklare miljøer, men de filosofier, de to virksomheder anvender, varierer en del. Begge tjenester lader dig vælge mellem forskellige grader af kontrol på de modeller, du bruger. I Watson ML har du nogle indbyggede modeller, der allerede er uddannet til at udføre nogle meget specifikke opgaver: for eksempel, hvis du vil genkende, hvilke objekter der er til stede i et billede, importerer du bare VisualRecognitionV3-modellen og videregiver det billede til dig ønsker at analysere. Du kan også bygge en "brugerdefineret model", men i Watson ML betyder det for det meste at tage en allerede bygget model og lave vores træning på den, så tilpasningen er ret begrænset. Det er vigtigt at bemærke, at hverken SageMaker eller Watson ML er de eneste måder at lave maskinlæring på deres udvikleres stakke, det er bare tjenester, der har til formål at gøre udviklernes liv lettere. Watson ML -platformen understøtter også mange af de mest populære maskinlæringsbiblioteker, så du kan endda bygge en model fra bunden med PyTorch, Tensorflow eller lignende biblioteker. Du bruger enten disse biblioteker direkte, eller brug de færdiglavede modeller, der er ingen mellemvej. Også Watson ML understøtter ikke Amazons valgbibliotek, Apache MXNet, som i stedet har førsteklasses support i SageMaker.

Amazon SageMakers tilgang, selv når du bruger indbyggede muligheder, er lidt mere lavt: I stedet for at få dig til at vælge mellem færdige modeller, kan du vælge mellem en overflod af allerede implementerede træningsalgoritmer, som du kan bruge, når du bygger dine model på en mere traditionel måde. Hvis disse ikke er nok, kan du også bruge din egen algoritme. Denne måde at gøre ting på kræver bestemt mere viden om, hvordan maskinlæring udføres i forhold til bare at bruge en uddannet model i Watson ML.

Umiddelbart kan det se ud til, at Watson ML er den "nemme og hurtige" måde, hvor Amazon SageMaker er den mere komplekse at oprette. Dette er måske ikke helt sandt fra nogle synspunkter, da SageMaker er struktureret til at få alt til at køre på en Jupyter Notebook, mens du for de samme funktioner i Watson ML skal konfigurere mange forskellige undertjenester fra webgrænsefladen. Forbehandlingen af dataene har også dedikerede mellemrum på IBM -tjenesten, mens SageMaker er afhængig af, at du gør det hele fra kode i din notesbog. Dette plus det faktum, at Jupyter -notebooks ikke ligefrem er det bedste valg ud fra et softwareteknisk synspunkt, kan forhindre SageMaker i at skalere meget godt i produktionen. Begge tjenester har ret gode og enkle mekanismer til at implementere din model og gøre API'er til den tilgængelige i omverdenen.

Afslutningsvis klarer Watson ML sig bedre i enorme projekter, hvor Jupyter -notebooks begynder at vise deres grænser, og hvor du ikke har brug for meget tilpasning til, hvad modellen selv gør. SageMaker er meget bedre, når du har brug for mere fleksibilitet til at definere algoritmerne, men når du bruger den, skal du tage højde for, at du skal stole på Jupyter Notebooks, der muligvis ikke skaleres godt i produktionen. En løsning kan være at afkoble resten af koden fra modellen så meget som muligt, så koden i de egentlige notebooks ikke bliver for stor, og vi bedre kan organisere vores software i de andre moduler, der bare bruger vores models API.

Trin 3: Datastreaming og analyse

Datastreamingstjenester er afgørende for håndtering og analyse i realtid af store datastrømme. Dette flow kan være fra skyen til brugernes enhed, f.eks. En videostreaming, eller fra brugerne til skyen, f.eks. IoT -telemetri og sensoraflæsninger. Især i det andet tilfælde kunne vi have en situation, hvor enkelte kilder uploader små mængder data, men når vi overvejer den samlede gennemstrømning, der kommer fra alle enhederne, bruger den betydelig båndbredde, og derfor er det fornuftigt at bruge en service, der er specialiseret til at håndtere sådanne datastrømme. Uden at håndtere dette kontinuerlige flow direkte, ville vi skulle buffer de indgående oplysninger til et midlertidigt lager og i anden gang behandle det med en beregningsmotor. Problemet med denne sidste tilgang er, at vi skulle koordinere flere forskellige tjenester for at opnå, hvad en enkelt datastrømstjeneste allerede gør alene, hvilket øger kompleksiteten af applikationens vedligeholdelse og konfiguration. Desuden kan bufferen i princippet gøre, at vores ansøgning ikke længere er i realtid, for at en vare skal behandles, er det nødvendigt, at alle de andre elementer, før den også skal behandles, og tilføjelse af prioritetspolitikker til bufferen igen kan, øge kompleksiteten drastisk. Sammenfattende tilbyder datastreamingtjenester datahåndteringshåndtering i realtid med en let konfiguration og kan levere analyser af de indgående data. Her sammenligner vi de to vigtigste streamingtjenester i IBM- og AWS -stakken, nemlig IBM Streams og AWS Kinesis.

Vi starter med at bemærke, at alle de grundlæggende funktioner, vi måtte ønske fra en streamingtjeneste, tilbydes af både IBM og AWS. Disse funktioner omfatter praktisk talt uendelig behandlingshastighed, lav latenstid og dataanalyse i realtid. Da vi taler om professionelle tjenester, tilbyder de begge produktionsværktøjer til implementering og automatisering.

Når vi taler om dataanalyse, tilbyder begge tjenester det som valgfrit, så du kun betaler, uanset om du har brug for det eller ej. I tilfælde af Kinesis, når du ikke har brug for analyse, men kun håndtering af dataflow, opkræves priserne pr. GB behandlet i stedet for behandlingstid, som i IBM -sagen. Prisen pr. GB vil generelt være billigere end prissætningen pr. Gang, da du kun betaler for den indkommende trafik. I resten af dette indlæg vil vi overveje både IBM Streams og AWS Kinesis med dataanalysefunktionen aktiveret.

Streams og Kinesis giver integration med forskellige tjenester til forbehandling og filtrering af de indgående data, før de videregives til dataanalyse, henholdsvis med Apache Edgent og AWS Lambda. Selvom disse tjenester er radikalt forskellige fra hinanden, vil vi kun diskutere dem ud fra de to streamingtjenester. Den grundlæggende forskel mellem de to er, at Apache Edgent udfører på enheden, mens AWS Lambda udfører på skyen. Dette bringer masser af fordele og ulemper: fra Lambda-siden har vi en fleksibel og brugervenlig service med problemfri integration med Kinesis, men det kræver, at data allerede er uploadet til skyen, og dermed taber i effektivitet og betaler Kinesis også for de data, der i sidste ende vil blive kasseret. Fra Edgent -siden har vi i stedet, at det meste af beregningen er udført godt på kanten af netværket (altså på enhederne), før du uploader ubrugelige data til skyen. Den største ulempe er, at Edgent er en stor ramme, som kan kræve tid at oprette og kan være kompleks at vedligeholde. En anden forskel, der kan være relevant ved valget af en platform, er, at Edgent er fuldt open source, Lambda ikke. Dette kan ses både som en proff, da det altid er en positiv ting at have adgang til den kode, som du eller din kunde vil udføre, både som en ulempe, fordi der kan være situationer, hvor du har brug for akut support, der ikke kan leveres i alle open source -miljøer.

Andre funktioner, som vi kan nævne, er Kinesis automatiske skalerbarhed af de tildelte ressourcer. Den hardware, den tilbyder, består faktisk af en række såkaldte Kinesis Processing Units (KPU'er), der kører parallelt, hvor en KPU tilbyder 1 vCore og 4 GB RAM. Deres antal afhænger af applikationens behov og tildeles dynamisk og automatisk (hvad du betaler er faktisk cpu -tiden gange antallet af KPU'er), husk bare at det er en Kinesis -politik at opkræve dig en KPU mere, hvis du bruger en Java Ansøgning. IBM Streams giver i stedet ikke denne form for fleksibilitet og tilbyder dig en container med fast hardware, flere detaljer, når vi taler om priser. På den anden side er IBM Streams mere åbne end Kinesis, da det grænseflader til WAN via almindelige brugte protokoller, som HTTP, MQTT og så videre, mens Kinesis er lukket for AWS -økosystemet.

Som sidste sammenligning lad os tale om priser, og lad mig fortælle, at IBM ikke fungerer godt på dette punkt. Vi har konfigureret forskellige løsninger til tre forskellige kategorier (basic, high-end, ultra-high-end) til både IBM og AWS, og vi vil sammenligne deres pris. I grundkonfigurationen har vi en AWS KPU, der er nævnt tidligere, mod en IBM -løsning med den samme hardware. For high-end har vi 8 KPU'er, der kører parallelt for Kinesis og 2 containere altid parallelt for IBM, hver med 4 vCores og 12 GB RAM. Altid tilbyder IBM i ultra-high-end en enkelt beholder med 16 vCores og 128 GB RAM, mens vi udelod en tilsvarende løsning til AWS, da hvis et program kræver denne store mængde RAM, kunne det ikke lade sig gøre at køre det på forskellige KPU'er. De priser, vi rapporterer, er udtrykt i $/måned i betragtning af en brug døgnet rundt. For den grundlæggende konfiguration, vi har for henholdsvis IBM og AWS 164 $ og 490 $, for high-end 1320 $ og 3500 $, for ultra-high-end AWS betragtes ikke, og der er kun IBM med 6300 $. Fra disse resultater kan vi se, at Kinesis fungerer bedre for den daglige bruger op til virksomhedsniveau, mens den mangler muligheder for direkte at håndtere dataanalyse, som kræver enorm mængde computerkraft. Kinesis leverer bedre ydelse/$ forhold end IBM Streams, også hjulpet af dynamisk tildeling af små ressourceblokke, når det er nødvendigt, mens IBM tilbyder dig en fast container. På denne måde, hvis din arbejdsbyrde er præget af toppe, er du med IBM tvunget til at overvurdere dine applikationsbehov og konfigurere en løsning i værste fald. IBM tilbyder timegebyrer i stedet for at betale hele måneden, men det er ikke automatiseret som Kinesis.

Trin 4: IoT -arkitektur

Konfigurationen for enheder til aws iot er ret let sammenlignet med ibm watson iot. Fordi ibm watson iot er godkendelsen pr. Enhed med token, og når den viser token, vises den aldrig igen. Kommer til at prissætte del igen ibm watson iot er ret dyrt i forhold til aws iot. Så prisen i ibm watson iot -gebyrer er baseret på pr. Enhed, datalagring, datatrafik. Men i aws iot kan vi betale beløbet én gang, og vi kan tilføje flere enheder og data, der er offentliggjort fra enheder og leveret til enheder.

Start med din enhed- uanset om det er en sensor, gateway eller noget andet- og lad os hjælpe dig med at oprette forbindelse til skyen.

Din enhedsdata er altid sikker, når du opretter forbindelse til skyen ved hjælp af åben, let MGTT -beskedprotokol eller HTTP. Ved hjælp af protokoller og node-rød kan vi forbinde vores enhed med iot-platform og kan få adgang til levende og historiske data.

Brug vores sikre API'er til at forbinde dine apps med data fra dine enheder.

Opret applikationer inden for vores givne cloud -service for at fortolke data.