Zagadnienia dotyczące niezależnego dostawcy oprogramowania dla stref docelowych platformy Azure
W przypadku wielu organizacji architektura koncepcyjna stref docelowych platformy Azure reprezentuje miejsce docelowe podróży wdrażania chmury. Strefy docelowe opisują sposób tworzenia środowiska platformy Azure z wieloma subskrypcjami. Każda strefa docelowa odpowiada na potrzeby skalowania, zabezpieczeń, ładu, sieci i tożsamości oraz opiera się na opiniach i lekcjach uzyskanych od wielu klientów.
Napiwek
Warto myśleć o strefach docelowych platformy Azure jako o planach miejskich. Architektury obciążeń wdrożonych w strefie docelowej są jak plany budynków w mieście.
Przed budową budynków muszą istnieć systemy wody, gazu, energii elektrycznej i transportu. Podobnie składniki strefy docelowej platformy Azure, w tym grupy zarządzania, zasady, subskrypcje i kontrola dostępu oparta na rolach (RBAC) muszą być stosowane przed wdrożeniem obciążeń produkcyjnych.
Jako niezależny dostawca oprogramowania (ISV) kompilowanie i obsługa rozwiązania na platformie Azure należy odwołać się do następujących zasobów podczas tworzenia środowiska platformy Azure:
- Strefy docelowe platformy Azure: zawiera wskazówki dotyczące ogólnego środowiska platformy Azure.
- Platforma Azure Well-Architected Framework: zapewnia wskazówki dotyczące architektury dotyczące wszystkich obciążeń.
- Tworzenie architektury wielodostępnych rozwiązań na platformie Azure: zapewnia konkretne wskazówki dotyczące architektury dla wielodostępnych rozwiązań na platformie Azure.
Strefy docelowe platformy Azure ułatwiają wybór kierunku dla ogólnego środowiska platformy Azure. Jednak jako niezależnego dostawcy oprogramowania, dostawcy SaaS lub uruchamiania konkretne potrzeby implementacji mogą różnić się od bardziej standardowych scenariuszy klientów. Poniżej przedstawiono kilka różnych przykładów scenariuszy implementacji:
- Tworzysz oprogramowanie, które klienci wdrażają we własnych subskrypcjach.
- Masz własną płaszczyznę sterowania i używasz skryptów automatyzacji lub oprogramowania do wdrażania i konfigurowania zasobów platformy Azure dla rozwiązań SaaS.
- Jesteś małym dostawcą oprogramowania lub startupem i chcesz zacząć od najniższego możliwego kosztu i może nie chcieć początkowo korzystać z usług, takich jak Azure Firewall i Azure DDoS Protection.
- Jesteś dużym dostawcą oprogramowania SaaS i planujesz podzielenie aplikacji SaaS między wiele subskrypcji na potrzeby skalowania. Chcesz również zgrupować subskrypcje, aby odpowiadały one twoim środowiskom deweloperskim, testowym, przejściowym i produkcyjnym.
- Model operacyjny organizacji oddziela role firmowego zespołu IT i zespołów produktów SaaS. Firmowy zespół IT twojej organizacji może zarządzać zasobami, takimi jak Microsoft Office 365 i Microsoft Teams, a zespół produktu SaaS może być odpowiedzialny za tworzenie i obsługę produktu SaaS (w tym jej centralnych składników platformy i tożsamości).
Uwaga
Czasami niezależnych dostawców oprogramowania chce zacząć od tylko jednej subskrypcji platformy Azure, która obejmuje zarówno aspekty "usług udostępnionych" platformy, jak i rzeczywiste zasoby obciążenia. Chociaż jest to technicznie możliwe, później będziesz napotykać wyzwania, gdy trzeba przenieść zasoby między subskrypcjami i stwierdzić, że nie wszystkie typy zasobów można przenieść. Przejrzyj wpływ odchyleń projektowych, aby dowiedzieć się, jakie odchylenia są możliwe i jakie są ich różne poziomy ryzyka.
Modele wdrażania niezależnego dostawcy oprogramowania
Rozwiązania niezależnego dostawcy oprogramowania często pasują do jednego z trzech modeli wdrażania: czystego modelu SaaS, wdrożonego przez klienta lub modelu SaaS z podwójnym wdrożeniem. W tej sekcji opisano różne zagadnienia dotyczące poszczególnych modeli dla stref docelowych platformy Azure.
Czysty SaaS
W czystym modelu SaaS twoje oprogramowanie jest wdrażane w pełni tylko w ramach subskrypcji platformy Azure. Klienci końcowi korzystają z oprogramowania bez wdrażania go we własnych subskrypcjach platformy Azure. Na poniższym diagramie użytkownicy korzystają z czystej aplikacji SaaS udostępnianej przez niezależnego dostawcę oprogramowania:
Przykłady czystego oprogramowania SaaS obejmują pocztę e-mail jako usługę, kafka-as-a-service, cloud-data-warehouse-as-a-service i wiele ofert SaaS w witrynie Azure Marketplace.
Jeśli jesteś małym dostawcą oprogramowania SaaS, możesz nie użyć wielu subskrypcji platformy Azure do wdrożenia zasobów od razu. Jednak w miarę skalowania limity subskrypcji platformy Azure mogą mieć wpływ na możliwość skalowania w ramach jednej subskrypcji. Zapoznaj się z zasadami projektowania strefy docelowej w skali przedsiębiorstwa, szczególnie demokratyzacją subskrypcji, i zapoznaj się z podejściami architektury do wielodostępności, aby zaplanować przyszły rozwój.
Niezależnych dostawców oprogramowania tworzących czyste rozwiązania SaaS powinny rozważyć następujące pytania:
- Czy wszystkie zasoby platformy Azure tworzące nasze rozwiązanie SaaS powinny znajdować się w jednej subskrypcji platformy Azure lub partycjonowane w wielu subskrypcjach platformy Azure?
- Czy każdy klient powinien być hostowany we własnej dedykowanej subskrypcji platformy Azure, czy też utworzyć zasoby w ramach jednej lub kilku udostępnionych subskrypcji?
- Jak można zastosować wzorzec sygnatury wdrożenia (jednostki skalowania) do wszystkich warstw rozwiązania?
- W jaki sposób możemy używać organizacji zasobów platformy Azure w rozwiązaniach wielodostępnych, aby sprostać wyzwaniom związanym ze skalowaniem i limitami subskrypcji platformy Azure?
Wdrożony przez klienta
W modelu wdrożonym przez klienta klienci końcowi kupują od Ciebie oprogramowanie, a następnie wdrażają je we własnych subskrypcjach platformy Azure. Mogą zainicjować wdrożenie z witryny Azure Marketplace lub wykonać je ręcznie, postępując zgodnie z instrukcjami i używając podanych skryptów.
Na poniższym diagramie dostawca oprogramowania udostępnia pakiet oprogramowania lub produkt katalogu witryny Azure Marketplace, a użytkownicy wdrażają ten zasób we własnych subskrypcjach platformy Azure wraz z innymi obciążeniami:
Inny element obciążenia klienta na diagramie może reprezentować własne obciążenie klienta lub inny produkt niezależnego dostawcy oprogramowania wdrożony w ramach subskrypcji platformy Azure. Klienci często wdrażają wiele produktów z różnych niezależnych dostawców oprogramowania do swoich subskrypcji platformy Azure. Łączą one te poszczególne produkty, aby tworzyć rozwiązania. Na przykład klient może wdrożyć produkt bazy danych z jednego niezależnego dostawcy oprogramowania, wirtualnego urządzenia sieciowego z innego niezależnego dostawcy oprogramowania i aplikacji internetowej z trzeciego niezależnego dostawcy oprogramowania.
Przykłady produktów niezależnego dostawcy oprogramowania wdrożonego przez klienta obejmują wiele obrazów maszyn wirtualnych (takich jak wirtualne urządzenia sieciowe i magazynowe) oraz aplikacje platformy Azure w witrynie Azure Marketplace.
W przypadku niektórych rozwiązań wdrożonych przez klienta organizacja może zapewnić zarządzanie rozwiązaniem wdrożonym w ramach subskrypcji platformy Azure dla klientów końcowych i aktualizacji go za pomocą usługi Azure Lighthouse lub aplikacji zarządzanych platformy Azure. Dostawcy niezależnych dostawców oprogramowania, integratorzy rozwiązań (SI) i dostawcy usług zarządzanych (MSP) mogą używać tej strategii, gdy spełnia określone potrzeby.
Rozwiązania niezależnego dostawcy oprogramowania wdrożone przez klienta są uznawane za standardowe obciążenie aplikacji z perspektywy stref docelowych platformy Azure. Zapoznaj się ze wskazówkami dotyczącymi stref docelowych platformy Azure podczas projektowania produktu do pracy z zasadami projektowania stref docelowych platformy Azure, które są wdrażane przez klientów platformy Azure.
Szczególnie ważne jest, aby dobrze zrozumieć pojęcia dotyczące strefy docelowej platformy Azure podczas migrowania obciążeń istniejących klientów na platformę Azure.
Dostawcy oprogramowania niezależnych dostawców oprogramowania tworzący rozwiązania wdrożone przez klienta powinni rozważyć następujące pytania:
- Czy klient powinien wdrożyć nasze rozwiązanie we własnej dedykowanej subskrypcji lub w istniejącej subskrypcji, która zawiera powiązane obciążenia?
- Jak klienci powinni ustanowić łączność sieciową między istniejącymi obciążeniami (wewnątrz i poza platformą Azure) a naszym rozwiązaniem?
- Czy nasze rozwiązanie obsługuje mechanizmy uwierzytelniania z identyfikatora Entra firmy Microsoft lub wymagają innych protokołów, takich jak LDAP lub Kerberos?
- Jak zmniejszyć lub wyeliminować naruszenia usługi Azure Policy, takie jak te spowodowane konfliktami między naszymi szablonami rozwiązań a zasadami platformy Azure klienta?
Zasady platformy Azure klienta, które mogą powodować naruszenia usługi Azure Policy, obejmują przykłady, takie jak "Wszystkie podsieci muszą mieć sieciową grupę zabezpieczeń" i "Nie można dołączyć publicznych adresów IP do interfejsów sieciowych w strefie docelowej Corp". Podczas planowania wdrożenia należy pamiętać o tych zasadach powodujących konflikty.
Rozwiązanie SaaS z podwójnym wdrożeniem
Niektóre rozwiązania SaaS współdziałają z zasobami wdrożonym w subskrypcjach platformy Azure klientów lub korzystają z nich. Ten model wdrażania jest czasami nazywany podwójnym wdrożeniem SaaS lub rozwiązaniem Hybrydowym SaaS. Na poniższym diagramie dostawca oprogramowania udostępnia hostowane rozwiązanie SaaS, które współdziała z zasobami wdrożonym w subskrypcji platformy Azure klienta końcowego:
Rzeczywistym przykładem podwójnego wdrożenia SaaS jest usługa Microsoft Power BI, usługa SaaS, która opcjonalnie może używać lokalnej bramy danych usługi Power BI wdrożonej na maszynie wirtualnej w subskrypcji platformy Azure klienta.
Inne przykłady scenariuszy SaaS z podwójnym wdrożeniem obejmują:
- Twoja organizacja tworzy program Virtual Desktop Manager, produkt, który udostępnia interfejs konsoli SaaS do kontrolowania zasobów usługi Azure Virtual Desktop w ramach subskrypcji platformy Azure każdego klienta.
- Twoja organizacja udostępnia konsolę SaaS do analizy danych i dynamicznie tworzy i usuwa maszyny wirtualne węzłów obliczeniowych w subskrypcji platformy Azure każdego klienta.
Jako niezależnego dostawcy oprogramowania z podwójnym wdrożeniem należy zapoznać się ze strefą docelową platformy Azure, aby uzyskać wskazówki w dwóch obszarach: strukturyzowanie własnego środowiska platformy Azure w celu hostowania usługi SaaS i zapewnienie prawidłowej interakcji między wdrożeniami w subskrypcjach platformy Azure klientów a strefami docelowymi klientów.
Niezależnych dostawców oprogramowania tworzących rozwiązania SaaS z podwójnym wdrożeniem powinny rozważyć następujące pytania:
- Czy przejrzeliśmy wszystkie zagadnienia dotyczące tworzenia zarówno czystych rozwiązań SaaS, jak i wdrożonych przez klientów?
- Które składniki naszego rozwiązania powinny być hostowane w naszych subskrypcjach platformy Azure i które składniki powinny być wdrażane przez klienta?
- Jak zapewnić bezpieczną aprowizację i interakcje z zasobami wdrożonym w subskrypcjach platformy Azure naszych klientów?
Zasady i implementacje projektowania strefy docelowej platformy Azure
Zasady projektowania strefy docelowej platformy Azure zalecamy dostosowanie do natywnych dla platformy Azure możliwości platformy, takich jak Log Analytics, Azure Monitor i Azure Firewall. Wskazówki dotyczące strefy docelowej zawierają również określone opcje implementacji strefy docelowej platformy Azure.
Jako niezależnego dostawcy oprogramowania możesz zdecydować się na wdrożenie własnych środowisk strefy docelowej. Może być konieczne użycie własnej automatyzacji w celu wdrożenia zasobów platformy Azure w ramach subskrypcji. Możesz też nadal korzystać z narzędzi, które są już używane do rejestrowania, monitorowania i innych usług warstwowych platformy.
Jeśli zaimplementujesz własne środowiska strefy docelowej, zalecamy użycie wskazówek dotyczących strefy docelowej platformy Azure i przykładowych implementacji do celów referencyjnych oraz dostosowanie podejścia do sprawdzonych projektów stref docelowych platformy Azure.
Dzierżawy firmy Microsoft Entra
Każda strefa docelowa platformy Azure i jej hierarchia grup zarządzania jest zakorzeniona w jednej dzierżawie firmy Microsoft Entra. Oznacza to, że pierwszą decyzją, którą należy podjąć, jest dzierżawa firmy Microsoft Entra do użycia jako źródło tożsamości do zarządzania zasobami platformy Azure. Tożsamości w identyfikatorze Entra firmy Microsoft obejmują użytkowników, grupy i jednostki usługi.
Napiwek
Dzierżawa firmy Microsoft Entra wybrana dla strefy docelowej nie ma wpływu na uwierzytelnianie na poziomie aplikacji. Nadal możesz używać innych dostawców tożsamości, takich jak Azure AD B2C, niezależnie od wybranej dzierżawy.
Wskazówki dotyczące stref docelowych platformy Azure i dzierżaw firmy Microsoft Entra zdecydowanie zaleca korzystanie z jednej dzierżawy firmy Microsoft Entra i jest to prawidłowe podejście w większości sytuacji. Jednak jako niezależnego dostawcy oprogramowania SaaS może być konieczne użycie dwóch dzierżaw.
W przypadku niektórych niezależnych dostawców oprogramowania SaaS jeden zespół zarządza zasobami firmowymi, a oddzielny zespół obsługuje rozwiązanie SaaS. Takie rozdzielenie może być ze względów operacyjnych lub zgodne z wymaganiami prawnymi. Być może twój firmowy zespół IT nie może zarządzać żadnymi subskrypcjami i zasobami związanymi z usługą SaaS, więc nie mogą być administratorami dzierżawy firmy Microsoft Entra. Jeśli ten scenariusz dotyczy Ciebie, rozważ użycie dwóch oddzielnych dzierżaw firmy Microsoft Entra: jednej dzierżawy dla firmowych zasobów IT, takich jak usługa Office 365, i jednej dzierżawy dla zasobów platformy Azure, które składają się na rozwiązanie SaaS.
Każda dzierżawa firmy Microsoft Entra musi mieć własną nazwę domeny. Jeśli twoja organizacja korzysta z dwóch dzierżaw, możesz wybrać nazwę podobną contoso.com do swojej firmowej dzierżawy firmy Microsoft Entra i contoso-saas-ops.com dzierżawy SaaS Microsoft Entra, jak pokazano na poniższym diagramie.
Ostrzeżenie
W przypadku korzystania z wielu dzierżaw firmy Microsoft Entra zwiększa się obciążenie związane z zarządzaniem. Jeśli używasz funkcji Microsoft Entra ID P1 lub P2, takich jak Privileged Identity Management, musisz kupić indywidualne licencje dla każdej dzierżawy firmy Microsoft Entra. Najlepiej używać tylko wielu dzierżaw firmy Microsoft Entra, jeśli twoja sytuacja naprawdę tego wymaga.
Unikaj używania oddzielnych dzierżaw firmy Microsoft Entra w środowiskach przedprodukcyjnych i produkcyjnych. Zamiast tworzyć dwie dzierżawy, takie jak contoso-saas-ops-preprod.com i contoso-saas-ops-prod.com z oddzielnymi subskrypcjami platformy Azure w ramach każdej z nich, należy utworzyć jedną dzierżawę firmy Microsoft Entra. Za pomocą grup zarządzania i kontroli dostępu opartej na rolach platformy Azure można zarządzać dostępem do subskrypcji i zasobów w ramach tej pojedynczej dzierżawy.
Aby uzyskać więcej informacji na temat korzystania z wielu dzierżaw firmy Microsoft Entra, zobacz Strefy docelowe platformy Azure i wiele dzierżaw firmy Microsoft Entra i izolacja zasobów z wieloma dzierżawami.
Grupy zarządzania
Architektura koncepcyjna strefy docelowej platformy Azure zaleca użycie określonej hierarchii grup zarządzania. Jednak niezależnych dostawców oprogramowania może mieć inne wymagania niż inne organizacje. W tej sekcji opisano niektóre sposoby, w jaki organizacja niezależnego dostawcy oprogramowania może zdecydować się na przyjęcie różnych rozwiązań, niż zaleca architektura koncepcyjna strefy docelowej.
Grupa zarządzania najwyższego poziomu
Hierarchia grup zarządzania jest zagnieżdżona w ramach utworzonej przez platformę Azure grupy zarządzania grupą główną dzierżawy . Nie używasz grupy głównej dzierżawy bezpośrednio.
Standardowa organizacja, która ma scentralizowany zespół IT zarządzający platformą i usługami udostępnionymi (takimi jak rejestrowanie, sieć, tożsamość i zabezpieczenia) zwykle tworzy jedną grupę zarządzania najwyższego poziomu w ramach utworzonej przez platformę Azure grupy głównej dzierżawy i wdraża pozostałe grupy zarządzania poniżej. Ta grupa zarządzania najwyższego poziomu jest zwykle nazwana po samej organizacji (np . Contoso).
Jako niezależny dostawca oprogramowania SaaS możesz mieć jeden produkt SaaS lub mieć kilka oddzielnych produktów SaaS lub linii biznesowych. Chociaż zazwyczaj należy używać tej samej dzierżawy firmy Microsoft Entra do zarządzania zasobami platformy Azure we wszystkich produktach (zgodnie z opisem w sekcji Dzierżawy firmy Microsoft), w niektórych scenariuszach można wybrać wdrożenie wielu hierarchii grup zarządzania.
Zastanów się, jak niezależne są twoje produkty od siebie i zadaj sobie pytanie:
- Czy nasze produkty korzystają z tych samych platform na potrzeby metodyki DevOps, tożsamości, zabezpieczeń, łączności i rejestrowania?
- Czy te usługi współużytkowane są obsługiwane przez jeden centralny zespół?
Jeśli udzielono odpowiedzi na oba pytania, utwórz pojedynczą grupę zarządzania produktami SaaS najwyższego poziomu w grupie głównej dzierżawy.
Jeśli zamiast tego nie odpowiedziałeś, a każdy z produktów SaaS jest zarządzany i obsługiwany przez oddzielne zespoły platformy, rozważ utworzenie oddzielnej grupy zarządzania najwyższego poziomu dla każdego produktu, na przykład dwóch grup zarządzania najwyższego poziomu SaaS Product-01 i SaaS Product-02.
Napiwek
Rzadko zdarza się, że jeden niezależnego dostawcy oprogramowania ma więcej niż tylko kilka grup zarządzania najwyższego poziomu. Często kilka produktów można połączyć ze sobą ze względu na podobieństwa w sposobie zarządzania nimi i obsługi.
Takie podejście do zarządzania jest podobne do podejścia testowego dla stref docelowych w skali przedsiębiorstwa. Jednak zamiast tworzyć firmy Contoso i Contoso-Canary w grupie głównej Dzierżawy, w tym podejściu przykładowa firma utworzy w niej grupy zarządzania najwyższego poziomu specyficzne dla produktu Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 i Contoso-SaaS-Product-03. Ten scenariusz przedstawiono na poniższym diagramie:
Grupa zarządzania platformą
W hierarchii organizacji zasobów strefy docelowej platformy Azure grupa zarządzania platformą zawiera wszystkie subskrypcje platformy Azure hostujące składniki i usługi udostępnione używane przez obciążenia w subskrypcjach strefy docelowej. Przykłady składników wdrożonych w ramach subskrypcji platformy i usług udostępnionych obejmują scentralizowaną infrastrukturę rejestrowania (np. obszary robocze usługi Log Analytics), DevOps, zabezpieczenia, narzędzia automatyzacji, centralne zasoby sieciowe (takie jak plany hub-VNet i DDos Protection) oraz usługi płaszczyzny sterowania niezależnego dostawcy oprogramowania.
Grupa zarządzania platformą jest często podzielona na grupy podrzędne Identity, Management i Connectivity , aby zapewnić wygodne rozdzielenie ról i zasad dla klientów korporacyjnych.
W organizacji może istnieć jeden zespół, który zarządza wszystkimi udostępnionymi składnikami platformy, takimi jak tożsamość, sieć i zarządzanie. Jeśli tak, i jeśli nie masz planów oddzielenia tego zarządzania między wieloma zespołami, rozważ użycie jednej grupy zarządzania platformy .
Jeśli zamiast tego będziesz mieć oddzielne zespoły, które zarządzają różnymi częściami scentralizowanej platformy, należy wdrożyć kolejne poziomy w hierarchii grup zarządzania w grupie zarządzania platformy . Dzięki temu można przypisać oddzielne zasady dla każdej części scentralizowanej platformy.
Na poniższym diagramie przedstawiono dwie potencjalne implementacje grupy zarządzania platformą . Opcja A przedstawia bardziej kompleksowy scenariusz, w którym grupa zarządzania platformą zawiera trzy podrzędne grupy zarządzania: zarządzanie i metodyka DevOps, tożsamość i zabezpieczenia oraz łączność. Każda podrzędna grupa zarządzania zawiera subskrypcję z odpowiednimi zasobami. Opcja B przedstawia prostszy scenariusz, w którym grupa zarządzania platformą zawiera jedną subskrypcję platformy.
Grupa zarządzania strefami docelowymi
Grupa zarządzania Strefy docelowe zawiera subskrypcje platformy Azure hostujące rzeczywiste podsystemy i obciążenia rozwiązania SaaS.
Ta grupa zarządzania zawiera co najmniej jedną podrzędną grupę zarządzania. Każda podrzędna grupa zarządzania w obszarze Strefy docelowe reprezentuje archetyp obciążenia lub podsystemu z spójnymi zasadami i wymaganiami dotyczącymi dostępu, które powinny mieć zastosowanie do wszystkich subskrypcji. Przyczyny używania wielu archetypów obejmują:
- Zgodność: jeśli podsystem produktu SaaS musi być zgodny ze standardem PCI-DSS, rozważ utworzenie grupy zarządzania podrzędnego PCI DSS w obszarze Strefy docelowe. Wszystkie subskrypcje platformy Azure, które zawierają zasoby w zakresie zgodności ze standardem PCI-DSS, powinny zostać umieszczone w tej grupie zarządzania.
- Warstwy: rozważ utworzenie oddzielnych archetypów strefy docelowej dla klientów z dedykowaną warstwą rozwiązania SaaS i klientów w warstwie Bezpłatna. Każda z podrzędnych grup zarządzania zawiera różne ustawienia usługi Azure Policy. Na przykład zasady w warstwie Bezpłatna mogą ograniczać wdrożenia tak, aby włączały tylko określone jednostki SKU maszyn wirtualnych, a zasady w warstwie dedykowanej mogą wymagać wdrożenia zasobów w określonych regionach.
Grupy zarządzania specyficzne dla środowiska
Dostawcy oprogramowania SaaS często organizują swoje środowiska w chmurze, modelując środowiska cyklu życia tworzenia oprogramowania w sekwencji. Zwykle wymaga to najpierw wdrożenia w środowisku deweloperskim, a następnie w środowisku testowym, a następnie w środowisku przejściowym, a na koniec w środowisku produkcyjnym.
Jedną z typowych różnic między środowiskami jest ich reguły RBAC platformy Azure, takie jak osoby, które mogą uzyskiwać dostęp do każdej grupy subskrypcji. Na przykład zespoły DevOps, SaaSOps, programistyczne i testowe mogą mieć różne poziomy dostępu do różnych środowisk.
Ważne
Większość klientów platformy Azure ma setki aplikacji i używa oddzielnych subskrypcji platformy Azure dla każdego zespołu aplikacji. Gdyby każda aplikacja miała własne grupy zarządzania programistyczne, testowe, przejściowe i produkcyjne, istniałaby duża liczba grup zarządzania z niemal identycznymi zasadami. W przypadku większości klientów często zadawane pytania dotyczące strefy docelowej w skali przedsiębiorstwa zaleca używanie oddzielnych grup zarządzania dla każdego środowiska. Zaleca się używanie oddzielnych subskrypcji w ramach jednej grupy zarządzania.
Jednak dostawcy oprogramowania SaaS mogą mieć inne wymagania niż większość innych klientów platformy Azure i mogą mieć dobry powód do korzystania z grup zarządzania specyficznych dla środowiska w niektórych sytuacjach.
Dostawcy oprogramowania SaaS czasami muszą grupować wiele subskrypcji reprezentujących fragmenty lub partycje tego samego podsystemu, aplikacji lub obciążenia. Może być konieczne zastosowanie zasad lub przypisań ról do grup subskrypcji w znacznie inny sposób niż w archetypowej grupie zarządzania. W takim przypadku należy rozważyć utworzenie podrzędnych grup zarządzania odpowiadających każdemu środowisku w ramach archetypowej grupy zarządzania.
Na poniższych diagramach przedstawiono dwie potencjalne opcje. Opcja A przedstawia scenariusz z oddzielnymi subskrypcjami dla każdego środowiska, ale bez grup zarządzania specyficznych dla środowiska. Opcja B przedstawia scenariusz niezależnego dostawcy oprogramowania SaaS z grupami zarządzania specyficznymi dla środowiska w grupie zarządzania Sygnatury regularne. Każda grupa zarządzania specyficzna dla środowiska zawiera wiele subskrypcji. W miarę upływu czasu niezależnego dostawcy oprogramowania skaluje swoje zasoby platformy Azure w każdym środowisku w coraz większej liczbie subskrypcji z typowym zestawem zasad i przypisań ról.
Wybierz każdą kartę, aby wyświetlić dwa diagramy.
Zlikwidowane grupy zarządzania i piaskownice
Wskazówki dotyczące organizacji zasobów strefy docelowej platformy Azure są zalecane, w tym grupy zarządzania Zlikwidowane i Piaskownice bezpośrednio poniżej grupy zarządzania najwyższego poziomu.
Zlikwidowana grupa zarządzania to miejsce przechowywania subskrypcji platformy Azure, które są wyłączone i ostatecznie zostaną usunięte. Możesz przenieść subskrypcję, która nie jest już używana do tej grupy zarządzania, aby śledzić ją do momentu trwałego usunięcia wszystkich zasobów w subskrypcji.
Grupa zarządzania Piaskownice zwykle zawiera subskrypcje platformy Azure, które są używane do celów eksploracji i mają luźne lub nie zastosowano do nich żadnych zasad. Możesz na przykład udostępnić poszczególnym deweloperom własne subskrypcje na potrzeby programowania i testowania. Można uniknąć stosowania normalnych zasad i ładu do tych subskrypcji, umieszczając je w grupie zarządzania Piaskownice . Zwiększa to elastyczność deweloperów i umożliwia im łatwe eksperymentowanie z platformą Azure.
Ważne
Subskrypcje w grupie zarządzania Piaskownice nie powinny mieć bezpośredniej łączności z subskrypcjami strefy docelowej. Unikaj łączenia subskrypcji piaskownicy z obciążeniami produkcyjnymi lub z dowolnymi środowiskami nieprodukcyjnymi, które dublować środowiska produkcyjne.
Na poniższym diagramie przedstawiono dwie potencjalne opcje. Opcja A nie obejmuje grup zarządzania Zlikwidowane i Piaskownica , natomiast opcja B.
Przykładowe strefy docelowe niezależnego dostawcy oprogramowania
Ta sekcja zawiera dwa przykładowe struktury strefy docelowej platformy Azure dla niezależnego dostawcy oprogramowania SaaS. Wybierz każdą kartę, aby porównać dwie przykładowe strefy docelowe.
Na poniższym diagramie przedstawiono przykładową hierarchię stref docelowych platformy Azure niezależnego dostawcy oprogramowania SaaS o następujących cechach:
- Niezależnego dostawcy oprogramowania przechowuje wszystkie składniki platformy w jednej subskrypcji platformy Azure, zamiast dzielić je na wiele grup zarządzania platformą.
- Istnieje tylko jedna grupa zarządzania strefą docelową.
- Strefa docelowa obejmuje grupy zarządzania specyficzne dla środowiska do organizowania subskrypcji i przypisywania różnych zasad i ról.
- Niezależnego dostawcy oprogramowania nie uwzględnili grup zarządzania dla zlikwidowanych subskrypcji i piaskownicy.
Następne kroki
- Jeśli tworzysz rozwiązanie wielodostępne, dowiedz się więcej na temat tworzenia architektury wielodostępnych rozwiązań na platformie Azure.
- Dowiedz się , co to jest strefa docelowa platformy Azure.
- Dowiedz się więcej o obszarach projektowych strefy docelowej platformy Azure.