AWS en IBM: een vergelijking van IoT-services: 4 stappen

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:17

Vandaag vergelijken we twee stapels die het mogelijk maken om IoT-toepassingen te ontwikkelen vanuit het oogpunt van verschillende serviceaanbiedingen.

Stap 1: Functioneert als een service

FaaS is een categorie cloudservices die wordt gebruikt om een "serverloze" architectuur te bouwen. Met FaaS kunnen klanten applicatiefunctionaliteiten ontwikkelen, uitvoeren en beheren zonder de infrastructuur te bouwen en te onderhouden.

Amazon biedt AWS Lambda, IBM biedt IBM Cloud Functions. Die diensten lijken veel op elkaar, maar Lambda was de eerste van deze soort. Met FaaS kun je stukjes code in de cloud draaien en elke dienst ondersteunt verschillende programmeertalen.

IBM Cloud-functies: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# enz.), Elke via Docker AWS Lambda: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Elke via Runtime-API

IBM ondersteunt meer talen en met docker zijn eenvoudig te gebruiken scripts die in andere talen zijn geschreven. Dit kan ook met Lambda, maar het is niet onmiddellijk. Een voorbeeld lees je hier:

Beide services hebben gebruikslimieten, we rapporteren ze in een tabel en markeren de beste.

De prijs is gebaseerd op GigaBytes per seconde (RAM) met toevoeging van het aantal verzoeken voor AWS Lambda. Elke service heeft een gratis abonnement en ze zijn bijna gelijk. Zoals je kunt zien is Lambda een beetje goedkoper voor de GB/s, maar er zijn kosten verbonden aan verzoeken die Cloud Functions niet heeft, dus de kosten zijn over het algemeen bijna hetzelfde. Natuurlijk, als je taken moet uitvoeren die geheugen in beslag nemen en weinig verzoeken gebruiken, moet je Lambda gebruiken. Het belangrijkste voordeel van IBM Cloud Function is naar onze mening dat de stack open source is. Het is volledig gebaseerd op Apache OpenWhisk en kan ook worden ingezet op een privé-infrastructuur.

Stap 2: machinaal leren

Een gebied waar de IBM- en AWS-stacks vergelijkbare diensten bieden, is dat van machine learning: Amazon met zijn SageMaker en IBM met Watson Machine Learning. De twee services lijken in veel opzichten erg op elkaar: beide presenteren zichzelf als hulpmiddelen om datawetenschappers en ontwikkelaars te helpen bij het bouwen, trainen en implementeren in productieklare omgevingen van hun machine learning-modellen, maar de filosofieën die de twee bedrijven hanteren, lopen nogal uiteen. Met beide services kunt u kiezen tussen verschillende mate van controle over de modellen die u gebruikt. In Watson ML hebt u enkele ingebouwde modellen die al zijn getraind om een aantal zeer specifieke taken uit te voeren: als u bijvoorbeeld wilt herkennen welke objecten in een afbeelding aanwezig zijn, importeert u gewoon het VisualRecognitionV3-model en geeft u de afbeelding die u willen analyseren. Je kunt ook een "aangepast model" bouwen, maar in Watson ML betekent dit meestal een reeds gebouwd model nemen en onze training daarop volgen, dus het maatwerk is vrij beperkt. Het is echter belangrijk op te merken dat noch SageMaker noch Watson ML de enige manieren zijn om machine learning op de stacks van hun ontwikkelaars uit te voeren, het zijn slechts services die erop gericht zijn het leven van de ontwikkelaars gemakkelijker te maken. Het Watson ML-platform ondersteunt ook veel van de meest populaire bibliotheken voor machine learning, dus je kunt zelfs helemaal opnieuw een model bouwen met PyTorch, Tensorflow of vergelijkbare bibliotheken. U gebruikt die bibliotheken rechtstreeks of gebruikt de vooraf gemaakte modellen, er is geen middenweg. Watson ML ondersteunt ook niet de keuzebibliotheek van Amazon, Apache MXNet, die in plaats daarvan eersteklas ondersteuning heeft in SageMaker.

De aanpak van Amazon SageMaker, zelfs bij het gebruik van ingebouwde opties, is een beetje laagdrempeliger: in plaats van u te laten kiezen uit vooraf gemaakte modellen, kunt u kiezen uit een overvloed aan reeds geïmplementeerde trainingsalgoritmen, die u kunt gebruiken bij het bouwen van uw op een meer traditionele manier te modelleren. Als dit niet genoeg is, kunt u ook uw eigen algoritme gebruiken. Deze manier van doen vereist zeker meer kennis over hoe machine learning wordt gedaan in vergelijking met alleen het gebruik van een getraind model in Watson ML.

Op het eerste gezicht lijkt het erop dat Watson ML de "gemakkelijke en snelle" manier is, waarbij Amazon SageMaker de meest complexe is om in te stellen. Dit is vanuit sommige gezichtspunten misschien niet helemaal waar, omdat SageMaker is gestructureerd om alles op een Jupyter Notebook te laten draaien, terwijl je voor dezelfde functies in Watson ML veel verschillende subservices moet instellen vanuit de web-UI. De voorbewerking van de gegevens heeft ook speciale ruimtes op de IBM-service, terwijl SageMaker erop vertrouwt dat u alles vanuit code in uw notebook doet. Dit plus het feit dat Jupyter-notebooks niet bepaald de beste keuze zijn vanuit het oogpunt van software-engineering, kan ervoor zorgen dat SageMaker niet goed kan schalen in productie. Beide services hebben redelijk goede en eenvoudige mechanismen om je model te implementeren en API's ervoor beschikbaar te maken in de buitenwereld.

Kortom, Watson ML presteert beter in grote projecten waar de Jupyter-notebooks hun grenzen beginnen te vertonen en waar je niet veel aanpassingen nodig hebt in wat het model zelf doet. SageMaker is een stuk beter als je meer flexibiliteit nodig hebt bij het definiëren van de algoritmen, maar als je het gebruikt, moet je er rekening mee houden dat je moet vertrouwen op Jupyter Notebooks, die mogelijk niet goed schalen in productie. Een oplossing zou kunnen zijn om de rest van de code zoveel mogelijk los te koppelen van het model, zodat de code in de eigenlijke notebooks niet te groot wordt en we onze software beter kunnen organiseren in de andere modules die alleen de API van ons model gebruiken..

Stap 3: Gegevensstreaming en -analyse

Datastreamingdiensten zijn cruciaal bij het in realtime verwerken en analyseren van grote datastromen. Deze stroom kan van de cloud naar het apparaat van de gebruiker zijn, zoals een videostreaming, of van de gebruikers naar de cloud, zoals IoT-telemetrie en sensormetingen. Vooral in het tweede geval zouden we een situatie kunnen hebben waarin afzonderlijke bronnen kleine hoeveelheden gegevens uploaden, maar als we kijken naar de totale doorvoer, afkomstig van alle apparaten, verbruikt dit aanzienlijke bandbreedte, dus is het logisch om een service te gebruiken die gespecialiseerd is om dergelijke gegevens af te handelen. gegevensstromen. Zonder deze continue stroom rechtstreeks af te handelen, zouden we de binnenkomende informatie in een tijdelijke opslag moeten bufferen en deze vervolgens met een rekenmachine moeten verwerken. Het probleem van deze laatste benadering is dat we meer verschillende services zouden moeten coördineren om te bereiken wat een enkele datastroomservice alleen al doet, waardoor de complexiteit van het onderhoud en de configuratie van de applicatie toeneemt. Bovendien kan de buffering onze applicatie in principe niet langer in realtime maken, aangezien het nodig is om een item te verwerken voordat het ook wordt verwerkt, en het toevoegen van prioriteitsbeleid aan de buffer kan, opnieuw, de complexiteit drastisch verhogen. Samenvattend, datastreamingservices bieden realtime verwerking van gegevensstromen, met een eenvoudige configuratie, en kunnen analyses van de binnenkomende gegevens bieden. Hier vergelijken we de twee belangrijkste streamingdiensten van de IBM- en AWS-stack, namelijk IBM Streams en AWS Kinesis.

We beginnen met op te merken dat alle basisfuncties die we misschien van een streamingdienst willen, worden aangeboden door zowel IBM als AWS. Deze functies omvatten een vrijwel oneindige verwerkingssnelheid, lage latentie en realtime gegevensanalyse. Omdat we het hebben over professionele services, bieden ze allebei tools van productiekwaliteit voor implementatie en automatisering.

Over data-analyse gesproken, beide services bieden het als een optie aan, waardoor u alleen betaalt of u het nodig heeft of niet. In het geval van Kinesis, wanneer u geen analyse nodig heeft maar alleen gegevensstroomverwerking, worden de prijzen in rekening gebracht per verwerkte GB in plaats van verwerkingstijd, zoals in het IBM-geval. De prijs per GB zal over het algemeen goedkoper zijn dan de prijs per keer, aangezien u alleen betaalt voor het inkomende verkeer. Voor de rest van dit bericht zullen we zowel IBM Streams als AWS Kinesis overwegen met de data-analysefunctie ingeschakeld.

Streams en Kinesis bieden integratie met verschillende services voor het voorbewerken en filteren van de binnenkomende gegevens voordat ze worden doorgegeven aan gegevensanalyse, respectievelijk met Apache Edgent en AWS Lambda. Hoewel deze diensten radicaal van elkaar verschillen, zullen we ze alleen bespreken vanuit het oogpunt van de twee streamingdiensten. Het fundamentele verschil tussen de twee is dat Apache Edgent op het apparaat wordt uitgevoerd, terwijl AWS Lambda op de cloud wordt uitgevoerd. Dit brengt veel voor- en nadelen met zich mee: van Lambda-kant hebben we een flexibele en gebruiksvriendelijke service met een naadloze integratie met Kinesis, maar het vereist dat de gegevens al naar de cloud zijn geüpload, waardoor de efficiëntie verloren gaat en Kinesis ook betaalt voor de gegevens die uiteindelijk worden weggegooid. Aan de kant van Edgent hebben we in plaats daarvan dat het grootste deel van de berekening wordt gedaan, nou ja, aan de rand van het netwerk (dus op de apparaten) voordat nutteloze gegevens naar de cloud worden geüpload. Het belangrijkste nadeel is dat Edgent een groot raamwerk is, dat tijd nodig heeft om op te zetten en complex kan zijn om te onderhouden. Een ander verschil dat relevant kan zijn bij de keuze van een platform is dat Edgent volledig open source is, Lambda niet. Dit kan zowel als een voordeel worden gezien, aangezien toegang hebben tot de code die u of uw klant zal uitvoeren altijd een positieve zaak is, zowel als een nadeel, omdat er situaties kunnen zijn waarin u dringende ondersteuning nodig heeft die niet kan worden geleverd in alle open source-omgevingen.

Andere kenmerken die we kunnen noemen, zijn de automatische schaalbaarheid van de toegewezen bronnen door Kinesis. De hardware die het biedt, bestaat inderdaad uit een aantal zogenaamde Kinesis Processing Units (KPU's) die parallel lopen, waarbij één KPU 1 vCore en 4 GB RAM biedt. Hun aantal hangt af van de behoeften van de applicatie en wordt dynamisch en automatisch toegewezen (wat u betaalt is inderdaad de cpu-tijd maal het aantal KPU's), onthoud dat het een Kinesis-beleid is om u één KPU meer in rekening te brengen als u een Java gebruikt sollicitatie. IBM Streams biedt daarentegen dit soort flexibiliteit niet en biedt u een container met vaste hardware, meer details als we het hebben over prijzen. Aan de andere kant is IBM Streams meer open dan Kinesis, omdat het een interface heeft met het WAN via veelgebruikte protocollen, zoals HTTP, MQTT enzovoort, terwijl Kinesis gesloten is voor het AWS-ecosysteem.

Laten we het als laatste vergelijking hebben over prijzen, en laat me zeggen dat IBM op dit punt niet geweldig werkt. We hebben verschillende oplossingen geconfigureerd voor drie verschillende categorieën (basic, high-end, ultra-high-end) voor zowel IBM als AWS, en we gaan hun prijs vergelijken. In de basisconfiguratie hebben we één AWS KPU, eerder genoemd, tegen een IBM-oplossing met dezelfde hardware. Voor de high-end hebben we 8 KPU's die parallel lopen voor Kinesis en 2 containers altijd parallel voor IBM, elk met 4 vCores en 12 GB RAM. IBM biedt altijd in de ultra-high-end een enkele container met 16 vCores en 128 GB RAM, terwijl we een equivalente oplossing voor AWS hebben weggelaten, omdat als een applicatie deze grote hoeveelheid RAM vereist, het niet mogelijk zou zijn om deze op verschillende KPU's te draaien. De prijzen die we rapporteren zijn uitgedrukt in $/maand, rekening houdend met een 24/7 gebruik. Voor de basisconfiguratie hebben we voor IBM en AWS respectievelijk 164$ en 490$, voor de high-end 1320$ en 3500$, voor de ultra-high-end AWS wordt geen rekening gehouden en er is alleen IBM met 6300$. Uit deze resultaten kunnen we zien dat Kinesis beter werkt voor de dagelijkse gebruiker tot op enterprise-niveau, terwijl het geen opties heeft om direct data-analyses af te handelen, wat een enorme hoeveelheid rekenkracht vereist. Kinesis levert een betere prestatie/$-verhouding dan IBM Streams, ook geholpen door de dynamische toewijzing van kleine resourceblokken alleen wanneer dat nodig is, terwijl IBM u een vaste container biedt. Op deze manier, als uw workload wordt gekenmerkt door pieken, bent u bij IBM gedwongen om uw applicatiebehoeften te overschatten en in het ergste geval een oplossing te configureren. IBM biedt urenvergoedingen in plaats van de volledige maand te betalen, maar het is niet geautomatiseerd zoals Kinesis.

Stap 4: IoT-architectuur

De configuratie voor apparaten voor aws iot is vrij eenvoudig in vergelijking met ibm watson iot. Omdat in ibm watson iot de authenticatie per apparaat met token is en als het eenmaal het token weergeeft, wordt het nooit meer weergegeven. IBM watson iot is weer vrij duur in vergelijking met aws iot. De prijs in ibm watson iot-kosten is dus gebaseerd op per apparaat, gegevensopslag, gegevensverkeer. Maar in aws iot kunnen we het bedrag eenmalig betalen en kunnen we meer apparaten en gegevens toevoegen die vanaf apparaten zijn gepubliceerd en op apparaten worden afgeleverd.

Begin met uw apparaat - of het nu een sensor, gateway of iets anders is - en laat ons u helpen verbinding te maken met de cloud.

Uw apparaatgegevens zijn altijd veilig wanneer u verbinding maakt met de cloud via een open, lichtgewicht MGTT-berichtenprotocol of HTTP. Met behulp van protocollen en node-red kunnen we ons apparaat verbinden met het iot-platform en hebben we toegang tot live en historische gegevens.

Gebruik onze beveiligde API's om uw apps te verbinden met gegevens van uw apparaten.

Maak applicaties binnen onze gegeven cloudservice om gegevens te interpreteren.