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 rozwiązań 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. Podróż do architektury koncepcyjnej ewoluuje wraz ze zmianą wymagań i uczysz się z implementacji. Na przykład korzystanie z usług w wersji zapoznawczej i podejmowanie zależności od planów 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ę, obsługa subskrypcji 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 zdecentralizowanie operacji przez przeniesienie ich do jednostek biznesowych i zespołów obciążeń. 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 operacji i którzy nie chcą delegować kontroli nad środowiskami produkcyjnymi do zespołów obciążeń lub jednostek biznesowych, mogą potrzebować zmodyfikować projekt organizacji zasobów 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.
Z tym odchyleniem w miarę rozwoju i rozwoju organizacji model operacyjny może ulec zmianie. Ta zmiana może prowadzić do ponownego migracji zasobów do oddzielnych subskrypcji, a następnie skomplikowanych migracji technicznych. Przed zatwierdzeniem podejścia zapoznaj się ze wskazówkami dotyczącymi wyrównania .
Utrzymywanie ładu dzięki zasadom
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 Twoich zagadnień projektowych zapoznaj się ze sposobem korzystania z 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 posiadanie spójnego środowiska zarówno dla operacji centralnych, jak i operacji obciążeń.
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 projektu rasy" lub narzędzi do obsługi operacji wielu dostawców może mieć ograniczenia i spowodować niezamierzone błędy z powodu nieodłącznych zależności.
W przypadku klientów, którzy przynoszą istniejące inwestycje w narzędzia do operacji, zabezpieczeń lub ładu, zalecamy przejrzenie usług platformy Azure i wszelkich zależności.
Model usługi skoncentrowanej na aplikacji
Skoncentruj się na migracjach i programach skoncentrowanych na aplikacjach, a nie na czystych migracjach infrastruktury metodą "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 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ń "tworzenie/testowanie/produkcja" 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ędniaj zależności w planach rozwoju usług, aby usuwać bariery techniczne.
Pamiętaj, że nie wszystkie aspekty żądanego modelu operacyjnego będą ogólnie dostępne podczas korzystania z tego podejścia.