AWS na IBM: Ulinganisho wa Huduma za IoT: Hatua 4

2024 Mwandishi: John Day | [email protected]. Mwisho uliobadilishwa: 2024-01-30 12:52

Leo tunalinganisha mwingi mbili ambao hufanya iwezekane kukuza programu za IoT chini ya maoni ya matoleo tofauti ya huduma.

Hatua ya 1: Kazi kama Huduma

FaaS ni kitengo cha huduma za wingu zinazotumiwa kujenga usanifu "usio na seva". FaaS inaruhusu wateja kukuza, kuendesha, na kusimamia utendaji wa programu bila kujenga na kudumisha miundombinu.

Amazon inatoa AWS Lambda, IBM inatoa IBM Cloud Functions. Huduma hizo ni sawa kabisa, hata hivyo Lambda alikuwa wa kwanza wa aina hii. Kutumia FaaS unaweza kukimbia vipande vya nambari kwenye wingu na kila huduma inasaidia lugha tofauti za programu.

Kazi za Wingu la IBM: JavaScript, Swift, Java, Go, Php, Python, Ruby,. NET (C # F # n.k.), Yoyote kupitia Docker AWS Lambda: JavaScript, Java, C #, F #, Go, Python, Ruby, PowerShell, Yoyote kupitia Runtime API

IBM Inasaidia lugha zaidi na kwa docker ni rahisi kutumia maandishi yaliyoandikwa katika lugha zingine. Hii inaweza kufanywa pia na Lambda lakini sio ya haraka. Unaweza kusoma mfano hapa:

Huduma zote mbili zina mipaka ya utumiaji, tunairipoti katika jedwali na tunaangazia bora.

Bei hiyo inategemea GigaBytes kwa sekunde (RAM) na kuongezewa idadi ya maombi ya AWS Lambda. Kila huduma ina mpango wa bure na karibu ni sawa. Kama unaweza kuona Lambda ni ya bei rahisi kwa GB / s lakini ina gharama inayohusiana na maombi ambayo Kazi za Cloud hazina gharama karibu sawa kwa ujumla. Kwa kweli, ikiwa unahitaji kuendesha majukumu ambayo hula kumbukumbu na hutumia maombi machache unapaswa kutumia Lambda. Faida kuu ya IBM Cloud Function, kwa maoni yetu, ni kwamba stack yake ni chanzo wazi. Inategemea kabisa Apache OpenWhisk na inaweza pia kupelekwa kwenye miundombinu ya kibinafsi.

Hatua ya 2: Kujifunza kwa Mashine

Shamba ambalo vifurushi vya IBM na AWS vinatoa huduma sawa ni ile ya ujifunzaji wa mashine: Amazon na SageMaker yake na IBM na Watson Machine Learning. Huduma hizi mbili ziko katika hali nyingi sawa: zote zinajionyesha kama zana za kusaidia wanasayansi wa data na watengenezaji kujenga, kutoa mafunzo na kisha kupeleka katika mazingira tayari ya uzalishaji mifano yao ya kujifunza mashine, lakini falsafa ambazo kampuni hizo mbili zinachukua hutofautiana kidogo. Huduma zote mbili hukuruhusu kuchagua kati ya digrii tofauti za udhibiti kwenye modeli unazotumia. Katika Watson ML, una modeli zilizojengwa ambazo tayari zimefundishwa kufanya kazi maalum sana: kwa mfano, ikiwa unataka kutambua ni vitu gani vilivyopo kwenye picha unaingiza tu mfano wa VisualRecognitionV3 na kuipatia picha hiyo unataka kuchambua. Unaweza pia kujenga "mfano wa kawaida", lakini katika Watson ML hii inamaanisha kuchukua mfano uliojengwa tayari na kufanya mafunzo yetu juu yake, kwa hivyo usanifu ni mdogo sana. Ni muhimu kutambua ingawa kwamba SageMaker wala Watson ML sio njia pekee za kufanya ujifunzaji wa mashine kwenye stori za watengenezaji wao, ni huduma tu zinazolenga kufanya maisha ya watengenezaji kuwa rahisi. Jukwaa la Watson ML pia inasaidia maktaba nyingi maarufu zaidi za kujifunza mashine, kwa hivyo unaweza hata kujenga mfano kutoka mwanzo na PyTorch, Tensorflow au maktaba kama hizo. Unaweza kutumia maktaba hizo moja kwa moja, au utumie mifano iliyotengenezwa tayari, hakuna uwanja wa kati. Pia Watson ML haiungi mkono maktaba ya chaguo-msingi ya Amazon, Apache MXNet, ambayo badala yake ina msaada wa darasa la kwanza katika SageMaker.

Njia ya Amazon SageMaker, hata wakati wa kutumia chaguo zilizojengwa, ni kiwango cha chini zaidi: badala ya kukufanya uchague kutoka kwa aina zilizotengenezwa tayari, inakuwezesha kuchagua kutoka kwa idadi kubwa ya algorithms za mafunzo zilizotekelezwa tayari, ambazo unaweza kutumia wakati wa kujenga mfano kwa njia ya jadi zaidi. Ikiwa hizi hazitoshi, unaweza pia kutumia algorithm yako mwenyewe. Njia hii ya kufanya vitu hakika inahitaji maarifa zaidi juu ya jinsi ujifunzaji wa mashine unafanywa ikilinganishwa na kutumia tu mfano wa mafunzo katika Watson ML.

Kwa mtazamo wa kwanza inaweza kuonekana kuwa Watson ML ni njia "rahisi na ya haraka", na Amazon SageMaker kuwa ngumu zaidi kuanzisha. Hii inaweza kuwa sio kweli kabisa kutoka kwa maoni kadhaa, kwani SageMaker imeundwa kufanya kila kitu kiendeshwe kwenye Jarida la Jupyter, wakati kwa huduma zile zile katika Watson ML lazima usanidi huduma nyingi tofauti ndogo kutoka kwa UI ya wavuti. Utabiri wa data pia una nafasi za kujitolea kwenye huduma ya IBM wakati SageMaker inategemea wewe kuifanya yote kutoka kwa nambari kwenye daftari lako. Hii pamoja na ukweli kwamba daftari za Jupyter sio chaguo bora kabisa kutoka kwa maoni ya uhandisi wa programu, inaweza kuzuia SageMaker kutoka kuongeza vizuri katika uzalishaji. Huduma zote mbili zina njia nzuri na rahisi za kupeleka mfano wako na kuzifanya APIs zipatikane katika ulimwengu wa nje.

Kwa kumalizia, Watson ML inafanya vizuri katika miradi mikubwa ambapo daftari za Jupyter zinaanza kuonyesha mipaka yao, na ambapo hauitaji uboreshaji sana kwa kile mfano yenyewe unafanya. SageMaker ni bora zaidi wakati unahitaji kubadilika zaidi katika kufafanua algorithms, lakini wakati wa kuitumia unahitaji kuzingatia ukweli kwamba unapaswa kutegemea Jupyter Notebooks, ambazo zinaweza kutokua vizuri katika uzalishaji. Suluhisho linaweza kuwa kuondoa nambari iliyobaki kutoka kwa modeli iwezekanavyo, ili nambari iliyo kwenye madaftari halisi isiwe kubwa sana na tunaweza kuandaa programu yetu katika moduli zingine ambazo zinatumia tu API ya mtindo wetu..

Hatua ya 3: Utiririshaji wa data na Takwimu

Huduma za utiririshaji wa data ni muhimu katika kushughulikia na kuchambua kwa wakati halisi mtiririko mkubwa wa data. Mtiririko huu unaweza kutoka kwa wingu hadi kifaa cha watumiaji, kama utiririshaji wa video, au kutoka kwa watumiaji hadi kwenye wingu, kama Imet Telemetry na usomaji wa sensa. Hasa katika kesi ya pili, tunaweza kuwa na hali ambapo vyanzo moja vinapakia data kidogo lakini tunapofikiria kupitisha jumla, inayotokana na vifaa vyote, hutumia bandwidth kubwa, kwa hivyo ni busara kutumia huduma maalum kushughulikia vile mtiririko wa data. Bila kushughulikia mtiririko huu unaoendelea moja kwa moja, itabidi tuweke habari zinazoingia kwenye uhifadhi wa muda na kwa mara ya pili kuichakata na injini fulani ya hesabu. Shida ya njia hii ya mwisho ni kwamba tutalazimika kuratibu huduma tofauti zaidi kufikia kile huduma moja ya mkondo wa data tayari inafanya peke yake, na kuongeza ugumu wa matengenezo na usanidi wa programu. Kwa kuongezea, kubatilisha kwa kanuni kunaweza kufanya programu yetu isiwe tena kwa wakati halisi, kwani kwa kitu kusindika ni muhimu kwamba vitu vingine vyote kabla yake vishughulikiwe pia, na kuongeza sera za kutanguliza kwenye bafa inaweza, tena, Ongeza ugumu sana. Kwa muhtasari, huduma za utiririshaji wa data hutoa utunzaji wa mtiririko wa data kwa wakati halisi, na usanidi rahisi, na inaweza kutoa uchambuzi kwenye data inayoingia. Hapa tunalinganisha huduma mbili kuu za utiririshaji wa stack ya IBM na AWS, ambayo ni Mito ya IBM na AWS Kinesis.

Tunaanza kwa kubainisha kuwa huduma zote za msingi ambazo tunaweza kutaka kutoka kwa huduma ya utiririshaji hutolewa na IBM na AWS. Vipengele hivi ni pamoja na kiwango cha usindikaji kisicho na kikomo, latency ya chini na uchambuzi wa data ya wakati halisi. Kwa kuwa tunazungumza juu ya huduma za kitaalam, zote zinatoa zana za kiwango cha uzalishaji kwa kupelekwa na kiotomatiki.

Kuzungumza juu ya uchanganuzi wa data, huduma zote mbili hutoa kama hiari, ikifanya ulipe tu ikiwa unahitaji au la. Katika kesi ya Kinesis, wakati hauitaji uchambuzi lakini utunzaji wa mtiririko wa data tu, bei hutozwa kwa GB kusindika badala ya wakati wa usindikaji, kama katika kesi ya IBM. Bei kwa GB kwa ujumla itakuwa chini ya bei kuliko bei kwa wakati, kwani unalipa tu trafiki inayoingia. Kwa habari hii iliyobaki tutazingatia Mito ya IBM na AWS Kinesis na huduma ya uchambuzi wa data imewezeshwa.

Mito na Kinesis hutoa ujumuishaji na huduma tofauti kwa kuchakata kabla na kuchuja data zinazoingia kabla ya kuzipitia kwa uchambuzi wa data, mtawaliwa na Apache Edgent na AWS Lambda. Wakati huduma hizi ni tofauti kabisa kwa moja, tutazungumzia tu kutoka kwa mtazamo wa huduma mbili za utiririshaji. Tofauti ya kimsingi kati ya hizi mbili ni kwamba Apache Edgent hufanya kwenye kifaa, wakati AWS Lambda inafanya juu ya wingu. Hii inaleta faida na hasara nyingi: kutoka upande wa Lambda tuna huduma rahisi na rahisi kutumia na ujumuishaji ulio na mshono na Kinesis, lakini inahitaji data kupakiwa tayari kwenye wingu, na hivyo kupoteza kwa ufanisi na kulipa Kinesis pia kwa data ambayo hatimaye itatupwa. Kutoka upande wa Edgent badala yake, tuna hesabu nyingi hufanywa, vizuri, kwenye ukingo wa mtandao (kwa hivyo kwenye vifaa) kabla ya kupakia data isiyo na maana kwenye wingu. Kikwazo kuu ni kwamba Edgent ni mfumo mkubwa, ambao unaweza kuhitaji muda wa kuanzisha na inaweza kuwa ngumu kutunza. Tofauti nyingine ambayo inaweza kuwa muhimu katika uchaguzi wa jukwaa ni kwamba Edgent ni chanzo wazi kabisa, Lambda sio. Hii inaweza kuonekana kama pro mazingira yote ya chanzo wazi.

Vipengele vingine ambavyo tunaweza kutaja ni upungufu wa kiotomatiki wa Kinesis wa rasilimali zilizotengwa. Kwa kweli, vifaa inavyotoa vimeundwa na idadi inayoitwa Kinesis Processing Units (KPUs) inayoendesha sambamba, ambapo KPU moja hutoa 1 vCore na 4GB ya RAM. Idadi yao inategemea mahitaji ya programu na imetengwa kwa nguvu na kiatomati (unacholipa ni kweli wakati wa cpu idadi ya KPUs), kumbuka tu kwamba ni sera ya Kinesis kukutoza KPU moja zaidi ikiwa unatumia Java matumizi. Mito ya IBM, badala yake, haitoi ubadilikaji wa aina hii, ikikupa kontena na vifaa vya kudumu, maelezo zaidi tunapozungumza juu ya bei. Kwa upande mwingine, Mito ya IBM iko wazi zaidi kuliko Kinesis, kwani inaingiliana na WAN kupitia itifaki za kawaida zinazotumiwa, kama HTTP, MQTT na kadhalika, wakati Kinesis imefungwa kwa mfumo wa ikolojia wa AWS.

Kama kulinganisha kwa mwisho wacha tuzungumze juu ya bei, na wacha niambie kwamba IBM haifanyi kazi vizuri kwa hatua hii. Tumesanidi suluhisho tofauti kwa vikundi vitatu tofauti (msingi, mwisho-juu, mwisho-juu-mwisho) kwa IBM na AWS, na tutalinganisha bei yao. Katika usanidi wa kimsingi tuna AWS KPU moja, iliyotajwa hapo awali, dhidi ya suluhisho la IBM na vifaa sawa. Kwa mwisho wa juu tuna KPU 8 zinazoendesha ni sawa na Kinesis na kontena 2 kila wakati sawa na IBM, kila moja ikiwa na vCores 4 na 12GB ya RAM. Daima IBM hutoa katika mwisho-wa-mwisho kontena moja na 16 vCores na 128GB ya RAM, wakati tuliacha suluhisho sawa kwa AWS, kwani ikiwa programu tumizi fulani inahitaji kiasi hiki kikubwa cha RAM haikuwezekana kuiendesha kwenye KPU tofauti. Bei tunayoripoti zinaonyeshwa kwa $ / mwezi kwa kuzingatia matumizi ya 24/7. Kwa usanidi wa kimsingi tuna IBM na AWS mtawaliwa 164 $ na 490 $, kwa mwisho wa juu 1320 $ na 3500 $, kwa AWS ya mwisho-wa juu haizingatiwi na kuna IBM tu na 6300 $. Kutoka kwa matokeo haya tunaweza kuona kwamba Kinesis inafanya kazi bora kwa mtumiaji wa kila siku hadi kiwango cha biashara, wakati haina chaguo za kushughulikia moja kwa moja uchambuzi wa data ambao unahitaji nguvu kubwa sana ya kompyuta. Kinesis hutoa utendaji bora / uwiano wa $ kuliko Mito ya IBM, iliyosaidiwa pia na mgawanyo wa nguvu wa vizuizi vidogo vya rasilimali wakati tu inahitajika, wakati IBM inakupa chombo kilichowekwa. Kwa njia hii, ikiwa mzigo wako wa kazi unajulikana na kilele, na IBM unalazimika kuzingatia mahitaji yako ya maombi na kusanidi suluhisho katika hali mbaya zaidi. IBM hutoa ada ya masaa badala ya kulipa mwezi kamili, lakini sio kiotomatiki kama Kinesis.

Hatua ya 4: Usanifu wa IoT

Usanidi wa vifaa vya aws iot ni rahisi sana ikilinganishwa na ibm watson iot. Kwa sababu katika ibm watson iot uthibitisho ni kwa kila kifaa kilicho na ishara na mara tu itakapoonyesha ishara hiyo haitaonyeshwa tena. Kuja kwenye sehemu ya bei tena ibm watson iot ni gharama kubwa sana ikilinganishwa na aws iot. Kwa hivyo, bei katika malipo ya ibm watson iot inategemea kila kifaa, uhifadhi wa data, trafiki ya data. Lakini katika aws iot tunaweza kulipa kiasi hicho mara moja na tunaweza kuongeza vifaa na data zaidi iliyochapishwa kutoka kwa vifaa na kupelekwa kwa vifaa.

Anza na kifaa chako - iwe ni sensa, lango, au kitu kingine- na tukusaidie kuungana na wingu.

Data ya kifaa chako iko salama kila wakati unapounganisha na wingu ukitumia itifaki ya ujumbe wazi, nyepesi ya MGTT au HTTP. Kwa msaada wa itifaki na node-nyekundu tunaweza kuunganisha kifaa chetu na jukwaa la iot na tunaweza kupata data ya moja kwa moja na ya kihistoria.

Tumia API zetu salama kuunganisha programu zako na data kutoka kwa vifaa vyako.

Unda programu ndani ya huduma yetu ya wingu ili kutafsiri data.