IoT, udu ja pilved: räägime tehnoloogiatest?

Tehnoloogia areng tarkvara ja riistvara valdkonnas ning uute suhtlusprotokollide tekkimine on toonud kaasa asjade interneti (IoT) laienemise. Seadmete arv kasvab päevast päeva ja need genereerivad tohutul hulgal andmeid. Seetõttu tekib vajadus mugava süsteemi arhitektuuri järele, mis suudaks neid andmeid töödelda, salvestada ja edastada.

Praegu kasutatakse nende eesmärkide saavutamiseks pilveteenuseid. Kuid üha populaarsem muutuv uduarvutuste paradigmad (Fog) võivad täiendada pilvelahendusi, suurendades ja optimeerides IoT infrastruktuuri.

«Pilved» suudavad rahuldada enamiku IoT nõudmisi. Näiteks tagada teenuste jälgimise, andmete kiire töötlemise, mida seadmed genereerivad, ning nende visualiseerimise. Uduarvutused on aga efektiivsemad reaalaja probleemide lahendamisel. Need tagavad kiire vastuse päringutele ja minimaalne viivitus andmete töötlemisel. Seega täiendab Fog pilvi, laiendab selle võimalusi.

Kuid peamine küsimus on hoopis teine: kuidas peaks see kõik toimima IoT kontekstis? Millised suhtlusprotokollid oleksid kõige tõhusamad ühtses IoT-Fog-Cloud süsteemis?

Hoolimata näilisest HTTP domineerimisest kasutatakse IoT, Fog ja Cloud süsteemides palju muid lahendusi. See tuleneb sellest, et IoT peab ühendama erinevate seadmete sensorite funktsionaalsused turvalisuse, ühilduvuse ja teiste kasutajate nõuetega.

Kuid ühtset arusaama standardarhitektuurist ja suhtlusstandardist pole lihtsalt olemas. Seetõttu on uue protokolli loomine või olemasoleva kohandamine konkreetsetele IoT ülesannetele üks IT-kogukonna olulisemaid ülesandeid.

Milliseid protokolle praegu kasutatakse ja mida need võivad pakkuda? Uurime lähemalt. Aga kõigepealt arutame ökosüsteemi põhimõtteid, kus suhtlevad pilved, udu ja asjade internet.

IoT Fog-to-Cloud (F2C) arhitektuur

Olete kindlasti märganud, kui suuri jõupingutusi tehakse, et uurida IoT, pilvede ja uduhalduse seotud eeliseid ja kasu. Kui ei, siis siin on kolm standardimisalgatust: OpenFog Consortium, Edge Computing Consortium ja mF2C H2020 EL projekti.

Kui varem vaadati ainult kahte taset, pilvi ja lõppseadmeid, siis pakutud arhitektuur tutvustab uut taset — uduarvutust. Samuti võib udu tase jagada mitmeks alamtasemeks, sõltuvalt ressursside spetsiifikast või poliitikapaketist, mis määratleb erinevate seadmete kasutamise nende alamtasemetes.

Kuidas võiks see abstraktsioon välja näha? Siin on tüüpiline IoT-Udu-Pilv ökosüsteem. IoT-seadmed saadavad andmeid tootlikumatel serveritele ja arvutusüksustele, et lahendada madala latentsusega ülesandeid. Samas süsteemis vastutavad pilved suurte arvutusressursside või andmete salvestamise ruumi vajalike ülesannete täitmise eest.

Nutitelefonid, nutikellad ja muud seadmed võivad samuti kuuluda IoT-sse. Kuid sellised seadmed kasutavad tavaliselt suurte arendajate omandiõiguslikke kommunikatsiooniprotokolle. Interneti asjade genereeritud andmed edastatakse udu tasandile üle REST HTTP protokolli, mis tagab paindlikkuse ja funktsionaalse ühilduvuse RESTful teenuste loomiseks. See on oluline, kuna on vajalik tagada ühilduvus olemasoleva arvutitehnoloogiaga, mis töötab kohalikel arvutitel, serveritel või serverite klastritel. Kohalikud ressursid, mida nimetatakse «udu sõlmedeks», filtreerivad saadud andmeid ja töötlevad neid kohapeal või edastavad edasiseks töötlemiseks pilve.

Pilved toetavad erinevaid kommunikatsiooniprotokolle, mille seas on kõige sagedamini AMQP ja REST HTTP. Kuna HTTP on laialdaselt tuntud ja internetti kohandatud, võib tekkida küsimus: «kas seda kasutada IoT ja udus töötamiseks?». Siiski on selle protokolliga seotud jõudlusprobleeme. Edasi tulles räägime sellest rohkem.

Kokkuvõttes on olemas kaks sideprotokollide mudelit, mis sobivad meie süsteemi vajadustele. Need on päring-vastus ja avaldamine-tellimine. Esimene mudel on laiemalt tuntud, eriti server-klient arhitektuuris. Klient küsib serverilt teavet, server võtab päringu vastu, töötleb selle ning tagastab vastuse. Selle mudeli alusel töötavad protokollid REST HTTP ja CoAP.

Teine mudel tekkis vajadusest tagada asünkroonne, jaotatud ja nõrk side andmete genereerimise allikate ja nende andmete vastuvõtjate vahel.

Mudel eeldab kolme osalist: väljaandjat (andmeallikat), vahendajat (dispetšerit) ja tellijat (vastuvõtjat). Siin klient, kes tegutseb tellijana, ei pea serverilt teavet küsima. Kliendi asemel tellib ta süsteemis teatud sündmuste jaoks vahendaja kaudu, kes vastutab kõigi sisenevate sõnumite filtreerimise ja suunamise eest väljaandjate ja tellijate vahel. Kui teatud teema haru puhul toimub sündmus, avaldab väljaandja selle vahendajale, kes saadab tellijale teavet taotletud teema kohta.

Tegelikult põhineb see arhitektuur sündmustel. Selline suhtlemismudel on huvitav IoT, pilve ja serva rakenduste jaoks tänu oma võimele tagada skaleeritavust ja lihtsustada erinevate seadmete vahelist suhtlust, toetada dünaamilist «palju-paljude» ja asünkroonset suhtlust. Tuntud standardiseeritud sõnumivahetuse protokollid, mis kasutavad «väljaande-tellija» mudelit, hõlmavad näiteks MQTT, AMQP ja DDS.

On ilmne, et «väljaande-tellija» mudelil on hulgaliselt eeliseid:

• Väljaandjatel ja tellijatel ei ole vaja üksteisest teadlikud olla;
• Üks tellija võib saada teavet paljude erinevate väljaannete käest, samas kui üks väljaandja võib edastada andmeid paljudele erinevatele tellijatele (põhimõte «palju-paljude»);
• Väljaandja ja tellija ei pea andmete edastamiseks olema korraga aktiivsed, kuna vahendaja (kes töötab järjekorrasüsteemina) suudab hoida sõnumit klientide jaoks, kes hetkel ei ole võrku ühendatud.

Kuid ka mudel "päring-vastus" omab oma eeliseid. Situatsioonides, kus serveri pool ei ole mitme kliendi päringute töötlemise osas probleemiks, on mõistlik kasutada juba tõestatud usaldusväärseid lahendusi.

On ka protokolle, mis toetavad mõlemat mudelit. Näiteks XMPP ja HTTP 2.0, mis toetavad „serveri push“ võimalust. IETF on ka välja andnud CoAP. Probleemide lahendamiseks sõnumite vahetamise osas on loodud mitmeid teisi lahendusi, nagu WebSocket protokoll või HTTP kasutamine QUIC (Quick UDP Internet Connections) kaudu.

WebSocketide puhul, kuigi seda kasutatakse andmete edastamiseks reaalajas serverist veebiklientidele ning tagab pidevad ühendused ja kahepoolsed suhted, ei ole see mõeldud seadmete jaoks, millel on piiratud arvutusvõimsus. QUIC väärib samuti tähelepanu, kuna uus transportprotokoll avab palju uusi võimalusi. Kuid kuna QUIC ei ole veel standardiseeritud, on liiga vara prognoosida selle võimalikke kasutusviise ja mõju IoT lahendustele. Seega jätame WebSocketid ja QUIC oma mälu, silmas pidades tulevikku, kuid ei süvene seni rohkem.

Kes on kõige armsam: võrdleme protokolle

Nüüd räägime protokollide tugevustest ja nõrkustest. Juba ette öeldes tuleks märkida, et ühte selget liidrit ei ole. Iga protokolli puhul on omad eelised ja puudused.

Reageerimisaeg

Üks peamisi sideprotokollide omadusi, eriti asjade interneti kontekstis, on reageerimisaeg. Siiski ei ole olemas ühtegi protokolli, mis oleks täiesti ülekaalus ja näitaks minimaalset latentsust erinevates tingimustes. Siiski on mitmeid uuringuid ja protokollide võrdlusi.

Näiteks, tulemused HTTP ja MQTT tõhususe võrdlus asjade internetis näitas, et MQTT reageerimisaeg on lühem kui HTTP-l. Ja kui uurida edastamise vastastikust aega (RTT) MQTT ja CoAP puhul selgus, et CoAP keskmine RTT on 20% madalam kui MQTT-l.

Muu katse MQTT ja CoAP protokollide RTT-d uuriti kahes stsenaariumis: kohaliku võrgu ja asjade interneti võrgus. Selgus, et keskmine RTT on IoT-võrgus 2–3 korda kõrgem. MQTT QoS0 näitas madalamat tulemust võrreldes CoAP-iga, samas kui MQTT QoS1 näitas kõrgemat RTT-d tänu ACK-le rakendus- ja transporttasanditel. Erinevate QoS tasemete latentsus koormusteta võrgus oli MQTT-l millisekundites, CoAP-l aga sadades mikrosekundites. Tuleb siiski meeles pidada, et vähem usaldusväärsetes võrkudes näitab MQTT, mis töötab TCP peal, hoopis teistsuguseid tulemusi.

Võrdlus AMQP ja MQTT protokollide vastusajad koormuse suurenemisega näitasid, et madala koormuse korral on viivituse tase peaaegu sama. Kuid suurte andmemahtude edastamisel näitab MQTT lühemat vastusaega. Veel ühes uurimuses võrdlesid CoAP-i ja HTTP-d masinatevahelise suhtluse stsenaariumis seadmetega, mis on paigutatud sõidukite peale ja varustatud gaasiandurite, ilmatingimuste andurite, asukoha (GPS) ja mobiilse võrgu liidesega (GPRS). Aeg, mis kulus CoAP sõnumi edastamiseks mobiilvõrgu kaudu, oli peaaegu kolm korda lühem kui HTTP sõnumite edastamiseks vajalik aeg.

Viidi läbi uuringud, kus võrreldi mitte kahte, vaid kolme protokolli. Näiteks võrdlus IoT protokollide MQTT, DDS ja CoAP jõudlust meditsiinilistes rakendustes, kasutades võrgusimulaatorit. DDS ületas MQTT telemeetriaviivituse osas erinevates halbadest võrguoludest. UDP-põhine CoAP töötas hästi rakendustes, mis nõudsid kiiret vastust, kuid kuna see põhineb UDP-l, esines märkimisväärset ettenägematut pakettide kaotust.

Läbivool

Võrdlus MQTT ja CoAP kanalikasutuse efektiivsuse osas toimus andmete edastamise koguhulga arvestamine ühe sõ numbriga. CoAP näitas väiksemat läbilaskevõimet kui MQTT väikeste sõnumite edastamisel. Kuid võrreldes protokollide efektiivsust informatiivsete baitide ja edastatud baitide koguhulga suhte osas osutus CoAP tõhusamaks.

Koormuse analüüsi korral analüüs MQTT, DDS (TCP transpordiprotokollina) ja CoAP kanalikasutuse analüüs näitas, et CoAP, üldiselt näitas suhteliselt madalamat ribakulu, mis ei suurenenud, kui suurenes võrgupakettide kaotamine või võrgu viivitus, erinevalt MQTT ja DDS-st, kus nendes stsenaariumides täheldati kanalikasutuse kasvu. Teises stsenaariumis oli kaasatud suur hulk seadmeid, mis edastavad andmeid samal ajal, mis on tüüpiline IoT keskkondades. Tulemused näitasid, et suurema koormuse korral on parem kasutada CoAP-i.

Vähenenud koormuse korral kasutas CoAP kõige vähem ribalaiust, järgnesid MQTT ja REST HTTP. Siiski, kui kasulike koormuste suurus suurenes, saavutas parima tulemuse REST HTTP.

Energiatarve

Energiatarbe küsimus on alati oluline, eriti IoT süsteemides. Kui võrrelda elektritootmise MQQT ja HTTP puhul, siis HTTP „neelab“ märgatavalt rohkem. CoAP seevastu on energiatõhusam kui MQTT, võimaldades toite haldamist. Lihtsates stsenaariumides on MQTT siiski rohkem sobiv teabe vahetamiseks asjade internetis, eriti kui võimsuspiiranguid ei ole.

Muu Eksperiment, kus võrreldi AMQP ja MQTT võimalusi mobiilses või ebastabiilses juhtmevabas võrgus, näitas, et AMQP pakub rohkem turvalisuse võimalusi, samas kui MQTT on energiatõhusam.

Ohutus

Turvalisus on veel üks oluline teema, mida arutatakse asjade interneti ja serva/pilvetehnoloogiate uurimisel. Turvamehhanism põhineb tavaliselt TLS-il HTTP-s, MQTT-s, AMQP-s ja XMPP-s, või DTLS CoAP-s ning toetab mõlemat DDS.

TLS ja DTLS algavad kliendi ja serveri vahelise ühenduse loomise protsessist, et vahetada toetatavaid krüptokomplekte ja võtmeid. Mõlemad pooled lepivad kokku komplektides, et tagada edasine suhtlemine turvalises kanalites. Nende vahe seisneb väikestes muudatustes, mis võimaldavad DTLS-il, mis põhineb UDP-l, töötada usaldamatutel ühendustel.

Koormuse analüüsi korral testirünnakutes Mitmete erinevate TLS ja DTLS rakenduste testimisel on selgunud, et TLS on ülesande täitmisel paremini hakkama saanud. DTLS rünnakud olid edukamad tänu oma vigade taluvusele.

Kuid suurim probleem nende protokollide puhul on see, et need ei olnud algselt mõeldud IoT kasutamiseks ega arvestanud pilves või udus töötamisega. Kokkulepitud vahetuse (handshaking) kaudu lisavad nad iga ühenduse loomisega täiendavat liiklust, mis kurnab arvutusressursse. Keskmiselt on TLS-i puhul täiendav koormus 6,5% ja DTLS-i puhul 11% võrreldes turvataseme puudumisega. Ressursirikkas keskkonnas, mis asub tavaliselt pilves tasemel, see ei tohiks probleemi tekitada, kuid IoT ja udu taseme vahelise seose tõttu muutub see tõsiseks piiranguks.

Mida siis valida? Ühtset vastust ei ole. MQTT ja HTTP paistavad olevat kõige perspektiivikamad protokollid, kuna neid peetakse võrreldes teiste protokollidega suhteliselt küpseks ja stabiilseks lahenduseks IoT jaoks.

Ühtse kommunikatsiooniprotokolli lahendused

Ühe protokolli lahenduse praktika omab palju puudusi. Näiteks protokoll, mis rahuldab piiratud keskkonda, ei pruugi töötada valdkonnas, kus on ranged turvanõuded. Seda silmas pidades jääb meil peaaegu kõik ainuprotokolliga lahendused Fog-to-Cloud ökosüsteemis IoT-s välja jätta, välja arvatud MQTT ja REST HTTP.

REST HTTP ühtse protokolli lahendusena

Härra hea näide REST HTTP päringute ja vastuste interaktsioonist IoT-to-Fog valdkonnas: intelligentne farm. Loomad on varustatud kantavate anduritega (IoT klient, C) ja neid haldab nutika põllumajanduse süsteem (Fog-server, S) pilvearvutuse kaudu.

POST meetodi pealkirjas määratakse ressurss, mida tuleb muuta (/farm/animals), samuti HTTP versioon ja sisu tüüp, mis antud juhul on JSON objekti kujul, esindades loomafarmi, mida süsteem peab haldama (Dulcineia/lehm). Serveri vastus näitab, et päring oli edukas, saates HTTPS staatuse koodi 201 (ressurss loodud). GET meetod peaks määrama ainult taotletud ressursi URI (näiteks /farm/animals/1), mis tagastab selle identifikaatoriga looma JSON esitlemise serverist.

PUT meetodi kasutatakse, kui on vaja värskendada mõnda konkreetset ressursi kirjet. Sel juhul määratakse ressursis URI parameetrile, mida tuleb muuta, ja praegusele väärtusele (näiteks näidates, et lehm on nüüd jalutamas, /farm/animals/1?state=jalutamine). Lõpuks kasutatakse DELETE meetodit võrdselt GET meetodiga, kuid see lihtsalt kustutab ressursi toimingu tulemusena.

MQTT kui üheahelaline lahendus

Võtame sama nutifarmi, kuid REST HTTP protokolli asemel kasutame MQTT protokolli. Kohalik server koos paigaldatud Mosquitto teegiga funktsioneerib vahendajana. Selles näites toimib lihtne arvuti (mida tähistatakse farmiserverina) Raspberry Pi MQTT kliendina, mis on toimiv läbi MQTT Paho raamatukogu, mis on täielikult ühilduv Mosquitto vahendajaga.

See klient vastab IoT abstraktsioonitasemele, mis esindab seadet, millel on tuvastamise ja arvutamise võimed. Vahendaja, teisalt, vastab kõrgemale abstraktsioonitasemele, mis esindab udutehnoloogia arvutuspunkti, mis iseloomustab suuremaid võimeid andmete töötlemisel ja salvestamisel.

Pakutud „nutika talu“ stsenaariumis ühineb Raspberry Pi akseleromeetri, GPS-i ja temperatuurianduritega ning avaldab nende andurid andmed udutootmisajas. Nagu te ilmselt teate, käsitleb MQTT teemasid hierarhias. Üks MQTT väljaandja võib avaldada sõnumeid kindlas teemade kogus. Meie puhul on neid kolm. Loomade tallis temperatuuri mõõtmiseks valib klient teema (animalfarm/shed/temperature). GPS-i ja loomade liikumise mõõtmiseks akseleromeetri kaudu avaldab klient värskendusi (animalfarm/animal/GPS) ja (animalfarm/animal/movement).

See teave edastatakse vahendajale, kes võib selle ajutiselt salvestada kohalikku andmebaasi juhuks, kui hiljem ilmneb mõni teine huvitatud tellija.

Lisaks kohalikele serveritele, mis toimivad MQTT vahendajatena uduvaikus ja kuhu Raspberry Pi, tegevad MQTT klientid, saadavad andmeid sensoritest, võib pilve tasemel olla veel üks MQTT vahendaja. Sellisel juhul võib kohaliku vahendajaga edastatav teave ajutiselt salvestada kohalikku andmebaasi ja/või saata pilve. Udu MQTT vahendajat kasutatakse selles olukorras, et siduda kõik andmed pilve MQTT vahendajaga. Sellise arhitektuuri korral võib mobiilirakenduse kasutaja olla tellitud mõlemale vahendajale.

Ühenduse katkemise korral ühe vahendajaga (näiteks pilvega) saab lõppkasutaja teavet teisest (udust). See on iseloomulik tunnus udu ja pilve arvutuste kombineeritud süsteemide puhul. Vaikimisi võib mobiilirakendus olla seadistatud esmakordselt ühenduma udus oleva MQTT vahendajaga ning ebaõnnestumise korral ühenduma pilve MQTT vahendajaga. See lahendus on vaid üks paljusid IoT-F2C süsteemides.

Mitmeprotokollilised lahendused

Ühe protokolli lahendused on populaarsed, kuna nende rakendamine on lihtsam. Kuid on selge, et IoT-F2C süsteemides on mõistlik kombineerida erinevaid protokolle. Eesmärk on, et erinevates kihtides võivad töötada erinevad protokollid. Kui võtame näiteks kolm abstraktsiooni: IoT, udune ja pilvetehnoloogia tasemed. IoT tasemel peetakse seadmeid tavaliselt piiratud võimekusega. Selle ülevaate jaoks käsitleme IoT tasemeid kui kõige piiratumateid, pilvetasemeid kui kõige vähem piiratud, ning udutehnoloogiat kui midagi nende vahepealset. Seega sisaldavad IoT ja udust abstraktsiooni vahel hetke protokollilahendused MQTT, CoAP ja XMPP. Udune ja pilve vahel on AMQP üks peamisi kasutatavaid protokolle koos REST HTTP-ga, mida kasutatakse ka IoT ja udutasemete vahel oma paindlikkuse tõttu.

Põhiliseks probleemiks on protokollide funktsionaalne ühilduvus ja sõnumite lihtsus ühelt protokollilt teisele tõlkimisel. Ideaalis peaks tulevikus asjade interneti arhitektuur pilve- ja uduressurssidega olema sõltumatu kasutatavast sideprotokollist ning tagama erinevate protokollide hea koostöö.

Kuna see ei ole praegu nii, on mõistlik liita protokolle, millel ei ole olulisi erinevusi. Selle eesmärgi saavutamiseks põhineb üks potentsiaalne lahendus kahe protokolli, REST HTTP ja CoAP, kombinatsioonil, mis järgivad sama arhitektuurilist stiili. Teine ettepanekud lahendus põhineb kahe protokolli ühendamisel, mis pakuvad koostööd „publikatsioon-registratsioon“ mudeli kaudu, MQTT ja AMQP. Lähedaste kontseptsioonide kasutamine (nii MQTT kui AMQP kasutavad vahebrokereid, CoAP ja HTTP kasutavad REST-i) lihtsustab nende kombinatsioonide rakendamist ning nõuab vähem integreerimise pingutusi.

Joonisel (a) on kujutatud kaks mudeleid, mis põhinevad päringutel ja vastustel, HTTP ja CoAP, ning nende võimalik paigutus IoT-F2C lahenduses. Kuna HTTP on üks tuntumaid ja laialdaselt kohandatud protokolle kaasaegsetes võrkudes, on ebatõenäoline, et see asendatakse täielikult teiste sõnumivahetuse protokollidega. Võimsate seadmete, mis asuvad pilve ja udu vahel, seas on REST HTTP mõistlik lahendus.

Teisest küljest, piiratud arvutusressurssidega seadmete puhul, mis suhtlevad udu ja IoT tasemete vahel, on CoAP kasutamine efektiivsem. Üks CoAP suuremaid eeliseid on tegelikult selle ühilduvus HTTP-ga, kuna mõlemad protokollid põhinevad REST-i põhimõtetel.

Joonisel (b) on kujutatud kaks "publikatsiooni-ja tellimise" interaktsiooni mudelit ühes stsenaariumis, sealhulgas MQTT ja AMQP. Kuigi hüpoteetiliselt võiks mõlemat protokolli kasutada sidepidamiseks sõlmede vahel igas abstraktsiooni tasemes, tuleks nende asukoht määrata jõudluse alusel. MQTT on loodud lihtsustatud protokollina piiratud arvutusvõimekusega seadmetele, seega saab seda kasutada IoT ja uduste vahelise sidepidamiseks. AMQP sobib paremini jõulisematele seadmetele, mis positsioneeriksid selle ideaalselt uduste ja pilveteenuste vahel. IoT-s võib MQTT asemel kasutada protokolli XMPP, kuna seda peetakse kergemaks, kuid see ei ole sarnastes stsenaariumites nii laialdaselt kasutatav.

Järeldused

On ebatse, et ükski kaalutletud protokollidest ei pruugi olla piisav, et katab kogu süsteemi suhtlemise, alustades seadmetest, mille arvutusvõimsus on piiratud, ja lõpetades pilveserveritega. Uuringud on näidanud, et kaks kõige paljutõotavamat valikut, mida arendajad tihti kasutavad, on MQTT ja RESTful HTTP. Need kaks protokolli on mitte ainult kõige küpsemad ja stabiilsemad, vaid sisaldavad ka palju hästi dokumenteeritud ja edukaid rakendusi ning veebivähendeid.

Oma stabiilsuse ja lihtsa seadistuse tõttu on MQTT protokoll, mis on aja jooksul tõestanud oma erakordset sooritust IoT tasemel piiratud seadmetega. Süsteemi osades, kus piiratud ühenduvus ja aku tarbimine ei ole probleem, näiteks teatud udusfääride ja enamikul pilveteenuste casos, on RESTful HTTP lihtne valik. Samuti tuleks arvestada CoAP-iga, kuna see areneb samuti kiiresti IoT sõnumivahetuse standardiks, ja on tõenäoline, et peagi saavutataks see stabiilsuse ja küpsuse tase, mis on sarnane MQTT ja HTTP-le. Kuid standard areneb praegu, mis toob kaasa lühiajalisi ühilduvusprobleeme.

Mida veel huvitavat blogis lugeda Cloud4Y

→ Arvuti teeb teile maitsvat
→ AI aitab õppida Aafrika loomi
→ Suvi on peaaegu läbi. Peaaegu ei ole andmeid, mis oleks kaduma läinud
→ 4 viisi, kuidas pilves varundamisel raha säästa
→ Üksikust föderaalsest teabest, mis sisaldab andmeid rahvastiku kohta

Liituge meiega Telegram-kanal, et mitte jääda ilma järgnevast artiklist! Kirjutame mitte tihedamini kui kaks korda nädalas ja ainult asjalikult.

Allikas: habr.com