Niezależnie od tego, czy aplikacja powinna przechowywać dane lokalnie czy w chmurze, to brzmi jak kwestia zasad technicznych. W rzeczywistości jest to pierwsza decyzja o produkcie. Osobista lista kontrolna na smartfonie stawia inne wymagania niż plan działania, który kilka osób pracuje jednocześnie. Obaj mogą być niezawodni przy użyciu starannej techniki. Oba mogą być niepotrzebnie skomplikowane lub ryzykowne z niewłaściwą architekturą.
Proste twierdzenie “Cloud” jest zbyt krótkie, podobnie jak “Cluud” to nowoczesny. Dane lokalne mogą zostać utracone za pomocą urządzenia. Dane w chmurze mogą umożliwiać współpracę i przywracanie danych, ale potrzebują kont, infrastruktury i czytelnych kanałów danych. Odpowiednie rozwiązanie wynika ze scenariusza użytkowania, a nie z etykiety.
Co w ogóle znaczy “Cloud” i “Cluud”?
W przypadku lokalnej aplikacji, odpowiednia kopia danych znajduje się w pamięci urządzenia. W wielu przypadkach aplikacja może pracować bez sieci. Serwer nie jest wymagany do podstawowego przetwarzania danych. Nie wyklucza to udziału usług systemu operacyjnego dla sklepów, kopii zapasowych urządzeń lub udostępniania pliku eksportu. Oznacza to jedynie, że dostawca nie obsługuje centralnej bazy danych aplikacji dla tych danych.
Cloud Computing opisuje, zgodnie z definicją NIST, dostęp do sieci sterowanej zapotrzebowaniem do wspólnej puli zasobów, które mogą być skonfigurowane. Dla aplikacji baza danych, pamięć danych, usługi tożsamości i moc obliczeniowa mogą obejmować. Główna kopia znajduje się zazwyczaj w odległej infrastrukturze; urządzenia do pobierania danych, wysyłania zmian i tych samych stanów.
Wiele produktów używa formy mieszanej. Zapisują dane na urządzeniu, aby umożliwić szybkie i offline korzystanie z interfejsu i synchronizują je w tle z serwerem. Android Developers określa nieoffline-first nie tylko architekturę, ale także lokalne źródło danych jako podstawę do odczytu, ale również aktualizuje tę kopię w sieci. Dzięki temu chmura nie znika. Jest ona uzupełniana o dodatkowy lokalny poziom i zasady synchronizacji.
Lokalne przechowywanie zmniejsza uzależnienie
Jeśli aplikacja nie posiada konta i serwera, jej podstawowa ścieżka staje się łatwiejsza. Nie ma logowania, nie ma zapomnianego hasła ani awarii usługi synchronizacji. Dane osobowe nie muszą być przesyłane do dostawcy w celu normalnego użytkowania. Może to być bardzo dobre w przypadku narzędzia dla jednej osoby, które pasuje do oczekiwanego modelu zaufania.
Dostępność offline jest natychmiastowa. W piwnicy, w budynku o słabym odbiorze lub podczas podróży informacje pozostają dostępne. Zmiany mogą być przechowywane bez pytania o stan zdalny. Reakcja aplikacji nie zależy od opóźnienia usługi.
Również obsługa może być bardziej przejrzysta. Bez centralnej bazy danych użyteczności, niektóre koszty serwerów, procesy kont i bieżące problemy z synchronizacją nie są możliwe. Jednakże mniej infrastruktury nie oznacza infrastruktury ani odpowiedzialności: publikacja, połączenia ze sklepem, strona internetowa, wsparcie i utrzymanie produktów. Ponadto, lokalne magazyny, migracje, zarządzanie plikami i przywracanie plików muszą być starannie wdrożone.
Największą lokalną siłą jest jednocześnie jej granica
Urządzenie, które jest głównym zasobnikiem, tworzy klarowność, ale także pojedyncze usterki. Jeśli smartfon zostanie zgubiony, zostanie uszkodzony lub aplikacja zostanie usunięta bez odpowiedniego zabezpieczenia, może zniknąć tylko kopia danych. Kto chce kontynuować pracę na nowym urządzeniu, musi mieć planowaną ścieżkę eksportu i odzyskiwania.
Backupy nie są zatem opcjonalną funkcją krawędzi produktów lokalnych. Musisz tworzyć je w sposób zrozumiały, przechowywać poza aplikacją, a później niezawodnie odczytać. Plik, który znajduje się tylko w prywatnej aplikacji, nie chroni przed deinstalacją lub utratą urządzenia. Szyfrowanie może chronić wrażliwy eksport, ale zwiększa odpowiedzialność: Zagubione hasło może nie zostać zastąpione bez centralnej usługi przywracania.
Apple opisuje, że niektóre katalogi aplikacji mogą być włączane do kopii zapasowych urządzeń lub iCloud w zależności od rodzaju plików. Produkt musi świadomie decydować o tym, które dane są ważne, możliwe do odzyskania lub tymczasowe. Niemniej jednak użytkownicy powinni mieć pewność, czy sama aplikacja oferuje kopię zapasową i na co mogą polegać podczas zmiany urządzenia.
Systemy chmurowe umożliwiają współpracę i ciągłość
Gdy kilka osób potrzebuje tego samego stanu rzeczy, infrastruktura centralna otrzymuje dużą przewagę. Zespół może dzielić się zadaniami, przydzielać role i łączyć zmiany z różnymi urządzeniami. Nowy komputer nie musi otrzymywać ręcznie przeniesionego pliku. Po zalogowaniu można ponownie wczytać istniejącą pozycję.
Usługi w chmurze nadają się również do scentralizowanej automatyzacji. Serwer może uruchamiać procesy w tle, udostępniać wspólne powiadomienia, integrować dane z innymi systemami i stosować zasady niezależnie od tego, czy dany smartfon jest aktualnie aktywny. Często jest to niezbędne w przypadku sportów rezerwacyjnych, zarządzania zespołami lub oceny w skali przedsiębiorstwa.
Nawet tworzenie kopii zapasowych i przywracanie mogą być łatwiejsze dla każdego użytkownika. Redundante kopie serwerów, stan wersji i zarządzane kopie zapasowe zmniejszają ryzyko, że pojedyncze urządzenie zawiera wszystko. Jednak ta umiejętność jest działaniem konkretnej usługi, a nie automatyczną właściwością słowa Cloud. Przechowywanie, testowanie odzyskiwania, zasady usuwania i procesy awaryjne muszą być rzeczywiście dostępne.
Synchronizacja to własny problem z produktem
Aplikacja z lokalną kopią i synchronizacją w chmurze idealnie oferuje szybkie korzystanie z sieci offline i ciągłość między urządzeniami. Nasuwa się trudne pytanie: Co się stanie, jeśli dwa urządzenia zmienią ten sam zestaw danych niezależnie?
Niektóre konflikty mogą zostać rozwiązane według znacznika czasu. W przypadku innych najbardziej aktualna wersja wygrywałaby wartościowe informacje. Listy mogą łączyć elementy, podczas gdy długie teksty wymagają widocznego konfliktu. Pliki potrzebują statusu wysyłania, powtórzenia po rozbiórce i zasad usuwania. Produkt musi również pokazać, czy stand jest zapisany lokalnie, synchronizowany lub wadliwy.
Przewodnik Androidów Offline First opisuje m.in. lokalne i sieciowe źródła danych, kolejki synchronizacyjne oraz strategie odczytu i zapisu. Za nimi znajduje się duży zakres testów: tryb lotu, niestabilne połączenia, przerwy procesowe, podwójne wysyłanie, starsze wersje aplikacji oraz równolegle zmienione dane.
Synchronizacja nie powinna być więc planowana jako pojedynczy przełącznik. Jest ona stałym elementem logiki i powierzchni. Jeśli nie jest ona konieczna dla rzeczywistych korzyści, jej pominięcie może uczynić produkt bardziej solidnym. Jeżeli współpraca jest centralna, to nie skupianie się, lecz niewłaściwe ograniczenie.
Ochrona danych zależy od pełnej ścieżki danych
Lokalne przechowywanie danych może zapobiec transferom i scentralizowanym zasobom danych. Jest to skuteczna forma minimalizacji danych, jeśli zadanie można wykonać bez serwera. Mimo to ochrona urządzenia, skrzynki sandowej aplikacji, szyfrowanie lokalne, uprawnienia, dzienniki, eksport i kopie zapasowe pozostają istotne. Niechronione archiwum eksportu w współdzielonej lokalizacji może szybko zerwać z aplikacją prywatną.
W przypadku produktów w chmurze pojawiają się inne zainteresowane strony i pytania: Jakie dane opuszczają urządzenie? W jakim regionie są przetwarzane? Kto obsługuje infrastrukturę i wsparcie? Jak zabezpieczać, rejestrować i cofać dostęp? Jak długo pozostają kopie zapasowe po usunięciu? Jakie dane są przekazywane do usług analitycznych, informacyjnych lub SI?
Cloud nie oznacza automatycznie szerokiego przekazywania danych. Dobrze zaprojektowana platforma może minimalizować, szyfrować, ściśle oddzielać dostęp i zapewniać przejrzyste procesy usuwania danych. Lokalne nie oznacza, że nikt oprócz użytkownika nie może automatycznie zobaczyć danych; system operacyjny, kopie zapasowe urządzeń, pliki dzielone lub urządzenia kompromitowane zmieniają obraz. Ochrona danych wynika z konkretnej architektury i praktyki operacyjnej.
Skalowanie dotyczy więcej niż liczby użytkowników
Architektura w chmurze jest często oparta na skalowalności. Centralna usługa może pomieścić dodatkowych użytkowników, urządzenia lub ilości danych, pod warunkiem, że baza danych, pamięć i obsługa są do tego zaprojektowane, co powoduje bieżące koszty, monitorowanie, planowanie przepustowości i odpowiedzialność za bezpieczeństwo. Niewielkie wykorzystanie może kosztować niewiele; silne wykorzystanie lub duże pliki mogą zmienić model biznesowy.
Lokalne aplikacje dystrybuują pamięć i pracę obliczeniową na urządzenia. Dostawca nie płaci za każdy plik osobisty miejsca do przechowywania w chmurze. W tym celu urządzenia różnią się wydajnością i dostępną pamięcią. Duże zapasy obrazów, skomplikowane modele lokalne lub długie migracje mogą obciążać starszych smartfonów. Wsparcie techniczne musi obejść się z sytuacjami, które nie mogą być centralnie przeglądane lub naprawione.
Skalowanie może być również techniczne. Produkt dla dziesięciu nieruchomości może potrzebować tylko lepszych filtrów i większej lokalnej bazy danych. Produkt przeznaczony dla dziesięciu pracowników wymaga ról, zasad konfliktu i identyfikowalności. Sama liczba zbiorów danych nie decyduje o tym, kiedy chmura jest potrzebna.
Propivio jako świadomie lokalny przykład
Propivio jest przeznaczony dla jednej osoby, która zarządza informacjami o niewielu własnych nieruchomościach na smartfonie. Nie ma konta użytkownika, nie ma wspólnej edycji ani automatycznego chmury aplikacji. Dokumenty, zdjęcia, kontakty, poziomy liczników i inne dane techniczne znajdują się lokalnie w prywatnej aplikacji.
W tym scenariuszu podejście zmniejsza zbędną złożoność kont i synchronizacji. Konsekwencje nie są ukryte: Zewnętrzny proces tworzenia kopii zapasowych i odzyskiwania jest ważny, a wiele urządzeń nie posiada automatycznie dopasowanej pozycji. Kto pracuje z zespołem, chce centralnie sterować dużymi zapasami lub podłączać portale, świadomie spada poza ten model produktu.
Kolejny produkt Zappapps może być przedmiotem innej decyzji. Gdy korzyści wynikające ze współpracy, centralnej automatyzacji lub wspólnego dostępu będą zależały od tego, czy architektura w chmurze będzie wiarygodna pomimo większej złożoności. Konsekwencja marki nie wymaga, aby każda aplikacja została zbudowana w taki sam sposób z technicznego punktu widzenia.
Matryca decyzyjna zamiast wiary
Przed wyborem architektury pomocne są konkretne pytania:
- Czy dana osoba pracuje sama, czy też musi widzieć te same role?
- Czy rdzeń musi działać całkowicie bez sieci?
- Jakie korzyści przyniesie utrata urządzenia?
- Kto jest odpowiedzialny za tworzenie kopii zapasowych i przywracanie do życia?
- Czy dostęp między urządzeniami jest kluczowymi korzyściami czy okazjonalnym wygodą?
- Jakie dane są wrażliwe i jakie transfery są naprawdę potrzebne?
- Czy produkt potrzebuje procesów tła lub integracji, gdy żadne urządzenie nie jest aktywne?
- Jakie koszty eksploatacji, wsparcia i infrastruktury są trwałe?
- W jaki sposób można rozwiązać problem eksportu, usuwania, migracji i ewentualnej zmiany dostawcy?
Odpowiedzi mogą prowadzić do lokalnych, chmurowych lub hybrydowych rozwiązań offline-first. Mogą się one zmieniać z produktem. Jednak późniejsza zmiana jest uciążliwa, ponieważ dotyczy tożsamości danych, konfliktów i zaufania. Dlatego też pierwsza decyzja nie powinna być podejmowana wyłącznie na podstawie preferowanej technologii.
Właściwa architektura sprawia, że ich skutki są widoczne
Ludzie nie muszą rozumieć rozproszonych systemów, aby korzystać z aplikacji, ale powinni wiedzieć, co jest ważne dla ich codziennego życia: działa bez sieci? Czy dane są dostępne na innych urządzeniach? Czy mogą współpracować ze współpracownikami? Co się dzieje w przypadku utraty lub deinstalacji? Jak powstaje backup? Jakie treści są przekazywane do usługi?
Dobra architektura danych odpowiada na te pytania nie tylko w technice, ale także w tekstach produktów i interakcjach. Lokalna i chmura nie są poziomami jakości. Są to różne podziały umiejętności, ryzyka i odpowiedzialności. Lepszym wyborem jest ta, która pasuje do rzeczywistego celu i której konsekwencje są uczciwie kontrolowane przez produkt.
Źródła i dalsze informacje
- NIST: Definition of Cloud Computing – oficjalna podstawa terminologiczna dla przetwarzania w chmurze.
- Android Developers: Build an offline-first app – lokalne źródło danych, synchronizacja oraz strategie odczytu i zapisu.
- Android Developers: Guide to app architecture – modele danych, jedno źródło prawdy i wyraźne granice odpowiedzialności.
- Apple Developer: Using the file system effectively – katalogi aplikacji, trwałe dane i działanie kopii zapasowych.
- Apple Developer: Optimizing your app’s data for iCloud backup – świadoma klasyfikacja plików trwałych i możliwych do odtworzenia.
