AWS ja IBM: IoT -palvelujen vertailu: 4 vaihetta

2024 Kirjoittaja: John Day | [email protected]. Viimeksi muokattu: 2024-01-30 09:01

Tänään vertaamme kahta pinoa, jotka mahdollistavat IoT -sovellusten kehittämisen eri palvelutarjontojen näkökulmasta.

Vaihe 1: Toimii palveluna

FaaS on pilvipalveluiden luokka, jota käytetään "palvelimettoman" arkkitehtuurin rakentamiseen. FaaS mahdollistaa asiakkaiden kehittää, käyttää ja hallita sovellustoimintoja rakentamatta ja ylläpitämättä infrastruktuuria.

Amazon tarjoaa AWS Lambdan, IBM tarjoaa IBM Cloud Functions -toimintoja. Nämä palvelut ovat melko samanlaisia, mutta Lambda oli ensimmäinen tällainen. FaaS: n avulla voit suorittaa koodipaloja pilvessä ja jokainen palvelu tukee eri ohjelmointikieliä.

IBM Cloud -toiminnot: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C# F# jne.), Kaikki Docker AWS Lambdan kautta: JavaScript, Java, C#, F#, Go, Python, Ruby, PowerShell, Mikä tahansa Runtime API: n kautta

IBM tukee enemmän kieliä, ja telakointiaseman avulla on helppo käyttää muilla kielillä kirjoitettuja skriptejä. Tämä voidaan tehdä myös Lambdalla, mutta se ei ole välitöntä. Voit lukea esimerkin täältä:

Molemmilla palveluilla on käyttörajoituksia, raportoimme ne taulukossa ja korostamme parhaat.

Hinta perustuu gigatavua sekunnissa (RAM), johon lisätään AWS Lambda -pyyntöjen määrä. Jokaisella palvelulla on ilmainen suunnitelma ja ne ovat lähes vastaavia. Kuten näette, Lambda on hieman halvempi GB/s: lle, mutta sillä on kustannuksia, jotka liittyvät pyyntöihin, joita Cloud Functionsilla ei ole, joten kustannukset ovat lähes samat yleensä. Tietenkin, jos sinun on suoritettava tehtäviä, jotka syövät muistia ja käyttävät vain vähän pyyntöjä, käytä Lambdaa. IBM Cloud Functionin tärkein etu on mielestämme sen pino avoimen lähdekoodin. Se perustuu täysin Apache OpenWhiskiin, ja se voidaan ottaa käyttöön myös yksityisessä infrastruktuurissa.

Vaihe 2: Koneoppiminen

Kenttä, jossa IBM ja AWS -pinot tarjoavat samankaltaisia palveluja, on koneoppiminen: Amazon ja sen SageMaker sekä IBM ja Watson Machine Learning. Molemmat palvelut ovat monilta osin hyvin samankaltaisia: molemmat esittelevät itsensä työkaluina, jotka auttavat datatieteilijöitä ja -kehittäjiä rakentamaan, kouluttamaan ja sitten ottamaan tuotantovalmiisiin ympäristöihin koneoppimismallinsa, mutta näiden kahden yrityksen omaksuma filosofia vaihtelee melko paljon. Molempien palveluiden avulla voit valita eri hallintatasojen välillä käyttämissäsi malleissa. Watson ML: ssä sinulla on joitakin sisäänrakennettuja malleja, jotka on jo koulutettu suorittamaan tiettyjä tehtäviä: esimerkiksi jos haluat tunnistaa, mitä objekteja kuvassa on, tuoda vain VisualRecognitionV3-mallin ja välität sille kuvan haluavat analysoida. Voit myös rakentaa”mukautetun mallin”, mutta Watson ML: ssä tämä tarkoittaa enimmäkseen jo rakennetun mallin ottamista ja sen harjoittelua, joten räätälöinti on melko rajallista. On kuitenkin tärkeää huomata, että SageMaker tai Watson ML eivät ole ainoita tapoja tehdä koneoppimista kehittäjiensä pinossa, ne ovat vain palveluja, joiden tarkoituksena on helpottaa kehittäjien elämää. Watson ML -alusta tukee myös monia suosituimpia koneoppimiskirjastoja, joten voit jopa rakentaa mallin alusta alkaen PyTorch-, Tensorflow- tai vastaavien kirjastojen avulla. Käytät joko näitä kirjastoja suoraan tai esivalmistettuja malleja, keskitietä ei ole. Myös Watson ML ei tue Amazonin valinnaista Apache MXNet -kirjastoa, jolla on sen sijaan ensiluokkainen tuki SageMakerissa.

Amazon SageMakerin lähestymistapa, jopa käytettäessä sisäänrakennettuja vaihtoehtoja, on hieman matalampi: sen sijaan, että pakottaisit valitsemaan valmiista malleista, sen avulla voit valita lukuisista jo toteutetuista koulutusalgoritmeista, joita voit käyttää rakennettaessa mallia perinteisemmällä tavalla. Jos nämä eivät riitä, voit myös käyttää omaa algoritmiasi. Tämä tapa tehdä asioita vaatii varmasti enemmän tietoa koneoppimisen suorittamisesta verrattuna pelkästään koulutetun mallin käyttämiseen Watson ML: ssä.

Ensi silmäyksellä saattaa tuntua siltä, että Watson ML on”helppo ja nopea” tapa, ja Amazon SageMaker on monimutkaisin asentaa. Tämä ei ehkä ole täysin totta joistakin näkökulmista, koska SageMaker on rakennettu niin, että kaikki toimii Jupyter-muistikirjalla, kun taas Watson ML: n samojen ominaisuuksien vuoksi sinun on määritettävä monia erilaisia alipalveluja web-käyttöliittymästä. Tietojen esikäsittelyssä on myös omat tilat IBM -palvelussa, kun taas SageMaker luottaa siihen, että teet kaiken kannettavan tietokoneen koodista. Tämä sekä se tosiasia, että Jupyter -muistikirjat eivät ole juuri paras valinta ohjelmistosuunnittelun näkökulmasta, voivat estää SageMakeria skaalautumasta erittäin hyvin tuotannossa. Molemmilla palveluilla on melko hyvät ja yksinkertaiset mekanismit mallin käyttöön ottamiseksi ja sovellusliittymien asettamiseksi saataville ulkomaailmaan.

Yhteenvetona voidaan todeta, että Watson ML toimii paremmin suurissa projekteissa, joissa Jupyter -muistikirjat alkavat näyttää rajojaan ja joissa ei tarvitse paljon mukauttaa itse mallia. SageMaker on paljon parempi, kun tarvitset enemmän joustavuutta algoritmien määrittelyssä, mutta kun käytät sitä, sinun on otettava huomioon se, että sinun on luotettava Jupyter -muistikirjoihin, jotka eivät ehkä skaalaudu hyvin tuotannossa. Ratkaisu voisi olla irrottaa loput koodista mallista niin paljon kuin mahdollista, jotta varsinaisten muistikirjojen koodi ei kasva liian suureksi ja voimme järjestää ohjelmistomme paremmin muihin moduuleihin, jotka käyttävät vain mallimme sovellusliittymää.

Vaihe 3: Tietojen suoratoisto ja analytiikka

Tietojen suoratoistopalvelut ovat ratkaisevia suurten datavirtojen reaaliaikaisessa käsittelyssä ja analysoinnissa. Tämä kulku voi tapahtua pilvestä käyttäjien laitteeseen, kuten videon suoratoistoon, tai käyttäjistä pilveen, kuten IoT -telemetria ja anturilukemat. Erityisesti toisessa tapauksessa meillä voi olla tilanne, jossa yksittäiset lähteet lataavat pieniä määriä dataa, mutta kun otetaan huomioon kaikkien laitteiden kokonaisteho, se kuluttaa huomattavaa kaistanleveyttä, joten on järkevää käyttää palvelua, joka on erikoistunut tällaisten laitteiden käsittelyyn tietovirrat. Jos emme käsittele tätä jatkuvaa virtausta suoraan, meidän olisi puskuroitava saapuva tieto väliaikaiseen tallennustilaan ja käsiteltävä se toisen kerran jollakin laskennallisella moottorilla. Tämän viimeisen lähestymistavan ongelma on se, että meidän olisi koordinoitava enemmän erilaisia palveluja saavuttaaksemme sen, mitä yksittäinen datavirtapalvelu jo yksin tekee, mikä lisää sovelluksen ylläpidon ja kokoonpanon monimutkaisuutta. Lisäksi puskurointi voi periaatteessa tehdä sovelluksestamme enää reaaliaikaisen, koska käsiteltävän kohteen käsittelemiseksi on välttämätöntä, että myös kaikki muut ennen sitä käsiteltävät kohteet ja etuoikeuskäytäntöjen lisääminen puskuriin voivat jälleen, lisää monimutkaisuutta rajusti. Yhteenvetona voidaan todeta, että tiedon suoratoistopalvelut tarjoavat reaaliaikaisen tiedonkulun käsittelyn ja helpon konfiguroinnin, ja ne voivat analysoida saapuvia tietoja. Tässä verrataan IBM: n ja AWS -pinon kahta tärkeintä suoratoistopalvelua, nimittäin IBM Streamsia ja AWS Kinesistä.

Aluksi huomaamme, että sekä IBM että AWS tarjoavat kaikki suoratoistopalvelun perustoiminnot. Näihin ominaisuuksiin kuuluu lähes ääretön käsittelynopeus, alhainen viive ja reaaliaikainen data -analyysi. Koska puhumme ammattitaitoisista palveluista, molemmat tarjoavat tuotantotason työkaluja käyttöönottoon ja automaatioon.

Kun puhutaan data -analytiikasta, molemmat palvelut tarjoavat sen valinnaisena, joten maksat vain, tarvitsetko sitä vai et. Kinesiksen tapauksessa, kun et tarvitse analytiikkaa, vaan vain tiedonkulun käsittelyä, hinnat veloitetaan käsitellystä Gt: sta käsittelyajan sijasta, kuten IBM: n tapauksessa. Hinnoittelu per Gt on yleensä halvempaa kuin aikahinta, koska maksat vain saapuvasta liikenteestä. Tämän postauksen loppuosassa harkitsemme sekä IBM Streamsia että AWS Kinesistä, kun data -analyysitoiminto on käytössä.

Streams ja Kinesis tarjoavat integroinnin eri palveluihin saapuvan datan esikäsittelyä ja suodattamista varten ennen niiden siirtämistä data-analytiikkaan, Apache Edgentin ja AWS Lambdan kanssa. Vaikka nämä palvelut eroavat toisistaan radikaalisti, keskustelemme niistä vain kahden suoratoistopalvelun näkökulmasta. Perusero näiden kahden välillä on se, että Apache Edgent suorittaa laitteen, kun taas AWS Lambda suorittaa pilvessä. Tämä tuo mukanaan monia etuja ja haittoja: Lambdan puolella meillä on joustava ja helppokäyttöinen palvelu, joka on integroitu saumattomasti Kinesiksen kanssa, mutta se edellyttää, että tiedot on jo ladattu pilveen, mikä heikentää tehokkuutta ja maksaa myös Kinesikselle tietoja, jotka lopulta hylätään. Edgentin puolelta sen sijaan meillä on, että suurin osa laskutoimituksista tehdään verkon laidalla (siis laitteilla) ennen kuin hyödyttömiä tietoja ladataan pilveen. Suurin haittapuoli on se, että Edgent on suuri kehys, jonka käyttöönotto voi vaatia aikaa ja jonka ylläpito voi olla monimutkaista. Toinen ero, jolla voi olla merkitystä alustan valinnassa, on se, että Edgent on täysin avoimen lähdekoodin, Lambda ei. Tämä voidaan nähdä sekä ammattilaisena, koska pääsy koodiin, jonka sinä tai asiakkaasi suoritat, on aina positiivinen asia, sekä huijauksena, koska voi olla tilanteita, joissa tarvitset kiireellistä tukea, jota ei voida tarjota kaikissa avoimen lähdekoodin ympäristöissä.

Muita ominaisuuksia, jotka voimme mainita, on Kinesiksen automaattinen skaalautuvuus varattuihin resursseihin. Itse asiassa sen tarjoama laitteisto koostuu useista rinnakkain toimivista ns. Kinesis Processing Units (KPU) -yksiköistä, joissa yksi KPU tarjoaa 1 vCoren ja 4 Gt RAM -muistia. Niiden määrä riippuu sovelluksen tarpeista, ja ne jaetaan dynaamisesti ja automaattisesti (maksat todellakin prosessorin aika kerrottuna KPU -laitteiden määrästä), muista vain, että Kinesis -käytäntö on veloittaa sinulta yksi KPU enemmän, jos käytät Javaa sovellus. Sen sijaan IBM Streams ei tarjoa tällaista joustavuutta ja tarjoaa sinulle kiinteän laitteiston sisältävän säiliön ja lisätietoja hinnoittelusta. Toisaalta IBM Streams on avoimempi kuin Kinesis, koska se liitetään WAN -verkkoon yleisten käytettyjen protokollien, kuten HTTP, MQTT ja niin edelleen, kautta, kun taas Kinesis on suljettu AWS -ekosysteemiltä.

Lopullisena vertailuna puhutaan hinnoittelusta ja haluan kertoa, että IBM ei toimi hyvin tässä asiassa. Olemme määrittäneet erilaisia ratkaisuja kolmeen eri luokkaan (perus-, huippuluokan-, huippuluokan) sekä IBM: lle että AWS: lle, ja aiomme vertailla niiden hintaa. Peruskokoonpanossa meillä on yksi AWS KPU, joka mainittiin aiemmin, IBM -ratkaisua vastaan, jolla on sama laitteisto. Huippuluokan osalta meillä on 8 KPU: ta käynnissä rinnakkain Kinesikselle ja 2 konttia aina rinnakkain IBM: lle, jokaisessa 4 vCores ja 12 Gt RAM-muistia. IBM tarjoaa aina huippuluokan yhden säiliön, jossa on 16 vCores ja 128 Gt RAM-muistia, kun taas jätimme pois vastaavan ratkaisun AWS: lle, koska jos jokin sovellus vaatii näin suuren määrän RAM-muistia, sitä ei voi käyttää eri KPU-laitteilla. Raportoitavat hinnat ilmaistaan dollareina kuukaudessa 24/7 käytön mukaan. Peruskokoonpanon osalta meillä on IBM: n ja AWS: n osalta 164 dollaria ja 490 dollaria, huippuluokan 1320 dollaria ja 3500 dollaria, huippuluokan AWS: ää ei oteta huomioon, ja vain IBM: llä on 6300 dollaria. Näistä tuloksista voimme nähdä, että Kinesis toimii paremmin jokapäiväiselle käyttäjälle jopa yritystasolle asti, mutta sillä ei ole vaihtoehtoja käsitellä suoraan data -analytiikkaa, joka vaatii valtavasti laskentatehoa. Kinesis tarjoaa paremman suorituskyvyn/dollarin suhteen kuin IBM Streams, jota auttaa myös pienten resurssilohkojen dynaaminen kohdistaminen vain tarvittaessa, kun taas IBM tarjoaa sinulle kiinteän säilön. Tällä tavalla, jos työllesi on ominaista huiput, sinun on pakko yliarvioida sovellustarpeesi ja määrittää ratkaisu pahimmassa tapauksessa. IBM tarjoaa tuntimaksuja koko kuukauden maksamisen sijasta, mutta sitä ei ole automatisoitu Kinesiksenä.

Vaihe 4: IoT -arkkitehtuuri

Aws iot -laitteiden määritys on melko helppoa verrattuna ibm watson iotiin. Koska ibm watson iotissa todennus tapahtuu laitekohtaisesti tunnuksella, ja kun se näyttää tunnuksen, sitä ei näytetä enää koskaan. Tulossa jälleen hinnoitteluosaan ibm watson iot on melko kallis verrattuna aws iotiin. Joten hinta ibm watson iot -maksuissa perustuu laitteeseen, tietojen tallennukseen ja dataliikenteeseen. Mutta aws iot voimme maksaa summan kerran ja voimme lisätä lisää laitteita ja tietoja, jotka on julkaistu laitteista ja toimitettu laitteille.

Aloita laitteestasi- olipa se anturi, yhdyskäytävä tai jotain muuta- ja anna meidän auttaa sinua muodostamaan yhteys pilveen.

Laitetietosi ovat aina turvassa, kun muodostat yhteyden pilveen käyttämällä avointa, kevyttä MGTT -viestiprotokollaa tai HTTP: tä. Protokollien ja solmupunaisen avulla voimme yhdistää laitteemme iot-alustalle ja käyttää reaaliaikaisia ja historiallisia tietoja.

Käytä suojattuja sovellusliittymiämme yhdistääksesi sovelluksesi laitteidesi tietoihin.

Luo sovelluksia tietyssä pilvipalvelussamme tietojen tulkitsemiseksi.