Zasady projektowania strefy docelowej platformy Azure

Architektura referencyjna strefy docelowej platformy Azure jest powszechnie stosowana do dowolnego procesu lub implementacji strefy docelowej platformy Azure. Na podstawie architektury zestaw podstawowych zasad projektowania służy jako kompas dla kolejnych decyzji projektowych w krytycznych domenach technicznych.

Zasady są celowo aspiracyjne, aby pomóc w dążeniu do optymalnego projektu architektury docelowej. Jeśli zdecydujesz się wdrożyć implementację, która jest architekturą referencyjną strefy docelowej platformy Azure lub dowolną wersją bazy kodu strefy docelowej w skali przedsiębiorstwa, utwórz architekturę, stosując zasady projektowania opisane w tym artykule.

Użyj tych zasad w implementacji jako przydatnego przewodnika, aby zrealizować zalety technologii w chmurze. To podejście natywne dla chmury lub chmury reprezentuje sposoby pracy i opcji technicznych dla organizacji, które starsze podejścia technologiczne zwykle nie oferują.

Zapoznaj się z tymi zasadami, aby lepiej zrozumieć ich wpływ i kompromisy związane z odchyleniem.

Wpływ odchyleń projektowych

Mogą istnieć ważne powody, aby odbiegać od zasad projektowania. Na przykład wymagania organizacyjne mogą dyktować konkretne wyniki lub podejścia do projektowania środowiska platformy Azure. W takich przypadkach ważne jest, aby zrozumieć wpływ odchylenia na projekt i przyszłe operacje. Uważnie zastanów się nad kompromisami, które opisano w każdej zasadzie.

Ogólnie rzecz biorąc, należy przygotować się do zrównoważenia wymagań i funkcjonalności. Twoja podróż do architektury koncepcyjnej zmienia się wraz ze zmianą wymagań i uczysz się z implementacji. Na przykład korzystanie z usług w wersji zapoznawczej i w zależności od planów obsługi może usunąć blokady techniczne podczas wdrażania.

Demokratyzacja subskrypcji

Demokratyzacja subskrypcji zapewnia skalowalny sposób przyspieszania migracji aplikacji i tworzenia nowych aplikacji. Takie podejście umożliwia zespołom obciążeń niezależne uzyskiwanie dostępu do subskrypcji platformy Azure i zarządzanie nimi przy jednoczesnym zachowaniu ładu na platformie i zabezpieczeniach operacyjnych.

1. Użyj subskrypcji jako jednostek zarządzania. Subskrypcje reprezentują podstawową granicę organizowania zasobów platformy Azure i zarządzania nimi. Przypisz subskrypcje do jednostek biznesowych, aby obsługiwać projektowanie, programowanie, testowanie i migrację obciążeń. To dopasowanie do potrzeb biznesowych i priorytetów umożliwia właścicielom portfolio i zespołom obciążeń szybsze dostarczanie wartości.

2. Użyj subskrypcji, aby oddzielić środowiska aplikacji. Subskrypcje powinny być również używane do kontrolowania i segregowania środowisk w całym cyklu życia tworzenia oprogramowania (SDLC), takim jak programowanie, testowanie i produkcja. Ta separacja poprawia ład, zmniejsza ryzyko i obsługuje spójne zarządzanie obciążeniami. Postępuj zgodnie ze wskazówkami w temacie Zarządzanie środowiskami projektowymi aplikacji w strefach docelowych platformy Azure.

3. Włącz samoobsługowy proces sprzedaży subskrypcji. Ustanów proces, który umożliwia zespołom aplikacji i usług wysyłanie żądań i odbierania subskrypcji przy minimalnym tarciu. Samoobsługowy lub niemal samoobsługowy model zmniejsza opóźnienia spowodowane ręcznymi zatwierdzeniami i złożonymi rejestracjami biznesowymi. Postępuj zgodnie ze wskazówkami w temacie subskrypcja vending, aby usprawnić aprowizację i przyspieszyć innowacje.

4. Oferowanie wielu typów subskrypcji do obsługi różnych wymagań. Podaj szereg linii produktów subskrypcji dostosowanych do różnych scenariuszy obciążeń. Ta elastyczność umożliwia zespołom wybór najbardziej odpowiedniego typu subskrypcji dla swoich potrzeb. Zapoznaj się z tematem Ustanawianie typowych linii produktów do sprzedaży subskrypcji.

5. Obsługa subskrypcji z skalowalną hierarchią grup zarządzania. Użyj dobrze zdefiniowanej hierarchii grupy zarządzania , aby efektywnie obsługiwać, zarządzać i zabezpieczać subskrypcje na dużą skalę. Ta hierarchia umożliwia scentralizowane wymuszanie zasad i wydajną organizację z wieloma subskrypcjami. Postępuj zgodnie z zalecanymi hierarchiami i zaleceniami dotyczącymi projektowania i projektowania subskrypcji platformy Azure, aby zapewnić spójność.

Wpływ odchylenia

• Zarządzanie współdzielone a scentralizowane operacje. Jednym ze sposobów wdrożenia tej zasady jest przekazanie operacji do jednostek biznesowych i zespołów odpowiedzialnych za obciążenia. Dzięki temu ponownemu przypiszowi właściciele obciążeń mają większą kontrolę i autonomię nad swoimi obciążeniami w ramach mechanizmów ochrony podstawy platformy. Organizacje wymagające operacji centralnych mogą nie chcieć delegować kontroli nad środowiskami produkcyjnymi do zespołów obciążeń lub jednostek biznesowych. Organizacje te mogą wymagać zmodyfikowania projektu organizacji zasobów , aby odbiegać od tej zasady.

• Niezgodność modelu operacyjnego. Projekt architektury referencyjnej strefy docelowej platformy Azure zakłada określoną grupę zarządzania i hierarchię subskrypcji dla wszystkich subskrypcji zarządzania operacjami. Ta hierarchia może nie być zgodna z podejściem do operacji. Wraz ze wzrostem i rozwojem organizacji model operacyjny może ulec zmianie. Przenoszenie zasobów do oddzielnych subskrypcji może prowadzić do skomplikowanych migracji technicznych. Przed zatwierdzeniem podejścia zapoznaj się ze wskazówkami dotyczącymi wyrównania .

• Brak procesu sprzedaży subskrypcji i automatyzacji. Jeśli nie zapewnisz procesu sprzedaży subskrypcji i odpowiedniej automatyzacji, niezależnie od tego, czy jest to samoobsługa, czy nie, zespoły aplikacji i usług będą opóźnione w dostarczaniu wartości dla twojej organizacji, podczas gdy subskrypcje są tworzone dla nich i umieszczane we właściwej grupie zarządzania w hierarchii. Jeśli proces uzyskiwania nowych subskrypcji jest skomplikowany i zajmuje dużo czasu, zespoły aplikacji i usług mogą zdecydować się na samodzielne tworzenie subskrypcji za pośrednictwem alternatywnych kont rozliczeniowych, a także być może w niezarządzanych dzierżawach Microsoft Entra, co oznacza, że powstaje shadow IT.

Zarządzanie oparte na zasadach

Użyj usługi Azure Policy, aby zapewnić zabezpieczenia i zapewnić, że wdrożone aplikacje są zgodne z zabezpieczeniami, ładem i mechanizmami kontroli regulacyjnych organizacji, które są niezależne od narzędzi implementacji i konfiguracji. Usługa Azure Policy udostępnia zespołom platformy wymagane narzędzia do implementowania, wymuszania, inspekcji i kontrolowania operacji i konfiguracji płaszczyzny danych oraz kontroli nad platformą Azure. Dzięki temu subskrypcje mogą być zdemokratyzowane, najlepiej za pośrednictwem procesu samoobsługowego, zespołom aplikacji i usług, dzięki czemu mogą szybko dostarczać wartość biznesową dla organizacji.

Aby uzyskać więcej informacji na temat korzystania z usługi Azure Policy, zobacz Wdrażanie barier zabezpieczających opartych na zasadach.

Wpływ odchylenia

Zwiększone obciążenie operacyjne i związane z zarządzaniem. Jeśli nie używasz usługi Azure Policy do tworzenia barier zabezpieczających w danym środowisku, zwiększasz nakład pracy operacyjnej i zarządzania pod kątem utrzymania zgodności. Usługa Azure Policy ułatwia ograniczanie i automatyzowanie żądanego stanu zgodności w środowisku.

Pojedyncza płaszczyzna sterowania i zarządzania

Unikaj zależności od warstw abstrakcji, takich jak portale opracowane przez klienta lub narzędzia. Najlepiej mieć spójne środowisko zarówno dla operacji centralnych, jak i operacji związanych z obciążeniami. Platforma Azure udostępnia ujednoliconą i spójną płaszczyznę sterowania, która ma zastosowanie we wszystkich zasobach platformy Azure i kanałach aprowizacji, nazywanych usługą Azure Resource Manager. Płaszczyzna sterowania podlega kontroli dostępu opartej na rolach i kontroli sterowanych zasadami. Za pomocą tej płaszczyzny sterowania platformy Azure można ustanowić ustandaryzowany zestaw zasad i mechanizmów kontroli, które zarządzają całym infrastrukturą przedsiębiorstwa.

Wpływ odchylenia

Zwiększona złożoność integracji. Podejście wielodostawcy do płaszczyzn kontroli i zarządzania może wprowadzać złożoność integracji i obsługi funkcji. Zastąpienie poszczególnych komponentów, aby osiągnąć projektowanie klasy najlepszej w swojej klasie lub narzędzia do operacji wielowendorowej, ma ograniczenia i może spowodować niezamierzone błędy z powodu nieodłącznych zależności.

Jeśli integrujesz istniejące inwestycje w narzędzia z operacjami, bezpieczeństwem lub zarządzaniem, zapoznaj się z usługami platformy Azure i wszelkimi zależnościami.

Model usługi skoncentrowanej na aplikacji

Skoncentruj się na migracjach i rozwoju skoncentrowanym na aplikacjach, a nie na czysto infrastrukturalnych migracjach typu lift-and-shift, takich jak przenoszenie maszyn wirtualnych. Opcje projektowania nie powinny rozróżniać starych i nowych aplikacji, aplikacji infrastruktury jako usługi (IaaS) ani aplikacji platformy jako usługi (PaaS).

Niezależnie od modelu usług, staraj się zapewnić bezpieczne środowisko dla wszystkich aplikacji wdrażanych na platformie Azure.

Wpływ odchylenia

• Zwiększona złożoność zasad ładu. W przypadku segmentowania obciążeń różni się od opcji implementacji hierarchii grup zarządzania, zwiększa się złożoność zasad ładu i struktur kontroli dostępu, które zarządzają środowiskiem. Przykłady obejmują odchylenie od struktury hierarchii organizacyjnej lub grupowania według usługi platformy Azure.

• Zwiększone obciążenie operacyjne. Kompromis ten wprowadza ryzyko niezamierzonych duplikacji i wyjątków zasad, które dodają do obciążeń operacyjnych i związanych z zarządzaniem.

• Tworzenie i testowanie/produkcja to inne typowe podejście, które rozważają organizacje. Aby uzyskać więcej informacji, zobacz Jak obsługiwać strefy docelowe obciążeń "dev/test/production" w architekturze strefy docelowej platformy Azure.

Dostosowanie do natywnego projektu i planów działania platformy Azure

Używaj natywnych dla platformy Azure usług i możliwości zawsze, gdy tylko jest to możliwe. Takie podejście powinno być zgodne z planami platformy Azure, aby zapewnić dostępność nowych funkcji w środowiskach. Plany platformy Azure powinny pomóc w informowaniu o strategii migracji i koncepcyjnej trajektorii strefy docelowej platformy Azure.

Wpływ odchylenia

Zwiększona złożoność integracji. Wprowadzenie rozwiązań innych firm do środowiska platformy Azure może stworzyć zależność od tych rozwiązań, aby zapewnić obsługę funkcji i integrację z usługami pierwszej firmy platformy Azure.

Czasami integracja istniejących inwestycji w rozwiązania innych firm w środowisko jest nieunikniona. Rozważ tę zasadę i jej kompromisy dokładnie, aby dostosować się do Twoich wymagań.

Dalsze kroki

Organizacje mogą znajdować się na różnych etapach podróży w chmurze podczas przeglądania tych wskazówek. W związku z tym wymagane działania i zalecenia dotyczące postępu w kierunku powyższych wyników mogą się różnić. Aby zrozumieć najlepsze kolejne kroki dla etapu wdrażania chmury, zapoznaj się z procesem dochodzenia do architektury docelowej.

Aby wybrać odpowiednią opcję implementacji strefy docelowej platformy Azure, zapoznaj się z obszarami projektowania strefy docelowej platformy Azure.