A helyi tárolás és a felhő közötti választás technikainak tűnik, de a termék használatával kezdődik. Egyetlen telefon személyes listája más igényeket támaszt, mint egy több ember által közösen szerkesztett terv. Mindkét architektúra lehet megbízható, és mindkettő szükségtelenül bonyolulttá válhat, ha nem illik a helyzethez.
A „helyi egyenlő privát” éppoly hiányos, mint a „felhő egyenlő modern”. A helyi adatok elveszhetnek az eszközzel. A felhő segítheti az együttműködést és a helyreállítást, de fiókokat, infrastruktúrát és érthető adatáramlást igényel. A megfelelő elosztást a konkrét felhasználási helyzet határozza meg, nem az architektúrára ragasztott címke.
Röviden
- A helyi vagy felhős megoldás termékdöntés, nem minőségi rangsor.
- A helyi adatok támogatják az offline használatot, de megbízható mentést igényelnek.
- A felhő közös állapotot tesz lehetővé, ugyanakkor fiókokat, szinkronizálást és üzemeltetést ad hozzá.
Mit jelent valójában a „helyi” és a „felhő”?
Helyi alkalmazás esetén az irányadó adatpéldány az eszköz tárhelyén található. Az alkalmazás sok esetben hálózat nélkül is működhet, és az alapfolyamathoz nincs szüksége szerverre. Ez nem jelenti azt, hogy az operációs rendszer szolgáltatásai ne vehetnének részt a terjesztésben, az eszköz biztonsági mentésében vagy egy exportfájl megosztásában. Csupán azt jelenti, hogy a szolgáltató nem tart fenn központi alkalmazás-adatbázist ezekhez a felhasználói adatokhoz.
A NIST definíciója szerint a felhőalapú számítástechnika igényvezérelt hálózati hozzáférést ír le a konfigurálható erőforrások megosztott készletéhez. Egy alkalmazáshoz az adatbázisok, a fájltárolók, az identitásszolgáltatások és a számítási teljesítmény is beépíthető. A központi másolat ekkor jellemzően egy távoli infrastruktúrában található; az eszközök betöltik az adatokat, elküldik a változtatásokat és egyeztetik az állapotot.
Sok termék hibrid megközelítést alkalmaz: az adatokat az eszközön tárolja a gyors, offline használathoz, majd a háttérben szinkronizálja őket egy szerverrel. Az Android fejlesztői dokumentáció ezt „offline-first” architektúrának nevezi, amelyben a helyi adatforrás az olvasás elsődleges alapja, a hálózati műveletek pedig frissítik ezt a példányt. A felhő tehát nem tűnik el; egy további helyi réteggel és szinkronizálási szabályokkal egészül ki.
A helyi tárolás csökkenti a függőséget
Ha egy alkalmazáshoz nem tartozik fiók vagy szerver, az alapfolyamat gyakran egyszerűbbé válik. Nincs bejelentkezés, elfelejtett jelszó vagy szinkronizálási szolgáltatás miatti kiesés. A személyes adatokat a szokásos használathoz nem kell továbbítani a szolgáltatónak. Ez jól illeszkedhet az egyetlen felhasználó által elvárt bizalmi modellhez.
Az offline elérhetőség azonnali. Az információ pincében, gyenge térerővel rendelkező épületben vagy utazás közben is hozzáférhető marad. A változtatások a távoli állapot előzetes lekérdezése nélkül menthetők. Az alkalmazás válaszideje nem függ egy szolgáltatás késleltetésétől.
Az üzemeltetés is kezelhetőbb lehet. Központi felhasználói adatbázis nélkül elmaradnak bizonyos szerverköltségek, fiókfolyamatok és folyamatos szinkronizálási problémák. A kevesebb infrastruktúra azonban nem jelent felelősség nélküli működést: továbbra is szükség van kiadásra, áruházi kapcsolatokra, weboldalra, támogatásra és termékkarbantartásra. Emellett a helyi tárolást, a migrációt, a fájlkezelést és a helyreállítást is gondosan kell megvalósítani.
A helyi tárolás legnagyobb erőssége egyben a korlátja is
Egyetlen eszköz elsődleges tárolóként való használata egyértelmű helyzetet teremt, ugyanakkor egyetlen hibapontot is jelent. Ha az okostelefon elveszik vagy megsérül, illetve az alkalmazást megfelelő mentés nélkül törlik, az egyetlen adatpéldány eltűnhet. Az új eszközön való folytatáshoz ezért előre megtervezett exportálási és helyreállítási lehetőség kell.
A biztonsági mentés ezért nem választható másodlagos funkció egy helyi tárolású termékben. Érthető módon kell elkészíteni, az alkalmazáson kívül tárolni, majd később megbízhatóan visszaolvasni. A kizárólag az alkalmazás privát területén tárolt fájl nem véd sem az alkalmazás eltávolítása, sem az eszköz elvesztése ellen. A titkosítás megvédheti az érzékeny exportokat, de növeli a felelősséget: központi helyreállítási szolgáltatás nélkül előfordulhat, hogy az elveszett jelszó nem pótolható.
Az operációs rendszer biztonsági mentéseit is külön kell értékelni. Az Apple leírja, hogy bizonyos alkalmazáskönyvtárak a fájlok típusától függően az eszköz vagy az iCloud biztonsági mentéseibe is bekerülhetnek. A terméknek tudatosan kell eldöntenie, mely adatok tartósan fontosak, helyreállíthatók vagy csak ideiglenesek. A felhasználók számára azonban világosnak kell maradnia, hogy maga az alkalmazás kínál-e hordozható biztonsági másolatot, és mire számíthatnak eszközcsere során.
A felhőrendszerek lehetővé teszik az együttműködést és a folyamatosságot
Amint több embernek ugyanarra a jelenlegi állapotra van szüksége, a központi infrastruktúra erős előnyhöz jut. A csapatok megoszthatnak feladatokat, szerepeket oszthatnak ki, és egyesíthetik a különböző eszközökről származó változtatásokat. Egy új eszközre nem kell kézzel fájlt átvinni. Bejelentkezés után a meglévő állapot újratölthető.
A felhőszolgáltatások központi automatizálásra is alkalmasak. A kiszolgáló háttérfolyamatokat futtathat, közös értesítéseket küldhet, más rendszerekkel kapcsolhat össze adatokat, és szabályokat alkalmazhat attól függetlenül, hogy egy adott okostelefon aktív-e. Ez gyakran elengedhetetlen a foglalási portálokhoz, a csapatmunkához vagy a vállalati szintű kimutatásokhoz.
A biztonsági mentés és a helyreállítás az egyes felhasználók számára is könnyebb lehet. A több szerverpéldány, a verzióelőzmények és a felügyelt mentések csökkentik annak kockázatát, hogy minden egyetlen eszközön legyen. Ez azonban az adott szolgáltatás képessége, nem a „felhő” szó automatikus ígérete. A tárhelynek, a helyreállítási teszteknek, a törlési szabályoknak és a vészhelyzeti folyamatoknak ténylegesen létezniük kell.
A szinkronizálás önmagában is termékprobléma
A helyi másolással és felhőszinkronizálással rendelkező alkalmazás ideálisan gyors offline használatot és több eszközön keresztüli folyamatosságot kínál. Ez felvet egy nehéz kérdést: Mi történik, ha két eszköz egymástól függetlenül módosítja ugyanazt a rekordot?
Egyes ütközések időbélyegek alapján feloldhatók. Más esetekben a „legutóbbi módosítás nyer” szabály értékes információkat írhat felül. A listák elemei esetleg összevonhatók, míg hosszabb szövegeknél látható ütközésfeloldásra lehet szükség. A fájlokhoz feltöltési állapot, megszakítás utáni újrapróbálkozás és törlési szabályok kellenek. A terméknek azt is jeleznie kell, hogy egy állapot csak helyben van-e tárolva, már szinkronizálódott-e, vagy hibás.
Az Android offline-first útmutatója többek között ismerteti a helyi és hálózati adatforrásokat, a szinkronizálási sorokat, valamint az olvasási és írási stratégiákat. Ez számos teszthelyzetet jelent: repülő üzemmódot, instabil kapcsolatot, megszakadt folyamatot, kettős beküldést, régebbi alkalmazásverziókat és párhuzamosan módosított adatokat.
A szinkronizálást ezért nem szabad egyetlen kapcsolóként kezelni. A szakterületi logika és a felület állandó része. Ha a tényleges haszonhoz nincs rá szükség, elhagyása jóval robusztusabbá teheti a terméket. Ha viszont az együttműködés központi szerepű, a szinkronizálás mellőzése nem tudatos fókusz, hanem hibás korlátozás lenne.
Az adatvédelem a teljes adatúttól függ
A helyi tárolás csökkentheti az adatátvitelt és a központi adatgyűjtést. Így az adatminimalizálás hatékony formája lehet, ha a feladat szerver nélkül is elvégezhető. Az eszköz védelme, az alkalmazás elkülönített tárhelye, a helyi titkosítás, az engedélyek, a naplók, az exportálás és a biztonsági mentések azonban továbbra is fontosak. Egy megosztott helyen tárolt, védelem nélküli exportarchívum gyorsan semmissé teheti a privát alkalmazástárhely előnyeit.
Felhőtermékeknél további szereplők és kérdések jelennek meg: milyen adatok hagyják el az eszközt? Melyik régióban dolgozzák fel őket? Ki üzemelteti az infrastruktúrát és a támogatást? Hogyan védik, naplózzák és vonják vissza a hozzáféréseket? Mennyi ideig maradnak meg a biztonsági másolatok a törlés után? Milyen adatok szükségesek az elemzésekhez, értesítésekhez vagy modellel támogatott szolgáltatásokhoz?
A felhő nem jelent automatikusan széles körű megosztást. Egy jól megtervezett platform minimálisra csökkentheti az adatokat, titkosíthatja őket, szigorúan elkülönítheti a hozzáféréseket, és átlátható törlési folyamatokat kínálhat. A helyi tárolás sem jelenti automatikusan, hogy az adatokat a felhasználón kívül senki nem láthatja; az operációs rendszer, az eszközmentések, a megosztott fájlok vagy egy feltört eszköz mind megváltoztatják a helyzetet. Az adatvédelmet a konkrét architektúra és az üzemeltetési gyakorlat teremti meg.
A méretezés többet érint, mint a felhasználói számokat
A felhőarchitektúrákat gyakran skálázhatóságra tervezik. Egy központi szolgáltatás további felhasználókat, eszközöket vagy adatmennyiséget fogadhat, ha az adatbázist, a tárhelyet és az üzemeltetést erre méretezték. Ez folyamatos költségekkel, felügyelettel, kapacitástervezéssel és biztonsági felelősséggel jár. Az alacsony használat kevesebbe kerülhet, míg az intenzív használat vagy a nagy fájlok megváltoztathatják az üzleti modellt.
A helyi alkalmazások az eszközök között osztják el a tárhelyet és a számítási feladatokat. A szolgáltató nem fizet felhőtárhelyet minden személyes fájl után. Másfelől az eszközök teljesítménye és szabad tárhelye eltérő. A nagy képgyűjtemények, az összetett helyi modellek vagy a hosszú migrációk megterhelhetik a régebbi okostelefonokat. A támogatásnak olyan állapotokat is kezelnie kell, amelyek központilag nem tekinthetők meg és nem javíthatók.
A méretezés a felhasználási területtől is függ. Egy tíz ingatlant kezelő terméknek lehet, hogy csak jobb szűrőkre és nagyobb helyi adatbázisra van szüksége. Egy tíz szakember által használt termékhez viszont szerepkörök, ütközéskezelési szabályok és nyomon követhetőség kellenek. A rekordok száma önmagában nem dönti el, mikor van szükség felhőre.
A Propivio a tudatos helyi megközelítés példája
A Propivio egyetlen személy számára készült, aki okostelefonon kezeli néhány saját ingatlanának adatait. Nincs felhasználói fiók, megosztott szerkesztés vagy automatikus alkalmazásfelhő. A dokumentumok, fényképek, névjegyek, mérőállások és egyéb szakterületi adatok helyben, az alkalmazás elkülönített tárhelyén találhatók.
Ebben a helyzetben a megközelítés csökkenti a fiókok és a szinkronizálás szükségtelen bonyolultságát. A következmény nyíltan vállalt: külső biztonsági mentési és helyreállítási folyamatra van szükség, és több eszköz nem osztozik automatikusan szinkronizált állapoton. Ez a termékmodell tudatosan nem csapatmunkára, nagy portfóliók központi kezelésére vagy külső portálok összekapcsolására készült.
Egy másik Zappapps-termék másként dönthet. Ha a termék együttműködéstől, központosított automatizálástól vagy megosztott hozzáféréstől függ, a felhőarchitektúra a nagyobb összetettség ellenére is indokolt lehet. A márka következetessége nem követeli meg, hogy minden alkalmazás műszakilag azonos legyen; azt követeli meg, hogy minden döntés érthető magyarázatot kapjon.
Döntési mátrix hitvita helyett
Az architektúra kiválasztása előtt konkrét kérdések segítenek:
- Egy ember egyedül dolgozik, vagy több szerepnek is ugyanazt a jelenlegi állapotot kell látnia?
- Az alapfolyamatnak teljesen hálózat nélkül kell működnie?
- Mennyire lenne súlyos a készülék elvesztése?
- Ki a felelős a biztonsági mentésért és helyreállításért?
- A több eszközről való hozzáférés központi előny vagy alkalmi kényelem?
- Mely adatok érzékenyek, és mely adatátvitelekre van valóban szükség?
- Szüksége van-e a terméknek háttérfolyamatokra vagy integrációkra, ha nincs aktív eszköz?
- Mely üzemeltetési, támogatási és infrastrukturális költségek fenntarthatóak?
- Hogyan oldják meg az exportálást, törlést, migrációt és egy esetleges szolgáltatóváltást?
A válaszok helyi, felhőalapú vagy hibrid, offline-first megoldáshoz vezethetnek. A termékkel együtt változhatnak. A későbbi váltás azonban költséges, mert érinti az adatok azonosságát, az ütközéskezelést és a bizalmat. Ezért az első döntést nem szabad pusztán egy előnyben részesített technológiára alapozni.
A megfelelő architektúra láthatóvá teszi a következményeit
Az embereknek nem kell érteniük az elosztott rendszereket, de tudniuk kell, mit jelent az architektúra a mindennapokban: működik-e az alkalmazás hálózat nélkül, elérhetők-e az adatok más eszközökön, hogyan készül mentés, és mi hagyja el a telefont?
A helyi és a felhős megoldás nem minőségi szint. Másképp osztják el a képességeket, kockázatokat és felelősséget. A jobb választás illik a tényleges célhoz, és a következményeit mind a műszaki megvalósításban, mind a termék nyelvezetében érthetővé teszi.
Források és további olvasnivalók
- NIST: Definition of Cloud Computing – a felhőalapú számítástechnika hivatalos terminológiája.
- Android Developers: Offline-first alkalmazás készítése – helyi adatforrások, szinkronizálás, valamint olvasási és írási stratégiák.
- Android Fejlesztők: Útmutató az alkalmazásarchitektúrához – adatmodellek, az igazság egyetlen forrása és egyértelmű felelősségi határok.
- Apple Fejlesztő: A fájlrendszer hatékony használata – alkalmazáskönyvtárak, állandó adatok és biztonsági mentési viselkedés.
- Apple Fejlesztő: Az alkalmazás adatainak optimalizálása az iCloud biztonsági mentéshez – a tartós és helyreállítható fájlok szándékos osztályozása.
