Ustanawianie typowych linii produktów sprzedaż abonamentów
Automat subskrypcji pomaga organizacjom osiągnąć zasady projektowania demokratyzacji subskrypcji stref docelowych platformy Azure, które mają kluczowe znaczenie dla spójnego skalowania, zabezpieczeń i ładu w środowiskach platformy Azure. Subskrypcja automatyzuje również organizacje zgodne z zasadami inżynierii platformy. Aby uzyskać więcej informacji, zobacz Adopt a product mindset and Empower developers through self-service with guardrails (Wdrażanie myślenia o produkcie i zwiększanie możliwości deweloperów za pomocą samoobsługi za pomocą barier zabezpieczających).
Wiele organizacji stara się zapewnić swoim zespołom aplikacji elastyczność, której potrzebują do efektywnego dostarczania obciążeń i usług. Jedną z kluczowych przeszkód jest brak ustandaryzowanego podejścia do sprzedaż abonamentów, co może prowadzić do nieporozumień, opóźnień i nieefektywności.
W tym artykule opisano, w jaki sposób zespoły platform mogą ustanowić wspólne linie produktów sprzedaż abonamentów, które zaspokajają zróżnicowane potrzeby różnych zespołów aplikacji. W tym artykule omówiono zalety oferowania różnych linii produktów i przedstawiono przykłady typowych scenariuszy opartych na rzeczywistych wdrożeniach klientów. Dowiesz się również, dlaczego sprzedaż abonamentów nie ma projektu "jeden rozmiar pasuje do wszystkich" i dlaczego musisz udostępnić różne linie produktów zespołom aplikacji.
Na poniższym diagramie przedstawiono organizację grup zarządzania i subskrypcji w środowisku platformy Azure.
W poniższych wskazówkach opisano, dlaczego mogą być wymagane różne linie produktów i opisano przykłady linii produktów dla klientów korzystających ze stref docelowych platformy Azure i sprzedaż abonamentów.
Korzystanie z różnych linii produktów
Subskrypcje, których zespoły aplikacji wymagają dostarczania obciążeń i usług, są dostępne w wielu typach i stylach. Poza zespołami aplikacji organizacja może mieć inne wymagania, które wymagają użycia subskrypcji platformy Azure, takie jak różne reguły zgodności i wzorce architektury.
Jeśli zdecydujesz się na podejście organizacji do projektowania i wdrażania sprzedaż abonamentów, rozważ zadawanie następujących pytań:
Jakie inne zasoby powinny być automatem zespołu platformy w ramach procesu sprzedaż abonamentów?
Czy dla każdego zespołu aplikacji domyślnie wdrażasz wiele subskrypcji, takich jak jeden na środowisko?
W przypadku każdej aplikacji domyślnie łączysz sieć wirtualną szprychy lub łączysz sieć wirtualną szprychy z koncentratorami łączności?
Jak należy utworzyć strukturę kontroli dostępu opartej na rolach (RBAC) w ramach każdej subskrypcji?
Jak należy zarządzać zasobami i stylami architektury lub archetypami używanymi w ramach subskrypcji i kontrolować je?
Nie można spełnić wszystkich unikatowych wymagań zespołu ds. aplikacji i platformy z dowolnym typem subskrypcji ani stylem subskrypcji, który jest automatycznie automat. Zespoły platformy muszą zapewnić elastyczność zespołów aplikacji, aby wybierać spośród wielu typów i stylów subskrypcji, które zespół może automatyzować do nich za pośrednictwem systemu samoobsługowego. Tego typu subskrypcje są określane jako linie produktów.
Organizacje, które zapewniają tylko "jeden rozmiar pasuje do wszystkich", aby sprzedaż abonamentów często ograniczać elastyczność swoich klientów wewnętrznych. Na przykład brak elastyczności może ograniczyć wybory projektowe architektury zespołu aplikacji i potencjalnie prowadzić do naruszenia z powodu tego, co zostały one automatyzowane.
W związku z tym zespoły platform muszą zapewnić różne linie produktów, aby zaspokoić potrzeby organizacji. Ta elastyczność gwarantuje, że konsumenci mogą wybrać linię produktu, która najlepiej spełnia ich wymagania.
Zarządzanie środowiskami aplikacji
Organizacja musi zarządzać środowiskami aplikacji dla zespołów aplikacji w ramach procesów i implementacji sprzedaż abonamentów. Należy jednak również zapewnić elastyczność, aby zespoły aplikacji mogły zarządzać swoimi środowiskami aplikacji, takimi jak tworzenie i testowanie/prod, sposób ich dostarczania. Aby uzyskać więcej informacji, zobacz Środowiska, subskrypcje i grupy zarządzania.
Niektóre usługi platformy Azure udostępniają funkcje natywne, które ułatwiają izolowanie środowiska w ramach pojedynczego wystąpienia zasobu w ramach jednej subskrypcji platformy Azure, takiej jak usługa aplikacja systemu Azure z funkcją miejsc wdrożenia. W tym przykładzie zespoły aplikacji wymuszają korzystanie z oddzielnych subskrypcji, dzięki czemu zespoły nie mogą korzystać z pełnego zestawu funkcji usług zapewnianych przez platformę Azure. Oddzielne subskrypcje mogą również zwiększyć koszty dostarczania aplikacji, w tym koszty operacyjne i konserwacyjne.
Projektowanie typowych linii produktów dla sprzedaż abonamentów
Teraz, gdy rozumiesz, że zespoły platformy muszą udostępniać wiele typów subskrypcji i stylów platformy Azure lub linii produktów użytkownikom swojej platformy Azure, w tej sekcji opisano kilka typowych linii produktów, których można używać w różnych branżach i krajach lub regionach.
Twój zespół ds. platformy powinien używać tych typowych sprzedaż abonamentów linii produktów jako punktu odniesienia. Twój zespół może udostępnić użytkownikom wiele opcji, które są gotowe, co jest zgodne z priorytetem zasady inżynierii platformy klientów . Takie podejście zapewnia klientom wewnętrznym swobodę korzystania z zasad projektowania strefy docelowej platformy Azure i zaleceń dotyczących obszaru projektowania w celu dostarczania obciążeń i usług, a także zapewniania ładu na platformie Azure.
Uwaga
Użyj tych przykładów jako punktu wyjścia. Możesz dostosować i rozwinąć te linie produktów, aby zaspokoić potrzeby organizacji.
Typowe linie produktów dla sprzedaż abonamentów obejmują:
Połączono z corp: obciążenia, które wymagają tradycyjnej łączności routingu adresów IP warstwy 3 z innymi aplikacjami i środowiskami lokalnymi za pośrednictwem subskrypcji łączność.
Online: obciążenia łączące się z innymi aplikacjami za pośrednictwem nowoczesnych usług łączności i architektur, takich jak usługa Azure Private Link lub interakcja za pośrednictwem uwidocznionych interfejsów API lub punktów końcowych z każdej aplikacji.
Platforma techniczna: obciążenia tworzące platformę, na której można tworzyć inne aplikacje. Na przykład flota klastrów usługi Azure Kubernetes Service (AKS), którymi zarządza zespół platformy usługi AKS, może hostować inne aplikacje w swoich klastrach AKS w imieniu innych zespołów aplikacji.
Portfolio aplikacji udostępnionych: Współdzielone obciążenia między tymi samymi zespołami aplikacji dla wspólnego zestawu ściśle powiązanych aplikacji. Nie chcesz hostować aplikacji samodzielnie ani z żadnym konkretnym obciążeniem.
Piaskownica: obszar, w którym zespoły aplikacji mogą tworzyć weryfikację koncepcji (PoC) lub minimalny produkt opłacalny (MVP) i nakładać mniej kontroli, dzięki czemu zespół może promować opracowywanie, wynalazek i swobodę tworzenia najlepszej możliwej aplikacji z katalogu dostępnych usług platformy Azure.
Linia produktu połączona z corp
Linia produktu połączona przez firmę, nazywana również wewnętrzną lub prywatną linią produktu, dla strefy docelowej aplikacji sprzedaż abonamentów zapewnia łączność za pośrednictwem tradycyjnych metod adresów IP warstwy 3. Możesz użyć tego wiersza produktu, aby zapewnić łączność między zasobami, które są:
W tej samej strefie docelowej aplikacji.
W różnych strefach docelowych aplikacji połączonych z siecią za pośrednictwem zapory platformy Azure lub wirtualnego urządzenia sieciowego (WUS).
Lokalnie lub w różnych chmurach za pośrednictwem usługi Azure ExpressRoute lub połączeń sieci VPN.
Organizacje korzystające z sprzedaż abonamentów często zawierają tę linię produktu, ponieważ są ściśle zgodne z tym, jak działają obecnie większość środowisk lokalnych. Jednak należy używać linii produktu połączonego z corp tylko wtedy, gdy jest to konieczne. Zalecamy, aby wolisz bardziej nowoczesne podejścia natywne dla chmury, takie jak linia produktów online, kiedy to możliwe.
Napiwek
Aby uzyskać informacje o różnicach między obciążeniami corp i online, zobacz What is the purpose of Connectivity, Corp, and Online management groups?.
Na poniższym diagramie przedstawiono przykład linii produktu połączonej sprzedaż abonamentów corp. Możesz użyć tej konfiguracji dla modelu sieci piasty i szprych, aby skutecznie zarządzać ruchem sieciowym i zasadami.
Kiedy używać linii połączonej produktu corp
Użyj linii połączonej produktu corp, gdy:
Chcesz wykonać migracje rehostu i refaktoryzacji oraz kompilacje aplikacji na podstawie pięciu r. racjonalizacji.
Chcesz rozpocząć podróż na platformie Azure i zapoznać się z podobną architekturą lokalną.
Chcesz "lift and shift" aplikacji na platformę Azure.
Chcesz zwiększyć bezpieczeństwo między obciążeniami przez izolowanie aplikacji do własnych subskrypcji strefy docelowej i przejście do zasad mikrosegmentacji z zerowego zaufania bez konieczności jeszcze zmieniania architektury aplikacji na w pełni natywną dla chmury.
Zanotuj te inne zagadnienia dotyczące linii produktu połączonej przez corp:
Zespół platformy może automatyzować sieć wirtualną do subskrypcji strefy docelowej aplikacji i połączyć sieć wirtualną z regionalną siecią wirtualną koncentratora lub koncentratorem Usługi Azure Virtual WAN. Twój zespół może następnie użyć narzędzia do zarządzania adresami IP (IPAM), aby kontrolować alokację adresów IP.
Zespoły platformy zwykle nie są podsieciami vend ani żadnymi innymi zasobami w sieci wirtualnej. Zamiast tego zespoły platform przypisują te działania do zespołów aplikacji, aby mogli projektować sieć aplikacji w sposób, w jaki chcą.
Zespoły platformy używają zasad platformy Azure przypisanych do grup zarządzania powyżej subskrypcji, aby wymusić żądane zachowanie, takie jak standardowe sieciowe grupy zabezpieczeń dołączone do każdej podsieci. Zespół aplikacji dziedziczy te zasady platformy Azure i nie może go edytować. Takie podejście jest zgodne z zasadą projektowania strefy docelowej platformy Azure w zakresie demokratyzacji subskrypcji.
Linia produktów online
Linia produktu online, nazywana również zewnętrzną lub publiczną linią produktu, dla strefy docelowej aplikacji sprzedaż abonamentów nie zapewnia łączności za pośrednictwem tradycyjnych metod adresów IP warstwy 3 między zasobami w innych strefach docelowych aplikacji lub lokalnie za pośrednictwem usługi ExpressRoute lub połączeń sieci VPN. Zasoby w tej samej subskrypcji strefy docelowej aplikacji online mogą używać sieci wirtualnych do komunikowania się ze sobą za pośrednictwem metod adresów IP warstwy 3. Jednak sieci wirtualne zwykle nie są równorzędne z regionalnymi centrami łączności ani innymi strefami docelowymi aplikacji.
Zamiast tego można zapewnić łączność za pośrednictwem interfejsów publicznych między zasobami, które są:
W różnych strefach docelowych aplikacji.
Lokalnie.
W obciążeniach, które znajdują się w różnych chmurach.
Połączenia można zabezpieczyć za pomocą mechanizmów kontroli sieci, funkcji uwierzytelniania i funkcji autoryzacji udostępnianych przez różne rozwiązania typu platforma jako usługa (PaaS), których używasz do konstruowania aplikacji.
Możesz użyć usługi Private Link i prywatnych punktów końcowych platformy Azure wewnątrz i między subskrypcjami strefy docelowej aplikacji online, aby włączyć i uwidocznić prywatną łączność opartą na warstwie 3 między aplikacjami. Można również użyć tego podejścia między usługami PaaS używanymi w strefach docelowych aplikacji, aby zapobiec użyciu publicznych interfejsów tych usług PaaS na potrzeby zabezpieczeń lub kontroli regulacyjnej.
Możesz również użyć usługi Private Link z prywatnymi punktami końcowymi , aby uwidocznić i opublikować aplikacje hostowane w strefach docelowych aplikacji online do połączonych stref docelowych aplikacji firmowych, lokalizacji lokalnych lub innych chmur. Prywatne punkty końcowe można umieszczać w strefach docelowych aplikacji połączonych z przedsiębiorstwa lub bezpośrednio w centrach łączności, które następnie udzielają dostępu do tych prywatnych punktów końcowych za pośrednictwem tradycyjnych metod łączności warstwy 3, takich jak komunikacja równorzędna sieci wirtualnych, połączenia usługi ExpressRoute lub połączenia sieci VPN.
Pomyśl o linii produktu strefy docelowej aplikacji online jako odizolowanych wyspach. Domyślnie jedynymi zasobami, które mogą uzyskiwać dostęp do zasobów w ramach subskrypcji, są zasoby wdrażane w ramach tej samej subskrypcji strefy docelowej aplikacji online. Jak wspomniano wcześniej, możesz użyć technik opisanych w tym artykule, aby rozszerzyć łączność z innymi strefami docelowymi aplikacji, lokalizacjami lokalnymi lub innymi chmurami.
Napiwek
Aby uzyskać więcej informacji na temat różnic między obciążeniami corp i online, zobacz What is the purpose of Connectivity, Corp, and Online management groups?.
Na poniższym diagramie przedstawiono przykład linii produktów online sprzedaż abonamentów.
Kiedy należy używać linii produktów online
Użyj linii produktów online, jeśli chcesz:
Refaktoryzacja, zmiana architektury, ponowne kompilowanie i wykonywanie migracji i kompilacji aplikacji na podstawie pięciu elementów racjonalizacji.
Zapewnij zespołom aplikacji w pełni zdemokratyzowaną strefę docelową aplikacji do użycia, nawet w odniesieniu do konfiguracji sieci.
Korzystaj z usług i architektur natywnych dla chmury.
Znacznie poprawić zgodność z zasadami zerowego zaufania.
Użyj linii połączonego produktu corp, ale prywatna przestrzeń adresów IP jest niedostępna lub ograniczona.
- W tym scenariuszu należy zapoznać się ze wskazówkami w artykule Zapobieganie wyczerpaniu protokołu IPv4 na platformie Azure.
Linia produktu platformy Tech
Zespoły korzystające z platform technologicznych, takich jak Azure VMware Solution lub Azure Virtual Desktop, powinny implementować linię produktu platformy technicznej. Linia produktów platformy technicznej jest zasadniczo sprzedaż abonamentów linii produktów, która lepiej odpowiada wymaganiom technicznym. Za pomocą linii produktów platformy technicznej można hostować duże i złożone obciążenia, które zwykle hostowały wiele aplikacji dla kilku innych zespołów aplikacji w całej organizacji i zarządzać nimi. Użyj tej linii produktu, jeśli zespół aplikacji zarządza tylko częściami aplikacji, a nie podstawowymi elementami platformy technologicznej.
Napiwek
Aby lepiej zrozumieć tę linię produktu, rozważ poniższy przykład. Zespół ds. platformy technologicznej, taki jak zespół usługi AKS, ma na celu oferowanie usługi AKS jako usługi zarządzanej innym zespołom aplikacji, które muszą uruchamiać swoje aplikacje na platformie AKS. Zespół ds. platformy technicznej usługi AKS zapewnia zarządzanie, konserwację, zabezpieczenia i konfigurację usługi AKS. W związku z tym zespół ds. aplikacji obsługuje tylko swoją aplikację i wdraża ją na platformie.
Możesz uwzględnić następujące produkty w linii produktów platformy technicznej:
Środowisko App Service Environment zazwyczaj za pośrednictwem oddzielnych planów usługi App Service.
Usługa AKS, zazwyczaj za pośrednictwem przestrzeni nazw w co najmniej jednym klastrze.
Maszyny wirtualne platformy Azure w klastrach lub hostach usługi Azure VMware Solution.
Usługa Azure Virtual Desktop umożliwia udostępnianie pulpitów wirtualnych lub aplikacji całej organizacji.
Te produkty można uwzględnić w liniach produktów połączonych w przedsiębiorstwie lub online , w zależności od wymagań dotyczących platformy technologicznej, którą zespół chce zapewnić jako usługę innym zespołom aplikacji w organizacji.
Portfolio aplikacji udostępnionych
Linia produktu portfolio aplikacji udostępnionej dla strefy docelowej aplikacji sprzedaż abonamentów dotyczy obciążeń, które nie wymagają kilku oddzielnych subskrypcji strefy docelowej aplikacji dla prostych aplikacji, które mogą być tworzone tylko z niewielkiej liczby zasobów platformy Azure.
Zespoły i działy aplikacji mogą używać tej linii produktu do hostowania kilku małych aplikacji lub składników udostępnionych, takich jak konta magazynu lub serwery SQL. Zespoły współdzielą te składniki między kilkoma własnymi aplikacjami w jednej subskrypcji lub niewielkiej liczbie subskrypcji.
Ważne
Wspólny zespół jest właścicielem subskrypcji, które jesteś automatem w ramach tej linii produktu. Ten zespół zarządza powiązanym portfolio aplikacji wdrażanych w tej subskrypcji dla tego produktu. Nie używaj tej linii produktów do ogólnych wdrożeń niepowiązanych obciążeń aplikacji, które mają odrębnych właścicieli portfolio aplikacji.
Zaplanuj uważnie, aby zapewnić ciągłą elastyczność, kontrolę dostępu, ład i łatwość utrzymania, jeśli organizacja zmieni się na jedną subskrypcję i używa grup zasobów do delegowania dostępu.
Jeśli rozważysz delegowanie grupy zasobów w jednej subskrypcji między wieloma zespołami, przed podjęciem ostatecznej decyzji należy uwzględnić następujące zagadnienia:
| Obszar | Kwestie wymagające rozważenia |
|---|---|
| Wspólna własność powiązanego portfela aplikacji | — Mieć wspólnego właściciela, takiego jak jednostka biznesowa działu, zarządzać aplikacjami, aby uprościć zarządzanie zmianami, tak aby pozostał w zakresie zatwierdzania tej samej jednostki. — Upewnij się, że obciążenia są zgodne z spójnym przypisaniem zasad w ramach subskrypcji, w tym rejestrowaniem, monitorowaniem i zabezpieczeniami. |
| Zgodność z przepisami | — Użyj zasad zarządzania dostępem i tożsamościami i platformy Azure, aby utworzyć subskrypcje dla obciążeń, które mają wymagania dotyczące zgodności z przepisami, w tym National Institute of Standards and Technology (NIST), Center for Internet Security Council (CIS), Payment Card Industry Security Standards Council (PCI SSC), wymagania branżowe i wymagania regionalne. Aby uzyskać więcej informacji, zobacz Dostosowywanie stref docelowych platformy Azure. — Tworzenie subskrypcji dla obciążeń korzystających z wymagań dotyczących prywatności i obsługi danych w celu zapewnienia ładu. Poszczególne subskrypcje zmniejszają dostęp. |
| Azure Policy | Określanie zakresu zasad platformy Azure do grup zarządzania, subskrypcji, grup zasobów i zasobów. Przypisz zasady platformy Azure na wysokim poziomie zakresu w celu zapewnienia efektywnego ładu podczas wdrażania zasobów w grupach zasobów. Podczas zarządzania usługą Azure Policy na poziomie zakresu grupy zasobów należy wziąć pod uwagę następujące ograniczenia: — Zwiększa obciążenie związane z zarządzaniem w celu utworzenia przypisań usługi Azure Policy podczas dodawania nowych grup zasobów do subskrypcji — Zwiększa obciążenie podczas zarządzania zmianami przypisań zasad — Zwiększa luki w zabezpieczeniach i zapewnianiu ładu, gdy zasady nie są natychmiast przypisywane do grup zasobów — Zmniejsza możliwość wprowadzania stanu zgodności w wysokich zakresach, takich jak grupy zarządzania i subskrypcje |
| Limity subskrypcji | — Sprawdź limity, aby upewnić się, że aplikacje nie osiągną twardych limitów, które uniemożliwiają wzrost. Każda subskrypcja ma miękkie i twarde limity dla usług platformy Azure. — Utwórz oddzielne subskrypcje dla aplikacji, które przewidują duże wzorce wzrostu spełniające limity subskrypcji. — Nie udostępniaj subskrypcji zespołom aplikacji z różnych jednostek biznesowych lub działów, aby zapobiec hałaśliwym problemom sąsiadów . |
| Usługi i wyrównanie funkcji platformy Azure | Usługi, które udostępniają podstawowe elementy pierwotne usług platformy Azure, takie jak Maszyny wirtualne, sieci wirtualne i proste usługi PaaS, można wdrożyć w ramach jednej grupy zasobów. Jednak złożoność nowoczesnych ofert złożonych może wymagać wdrożenia tych bardziej złożonych usług poza granicami pojedynczej grupy zasobów. Użyj innych zdemokratyzowanych metod subskrypcji opisanych wcześniej w tym artykule dla tych scenariuszy wdrażania. |
| Tylko zespoły platformy mogą tworzyć grupy zasobów | Jeśli udostępniasz subskrypcję między różnymi zespołami aplikacji w różnych jednostkach biznesowych lub działach, możesz ograniczyć możliwość tworzenia nowych grup zasobów w ramach subskrypcji udostępnionej przez dowolny zespół. To ograniczenie ogranicza rozrastanie grupy zasobów. Tylko zespół platformy może tworzyć i zarządzać nowymi grupami zasobów. Takie podejście zwiększa złożoność przypisań kontroli dostępu opartej na rolach i zwiększa zależność zespołów platformy do zarządzania wdrożeniami aplikacji, co może utrudniać elastyczność i możliwości zespołów aplikacji. |
Subskrypcje, które są automaty, można umieścić w linii produktów portfolio aplikacji udostępnionej w ramach grup zarządzania Corp lub Online. Ta metoda jest zgodna z domyślną zalecaną hierarchią stref docelowych platformy Azure. Alternatywnie możesz umieścić subskrypcje pod nowymi grupami zarządzania, jeśli hierarchia grup zarządzania organizacji jest zgodna ze wskazówkami w temacie Dostosowywanie architektury strefy docelowej platformy Azure w celu spełnienia wymagań.
Na poniższym diagramie przedstawiono przykład portfolio aplikacji udostępnionych sprzedaż abonamentów linii produktów.
Użyj linii produktu udostępnionego portfela aplikacji, jeśli:
Zespół aplikacji musi dostarczać kilka małych zasobów lub składników udostępnianych przez aplikacje, ale składniki nie mieszczą się bezpośrednio w żadnej z dedykowanych stref docelowych aplikacji.
Masz zasoby lub składniki, które należy udostępniać między aplikacjami w tym samym dziale, ale składniki nie pasują bezpośrednio do żadnej z dedykowanych stref docelowych aplikacji.
Zespoły ds. platform technologicznych chcą hostować duże, udostępnione usługi zarządzane, takie jak AKS, Azure Virtual Desktop i Azure VMware Solution, dzięki czemu inne zespoły aplikacji mogą używać lub hostować aplikacje w usługach.
Piaskownica
Użyj linii produktu piaskownicy dla strefy docelowej aplikacji sprzedaż abonamentów, aby ułatwić zapewnienie bezpiecznych, lekko zarządzanych i widocznych obszarów testowania do tworzenia weryfikacji koncepcji lub dostawców MVP na platformie Azure.
Aby uzyskać więcej informacji, zobacz Środowiska piaskownicy strefy docelowej i Zarządzanie środowiskami projektowymi aplikacji w strefach docelowych platformy Azure.
Piaskownice są często ograniczone czasowo lub ograniczone budżetowo, co oznacza, że mają limit czasu lub limit budżetu. W takich przypadkach należy rozszerzyć lub usunąć i zlikwidować piaskownicę.
Jeśli Twoja organizacja nie udostępnia linii produktów piaskownicy dla zespołów aplikacji ani innych osób do testowania i eksperymentowania z usługami na platformie Azure, zespoły mogą uciekać się do konfiguracji IT w tle. Jeśli tak, Twoja organizacja może mieć trudności z zapewnieniem raportowania i widoczności oraz stosowaniem ładu do subskrypcji tworzonych przez użytkowników biznesowych spoza kontroli i nadzoru zespołu platformy.
Zespół platformy musi zapewnić łatwy dostęp, najlepiej samoobsługę i automatycznie zatwierdzony dostęp do subskrypcji piaskownicy dla użytkowników i zespołów organizacji. Zapewnij użytkownikom i zespołom dostęp do środowiska, które zespół platformy może wyświetlać i zarządzać, aby zapobiec niezatwierdzonych środowiskach IT , do których zespół platformy nie może uzyskać dostępu lub kontroli, co stwarza ryzyko.
Piaskownice często stosują podejście do konfiguracji sieci subskrypcji produktów online, ponieważ nie są one powiązane z innymi sieciami wirtualnymi poza granicą subskrypcji piaskownicy. Piaskownice często mają również dodatkowe kontrolki, aby zapobiec łączności hybrydowej z lokalizacjami lokalnymi lub innymi lokalizacjami. Użyj tych kontrolek, aby nieznane źródła nie mogły eksfiltrować danych z piaskownic do niezatwierdzonych lokalizacji. Możesz użyć zasad platformy Azure, aby wymusić te kontrolki.
Podobnie jak w przypadku udostępnionego portfolio aplikacji i linii produktów platformy technicznej, możesz również udostępnić linię produktu piaskownicy między zespołami w tym samym dziale z tymi samymi zagadnieniami. Nie twórz pojedynczej subskrypcji piaskownicy i udostępniaj ją między zespołami za pośrednictwem grup zasobów. Zamiast tego utwórz dodatkowe subskrypcje piaskownicy.
Użyj linii produktu piaskownicy, jeśli musisz zapewnić bezpieczną, bezpieczną i zarządzaną subskrypcję platformy Azure wszystkim osobom w organizacji, którzy chcą eksperymentować, tworzyć weryfikacje koncepcji lub tworzyć mvps na platformie Azure. Należy lekko zarządzać tymi użytkownikami i udzielać im dostępu do wszystkich usług, aby zapobiec praktykom IT w tle.
Podsumowanie i wynos
W tym artykule opisano normatywne wskazówki ułatwiające przechodzenie do złożonych procesów sprzedaż abonamentów i przechodzenie do implementacji.
Określ wymagania przyszłych zespołów ds. aplikacji, aby wybrać sprzedaż abonamentów linię produktu, która najlepiej im odpowiada. Zidentyfikuj wymagania dotyczące początkowego zestawu obciążeń, które są kompilowane lub migrowane, aby ułatwić określanie priorytetów wierszy produktów sprzedaż abonamentów, które chcesz włączyć i uwidocznić za pośrednictwem interfejsu samoobsługowego.
Każda linia produktu ma koszt implementacji i koszt konserwacji. Oceń koszty długoterminowe w porównaniu z długoterminowymi korzyściami i użyciem.
Klienci zazwyczaj początkowo włączają następujące sprzedaż abonamentów wiersze produktów:
Dodatkowe zasoby
Aby dodatkowo wspierać podejście inżynieryjne platformy, zapoznaj się z następującymi zasobami podczas projektowania i implementowania sprzedaż abonamentów linii produktów i ofert organizacji:
- Wideo: Ile subskrypcji należy używać na platformie Azure?
- Strefy docelowe platformy a strefy docelowe aplikacji
- Zasady zawarte w implementacjach referencyjnych stref docelowych platformy Azure
- Dostosowywanie architektury strefy docelowej platformy Azure w celu spełnienia wymagań
- Jaki jest cel grup zarządzania Connectivity, Corp i Online?
- Zarządzanie środowiskami projektowymi aplikacji w strefach docelowych platformy Azure
- Zasady inżynierii platformy
Następny krok
Aby uzyskać najlepsze wyniki, należy zautomatyzować jak najwięcej procesu sprzedaż abonamentów. Skorzystaj z wskazówek towarzyszących dotyczących implementowania automatyzacji sprzedaż abonamentów.