Изборът между локално съхранение и облак изглежда технически, но започва от начина на употреба. Личен списък на един смартфон има различни изисквания от план, редактиран едновременно от няколко души. И двете архитектури могат да бъдат надеждни и да станат излишно сложни, ако не съответстват на сценария.
„Локално означава поверително“ е също толкова непълно, колкото „облак означава модерно“. Локалните данни могат да изчезнат заедно с устройството. Облакът може да улесни сътрудничеството и възстановяването, но изисква акаунти, инфраструктура и разбираеми потоци от данни.
Накратко
- Изборът между локално съхранение и облак е продуктово решение, а не класация за качество.
- Локалният подход подпомага офлайн работата, но изисква надеждни резервни копия.
- Облакът улеснява споделената работа, но добавя акаунти, синхронизация и постоянна експлоатация.
Какво всъщност означават „локално“ и „в облака“
При локално приложение основното копие на данните се съхранява на устройството. В много случаи основният процес работи без мрежа и без сървър. Това не изключва участието на услуги на операционната система при разпространение, архивиране на устройството или споделяне на експортиран файл. „Локално“ означава само, че доставчикът не поддържа централна база данни за тези потребителски данни.
Съгласно дефиницията на NIST облачните изчисления осигуряват мрежов достъп при поискване до общ набор от конфигурируеми ресурси. За едно приложение това може да включва бази данни, файлово хранилище, услуги за идентичност и изчислителна мощност. Централното копие обикновено се намира в отдалечена инфраструктура, а устройствата зареждат данни, изпращат промени и съгласуват състоянията.
Много продукти използват хибриден подход: пазят данни на устройството, за да остане интерфейсът бърз и използваем офлайн, и ги синхронизират във фонов режим със сървър. Android Developers нарича „offline-first“ архитектура тази, при която локалният източник е основата за четене, а достъпът до мрежата обновява това копие. Облакът не изчезва, а се допълва с локален слой и правила за синхронизация.
Локалното съхранение намалява зависимостите
Ако дадено приложение не изисква акаунт или сървър, основният му процес често се опростява. Няма влизане в акаунт, забравена парола или прекъсване на услугата за синхронизация. За нормална употреба не е необходимо личните данни да се прехвърлят на доставчика. Това може да съответства много добре на очаквания модел на доверие за един човек.
Офлайн достъпът е непосредствен. Информацията остава достъпна в мазето, в сграда със слаб сигнал или по време на пътуване. Промените могат да бъдат запазени, без първо да се прави заявка към отдалечено състояние. Бързодействието на приложението не зависи от забавянето на външна услуга.
Експлоатацията също може да бъде по-управляема. Без централна потребителска база данни отпадат определени разходи за сървър, процеси по управление на акаунти и постоянни проблеми със синхронизацията. По-малко инфраструктура обаче не означава липса на инфраструктура или отговорност: публикуването, връзките към магазините, уебсайтът, обслужването на потребителите и поддръжката на продукта остават. Локалното съхранение, миграциите, управлението на файлове и възстановяването също трябва да бъдат реализирани внимателно.
Най-голямото предимство на локалното съхранение е и неговото ограничение
Използването на едно устройство като основно хранилище създава яснота, но и единствена точка на отказ. Ако смартфонът бъде изгубен или повреден, или ако приложението бъде изтрито без подходящо резервно копие, единственото копие на данните може да изчезне. За продължаване на работата на ново устройство е нужен предварително планиран начин за експортиране и възстановяване.
Затова резервните копия не са незадължителна второстепенна функция на продуктите с локално съхранение. Те трябва да се създават по разбираем начин, да се пазят извън приложението и по-късно да могат да се възстановяват надеждно. Файл, съхраняван само в частната зона на приложението, не предпазва от деинсталиране или загуба на устройството. Шифроването може да защити чувствителни експортирани данни, но увеличава отговорността: изгубена парола може да не подлежи на възстановяване без централна услуга.
Резервните копия на операционната система също заслужават внимателно разглеждане. Apple обяснява, че според типа на файла определени директории на приложението могат да бъдат включени в резервно копие на устройството или в iCloud. Продуктът трябва съзнателно да реши кои данни са трайно важни, възстановими или само временни. За потребителите обаче трябва да е ясно дали самото приложение предлага преносимо резервно копие и на какво могат да разчитат при смяна на устройството.
Облачните системи позволяват сътрудничество и непрекъснатост
Когато няколко души се нуждаят от едно и също актуално състояние, централната инфраструктура има ясно предимство. Екипът може да споделя задачи, да присвоява роли и да обединява промени от различни устройства. На нов компютър не се налага файлът да се прехвърля ръчно; след влизане актуалното състояние може да бъде заредено отново.
Облачните услуги са подходящи и за централна автоматизация. Сървърът може да изпълнява фонови процеси, да разпространява споделени известия, да интегрира данни с други системи и да прилага правила, независимо дали даден смартфон е активен. Това често е от съществено значение за портали за резервации, управление на екипи или оценки в цялата компания.
Архивирането и възстановяването могат да бъдат по-лесни и за отделния потребител. Резервните сървърни копия, историята на версиите и управляваните архиви намаляват риска всичко да се пази на едно устройство. Това обаче е възможност на конкретната услуга, а не автоматично следствие от думата „облак“. Съхранението, тестовете за възстановяване, правилата за изтриване и аварийните процеси трябва действително да са реализирани.
Синхронизирането е самостоятелен продуктов проблем
Приложение с локално копие и облачна синхронизация в идеалния случай предлага бързо офлайн използване и непрекъснатост на различни устройства. Това повдига труден въпрос: Какво се случва, когато две устройства променят един и същ запис независимо?
Някои конфликти могат да се решат чрез времеви отметки. При други правилото „последната версия печели“ би заличило ценна информация. Списъците могат да обединяват елементи, докато дългите текстове може да изискват видимо разрешаване на конфликта. Файловете се нуждаят от състояние на качване, повторни опити след прекъсване и правила за изтриване. Продуктът трябва да показва и дали дадено състояние е само локално, вече е синхронизирано или съдържа грешка.
Ръководството на Android за архитектура с приоритет на офлайн режима описва, наред с друго, локални и мрежови източници на данни, опашки за синхронизация и стратегии за четене и запис. Това изисква значителен набор от тестове: самолетен режим, нестабилни връзки, прекъснати процеси, двойно изпращане, по-стари версии на приложението и данни, променени успоредно на няколко места.
Следователно синхронизирането не трябва да се планира като обикновен превключвател. То е постоянен компонент на предметната логика и интерфейса. Ако не е необходимо за реалната полза, изключването му може да направи продукта значително по-устойчив. Ако обаче сътрудничеството е в основата на продукта, премахването му не би било фокус, а погрешно ограничение.
Защитата на данните зависи от пълния път на данните
Локалното съхранение може да избегне прехвърлянето и централизираното натрупване на данни. Ако задачата може да се изпълни без сървър, това е ефективна форма на минимизиране на данните. Въпреки това устройството, изолираната зона на приложението, локалното криптиране, разрешенията, журналите, експортираните файлове и резервните копия трябва да бъдат защитени. Незащитен експортиран архив в споделено местоположение може бързо да обезсмисли предимството на частното хранилище на приложението.
При облачните продукти се появяват допълнителни участници и въпроси: Какви данни напускат устройството? В кой регион се обработват? Кой управлява инфраструктурата и поддръжката? Как се защитават, регистрират и отнемат правата за достъп? Колко време се пазят резервните копия след изтриването? Какви данни са необходими за анализи, известия или услуги, подпомагани от модел?
Облакът не означава автоматично широко споделяне. Една добре проектирана платформа може да минимизира данните, да шифрова, да разделя строго достъпа и да предлага прозрачни процеси на изтриване. От своя страна локалното съхранение не означава автоматично, че никой не може да вижда данни освен потребителя; операционната система, резервните копия на устройствата, споделените файлове или компрометираните устройства променят картината. Защитата на данните се създава от конкретна архитектура и оперативна практика.
Мащабирането засяга повече от броя на потребителите
Облачните архитектури често се проектират с оглед на мащабирането. Централната услуга може да поеме допълнителни потребители, устройства или обеми от данни, ако базата данни, хранилището и експлоатацията са планирани за това. Оттук произтичат постоянни разходи, наблюдение, планиране на капацитета и отговорност за сигурността. Слабото използване може да струва малко, а интензивното използване или големите файлове могат да променят бизнес модела.
Локалните приложения разпределят съхранението и изчисленията между устройствата. Доставчикът не плаща облачно хранилище за всеки личен файл. За сметка на това устройствата се различават по производителност и свободно място. Големи колекции от изображения, сложни локални модели или продължителни миграции могат да натоварят по-старите смартфони. Поддръжката трябва да се справя със състояния, които не могат да бъдат прегледани или поправени централно.
Мащабирането може също да бъде специфично за домейна. Един продукт за десет имота може да се нуждае само от по-добри филтри и по-голяма локална база данни. Продукт за десет професионалисти се нуждае от роли, конфликтни правила и възможност за проследяване. Броят на записите сам по себе си не решава кога е необходим облак.
Propivio като пример за съзнателно локален подход
Propivio е предназначен за един човек, който управлява на смартфон информация за няколко собствени имота. Няма потребителски акаунт, споделено редактиране или автоматична облачна услуга на приложението. Документите, снимките, контактите, показанията на измервателните уреди и останалите специализирани данни се пазят локално в защитената зона на приложението.
За този сценарий подходът намалява ненужната сложност на акаунтите и синхронизацията. Последицата е заявена открито: необходимо е външно архивиране с надеждно възстановяване, а няколко устройства не споделят автоматично синхронизирано състояние. Този продуктов модел съзнателно не е предназначен за екипна работа, централизирано управление на големи портфейли или свързване с външни портали.
Друг продукт на Zappapps може да стигне до различно решение. Когато продуктът зависи от сътрудничество, централизирана автоматизация или споделен достъп, облачната архитектура може да бъде обоснована въпреки по-голямата сложност. Последователността на марката не изисква всяко приложение да бъде изградено технически по един и същ начин. Тя изисква всяко решение да бъде обяснено разбираемо.
Матрица за вземане на решения вместо въпрос на вяра
Преди да изберете архитектура, конкретни въпроси помагат:
- Един човек ли работи сам или няколко роли трябва да виждат едно и също текущо състояние?
- Трябва ли основният процес да работи напълно без мрежа?
- Колко сериозна би била загубата на устройството?
- Кой отговаря за архивирането и възстановяването?
- Достъпът между устройства ключово предимство ли е или рядко използвано удобство?
- Кои данни са чувствителни и кое прехвърляне е действително необходимо?
- Продуктът има ли нужда от фонови процеси или интеграции, ако няма активно устройство?
- Кои разходи за експлоатация, поддръжка и инфраструктура са устойчиви?
- Как се решават експортирането, изтриването, миграцията и евентуалната смяна на доставчика?
Отговорите могат да насочат към локално, облачно или хибридно решение с приоритет на офлайн работата. Те могат да се променят с развитието на продукта. По-късната смяна обаче е трудна, защото засяга идентичността на данните, разрешаването на конфликти и доверието. Затова първото решение не бива да се основава единствено на предпочитана технология.
Правилната архитектура прави своите последствия видими
Хората не е нужно да разбират разпределени системи, но трябва да знаят какво означава архитектурата в ежедневието: работи ли приложението без мрежа, има ли данни на други устройства, как се прави резервно копие и какво напуска телефона?
Локалното съхранение и облакът не са нива на качество. Те разпределят различно възможностите, рисковете и отговорността. По-добрият избор съответства на реалната цел и прави последствията ясни както в технологията, така и в езика на продукта.
Източници и допълнителна литература
- NIST: Определение за облачни изчисления – официалната терминология за облачни изчисления.
- Android Developers: Създаване на приложение с приоритет на офлайн режима – локални източници на данни, синхронизация и стратегии за четене и запис.
- Android Разработчици: Ръководство за архитектура на приложения – модели на данни, един източник на истина и ясни граници на отговорност.
- Apple Разработчик: Ефективно използване на файловата система – директории на приложения, постоянни данни и поведение при архивиране.
- Apple Разработчик: Оптимизиране на данните на вашето приложение за архивиране в iCloud – умишлено класифициране на постоянни и възстановими файлове.
