Udostępnij za pośrednictwem

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

  • Artykuł

Płaszczyzny sterowania są ważną częścią oprogramowania jako usługi (SaaS) i rozwiązań wielodostępnych, zwłaszcza w celu ułatwienia zarządzania rozwiązaniem na dużą skalę. Zazwyczaj istnieją dwa główne składniki tworzące płaszczyznę sterowania:

  • Wykaz dzierżaw, w którym przechowywane są ważne informacje o dzierżawach, takie jak:
    • Konfiguracja dzierżawy.
    • Jednostki SKU wdrożone dla zasobów dzierżawy.
    • Do których sygnatur wdrożenia są przydzielane dzierżawy.
  • Procesy zarządzania zmianami w środowisku, które są wyzwalane przez zdarzenia cyklu życia dzierżawy. Na przykład dołączanie dzierżawy, odłączanie dzierżawy i wszelkie wymagane regularne konserwacje.

Sama płaszczyzna sterowania jest aplikacją. Należy dokładnie zastanowić się nad płaszczyzną sterowania i zaprojektować ją za pomocą tego samego rygora i zadbać o użycie z inną częścią rozwiązania. Aby uzyskać więcej informacji na temat płaszczyzny sterowania, dlaczego należy jej używać i zagadnień dotyczących projektowania, zobacz Zagadnienia dotyczące wielodostępnych płaszczyzn sterowania.

W tym artykule opisano niektóre podejścia, które można wziąć pod uwagę podczas projektowania i tworzenia płaszczyzny sterowania. Lista opisanych tutaj podejść nie jest kompleksowa. Chociaż wszystkie podejścia są prawidłowe, istnieją inne prawidłowe architektury.

Podejścia i wzorce do rozważenia

W poniższej tabeli przedstawiono podsumowanie różnic między niektórymi podejściami, które można wziąć pod uwagę w przypadku płaszczyzny sterowania. Porównywane są podejścia ręczne, małe i niestandardowe.

Kwestie wymagające rozważenia Ręcznie Niski kod Niestandardowy
Obciążenie operacyjne Wys. Niski średni Niski
Częstotliwość zdarzeń cyklu życia, dla których jest odpowiednie podejście Rzadki Okazjonalnie często Często
Czas i złożoność implementacji Niski Śred. Wys.
Obowiązki związane z konserwacją płaszczyzny sterowania Niski Śred. Wys.
Możliwość testowania Niski Śred. Wys.
Ryzyko niespójności Wys. Średnio-niski Niski

Procesy ręczne

Nie zawsze ważne jest utworzenie w pełni zautomatyzowanej płaszczyzny sterowania, zwłaszcza gdy zaczynasz i masz tylko niewielką liczbę dzierżaw.

Katalog dzierżaw może znajdować się gdzieś centralnie, na przykład w skoroszycie programu Excel lub pliku JSON, który jest przechowywany w miejscu, do którego twój zespół może uzyskać dostęp. Niezależnie od formatu warto przechowywać informacje w ustrukturyzowany sposób, dzięki czemu można łatwo pracować z danymi programowo.

Uwaga

Ręczna płaszczyzna sterowania to doskonały sposób na rozpoczęcie zarządzania aplikacją wielodostępną, ale nadaje się tylko dla niewielkiej liczby dzierżaw (mniej niż 5–10). Obciążenie administracyjne i ryzyko niespójności rosną wraz z każdą dzierżawą, którą dołączasz ręcznie. Tej metody należy używać tylko wtedy, gdy masz tylko kilka dzierżaw i nie potrzebujesz automatycznej ani samoobsługowej dołączania.

W przypadku procesów, takich jak dołączanie dzierżawy i działania konserwacji:

  • W miarę możliwości twórz skrypty lub zautomatyzowane potoki, nawet jeśli są uruchamiane ręcznie. Korzystając ze skryptów lub potoków, upewnij się, że kroki są wykonywane spójnie dla każdej dzierżawy.
  • W przypadku zadań, których nie można początkowo wykonać skryptu, należy dokładnie i szczegółowo udokumentować proces. Udomentuj, jak również dlaczego. Jeśli ktoś skończy automatyzować zadanie w przyszłości, powinien mieć dobre zrozumienie obu.

Na poniższym diagramie przedstawiono jeden ze sposobów użycia procesów ręcznych dla początkowej płaszczyzny sterowania:

Diagram przedstawiający jeden sposób używania skryptów i innych procesów ręcznych dla płaszczyzny sterowania.

Pobierz plik programu Visio z tą architekturą.

Zalety podejścia ręcznego

  • Uproszczone: dokumentacja, skrypty i potoki są łatwe do opracowywania i modyfikowania. Sprawia to, że są one odpowiednie podczas określania procesów, ponieważ można je szybko iterować i rozwijać.
  • Niski koszt: Utrzymywanie i uruchamianie ręcznego podejścia jest niedrogie.
  • Weryfikuje proces: Nawet jeśli w końcu zamierzasz użyć bardziej zautomatyzowanego podejścia, począwszy od podejścia ręcznego jako weryfikacji koncepcji, jest dobrym sposobem weryfikacji strategii konserwacji przed zainwestowanie czasu w opracowanie bardziej niezawodnej automatyzacji.

Wady podejścia ręcznego

  • Brak kontroli: Takie podejście opiera się na każdym zaangażowanym wykonywaniu właściwej rzeczy. 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 znacznie trudniejsze.
  • Wyzwania związane z kontrolą dostępu: w przypadku korzystania z tego podejścia zazwyczaj trzeba udzielić szeroko określonego, wysoce permisywnego dostępu do każdego, kto obsługuje rozwiązanie, co utrudnia stosowanie najlepszych rozwiązań dotyczących segmentacji dostępu.
  • Skalowalność: praca wymagana do uruchamiania procesów ręcznych jest skalowana z liczbą dzierżaw, 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 twój zespół nie może nadążyć za ilością pracy, którą musi wykonać, aby utrzymać aplikację. Na przykład gdy liczba dzierżaw jest skalowana poza krytyczny punkt, który dla większości zespołów wynosi od 5 do 10 dzierżaw.
  • Jeśli przewidujesz wzrost dzierżawy poza krytyczną liczbę dzierżaw i musisz przygotować się do pracy zaangażowanej w administrowanie liczbą dzierżaw.
  • Gdy trzeba ograniczyć ryzyko niespójności. Możesz na przykład zaobserwować błędy występujące, ponieważ ktoś nie wykonuje poprawnie procesów lub ponieważ w procesach występuje zbyt wiele niejednoznaczności. Ryzyko niespójności zwykle rośnie w miarę ręcznego dołączania większej liczby dzierżaw i rozwoju zespołu.

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

Płaszczyzna sterowania o niskim kodzie lub bez kodu jest oparta na platformie zaprojektowanej do automatyzacji procesów biznesowych i śledzenia informacji. Istnieje wiele platform, które umożliwiają wykonywanie tych zadań bez konieczności pisania kodu niestandardowego.

Platforma Microsoft Power Platform jest przykładem jednej z tych platform. Jeśli używasz platformy Power Platform, możesz zachować katalog dzierżaw w usłudze Dynamics 365, Dataverse lub Microsoft 365. Możesz również rozważyć utrzymanie tego samego katalogu dzierżawy używanego w procesach ręcznych, jeśli nie chcesz w pełni zatwierdzać automatyzacji wszystkiego na początku.

W przypadku dołączania i konserwacji dzierżawy można uruchamiać przepływy pracy, które wykonują zarządzanie dzierżawami, konfigurować dzierżawy, wyzwalać potoki lub wywołania interfejsu API itd. Usługa Power Automate umożliwia obserwowanie zmian w katalogu dzierżaw, jeśli dane są gdzieś dostępne dla usługi Power Automate. Jeśli używasz ręcznego wykazu dzierżaw, przepływy pracy usługi Power Automate mogą być również wyzwalane ręcznie. Możesz zdecydować się na ręczne kroki zatwierdzania w przepływach pracy, jeśli potrzebujesz kogoś z zespołu, aby zweryfikować coś lub wykonać dodatkowe kroki, które nie mogą być w pełni zautomatyzowane.

Takie podejście umożliwia również samoobsługowe rejestrowanie klientów, umożliwiając aplikacji internetowej bezpośrednie dodawanie rekordów do katalogu dzierżaw bez interwencji człowieka.

Na poniższym diagramie przedstawiono sposób tworzenia płaszczyzny sterowania z rejestracją samoobsługową przy użyciu platformy Microsoft Power Platform:

Diagram przedstawiający jeden ze sposobów używania usług Power Automate i Dataverse jako płaszczyzny sterowania z małą ilością kodu.

Pobierz plik programu Visio z tą architekturą.

Zalety podejścia o niskim kodzie

  • Uproszczone: często szybkie i niedrogie tworzenie zestawu przepływów pracy o niskim kodzie i łączenie ich z otaczającymi systemami.
  • Używa narzędzi platformy: możesz używać natywnych funkcji platformy do przechowywania danych, tworzenia portali administracyjnych do użycia przez zespół i monitorowania przepływów pracy podczas ich uruchamiania. Korzystając z natywnych funkcji platformy, unikaj samodzielnego tworzenia wielu składników.
  • Możliwość dostosowywania: jeśli potrzebujesz większej liczby dostosowań, możesz zwykle rozszerzyć przepływy pracy przy użyciu niestandardowego kodu i procesów. Możesz na przykład użyć usługi Power Automate do wyzwolenia przepływu pracy wdrażania w funkcji GitHub Actions lub wywołać usługę Azure Functions w celu uruchomienia własnego kodu. Ułatwia to również stopniowe wdrażanie.
  • Niskie obciążenie: usługi z niskim kodem są zwykle w pełni zarządzane, więc nie trzeba zarządzać infrastrukturą.

Wady podejścia o niskim kodzie

  • Wymagana wiedza: Aby używać platform z małą ilością kodu do tworzenia procesów i efektywnego korzystania z tych platform, zwykle potrzebna jest zastrzeżona wiedza. Wiele organizacji korzysta już z tych narzędzi, więc twój zespół może mieć już wymaganą wiedzę, ale może nie. Należy rozważyć, czy należy wytrenować zespół w celu efektywnego korzystania z tych platform.
  • Zarządzanie: zarządzanie może być trudne do obsługi zarządzania dużą ilością konfiguracji niskiego poziomu kodu.
  • Możliwość testowania: rozważ testowanie i podwyższanie poziomu zmian na płaszczyźnie sterowania. W zarządzanej platformie tworzenie typowego procesu DevOps na potrzeby testowania i promowania zmian jest trudniejsze, ponieważ zmiany są zwykle wprowadzane za pośrednictwem konfiguracji, a nie za pośrednictwem kodu.
  • Projektowanie: starannie zastanów się, jak spełnić wymagania niefunkcjonalne, takie jak zabezpieczenia i niezawodność. Te wymagania są często zarządzane na platformie o niskim kodzie.

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 w celu spełnienia Twoich potrzeb, prawdopodobnie warto odejść od rozwiązania zarządzanego i w kierunku niestandardowej płaszczyzny sterowania.

Niestandardowa płaszczyzna sterowania

Możesz również rozważyć utworzenie własnej całkowicie dostosowanej płaszczyzny 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. W tym przypadku nie pracujesz bezpośrednio z wykazem, ale zamiast tego zarządzasz nim za pomocą interfejsu administracyjnego, który może być aplikacją niestandardową lub systemem, takim jak aplikacja do zarządzania relacjami z klientami (CRM) w organizacji.

Zazwyczaj tworzy się zestaw składników płaszczyzny sterowania zaprojektowanych wokół wszystkich funkcji administracyjnych dzierżawy. Te składniki mogą obejmować portal administracyjny lub inny interfejs użytkownika, interfejs API i składniki przetwarzania w tle. Jeśli musisz wykonać takie czynności, jak wdrażanie kodu lub infrastruktury po wystąpieniu zdarzeń cyklu życia dzierżawy, potoki wdrażania mogą również składać się na płaszczyznę sterowania.

Upewnij się, że każde długotrwałe przetwarzanie korzysta z odpowiednich narzędzi. Możesz na przykład użyć rozszerzenia Durable Functions lub usługi Azure Logic Apps dla składników, które organizuje dołączanie dzierżawy lub wdrożenia, albo w przypadku składników, które muszą komunikować się z systemami zewnętrznymi.

Podobnie jak w przypadku podejścia z małą ilością kodu, takie podejście umożliwia samoobsługowe rejestrowanie klientów dzięki umożliwieniu aplikacji internetowej bezpośredniego dodawania rekordów do katalogu dzierżaw bez interwencji człowieka.

Na poniższym diagramie przedstawiono jeden ze sposobów utworzenia podstawowej niestandardowej płaszczyzny sterowania, która zapewnia rejestrację samoobsługową:

Diagram przedstawiający płaszczyznę sterowania utworzoną za pomocą rozszerzenia Durable Functions, bazy danych SQL i magistrali usług.

Pobierz plik programu Visio z tą architekturą.

Zalety podejścia niestandardowego

  • Pełna elastyczność i możliwość dostosowywania: masz pełną kontrolę nad tym, co robi płaszczyzna sterowania i może ją zmienić, jeśli wymagania się zmienią.
  • Możliwość testowania: możesz użyć standardowego cyklu życia tworzenia oprogramowania (SDLC) dla aplikacji płaszczyzny sterowania i zaimplementować normalne 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. Aby zapewnić niezawodność i bezpieczeństwo, należy zadbać o opracowywanie, testowanie i obsługę płaszczyzny sterowania.

Podejścia hybrydowe

Możesz również rozważyć użycie podejścia hybrydowego. Możesz użyć kombinacji systemów ręcznych i zautomatyzowanych lub użyć zarządzanej platformy, takiej jak Microsoft Power Platform, i rozszerzyć ją za pomocą aplikacji niestandardowych. Rozważ zaimplementowanie podejścia hybrydowego, jeśli potrzebujesz możliwości dostosowywania niestandardowej płaszczyzny sterowania, ale niekoniecznie chcesz tworzyć i obsługiwać w pełni niestandardowy system. Należy pamiętać, że w pewnym momencie automatyczne dostosowania procesów ręcznych lub zarządzanej platformy mogą stać się tak złożone, jak w pełni dostosowany system. Punkt zwrotny jest inny dla każdej organizacji, ale jeśli podejście hybrydowe jest uciążliwe do utrzymania, należy rozważyć przejście do w pełni niestandardowego systemu.

Stopniowe wdrażanie

Nawet jeśli wiesz, że chcesz w końcu zautomatyzować płaszczyznę sterowania, niekoniecznie musisz zacząć od tego podejścia. Typowym podejściem podczas początkowych etapów tworzenia aplikacji jest rozpoczęcie od ręcznej płaszczyzny sterowania. W miarę postępu aplikacji i dołączania większej liczby dzierżaw należy zacząć identyfikować obszary wąskich gardeł i automatyzować je w razie potrzeby, przechodząc do podejścia hybrydowego. W miarę automatyzowania większej liczby maszyn może być w pełni zautomatyzowana płaszczyzna sterowania.

Antywzorzecy, aby uniknąć

  • Poleganie na ręcznych procesach zbyt długo. Chociaż uzasadnione jest użycie procesów ręcznych podczas uruchamiania lub gdy masz małą liczbę dzierżaw i wymaga dość uproszczonego zarządzania, musisz zaplanować skalowanie do zautomatyzowanego rozwiązania w miarę rozwoju. Jeśli musisz zatrudnić dodatkowych członków zespołu, aby nadążyć za zapotrzebowaniem procesów ręcznych, to dobry znak, że należy zacząć automatyzować części płaszczyzny sterowania.
  • Używanie nieodpowiednich narzędzi do długotrwałych przepływów pracy. Na przykład unikaj używania standardowych funkcji platformy Azure, synchronicznych wywołań interfejsu API lub innych narzędzi, które mają limit czasu wykonywania w celu wykonywania długotrwałych operacji, takich jak wdrożenia usługi Azure Resource Manager lub aranżacje wieloetapowe. Zamiast tego użyj narzędzi, takich jak Azure Logic Apps, Durable Functions i inne narzędzia, które mogą wykonywać długotrwałe przepływy pracy lub sekwencje operacji. Aby uzyskać więcej informacji, zobacz Azure Functions performance and reliability and Asynchronous Request-Reply pattern (Wzorzec asynchronicznego żądania i odpowiedzi na żądanie w usłudze Azure Functions).

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inni współautorzy:

Następne kroki