Metody architektury dla płaszczyzn sterowania w rozwiązaniach wielodostępnych

Płaszczyzny sterowania są ważną częścią oprogramowania jako usługi (SaaS) i wielodostępnych rozwiązań. Ułatwiają one zarządzanie rozwiązaniem na dużą skalę. Zazwyczaj płaszczyzna sterowania składa się z dwóch głównych składników:

• Wykaz dzierżaw, który przechowuje ważne informacje o dzierżawach, w tym następujące informacje:

  • Konfiguracja dzierżawy
  • Jednostki SKU wdrożone dla zasobów najemców
  • Które sygnatury wdrożenia są przydzielane dzierżawcom

• Procesy, które zarządzają zmianami w środowisku. Cykl życia najemcy wyzwala te procesy. Przykłady obejmują zatrudnianie najemcy, rozwiązywanie umowy najmu i wymaganą regularną konserwację.

Płaszczyzna sterowania działa jako aplikacja. Musisz zaprojektować płaszczyznę sterowania z taką samą starannością i rygorem, jak do innych części rozwiązania. Aby uzyskać więcej informacji na temat czym jest płaszczyzna sterowania, dlaczego ma to znaczenie i zagadnienia projektowe, patrz Zagadnienia dotyczące wielodostępnych płaszczyzn sterowania.

W tym artykule opisano metody projektowania i tworzenia płaszczyzny sterowania. Każde podejście jest prawidłowe, ale inna architektura poza tym wskazówkami może lepiej odpowiadać konkretnemu scenariuszowi.

Podejścia i wzorce do rozważenia

W poniższej tabeli przedstawiono podsumowanie różnic między ręcznymi, niskokodowymi i niestandardowymi ścieżkami dla płaszczyzny sterowania.

Kwestie wymagające rozważenia	Podręcznik	Niski kod	Na zamówienie
Obciążenie operacyjne	Wysoki	Nisko-średni	Niski
Częstotliwość zdarzeń cyklu życia, które obsługuje podejście	Rzadki	Od czasu do czasu - często	Często
Czas i złożoność implementacji	Niski	Średni	Wysoki
Obowiązki związane z konserwacją płaszczyzny sterowania	Niski	Średni	Wysoki
Możliwość testowania	Niski	Średni	Wysoki
Ryzyko niespójności	Wysoki	Średnio-niski	Niski

Procesy ręczne

Nie zawsze trzeba budować w pełni zautomatyzowaną płaszczyznę sterowania, zwłaszcza gdy zaczynasz od kilku najemców.

Katalog dzierżaw można przechowywać w centralnej lokalizacji, takiej jak skoroszyt programu Excel lub plik JSON przechowywany w lokalizacji, do której twój zespół może uzyskać dostęp. Niezależnie od formatu, należy przechowywać informacje w ustrukturyzowany sposób, aby można było łatwo pracować z danymi programowo.

Uwaga / Notatka

Ręczna płaszczyzna kontrolna działa dobrze jako punkt wyjścia do zarządzania aplikacją wielodzierżawną, ale jest odpowiednia tylko dla mniej niż 10 lokatorów. Obciążenie administracyjne i ryzyko niespójności rosną wraz z każdym ręcznie dodanym klientem. Użyj tej metody tylko wtedy, gdy masz kilku tenantów i nie potrzebujesz automatycznego ani samoobsługowego wdrożenia.

Weź pod uwagę następujące czynniki związane z procesami, takimi jak wdrażanie najemców i działania konserwacyjne.

• Tworzenie skryptów lub zautomatyzowanych potoków, jeśli jest to możliwe, nawet jeśli są uruchamiane ręcznie. Skrypty lub potoki zapewniają spójne uruchamianie kroków dla każdego klienta.

• W przypadku zadań, których nie można początkowo zautomatyzować za pomocą skryptu, proces powinno się udokumentować w przejrzystych, szczegółowych krokach. Wyjaśnij , jak i dlaczego. Te informacje pomagają innym osobom zautomatyzować zadanie w przyszłości.

Na poniższym diagramie przedstawiono ręczne podejście do początkowej płaszczyzny sterowania.

Diagram zawiera dwie główne sekcje: płaszczyznę sterowania i płaszczyznę danych. Płaszczyzna sterowania zawiera aplikację internetową, sprzedawcę, plik programu Excel, inżyniera i skrypt. Płaszczyzna danych zawiera dwóch istniejących klientów i jednego nowego klienta. Każdy najemca ma aplikację i bazę danych SQL. Przepływ rozpoczyna się od zewnętrznego klienta, który zarejestruje się, rozmawiając z sprzedawcą. Sprzedawca wstawia informacje o dzierżawie do pliku programu Excel. Inżynier odczytuje informacje o dzierżawie i uruchamia skrypt wdrażania. Skrypt odczytuje informacje i wdraża i konfiguruje środowisko w usłudze Azure Resource Manager. Resource Manager przekierowuje się do nowego klienta na płaszczyźnie danych.

Pobierz plik programu Visio z tą architekturą.

Zalety podejścia ręcznego

• Lekki: Dokumentacja, skrypty i potoki są łatwe do opracowywania i modyfikowania. Ta elastyczność sprawia, że są one idealne podczas określania procesów, ponieważ można je szybko iterować i rozwijać.

• Niski koszt: Utrzymywanie i uruchamianie ręcznego podejścia jest niedrogie.

• Walidacja procesu: Podejście ręczne służy jako dowód koncepcji. Umożliwia testowanie i potwierdzanie strategii konserwacji przed przeznaczeniem zasobów i czasu na stworzenie pełnej automatyzacji.

Wady podejścia ręcznego

• Brak kontroli: Takie podejście polega na tym, że wszyscy zaangażowani robią właściwą rzecz. Ktoś może odbiegać od określonych procesów, przypadkowo lub celowo. Każda odmiana procesu zwiększa ryzyko niespójności w środowisku, co sprawia, że ciągłe zarządzanie jest trudne.

• Wyzwania związane z kontrolą dostępu: Takie podejście często wymaga szeroko ograniczonego, wysoce permisywnego dostępu do operatorów rozwiązania. Ten dostęp utrudnia wymuszanie najlepszych rozwiązań dotyczących segmentacji dostępu .

• Skalowalność: Praca wymagana do uruchamiania procesów ręcznych skaluje się wraz z liczbą najemców, którymi trzeba zarządzać.

• Możliwość testowania: Procesy ręczne są trudne do zweryfikowania i przetestowania.

Kiedy należy rozważyć odejście od podejścia ręcznego

• Gdy zespół nie może nadążyć za obciążeniem wymaganym do obsługi aplikacji. Ten scenariusz często występuje, gdy liczba dzierżaw przekracza próg możliwy do zarządzania, zazwyczaj z zakresu od 5 do 10 dzierżaw.

• Jeśli przewidujesz wzrost liczby dzierżawców poza krytyczną liczbę dzierżawców i musisz przygotować się na wymagania zarządzania większą liczbą dzierżawców.

• Gdy trzeba ograniczyć ryzyko niespójności. Na przykład możesz zaobserwować błędy występujące, ponieważ ktoś nie wykonuje poprawnie procesów lub z powodu niejasnych procesów. Ryzyko niespójności rośnie wraz z ręcznym dołączaniem większej liczby najemców i rozwojem zespołu.

Płaszczyzna sterowania z małą ilością kodu

Warstwa sterowania nisko- lub bezkodowa używa platformy zaprojektowanej do automatyzacji procesów biznesowych i śledzenia informacji. Wiele platform, w tym Microsoft Power Platform, umożliwia wykonywanie tych zadań bez konieczności pisania niestandardowego kodu.

Jeśli używasz platformy Microsoft Power Platform, możesz przechowywać katalog dzierżaw w usłudze Dynamics 365, Dataverse lub Microsoft 365. Możesz również zachować ten sam katalog najemców, którego używasz dla procesów ręcznych, jeśli nie chcesz na początku w pełni zaangażować się w automatyzację wszystkiego.

W przypadku wdrażania i utrzymania dzierżaw można użyć usługi Power Automate do uruchamiania przepływów pracy, które zarządzają dzierżawą, konfigurują dzierżawy oraz uruchamiają potoki lub wywołania interfejsu API. Usługa Power Automate może monitorować zmiany w katalogu dzierżaw, jeśli ma dostęp do danych. Jeśli używasz ręcznego katalogu dzierżawców, możesz ręcznie wyzwalać automatyczne przepływy pracy usługi Power Automate. Uwzględnij kroki ręcznego zatwierdzania w przepływach pracy, gdy potrzebny jest członek zespołu do weryfikowania lub wykonywania zadań, których nie można w pełni zautomatyzować.

To podejście wspiera również samodzielną rejestrację dla klientów. Aplikacja internetowa może automatycznie tworzyć wpisy wykazu dzierżaw bez udziału człowieka.

Na poniższym diagramie pokazano, jak za pomocą platformy Microsoft Power Platform utworzyć płaszczyznę kontrolną z samoobsługową rejestracją użytkownika.

Diagram zawiera dwie główne sekcje: płaszczyznę sterowania i płaszczyznę danych. Płaszczyzna sterowania zawiera aplikację internetową, tabelę Dataverse i przepływ pracy usługi Power Automate. Płaszczyzna danych zawiera dwóch istniejących klientów i jednego nowego klienta. Każdy najemca ma aplikację i bazę danych SQL. Przepływ rozpoczyna się od zewnętrznego klienta, który zarejestruje się przy użyciu aplikacji internetowej. Aplikacja internetowa wstawia informacje o dzierżawie do tabeli Dataverse. Te zmiany wyzwalają przepływ pracy usługi Power Automate, który wdraża i konfiguruje środowisko w usłudze Azure Resource Manager. Resource Manager przekierowuje się do nowego klienta na płaszczyźnie danych.

Pobierz plik programu Visio z tą architekturą.

Zalety podejścia o niskim kodzie

• Lekki: Możesz szybko i przystępnie cenowo tworzyć przepływy pracy z małą ilością kodu i łączyć je z otaczającymi systemami.

• Używa narzędzi platformy: Za pomocą natywnych funkcji platformy można przechowywać dane, tworzyć portale administracyjne dla zespołu i monitorować przepływy pracy. Takie podejście zmniejsza konieczność opracowywania i utrzymywania niestandardowych składników.

• Konfigurowalny: W razie potrzeby można rozszerzyć przepływy pracy przy użyciu kodu niestandardowego. Na przykład usługa Power Automate może wyzwolić przepływ zadań wdrażania w GitHub Actions lub wywołać Azure Functions, aby uruchomić kod. Ta elastyczność ułatwia stopniowe wdrażanie automatyzacji.

• Niskie obciążenie: Usługi o niskim kodzie są zwykle w pełni zarządzane, więc nie trzeba zarządzać infrastrukturą.

Wady podejścia o niskim kodzie

• Wymagana wiedza: Platformy z małą ilością kodu często wymagają własnościowej wiedzy w celu efektywnego tworzenia procesów i zarządzania nimi. Wiele organizacji korzysta już z tych narzędzi, więc twój zespół może mieć wymaganą wiedzę lub może być konieczne szkolenie.

• Zarządzanie: Zarządzanie dużymi ilościami konfiguracji niskiego kodu może być trudne.

• Możliwość testowania: W zarządzanej platformie tworzenie typowego procesu DevOps na potrzeby testowania i promowania zmian jest trudniejsze. Zazwyczaj wprowadzasz zmiany w konfiguracji, a nie za pomocą kodu.

• Projekt: Platformy z małą ilością kodu często zarządzają wymaganiami niefunkcjonalnymi, ale nadal trzeba sprawdzić, czy spełniają one standardy. Dokładnie oceń, jak spełnić te wymagania, takie jak zabezpieczenia i niezawodność.

Kiedy należy rozważyć odejście od podejścia o niskim kodzie

W końcu wymagania mogą stać się tak złożone, że nie można ich rozsądnie uwzględnić w rozwiązaniu o niskim kodzie. Jeśli musisz obejść ograniczenia narzędzi, aby spełnić swoje potrzeby, powinieneś zrezygnować z rozwiązania zarządzanego na rzecz niestandardowej płaszczyzny kontrolnej.

Niestandardowa płaszczyzna sterowania

Możesz utworzyć w pełni dostosowaną płaszczyznę sterowania. Ta opcja zapewnia największą elastyczność i moc, ale wymaga również największej pracy.

Wykaz dzierżaw jest zwykle przechowywany w bazie danych. Nie pracujesz bezpośrednio z katalogiem. Zamiast tego zarządzasz nim za pomocą interfejsu administracyjnego, takiego jak aplikacja niestandardowa lub system, taki jak aplikacja do zarządzania relacjami z klientami (CRM) organizacji.

Zazwyczaj tworzy się zestaw składników płaszczyzny kontrolnej do obsługi funkcji administracyjnych podmiotu. Składniki te mogą obejmować portal administracyjny lub inny interfejs użytkownika, interfejs API i składniki przetwarzania w tle. Jeśli musisz wdrożyć kod lub infrastrukturę przy wystąpieniu zdarzeń cyklu życia dzierżawy, możesz również dodać potoki wdrożeniowe do płaszczyzny sterującej.

Upewnij się, że procesy długotrwałe korzystają z odpowiednich narzędzi technologicznych. Możesz użyć Durable Functions lub Azure Logic Apps do składników, które koordynują dołączanie dzierżawców, zarządzają wdrożeniami lub wymagają komunikacji z systemami zewnętrznymi.

Podobnie jak w przypadku podejścia niskokodowego, to podejście umożliwia zapewnienie samoobsługowej rejestracji klientom. Aplikacja internetowa może bezpośrednio dodawać rekordy do katalogu dzierżaw bez interwencji człowieka.

Na poniższym diagramie pokazano, jak utworzyć podstawową niestandardową warstwę kontrolną, która zapewnia rejestrację samoobsługową.

Ten diagram zawiera dwie główne sekcje: płaszczyznę sterowania i płaszczyznę danych. Płaszczyzna sterowania zawiera aplikację internetową, usługę Azure Service Bus, Durable Functions i bazę danych SQL Database. Płaszczyzna danych zawiera dwóch istniejących klientów i jednego nowego klienta. Każdy najemca ma aplikację i bazę danych SQL. Przepływ rozpoczyna się od zewnętrznego klienta, który zarejestruje się przy użyciu aplikacji internetowej. Aplikacja internetowa przechowuje informacje o dzierżawie w usłudze Azure SQL Database i wysyła powiadomienie do usługi Service Bus. To powiadomienie wyzwala rozszerzenie Durable Functions, które wdraża i konfiguruje środowisko w usłudze Azure Resource Manager. Resource Manager przekierowuje się do nowego klienta na płaszczyźnie danych. Rozszerzenie Durable Functions przechowuje nowe metadane dotyczące środowiska dzierżawy w bazie danych SQL.

Pobierz plik programu Visio z tą architekturą.

Zalety podejścia niestandardowego

• Pełna elastyczność i możliwość dostosowywania: Masz pełną kontrolę nad funkcjonalnością płaszczyzny sterowania i możesz ją zmodyfikować, jeśli wymagania się zmienią.

• Możliwość testowania: Możesz użyć standardowego cyklu życia tworzenia oprogramowania dla aplikacji płaszczyzny sterowania i zaimplementować typowe podejścia do testowania i wdrażania, tak jak w przypadku głównych aplikacji.

Wady podejścia niestandardowego

• Obowiązki związane z konserwacją: Takie podejście wymaga większego nakładu pracy związanego z konserwacją, ponieważ musisz utworzyć wszystko samodzielnie. Płaszczyzna sterowania jest tak ważna, jak każda inna część aplikacji. Należy zadbać o opracowywanie, testowanie i obsługę płaszczyzny sterowania, aby zapewnić jego niezawodność i bezpieczeństwo.

Podejścia hybrydowe

Można również rozważyć podejście hybrydowe, które łączy systemy ręczne i zautomatyzowane. Możesz też użyć zarządzanej platformy, takiej jak Microsoft Power Platform i rozszerzyć ją za pomocą aplikacji niestandardowych. Rozważ wdrożenie podejścia hybrydowego, jeśli potrzebujesz elastyczności niestandardowej płaszczyzny sterowania, ale nie chcesz tworzyć i obsługiwać w pełni niestandardowego systemu. Należy jednak pamiętać, że automatyczne dostosowania procesów ręcznych lub zarządzanej platformy mogą stać się tak złożone, jak w pełni dostosowany system. Jeśli podejście hybrydowe staje się trudne do utrzymania, rozważ przejście do w pełni dostosowanego systemu.

Stopniowe wdrażanie

Nawet jeśli w końcu chcesz zautomatyzować płaszczyznę sterowania, niekoniecznie musisz zacząć od tego podejścia. Na początkowych etapach typowym podejściem do tworzenia aplikacji jest rozpoczęcie od ręcznej płaszczyzny sterowania. Gdy aplikacja ewoluuje i dołącza więcej najemców, zidentyfikuj obszary wąskich gardeł i w razie potrzeby automatyzuj je. Ta zmiana przenosi Cię w kierunku podejścia hybrydowego. W miarę automatyzowania większej liczby zadań można przejść do w pełni zautomatyzowanej płaszczyzny sterowania.

Antywzorce, których należy unikać

• Poleganie na ręcznych procesach zbyt długo: Procesy ręczne sprawdzają się dobrze, gdy dopiero zaczynasz działalność lub masz małą liczbę użytkowników i wymagają prostego zarządzania. Należy jednak zaplanować skalowanie do zautomatyzowanego rozwiązania w miarę rozwoju. Jeśli musisz zatrudnić więcej członków zespołu, aby nadążyć za zapotrzebowaniem procesów ręcznych, rozważ zautomatyzowanie części płaszczyzny sterowania.

• Używanie nieodpowiednich narzędzi do długotrwałych przepływów pracy: Nie używaj narzędzi, które mają limity środowiska uruchomieniowego, takie jak standardowe funkcje platformy Azure lub synchroniczne wywołania interfejsu API, w przypadku długotrwałych operacji, takich jak wdrożenia usługi Azure Resource Manager lub orkiestracja wieloetapowa. Zamiast tego użyj narzędzi, które obsługują długotrwałe przepływy pracy lub sekwencje operacji, takich jak Logic Apps i Durable Functions. Aby uzyskać więcej informacji, zobacz Azure Functions performance and reliability and Asynchronous Request-Reply pattern (Wzorzec wydajności i niezawodności usługi Azure Functions oraz asynchroniczny wzorzec Request-Reply).

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• John Downs | Główny inżynier oprogramowania
• Landon Pierce | Inżynier klienta

Inni współautorzy:

• Mick Alberts | Autor techniczny
• Bohdan Cherchyk | Starszy inżynier klienta
• Arsen Vladimirskiy | Główny Inżynier ds. Klientów

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Dalsze kroki

• Microsoft Power Platform
• Power Automate

Powiązane zasoby

• Zagadnienia dotyczące architektury płaszczyzn kontrolnych w rozwiązaniu wielodzierżawczym
• Podejścia architektoniczne dla rozwiązania wielodzierżawczego