Volba mezi lokálním úložištěm a cloudem působí technicky, ale začíná způsobem používání produktu. Osobní seznam v jednom telefonu má jiné nároky než plán, který současně upravuje několik lidí. Obě architektury mohou být spolehlivé a obě zbytečně složité, pokud neodpovídají scénáři.
„Lokální znamená soukromé“ je stejně neúplné jako „cloud znamená moderní“. Lokální data mohou zmizet se zařízením. Cloud může usnadnit spolupráci a obnovu, ale vyžaduje účty, infrastrukturu a srozumitelný tok dat.
Stručně
- Lokální úložiště versus cloud je produktové rozhodnutí, ne žebříček kvality.
- Lokální přístup podporuje práci offline, ale vyžaduje spolehlivé zálohy.
- Cloud umožňuje sdílený stav, zároveň však přidává účty, synchronizaci a provoz.
Co vlastně znamenají „lokální“ a „cloudové“
U lokální aplikace je hlavní kopie dat uložena v zařízení. Základní proces může v mnoha případech fungovat bez sítě a serveru. Služby operačního systému se přesto mohou podílet na distribuci, zálohování zařízení nebo sdílení exportovaného souboru. „Lokální“ pouze znamená, že poskytovatel pro tato uživatelská data neprovozuje centrální databázi aplikace.
Podle definice NIST označuje cloud computing síťový přístup na vyžádání ke sdílenému fondu konfigurovatelných prostředků. U aplikace může jít o databáze, úložiště souborů, služby identity i výpočetní výkon. Centrální kopie pak obvykle leží ve vzdálené infrastruktuře; zařízení načítají data, odesílají změny a sjednocují stav.
Mnoho produktů využívá hybridní přístup. Ukládají data v zařízení, aby rozhraní zůstalo rychlé a použitelné offline, a na pozadí je synchronizují se serverem. Dokumentace Android Developers označuje tento přístup za architekturu „offline-first“, v níž je lokální zdroj dat hlavním podkladem pro čtení a síťové požadavky tuto kopii aktualizují. Cloud tedy nezmizí; doplní jej další lokální vrstva a pravidla synchronizace.
Lokální úložiště snižuje závislosti
Pokud aplikace nemá účet nebo server, její základní cesta se často zjednoduší. Neexistuje žádné přihlášení, žádné zapomenuté heslo a žádné přerušení synchronizační služby. Osobní údaje není nutné pro běžné použití předávat poskytovateli. To může velmi dobře odpovídat očekávanému modelu důvěry pro jednu osobu.
Offline dostupnost je okamžitá. Informace zůstávají dostupné v suterénu, v budově se špatným příjmem nebo při cestování. Změny lze uložit bez předchozího dotazování na vzdálený stav. Odezva aplikace nezávisí na latenci služby.
Také provoz může být přehlednější. Bez centrální databáze uživatelů odpadají některé náklady na server, procesy spojené s účty a průběžné problémy se synchronizací. Méně infrastruktury však neznamená žádnou infrastrukturu ani odpovědnost: zůstává vydávání aplikace, napojení na obchody, web, podpora a údržba produktu. Pečlivě je nutné řešit také lokální úložiště, migrace, práci se soubory a obnovu.
Největší výhoda lokálního úložiště je zároveň jeho omezením
Použití jednoho zařízení jako primárního úložiště vytváří přehlednost – ale také jediný bod selhání. Pokud se smartphone ztratí, poškodí nebo je aplikace bez řádné zálohy odinstalována, může zmizet jediná kopie dat. K pokračování na novém zařízení je proto nutná předem připravená možnost exportu a obnovy.
Zálohy proto nejsou volitelnou vedlejší funkcí produktů s lokálním úložištěm. Musí se vytvářet srozumitelně, ukládat mimo aplikaci a později spolehlivě obnovovat. Soubor uložený pouze v soukromé oblasti aplikace nechrání před odinstalací ani ztrátou zařízení. Šifrování může chránit citlivé exporty, ale zvyšuje odpovědnost: bez centrální služby pro obnovu nemusí být možné ztracené heslo nahradit.
Odlišný pohled si zaslouží i zálohy operačního systému. Apple popisuje, že určité adresáře aplikací mohou být zahrnuty do záloh zařízení nebo iCloudu v závislosti na typu souborů. Produkt se musí vědomě rozhodnout, která data jsou trvale důležitá, obnovitelná nebo pouze dočasná. Uživatelům by však mělo zůstat jasné, zda samotná aplikace nabízí přenosnou zálohu a na co se mohou při změně zařízení spolehnout.
Cloudové systémy umožňují spolupráci a kontinuitu
Jakmile několik lidí potřebuje stejný aktuální stav, centrální infrastruktura získává silnou výhodu. Tým může sdílet úkoly, přidělovat role a slučovat změny z různých zařízení. Na nové zařízení není nutné ručně přenášet soubor. Po přihlášení lze stávající stav znovu načíst.
Cloudové služby jsou vhodné i pro centrální automatizaci. Server může spouštět procesy na pozadí, distribuovat sdílená oznámení, integrovat data s jinými systémy a aplikovat pravidla bez ohledu na to, zda je konkrétní smartphone aktivní. To je často nezbytné pro rezervační portály, vedení týmu nebo celofiremní hodnocení.
Zálohování a obnova mohou být také jednodušší pro jednotlivé uživatele. Redundantní kopie serveru, historie verzí a spravované zálohy snižují riziko, že jediné zařízení bude obsahovat vše. Tato možnost je však vlastností konkrétní služby, nikoli automatickou vlastností čehokoli označovaného jako cloud. Úložiště, testy obnovy, pravidla mazání a nouzové procesy musí být skutečně přítomny.
Synchronizace je sama o sobě produktový problém
Aplikace s lokálním kopírováním a cloudovou synchronizací ideálně nabízí rychlé offline použití a kontinuitu mezi zařízeními. To vyvolává obtížnou otázku: Co se stane, když dvě zařízení nezávisle upraví stejný záznam?
Některé konflikty lze vyřešit podle časových razítek. U jiných by pravidlo „vyhrává nejnovější verze“ přepsalo cenné informace. Seznamy mohou slučovat položky, zatímco dlouhé texty mohou vyžadovat viditelné řešení konfliktu. Soubory potřebují stav nahrávání, opakované pokusy po přerušení a pravidla mazání. Produkt musí také ukázat, zda je stav uložen pouze lokálně, již synchronizován, nebo skončil chybou.
Průvodce Android Developers architekturou s prioritou offline režimu popisuje mimo jiné lokální a síťové zdroje dat, synchronizační fronty a strategie čtení a zápisu. Takové řešení vyžaduje rozsáhlé testování: režim Letadlo, nestabilní připojení, přerušení procesů, duplicitní odeslání, starší verze aplikace a souběžně změněná data.
Synchronizaci proto nelze plánovat jako jediný přepínač. Je trvalou součástí doménové logiky i rozhraní. Pokud není pro skutečný přínos produktu potřebná, její vynechání může produkt výrazně zjednodušit a posílit. Jestliže je však spolupráce klíčová, její odstranění by nebylo projevem soustředěného rozsahu, ale chybným omezením.
Ochrana dat závisí na úplné datové cestě
Lokální úložiště může omezit přenosy i centrální shromažďování dat. Jde proto o účinnou formu minimalizace dat, pokud lze úkol splnit bez serveru. Nadále však záleží na ochraně zařízení, sandboxu aplikace, lokálním šifrování, oprávněních, protokolech, exportech a zálohách. Nechráněný exportovaný archiv ve sdíleném umístění může výhodu soukromé oblasti aplikace rychle znehodnotit.
U cloudových produktů vstupují do hry další subjekty a otázky: Jaká data opouštějí zařízení? V jakém regionu se zpracovávají? Kdo provozuje infrastrukturu a podporu? Jak se přístupy zabezpečují, protokolují a odvolávají? Jak dlouho po smazání zůstávají zálohy? Jaká data jsou nutná pro analýzy, oznámení nebo služby podporované modelem?
Cloud automaticky neznamená široké sdílení. Dobře navržená platforma dokáže minimalizovat data, používat šifrování, důsledně oddělit přístupy a nabídnout transparentní procesy mazání. Ani lokální uložení automaticky neznamená, že data vidí pouze uživatel; situaci mění operační systém, zálohy zařízení, sdílené soubory i napadené zařízení. Ochranu dat vytváří konkrétní architektura a provozní praxe.
Změna měřítka ovlivňuje více než jen počty uživatelů
Cloudové architektury se často navrhují s ohledem na škálování. Centrální služba může obsloužit další uživatele, zařízení nebo objemy dat, pokud jsou na to dimenzovány databáze, úložiště i provoz. S tím souvisejí průběžné náklady, monitorování, plánování kapacity a odpovědnost za zabezpečení. Nízké využití může stát málo, zatímco intenzivní provoz nebo velké soubory mohou změnit obchodní model.
Lokální aplikace rozdělují úložiště a výpočty mezi jednotlivá zařízení. Poskytovatel neplatí cloudové úložiště za každý osobní soubor. Na druhou stranu se zařízení liší výkonem a dostupným místem. Velké sady obrázků, náročné lokální modely nebo dlouhé migrace mohou zatěžovat starší smartphony. Podpora se navíc musí vypořádat se stavy, které nelze centrálně zobrazit ani opravit.
Škálování může být také specifické pro doménu. Produkt pro deset nemovitostí může potřebovat pouze lepší filtry a větší lokální databázi. Produkt pro deset profesionálů potřebuje role, pravidla pro řešení konfliktů a sledovatelnost. Počet záznamů sám o sobě nerozhoduje, kdy je cloud vyžadován.
Propivio jako příklad vědomě lokálního přístupu
Propivio je určeno jednomu člověku, který na telefonu spravuje informace o několika vlastních nemovitostech. Nemá uživatelský účet, sdílené úpravy ani automatický aplikační cloud. Dokumenty, fotografie, kontakty, odečty měřidel a další oborová data zůstávají lokálně v chráněném prostoru aplikace.
V tomto scénáři přístup snižuje zbytečnou složitost účtů a synchronizace. Důsledek je uveden otevřeně: nezbytný je externí postup zálohování a obnovy a více zařízení nesdílí automaticky synchronizovaný stav. Produktový model vědomě není určen pro týmovou práci, centrální správu velkých portfolií ani propojování s externími portály.
Jiný produkt Zappapps se může rozhodnout odlišně. Jakmile závisí na spolupráci, centralizované automatizaci nebo sdíleném přístupu, může být cloudová architektura navzdory vyšší složitosti přiměřená. Jednotná značka nevyžaduje, aby každá aplikace používala stejnou techniku; vyžaduje srozumitelné vysvětlení každého rozhodnutí.
Rozhodovací matice místo otázky přesvědčení
Před výběrem architektury vám pomohou konkrétní otázky:
- Pracuje jedna osoba sama nebo musí více rolí vidět stejný současný stav?
- Musí základní proces fungovat zcela bez sítě?
- Jak vážná by byla ztráta zařízení?
- Kdo je zodpovědný za zálohování a obnovu?
- Je přístup z více zařízení hlavním přínosem, nebo jen příležitostnou výhodou?
- Která data jsou citlivá a které přenosy jsou skutečně nezbytné?
- Potřebuje produkt procesy nebo integrace na pozadí, pokud není aktivní žádné zařízení?
- Které náklady na provoz, podporu a infrastrukturu jsou udržitelné?
- Jak jsou řešeny exporty, mazání, migrace a případná změna poskytovatele?
Odpovědi mohou vést k lokálnímu, cloudovému nebo hybridnímu řešení s přístupem offline-first. S vývojem produktu se mohou měnit. Pozdější přechod je však nákladný, protože zasahuje do identity dat, řešení konfliktů i důvěry. První rozhodnutí by proto nemělo vycházet jen z oblíbené technologie.
Správná architektura zviditelní své důsledky
Lidé nemusí rozumět distribuovaným systémům, měli by ale vědět, co architektura znamená v praxi: funguje aplikace bez sítě, jsou data na jiných zařízeních, jak vzniká záloha a který obsah opouští telefon?
Lokální řešení a cloud nejsou stupně kvality. Jinak rozdělují schopnosti, rizika a odpovědnost. Lepší volba odpovídá skutečnému účelu a jasně ukazuje své důsledky jak v technologii, tak v jazyce produktu.
Zdroje a další čtení
- NIST: Definice cloud computingu – oficiální terminologie pro cloud computing.
- Android Developers: Vytvoření aplikace s prioritou offline režimu – lokální zdroje dat, synchronizace a strategie čtení a zápisu.
- Android Vývojáři: Průvodce architekturou aplikací – datové modely, jediný zdroj pravdy a jasné hranice odpovědnosti.
- Apple Developer: Efektivní používání systému souborů – adresáře aplikací, trvalá data a chování při zálohování.
- Apple Developer: Optimalizace dat vaší aplikace pro zálohování na iCloud – záměrná klasifikace trvalých a obnovitelných souborů.
