Oprogramowanie jako usługa (SaaS) - izolacja danych i wyjście z usługi

Oprogramowanie jako usługa (SaaS) - jak działa model subskrypcyjny

Oprogramowanie jako usługa oznacza, że aplikacja działa na infrastrukturze dostawcy, a firma korzysta z niej przez przeglądarkę lub aplikację mobilną. Definicja Narodowego Instytutu Standardów i Technologii USA opisuje ten model jako używanie aplikacji dostawcy bez zarządzania infrastrukturą chmurową, do której należą serwery i sieć, co potwierdza dokument NIST SP 800-145. Klient nie instaluje programu i nie utrzymuje bazy danych.

Rozliczenie ma zwykle formę subskrypcji, czyli opłaty okresowej zależnej od liczby użytkowników albo zakresu funkcji. Model nie jest jednak tym samym co system napisany na zamówienie. W SaaS wielu odbiorców korzysta z tego samego kodu, a różnice między klientami wynikają z konfiguracji. Kiedy firma potrzebuje procesu, którego konfiguracja nie obejmuje, sięga po rozwiązanie opisane w artykule o oprogramowaniu na zamówienie.

Przykładami są pakiety biurowe Microsoft 365 i Google Workspace oraz platformy do komunikacji i sprzedaży internetowej. W logistyce ten sam mechanizm stosuje się do systemów magazynowych, o czym mówi artykuł o programie magazynowym w chmurze i na serwerze własnym.

Reguła: w SaaS klient kupuje dostęp do wspólnej aplikacji, więc wszystko, co wykracza poza konfigurację, wymaga zgody dostawcy i zwykle osobnej opłaty.

Z czego składa się opłata subskrypcyjna

Cennik SaaS rzadko sprowadza się do jednej kwoty. Dostawcy łączą opłatę za użytkownika z opłatami za dodatkowe moduły, ilość przechowywanych danych albo liczbę wywołań interfejsu. Przy porównaniu ofert trzeba więc policzyć koszt dla własnego profilu pracy, a nie zestawiać stawki z cenników.

Znaczenie ma także typ licencji użytkownika. Konto imienne jest przypisane do osoby, więc kupuje się je dla każdego pracownika, który loguje się choćby raz w miesiącu. Licencja równoległa ogranicza liczbę osób pracujących w tej samej chwili, co pasuje do hali zmianowej, gdzie jedno stanowisko obsługuje kilka osób w ciągu doby.

Izolacja danych klientów w usłudze wielodostępnej

Usługa SaaS jest zwykle wielodostępna: jedna instalacja obsługuje wielu klientów, którzy nie mogą widzieć swoich danych nawzajem. Izolację można zbudować na kilku poziomach, a wybór wpływa na koszt utrzymania i na łatwość przeniesienia klienta. Wzorce projektowe takich usług zbiera przewodnik Microsoft Learn o architekturze wielodostępnej.

Najtańszy wzorzec, czyli wspólne tabele, jest też najbardziej podatny na błąd programisty. Wystarczy zapytanie bez warunku na TenantId, żeby jeden klient zobaczył dane drugiego. SQL Server oferuje zabezpieczenie na poziomie wiersza, opisane w dokumentacji Row-Level Security. Baza dołącza wtedy warunek do każdego zapytania, niezależnie od kodu aplikacji. Poniższy przykład jest poglądowy, a nazwy obiektów są przykładowe.

CREATE FUNCTION dbo.fn_TenantFilter(@TenantId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS allowed
WHERE @TenantId = CAST(SESSION_CONTEXT(N'TenantId') AS INT);
GO
CREATE SECURITY POLICY dbo.TenantPolicy
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantId) ON dbo.Orders
WITH (STATE = ON);
GO
EXEC sp_set_session_context @key = N'TenantId', @value = 42, @read_only = 1;

Aplikacja ustawia TenantId po zalogowaniu użytkownika i blokuje możliwość zmiany wartości w tej samej sesji. Od tej chwili instrukcja SELECT na tabeli Orders zwraca wyłącznie wiersze klienta 42.

Reguła: identyfikator klienta ustawia warstwa aplikacji na podstawie konta użytkownika, a nie parametr przesłany z formularza.

Indeksy i obciążenie wspólnych tabel

Wspólne tabele wymagają indeksów, które zaczynają się od TenantId. Bez tego zapytanie jednego klienta przegląda wiersze wszystkich pozostałych, a czas odpowiedzi rośnie z każdym nowym klientem. Klucz klastrowy złożony z TenantId i identyfikatora wiersza grupuje dane klienta na sąsiednich stronach, co skraca odczyt.

CREATE INDEX IX_Orders_Tenant_Date
  ON dbo.Orders (TenantId, OrderDate)
  INCLUDE (Status);

Drugim zagadnieniem jest efekt hałaśliwego sąsiada. Klient uruchamiający duży raport może zająć zasoby serwera i spowolnić pozostałych. Dostawca ogranicza to limitami zapytań albo przenosi takiego klienta do osobnej bazy.

Aktualizacje w SaaS - wersje i okna serwisowe

Dostawca wdraża zmiany centralnie, więc klient nie instaluje poprawek i zawsze pracuje na aktualnej wersji. Wygoda ma odwrotną stronę: termin zmiany wybiera dostawca. Dlatego umowa powinna określać, jak wcześnie dostawca zapowiada zmiany funkcji i czy zmiany łamiące zgodność są poprzedzone okresem przejściowym.

Ryzyko jest największe przy integracjach. Klient, który wymienia dane z usługą przez API, opiera się na konkretnym formacie komunikatu. Dostawca wersjonuje interfejs, na przykład w adresie, i utrzymuje starą wersję przez ustalony czas. Bez takiej zasady zmiana jednego pola potrafi zatrzymać wymianę z systemem ERP. Zagadnienie łączenia aplikacji SaaS z resztą środowiska omawia tekst o oprogramowaniu jako usłudze a integracji aplikacji.

Nowe funkcje wprowadza się często za przełącznikiem włączanym osobno dla każdego klienta. Klient sprawdza działanie na własnych danych, a dostawca cofa zmianę bez wdrażania kodu od nowa.

const labelsV2 = tenant.features.has('labels-v2');
const render = labelsV2 ? renderLabelV2 : renderLabelV1;
render(document);

Przykład pokazuje mechanizm, a nie konkretny produkt. Przełączniki wymagają porządku: każdy powinien mieć datę usunięcia, bo po roku w kodzie zostaje kilkadziesiąt gałęzi, których nikt nie umie już wyjaśnić.

Środowisko testowe i zapowiedzi zmian

Część dostawców udostępnia klientom środowisko testowe z kopią konfiguracji. Zmiana trafia tam przed produkcją, a zespół klienta sprawdza integracje i wydruki na własnych scenariuszach. Jeżeli usługa takiego środowiska nie oferuje, zapowiedzi zmian trzeba traktować poważniej, bo pierwszy test odbywa się na danych produkcyjnych.

Notatki o wersji są użyteczne wtedy, gdy wskazują konkretne pola i adresy interfejsu, których dotyczy zmiana. Ogólne stwierdzenie o poprawie stabilności nie pozwala ocenić wpływu na procedury w magazynie ani na wymianę z ERP.

SLA w SaaS - dostępność i odtwarzanie danych

Umowa o poziomie usług, czyli SLA, zamienia obietnicę dostępności w liczby. Najczęściej podaje się procent czasu w miesiącu, w którym usługa działa, z wyłączeniem okien serwisowych. Procent brzmi abstrakcyjnie, dopóki nie przeliczy się go na godziny przestoju dopuszczonego umową.

Sama dostępność nie opisuje bezpieczeństwa danych. Do tego służą dwa parametry. RPO określa maksymalny wiek danych, które można utracić po awarii, a RTO maksymalny czas przywrócenia usługi. Kopia bazy wykonywana raz na dobę oznacza RPO do 24 godzin, a kopia dziennika transakcji co kilkanaście minut skraca je do takiego odstępu.

• RPO - ile pracy użytkowników można stracić po awarii, liczone od ostatniej kopii.
• RTO - ile czasu upłynie od awarii do momentu, gdy użytkownicy znów mogą pracować.

Kopie zapasowe a parametr RPO

Plan kopii bazy SQL Server opiera się na kopii pełnej wykonywanej rzadko oraz na kopiach dziennika transakcji wykonywanych często. Odstęp między kopiami dziennika wyznacza RPO. Kopia różnicowa skraca odtwarzanie, bo zawiera tylko zmiany od ostatniej kopii pełnej.

Odtworzenie zaczyna się od kopii pełnej, po której nakłada się różnicową i kolejne kopie dziennika w kolejności czasowej. Czas tej operacji buduje RTO, dlatego dostawca mierzy go na próbnym odtworzeniu, a nie szacuje z rozmiaru bazy.

Umowa określa także konsekwencje niedotrzymania SLA, często w postaci obniżenia opłaty za okres, w którym przestój przekroczył limit. Obniżka nie pokrywa strat klienta, więc przy procesach ważnych dla ciągłości pracy trzeba oszacować koszt godziny przestoju i porównać go z wysokością obniżki.

Reguła: SLA mierzy dostępność usługi, a nie poprawność danych, więc kopie zapasowe i próba odtworzenia wymagają osobnych zapisów w umowie.

Architekturę serwerową usługi magazynowej w chmurze, wraz z kopiami i odtwarzaniem, opisuje artykuł o magazynie w chmurze. W wersji chmurowej Studio WMS.net stosuje bazę Microsoft SQL Server, a wybór między chmurą a serwerem własnym porządkuje materiał producenta o WMS w chmurze i on-premise.

Wyjście z usługi SaaS - eksport danych i umowa

Zależność od dostawcy jest głównym ryzykiem modelu. Firma, która przez kilka lat prowadzi proces w cudzej aplikacji, gromadzi w niej dane i konfigurację, których nie odtworzy w tydzień. Zasady wyjścia trzeba więc zapisać na początku współpracy, kiedy klient ma jeszcze przewagę negocjacyjną.

Jeżeli usługa przetwarza dane osobowe, dostawca działa jako podmiot przetwarzający, więc potrzebna jest umowa powierzenia. Powinna wskazywać, co dzieje się z danymi po zakończeniu usługi. Wyjście warto przećwiczyć jeszcze w czasie trwania umowy, wykonując próbny eksport i wczytując go do środowiska testowego. Taka próba ujawnia braki w opisie pól szybciej niż spór po wypowiedzeniu.

Przejęcie procesów po wyjściu

Eksport danych rozwiązuje połowę problemu. Druga połowa to konfiguracja, która w usłudze działała bez wiedzy użytkowników: role i szablony dokumentów, a także reguły numeracji oraz integracje. Inwentarz tych elementów warto sporządzić przed wyjściem, bo nowy system wymaga ich odtworzenia.

Numeracja dokumentów zasługuje na osobną uwagę. Nowy system musi kontynuować kolejność od ostatniego wystawionego dokumentu, inaczej w ewidencji pojawią się duplikaty albo luki, o które zapyta kontrola zewnętrzna.

Koszty subskrypcji w całym okresie użytkowania omawia tekst o abonamencie za program magazynowy w chmurze, a zmianę skali zapotrzebowania na zasoby opisuje artykuł o skalowalności programu w chmurze.

Kiedy SaaS, a kiedy własny serwer lub system na zamówienie

SaaS sprawdza się przy procesach standardowych, w których liczy się szybki start i przewidywalny koszt. Własny serwer wybiera się, gdy przepisy lub polityka firmy wymagają kontroli nad lokalizacją danych, a system na zamówienie, gdy proces odbiega od typowych rozwiązań i konfiguracja go nie obejmie.

W portfolio SoftwareStudio występują oba warianty wdrożenia. Studio WMS.net działa w wersji chmurowej i w instalacji na serwerze klienta, a system reklamacji opisuje artykuł o programie do reklamacji w modelu SaaS. Producent publikuje też opis systemu RMA w modelu SaaS. Kryteria wyboru narzędzia do relacji z klientami, które często kupuje się jako usługę, zestawia tekst o CRM opartym na chmurze.

Korzyści operacyjne pracy w przeglądarce, w tym dostęp z wielu lokalizacji, opisuje artykuł o wskaźnikach systemu WMS online.