Zasady projektowania stref docelowych platformy Azure
Koncepcyjna architektura stref docelowych platformy Azure jest powszechnie stosowana do dowolnego procesu lub implementacji stref docelowych. Podstawą architektury jest zestaw podstawowych zasad projektowania, które służą jako kompas dla kolejnych decyzji projektowych w krytycznych domenach technicznych.
Zasady pomagają dążyć do optymalnego projektowania architektury docelowej. Jeśli zdecydujesz się wdrożyć akcelerator strefy docelowej platformy Azure lub dowolną wersję bazy kodu strefy docelowej w skali przedsiębiorstwa, skompiluj architekturę, stosując zasady projektowania opisane tutaj.
Zastosowanie tych zasad w ramach implementacji będzie stanowić przydatny przewodnik dotyczący realizacji korzyści związanych z technologiami chmury. Ta perspektywa zorientowana na chmurę, często nazywana natywną chmurą, reprezentuje sposoby pracy i opcji technicznych dla organizacji, które zwykle nie oferują starszych metod technologicznych.
Wpływ odchyleń projektowych
Mogą istnieć ważne powody, aby odbiegać od zasad, takich jak w przypadku firmy Tailwind Traders. 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 opisanymi dla każdej zasady.
Ogólnie rzecz biorąc, należy przygotować się do zrównoważenia wymagań i funkcjonalności. Twoja droga do architektury koncepcyjnej będzie się rozwijać z czasem, gdy wymagania będą się zmieniać, a Ty będziesz się uczyć na podstawie swojej implementacji. Na przykład korzystanie z usług w wersji zapoznawczej i opieranie się na mapach drogowych usług może usuwać blokady techniczne podczas wdrażania.
Demokratyzacja subskrypcji
Użyj subskrypcji jako jednostki zarządzania i skalowania, aby przyspieszyć migracje aplikacji i tworzenie nowych aplikacji. Dopasuj subskrypcje do potrzeb biznesowych i priorytetów, aby wspierać obszary biznesowe i właścicieli portfela. Udostępnianie subskrypcji jednostkom biznesowym w celu obsługi projektowania, programowania i testowania nowych obciążeń oraz migracji istniejących obciążeń.
Aby umożliwić organizacji efektywne działanie na dużą skalę, należy obsługiwać subskrypcję z odpowiednią hierarchią grup zarządzania . Ta obsługa umożliwi efektywne zarządzanie i organizowanie subskrypcji.
Wpływ odchylenia
Jedną z metod wdrażania tej zasady jest decentralizacja operacji poprzez przeniesienie ich do jednostek biznesowych i zespołów ds. obciążenia pracą. Takie podejście umożliwia właścicielom obciążeń większą kontrolę i autonomię nad swoimi obciążeniami w ramach barier zabezpieczających utworzonych przez podstawy platformy.
Klienci, którzy potrzebują scentralizowanych operacjii którzy nie chcą delegować kontroli nad środowiskami produkcyjnymi do zespołów obciążeń lub jednostek biznesowych, mogą potrzebować zmodyfikować swoją organizację zasobów projektu i odbiegać od tej zasady.
Projekt architektury koncepcyjnej stref docelowych platformy Azure zakłada określoną grupę zarządzania i hierarchię subskrypcji dla wszystkich subskrypcji zarządzania operacjami. To założenie może nie być zgodne z modelem operacyjnym .
Wraz z tą zmianą, w miarę wzrostu i rozwoju waszej organizacji, wasz model operacyjny może ulec zmianie. Ta zmiana może prowadzić do ponownej migracji zasobów do oddzielnych subskrypcji, a w konsekwencji do skomplikowanych migracji technicznych. Przed zatwierdzeniem podejścia zapoznaj się ze wskazówkami dotyczącymi Align.
Zarządzanie oparte na zasadach
Użyj usługi Azure Policy, aby zapewnić zabezpieczenia i zapewnić ciągłą zgodność z platformą organizacji i wdrożonych na nim aplikacjami. Usługa Azure Policy zapewnia również właścicielom aplikacji niezależność i bezpieczną ścieżkę do chmury.
Wpływ odchylenia
Nie używając usługi Azure Policy do tworzenia barier zabezpieczających w danym środowisku, zwiększasz nakład pracy i zarządzania utrzymaniem zgodności. Usługa Azure Policy ułatwia ograniczanie i automatyzowanie żądanego stanu zgodności w środowisku.
W ramach zagadnień projektowych przejrzyj , jak używać usługi Azure Policy wewnątrz implementacji strefy docelowej.
Pojedyncza płaszczyzna sterowania i zarządzania
Unikaj zależności od warstw abstrakcji, takich jak portale opracowane przez klienta lub narzędzia. Zdecydowanie zalecamy zapewnienie spójnych doświadczeń zarówno dla operacji centralnych, jak i operacji roboczych.
Platforma Azure zapewnia ujednoliconą i spójną płaszczyznę sterowania, która podlega kontroli opartej na rolach i sterowanych zasadami. Dotyczy to wszystkich zasobów platformy Azure i kanałów aprowizacji. Za pomocą platformy Azure można ustanowić ustandaryzowany zestaw zasad i mechanizmów kontroli dotyczących zarządzania całym majątkiem przedsiębiorstwa.
Wpływ odchylenia
Wybranie podejścia z wieloma dostawcami do obsługi płaszczyzn kontroli i zarządzania może spowodować złożoność obsługi integracji i funkcji. Zastąpienie poszczególnych składników w celu osiągnięcia "najlepszego rozwiązania w swojej klasie" lub narzędzi do zarządzania operacjami z wieloma dostawcami może mieć ograniczenia i spowodować niezamierzone błędy z powodu wbudowanych zależności.
W przypadku klientów, którzy wnoszą istniejące inwestycje w narzędzia do operacji, bezpieczeństwa lub zarządzania, zalecamy przejrzenie usług platformy Azure i wszelkich zależności.
Model usługi skoncentrowanej na aplikacji
Skoncentruj się na migracjach i rozwoju zorientowanych na aplikacje, a nie na prostych migracjach infrastruktury typu "lift-and-shift", takich jak przenoszenie maszyn wirtualnych. Wybory projektowe 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 wdrożonych na platformie Azure.
Wpływ odchylenia
Segmentowanie obciążeń w sposób, który różni się od opcji implementacji dla hierarchii grup zarządzania, może utworzyć złożoną strukturę zasad i kontroli dostępu w celu zarządzania środowiskiem. Przykłady obejmują odchylenie od struktury hierarchii organizacyjnej lub grupowania według usługi platformy Azure. Kompromis ten wprowadza ryzyko niezamierzonych duplikacji i wyjątków zasad, co zwiększa nakład pracy operacyjnej i zarządzania.
Innym typowym podejściem, które rozważają klienci, jest użycie stref docelowych na potrzeby obciążeń deweloperskich/testowych/produkcyjnych. Aby uzyskać więcej informacji, zobacz często zadawane pytania Jak obsługiwać strefy docelowe obciążeń „dev/test/production” w architekturze w skali przedsiębiorstwa?.
Dostosowanie do natywnego projektu i planów działania platformy Azure
Używaj natywnych dla platformy Azure usług i możliwości, jeśli to możliwe. Dostosuj to podejście do planów rozwoju platformy Azure, aby zapewnić dostępność nowych funkcji w środowiskach. Plany platformy Azure powinny pomóc w informowaniu o strategii migracji i koncepcyjnej trajektorii stref docelowych platformy Azure.
Wpływ odchylenia
Wprowadzenie rozwiązań innych firm do środowiska platformy Azure może stworzyć zależność od tych rozwiązań w celu zapewnienia obsługi funkcji i integracji z usługami platformy Azure.
Czasami wprowadzanie istniejących inwestycji w rozwiązania innych firm w środowisko jest nieuniknione. Należy uważnie rozważyć tę zasadę i jej kompromisy zgodnie z wymaganiami.
Zalecenia
Przygotuj się do kompromisu funkcjonalności, ponieważ jest mało prawdopodobne, że wszystko będzie wymagane pierwszego dnia. Korzystaj z usług w wersji zapoznawczej i uwzględnij zależności od map usług, aby usunąć blokady techniczne.
Pamiętaj, że nie wszystkie aspekty żądanego modelu operacyjnego będą ogólnie dostępne podczas korzystania z tego podejścia.