Zagłębienie się w pojęcie "wielozadaniowości" i podzielenie się naszymi spostrzeżeniami na temat tego, jak ją postrzegamy.
Często słyszymy o znaczeniu tworzenia aplikacji wielozadaniowej, zwłaszcza w kontekście rozwijania aplikacji typu Software as a Service (SaaS).
Istnieje pewne zamieszanie wokół pojęcia “aplikacji wielozadaniowej” i różnych modeli stosowanych do jej opracowywania. W tym artykule przyjrzeliśmy się bliżej tym terminom w bardziej praktyczny sposób.
Architektura jednokrotnego najmu to model oprogramowania lub przetwarzania w chmurze, w którym każdy klient lub najemca ma dedykowaną instancję aplikacji lub usługi. Jeśli spojrzymy na początek modelu biznesowego B2B, zaczyna się on od sytuacji, w której każda instancja oprogramowania obsługuje tylko jednego klienta lub organizację.
Architektura jednokrotnego najmu jest powszechnie stosowana w scenariuszach, w których zgodność z przepisami jest najważniejsza lub istnieją specjalne wymagania dotyczące bezpieczeństwa. Na przykład branże takie jak finanse, opieka zdrowotna i administracja, które mają rygorystyczne wymagania regulacyjne, często preferują rozwiązania jednokrotnego najmu, aby zapewnić zgodność.
Jednak warto zauważyć, że architektury jednokrotnego najmu mogą być bardziej zasobochłonne i trudniejsze do zarządzania w porównaniu do architektur wielozadaniowych, ponieważ instancja każdego klienta wymaga własnej infrastruktury i konserwacji. W związku z tym mogą być bardziej odpowiednie dla aplikacji z mniejszą liczbą, ale większymi klientami lub tam, gdzie dostosowanie i izolacja są kluczowe.
Wielozadaniowość oprogramowania to architektura oprogramowania, w której jedna instancja oprogramowania działa na serwerze i obsługuje wielu najemców. Systemy zaprojektowane w ten sposób są "współdzielone" (zamiast "dedykowanych" lub "izolowanych"). Najemca to grupa użytkowników, którzy dzielą wspólny dostęp z określonymi uprawnieniami do instancji oprogramowania. W przypadku architektury wielozadaniowej, aplikacja oprogramowania jest zaprojektowana tak, aby każdemu najemcy zapewnić dedykowany udział w instancji - w tym jego dane, konfigurację, zarządzanie użytkownikami, indywidualną funkcjonalność najemcy oraz właściwości niefunkcjonalne. -- Wikipedia
Podaliśmy definicje z perspektywy architekturalnej, co ułatwia rozróżnienie między projektami wielozadaniowymi a jednokrotnego najmu. Jednak to bardziej polega na definicji technicznej. Jeśli zastosujemy te definicje w naszym rzeczywistym środowisku deweloperskim podczas projektowania modeli najmu, takie podejście zakłada, że aplikacja wielozadaniowa musi mieć czysto współdzieloną infrastrukturę wielozadaniową.
Jednak biznes i produkty są zróżnicowane i mają wiele wymagań zależnych od przypadku, więc nie ma jednego rozwiązania pasującego do wszystkich.
Wyobraź sobie sytuację, w której najemca korzysta z zasobów współdzielonej infrastruktury, ale z powodu specyficznych potrzeb biznesowych wymaga jednej lub dwóch części systemu, które będą wyłącznie dedykowane dla nich. Te dedykowane części mogą obejmować bazę danych, instancje lub kombinację innych komponentów, jednocześnie dzieląc ogólną infrastrukturę. Tutaj pojawia się architektura mieszana.
W praktycznym rozwoju produktów SaaS, często występuje sytuacja, w której produkt jest głównie zaprojektowany według ogólnego modelu wielozadaniowego. Jednak pewne aspekty architektury lub zasobów mogą skłaniać się ku podejściu "jednokrotnego najmu".
AWS użył następującego przypadku, aby przekazać tę koncepcję: wielozadaniowość to szerokie pojęcie, i na podstawie przypadku jest to kombinowanie i wybieranie odpowiedniej strategii definiującej, co chciałbyś osiągnąć za pomocą współdzielonych zasobów i izolacji danych.
Innymi słowy, czasami ludzie nadal nazywają ten model “Wielozadaniowością”, więc w szerszej definicji wielozadaniowości, nie oznacza to, że każdy komponent w rozwiązaniu jest współdzielony. Oznacza to raczej, że przynajmniej niektóre komponenty rozwiązania są używane ponownie przez wielu najemców.
Szerokie zrozumienie tego pojęcia może lepiej pomóc ci wczuć się w potrzeby klienta i zrozumieć, skąd pochodzą.
Zamiast skupiać się na jednym modelu architektonicznym, wielozadaniowość odzwierciedla praktyczność architektury produktu SaaS w rzeczywistym świecie. Kiedy mówimy o aplikacji wielozadaniowej, niekoniecznie oznacza to, że aplikacja przestrzega jednego modelu architektonicznego; może wykorzystywać różne strategie najmu, wskazując, że przynajmniej niektóre jej komponenty są współdzielone.
Pojawia się pytanie, jak zaproponować strategię najmu dla mojego produktu? Oto kilka ważnych pytań do przemyślenia:
Pamiętaj, że w twoim produkcie nie ma sztywnego podziału, gdzie musisz zdecydować się albo na czysto wielozadaniowy, albo wyłącznie jednokrotnego najmu model. Twoja decyzja powinna być oparta na tym, jak dzielisz komponenty architektoniczne twojego produktu i na specyficznych poziomach izolacji, których potrzebują twoi klienci lub biznes. Następnie możesz zastosować odpowiednie podejścia.
Mówiliśmy o “nowej” definicji aplikacji wielozadaniowej, ale co z izolacją najemców, tożsamościami i tym, jak określić, czy twoje tożsamości powinny być izolowane, czy nie? Co oznacza dla tożsamości, aby były "izolowane"?
Często pojawia się zamieszanie w sytuacjach, w których jeden użytkownik rzeczywistego świata ma dwie różne tożsamości. Czy odpowiednim jest nazywanie tej sytuacji - “tożsamości izolowane”?
Odpowiemy na te pytania w naszej nadchodzącej serii artykułów. Zostańcie z nami!