W tym artykule opisano cztery wzorce wdrażania, które można wybrać podczas wdrażania usługi Microsoft Fabric. Dowiedz się więcej o zagadnieniach, zaleceniach i potencjalnych decyzjach niezweryfikowanych dla każdego wzorca wdrażania.
Dla każdego wzorca wdrażania sieci szkieletowej opisano następujące obszary projektowe:
- Nadzór
- Zabezpieczenia
- Administracja
- DevOps
- Użyteczność
- Wydajność i skalowalność
- Rozliczenia i zarządzanie kosztami
Poziomy we wdrożeniu sieci szkieletowej
Wdrożenie sieci szkieletowej ma cztery poziomy: dzierżawa, pojemność, obszar roboczy i element. Na najwyższym poziomie jest dzierżawa sieci szkieletowej. Każda dzierżawa może mieć co najmniej jedną pojemność, każda pojemność może zawierać co najmniej jeden obszar roboczy, a każdy obszar roboczy może zawierać zero lub więcej elementów sieci szkieletowej.
Struktura lub cele organizacji w obszarach zabezpieczeń, skalowania, ładu i cyklu życia aplikacji mogą mieć wpływ na wybór wzorca wdrażania. Różne wzorce wdrażania oferują różną elastyczność i nacisk na poziomy wdrożenia.
Na przykład organizacja może używać domen do grupowania obszarów roboczych w sieci szkieletowej. Podobnie, jeśli organizacja musi mieć scentralizowaną opcję, której może użyć do współpracy i znalezienia zawartości, centrum danych OneLake w sieci szkieletowej oferuje scentralizowany punkt dostępu i jest zintegrowany z innymi znanymi produktami, takimi jak Microsoft Teams i Excel.
W sieci szkieletowej duża organizacja, która ma jednostki biznesowe w oddzielnych lokalizacjach geograficznych, może używać pojemności do kontrolowania miejsca, w którym znajdują się jego dane. Może zarządzać jednostką biznesową działającą z innej lokalizacji geograficznej jako pojedynczą jednostką przy użyciu domen sieci szkieletowej, ponieważ domeny mogą obejmować obszary robocze, które znajdują się w różnych regionach.
Aby uzyskać więcej informacji na temat poziomów sieci szkieletowej i ich roli podczas wybierania wzorca wdrażania, zobacz Pojęcia i licencje usługi Microsoft Fabric.
Jak wzorce wdrażania sieci szkieletowej są wyrównane
Wszystkie wzorce wdrażania sieci szkieletowej:
- Użyj obszarów roboczych sieci szkieletowej jako granic do skalowania, zapewniania ładu i zabezpieczeń.
- Użyj domen sieci szkieletowej do delegowania, aby zarządzać wieloma obszarami roboczymi, które mogą należeć do tej samej jednostki biznesowej, lub gdy dane należące do domeny biznesowej obejmują więcej niż jeden obszar roboczy. Niektóre ustawienia na poziomie dzierżawy można ustawić na potrzeby zarządzania danymi i zarządzania nimi na poziomie domeny i używać konfiguracji specyficznej dla domeny dla tych ustawień.
- Pojemności sieci szkieletowej umożliwiają skalowanie zasobów obliczeniowych podczas aprowizowania dedykowanych pojemności na obszar roboczy, gdy muszą zostać spełnione określone poziomy wydajności.
- Rozszerzaj, aby korzystać z równoważnych funkcji z chmury firmy Microsoft (Microsoft Azure, Microsoft 365 i innych), gdy funkcja nie jest dostępna w usłudze Fabric.
- Użyj centrum danych OneLake, aby podwyższyć poziom odnajdywania i używania zasobów danych.
- Użyj programu OneSecurity, aby skonfigurować zasady zabezpieczeń danych dla zasobów danych.
Scenariusze oparte na wymaganiach biznesowych
W tym artykule opisano sposób, w jaki każdy wzorzec wdrażania może spełniać różne wymagania biznesowe:
- Scenariusz 1: W przypadku organizacji, które chcą mieć krótszy (lub wolniejszy) czas obrotu, organizując zespoły, które mogą współpracować krzyżowo, z niższymi ograniczeniami dotyczącymi użycia danych. W tym scenariuszu organizacja może korzystać z wzorca wdrożenia monolitycznego . Organizacja działa w jednym obszarze roboczym i zarządza nim. Aby uzyskać więcej informacji, zobacz Wzorzec 1: wdrażanie monolityczne.
- Scenariusz 2: W przypadku organizacji, które chcą zapewnić izolowane środowiska dla zespołów do pracy, z centralnym zespołem odpowiedzialnym za zapewnianie infrastruktury i zarządzanie nią. Ten scenariusz odpowiada również organizacjom, które chcą zaimplementować siatkę danych. W tym scenariuszu organizacja może zaimplementować wiele obszarów roboczych , które używają pojemności udostępnionej lub mają oddzielne pojemności. Aby uzyskać więcej informacji, zobacz Wzorzec 2: wiele obszarów roboczych wspieranych przez pojedynczą pojemność sieci szkieletowej i Wzorzec 3: wiele obszarów roboczych wspieranych przez oddzielne pojemności.
- Scenariusz 3. W przypadku organizacji, które chcą całkowicie zdecentralizowanego modelu, który zapewnia jednostkom biznesowym lub zespołom swobodę kontrolowania własnych platform danych i zarządzania nimi. W tym scenariuszu organizacja może wybrać model wdrażania, w którym korzysta z oddzielnych obszarów roboczych, z których każda ma dedykowaną pojemność lub może mieć wiele dzierżaw sieci szkieletowej. Aby uzyskać więcej informacji, zobacz Wzorzec 3: wiele obszarów roboczych wspieranych przez oddzielne pojemności i Wzorzec 4: wiele dzierżaw sieci szkieletowej.
- Scenariusz 4. Organizacja może zdecydować się na użycie podejścia hybrydowego, w którym łączy wiele wzorców w celu osiągnięcia swoich wymagań. Na przykład organizacja może skonfigurować pojedynczy obszar roboczy dla określonych jednostek biznesowych (wzorzec wdrożenia monolitycznego) przy użyciu oddzielnych, dedykowanych obszarów roboczych i oddzielnych pojemności dla innych jednostek biznesowych.
Wzorzec 1. Wdrożenie monolityczne
W tym wzorcu wdrażania aprowizujesz jeden obszar roboczy, aby zaspokoić wszystkie przypadki użycia. Wszystkie jednostki biznesowe działają w ramach tego samego, pojedynczego obszaru roboczego.
W przypadku aprowizowania pojedynczej pojemności sieci szkieletowej i dołączenia do niego pojedynczego obszaru roboczego spełnione są następujące kwestie:
- Wszystkie elementy sieci szkieletowej mają taką samą aprowizowaną pojemność. Czas potrzebny na zakończenie zapytania lub zadania różni się, ponieważ inne obciążenia używają tej samej pojemności.
- Maksymalna liczba jednostek pojemności obszaru roboczego jest ograniczona do największej możliwej jednostki SKU F lub jednostki SKU P. W przypadku środowisk inżynierii danych można aprowizować oddzielne pule platformy Spark, aby przenieść pojemność obliczeniową wymaganą przez platformę Spark poza aprowizowaną jednostką CU.
- Funkcje, które są ograniczone do obszaru roboczego, mają zastosowanie we wszystkich jednostkach biznesowych, które współużytkują ten obszar roboczy.
- Wszystkie elementy i dane obszaru roboczego znajdują się w jednym regionie. Nie można użyć tego wzorca w scenariuszach obejmujących wiele regionów geograficznych.
- Funkcje, które korzystają z wielu obszarów roboczych, takich jak potoki wdrażania i zarządzanie cyklem życia, nie są dostępne.
- Mają zastosowanie ograniczenia skojarzone z jednym obszarem roboczym.
- Obowiązują ograniczenia pojemności skojarzone z określoną jednostkę SKU.
Możesz wdrożyć ten wzorzec wdrażania z co najmniej jednego z następujących powodów:
- Twoja organizacja nie ma złożonych wymagań inżynieryjnych, ma małą bazę użytkowników lub jej semantyczne modele są małe.
- Twoja organizacja działa w jednym regionie.
- Nie zajmujesz się przede wszystkim separacją organizacji między jednostkami biznesowymi.
- Twoja organizacja nie wymaga funkcji o zakresie obszaru roboczego, takich jak udostępnianie repozytoriów kodu za pomocą usługi Git.
- Chcesz zaimplementować architekturę medalonu lakehouse. Jeśli twoja organizacja jest ograniczona do jednego obszaru roboczego, można osiągnąć separację między warstwami z brązu, srebra i złota, tworząc oddzielne obiekty lakehouse w obszarze roboczym.
- Jednostki biznesowe organizacji współdzielą role i dopuszczalne jest posiadanie tych samych uprawnień na poziomie obszaru roboczego dla użytkowników w obszarze roboczym. Jeśli na przykład wielu użytkowników należących do różnych jednostek biznesowych jest administratorami jednego obszaru roboczego, mają te same prawa do wszystkich elementów w obszarze roboczym.
- Organizacja może tolerować zmienne czasy ukończenia zadania. Jeśli organizacja nie ma żadnych wymagań dotyczących gwarancji wydajności (na przykład zadanie musi zakończyć się w określonym przedziale czasu), dopuszczalne jest udostępnienie pojedynczej aprowizowanej pojemności w jednostkach biznesowych. Gdy pojemność jest udostępniana, użytkownicy mogą uruchamiać zapytania w dowolnym momencie. Liczba jednostek CU, które są dostępne do uruchomienia zadania, różni się w zależności od tego, jakie inne zapytania są uruchomione w pojemności. Może to prowadzić do zmiennych czasów ukończenia zadania.
- Twoja organizacja może osiągnąć wszystkie wymagania biznesowe (z perspektywy cu) przy użyciu pojedynczej pojemności sieci szkieletowej.
W poniższej tabeli przedstawiono zagadnienia, które mogą mieć wpływ na decyzję o wdrożeniu tego wzorca wdrażania:
| Aspekt | Kwestie wymagające rozważenia |
|---|---|
| Nadzór | - Wymagane są niższe mandaty i ograniczenia ładu na platformie. - Pasuje do mniejszych organizacji, które preferują szybszy czas obrotu. - Wyzwania mogą się rozwijać, jeśli wymagania dotyczące ładu ewoluują, aby stać się bardziej złożone. |
| Zabezpieczenia — płaszczyzna danych | — Dane mogą być współużytkowane przez zespoły, więc nie ma potrzeby wprowadzania ograniczeń dotyczących danych między zespołami. — Zespoły mają prawa własności do modeli semantycznych. Mogą odczytywać, edytować i modyfikować dane w usłudze OneLake. |
| Zabezpieczenia — płaszczyzna sterowania | — Wszyscy użytkownicy mogą współpracować w tym samym obszarze roboczym. - Nie ma żadnych ograniczeń dotyczących elementów. Wszyscy użytkownicy mogą odczytywać i edytować wszystkie elementy. |
| Administracja | Organizacja ma: - Niższe koszty administracyjne. — Nie ma rygorystycznej potrzeby śledzenia i monitorowania dostępu i użycia na zespół. — Mniej rygorystyczne monitorowanie obciążenia obciążenia sieci szkieletowej w zespołach. |
| DevOps | Metodyka DevOps zapewnia następujące korzyści: - Pojedyncza wersja dla całej platformy. — Mniej skomplikowane potoki wydania. |
| Użyteczność — Administracja istratorzy | — Administratorom łatwiej zarządzać, ponieważ mają mniej elementów do zarządzania. — Nie ma potrzeby innej aprowizacji ani obsługi żądań od zespołów dla nowych pojemności lub obszarów roboczych. — Administratorzy pojemności mogą być administratorami dzierżawy, więc nie ma potrzeby tworzenia innych grup ani zespołów ani zarządzania nimi. |
| Użyteczność — inne role | — Dopuszczalne jest udostępnienie obszaru roboczego innym użytkownikom. - Zachęcamy do współpracy między użytkownikami. |
| Wydajność | - Izolacja obciążeń nie jest obowiązkowa. — Nie trzeba spełniać rygorystycznych umów dotyczących poziomu usług dotyczących wydajności (SLA). - Ograniczanie przepustowości nie jest prawdopodobne. |
| Rozliczenia i zarządzanie kosztami | — Jeden, pojedynczy zespół może obsługiwać koszty. - Nie ma potrzeby ładowania z powrotem do różnych zespołów. |
Wzorzec 2. Wiele obszarów roboczych wspieranych przez pojedynczą pojemność sieci szkieletowej
W tym wzorcu wdrażania używasz oddzielnych obszarów roboczych. Ponieważ pojedyncza pojemność jest współdzielona między obszarami roboczymi, obciążenia uruchamiane współbieżnie w dowolnym momencie mogą mieć wpływ na wydajność zadań i interakcyjnych zapytań.
Podczas aprowizowania pojemności pojedynczej sieci szkieletowej i dołączania do niej wielu obszarów roboczych spełnione są następujące kwestie:
- Wszystkie elementy sieci szkieletowej mają taką samą aprowizowaną pojemność. Czas potrzebny na zakończenie zapytania lub zadania różni się, ponieważ inne obciążenia używają tej samej pojemności.
- Maksymalna liczba jednostek SKU, których może używać obszar roboczy, jest ograniczona do największej możliwej jednostki SKU F lub jednostki SKU P. W przypadku środowisk inżynierii danych można aprowizować oddzielne pule platformy Spark, aby przenieść pojemność obliczeniową wymaganą przez platformę Spark poza aprowizowaną jednostką CU.
- Funkcje, które są ograniczone do obszaru roboczego, mają zastosowanie we wszystkich jednostkach biznesowych, które współużytkują ten obszar roboczy.
- Wszystkie elementy i dane obszaru roboczego znajdują się w jednym regionie. Nie można użyć tego wzorca w scenariuszach obejmujących wiele regionów geograficznych.
- Możesz użyć funkcji Metodyki DevOps, które wymagają oddzielnych obszarów roboczych, takich jak potoki wdrażania i zarządzanie cyklem życia.
- Mają zastosowanie ograniczenia skojarzone z jednym obszarem roboczym.
- Obowiązują ograniczenia pojemności skojarzone z określoną jednostkę SKU.
Możesz wdrożyć ten wzorzec wdrażania z co najmniej jednego z następujących powodów:
- Chcesz mieć architekturę piasty i szprych, w której organizacja centralizuje niektóre aspekty działania środowiska analitycznego i decentralizuje inne.
- Potrzebujesz decentralizacji z aspektu operacyjnego i zarządzania, ale do różnych stopni. Możesz na przykład wybrać warstwy brązowe i srebrne architektury medalonu wdrożonej w jednym obszarze roboczym, a warstwa złota wdrożona w innym obszarze roboczym. Uzasadnieniem może być to, że jeden zespół jest odpowiedzialny za warstwy brązowe i srebrne, a inny zespół jest odpowiedzialny za obsługę warstwy złota i zarządzanie nią.
- Nie interesuje Cię przede wszystkim zarządzanie wydajnością i izolowanie obciążeń z perspektywy wydajności.
- Z perspektywy architektury medalonu lakehouse organizacja może tworzyć oddzielne obszary robocze, aby zaimplementować brązowe, srebrne i złote warstwy.
- Organizacja nie musi wdrażać obciążeń w różnych regionach geograficznych (wszystkie dane muszą znajdować się w jednym regionie).
- Organizacja może wymagać rozdzielenia obszarów roboczych z co najmniej jednego z następujących powodów:
- Członkowie zespołu odpowiedzialnego za obciążenia znajdują się w różnych obszarach roboczych.
- Chcesz utworzyć oddzielne obszary robocze dla każdego typu obciążenia. Możesz na przykład utworzyć obszar roboczy do pozyskiwania danych (potoki danych, przepływ danych Gen2 lub inżynieria danych) i utworzyć oddzielny obszar roboczy do użycia za pośrednictwem magazynu danych. Ten projekt działa dobrze, gdy oddzielne zespoły są odpowiedzialne za każde z obciążeń.
- Chcesz zaimplementować architekturę siatki danych, w której co najmniej jeden obszar roboczy jest grupowany razem w domenie sieci szkieletowej.
- Twoja organizacja może zdecydować się na wdrożenie oddzielnych obszarów roboczych na podstawie klasyfikacji danych.
W poniższej tabeli przedstawiono zagadnienia, które mogą mieć wpływ na decyzję o wybraniu tego wzorca wdrażania:
| Aspekt | Kwestie wymagające rozważenia |
|---|---|
| Nadzór | - Wymagane są średnie mandaty i ograniczenia ładu dotyczące platformy. — Organizacja potrzebuje bardziej szczegółowej kontroli, aby zarządzać działami, zespołami i rolami. |
| Zabezpieczenia — płaszczyzna danych | — Ograniczenia danych są wymagane i należy zapewnić ochronę danych na podstawie kontroli dostępu dla działów, zespołów i członków. |
| Zabezpieczenia — płaszczyzna sterowania | — Aby uniknąć przypadkowego uszkodzenia lub akcji złośliwych użytkowników, może być konieczne zapewnienie kontrolowanego dostępu do elementów sieci szkieletowej według roli. |
| Administracja | — Nie musisz zarządzać pojemnościami, ponieważ jest to model pojedynczej pojemności. — Obszary robocze można używać do izolowania działów, zespołów i użytkowników. |
| DevOps | — Możesz wykonywać niezależne wydania dla poszczególnych działów, zespołów lub obciążeń. — Łatwiej jest spełnić wymagania dotyczące programowania, testowania, akceptacji i produkcji (DTAP) dla zespołów, gdy wiele obszarów roboczych jest aprowizowanych w celu zaspokojenia każdego środowiska wydania. |
| Użyteczność — Administracja istratorzy | — Nie trzeba aprowizować wielu pojemności. — Administratorzy dzierżawy zwykle zarządzają pojemnością, więc nie trzeba zarządzać innymi grupami ani zespołami. |
| Użyteczność — inne role | — Obszary robocze są dostępne dla każdej warstwy medalonu. — Elementy sieci szkieletowej są izolowane dla każdego obszaru roboczego, co pomaga zapobiec przypadkowemu uszkodzeniu. |
| Wydajność | - Ścisłe umowy SLA dotyczące wydajności nie muszą być spełnione. - Ograniczanie przepustowości jest dopuszczalne w okresach szczytu. |
| Rozliczenia i zarządzanie kosztami | - Nie masz określonego wymagania, aby pobierać opłaty za zespół. - Centralny zespół ponosi wszystkie koszty. - Zespoły infrastruktury są właścicielami pojemności sieci szkieletowej w organizacji. |
Wzorzec 3. Wiele obszarów roboczych wspieranych przez oddzielne pojemności
W tym wzorcu wdrażania uzyskujesz separację między jednostkami biznesowymi w celu zapewnienia ładu i wydajności.
W przypadku aprowizowania wielu pojemności sieci szkieletowych przy użyciu własnych obszarów roboczych spełnione są następujące kwestie:
- Największa możliwa jednostka SKU F lub jednostka SKU P dołączona do obszaru roboczego określa maksymalną liczbę jednostek SKU, z których może korzystać obszar roboczy.
- Decentralizacja organizacji i zarządzania jest osiągana przez aprowizowanie oddzielnych obszarów roboczych.
- Organizacje mogą skalować poza jeden region przez aprowizowanie pojemności i obszarów roboczych w różnych regionach geograficznych.
- Możesz użyć pełnych możliwości usługi Fabric, ponieważ jednostki biznesowe mogą mieć jeden lub więcej obszarów roboczych, które znajdują się w osobnych pojemnościach i pogrupowane razem za pośrednictwem domen sieci szkieletowej.
- Obowiązują ograniczenia skojarzone z jednym obszarem roboczym, ale można je skalować poza te limity, tworząc nowe obszary robocze.
- Obowiązują ograniczenia pojemności skojarzone z określoną jednostką SKU, ale można skalować jednostki CU przez aprowizowanie oddzielnych pojemności.
- Wszystkie elementy sieci szkieletowej we wszystkich obszarach roboczych w dzierżawie i ich stanach certyfikacji można odnaleźć przy użyciu centrum danych OneLake.
- Domeny mogą grupować obszary robocze razem, aby jedna jednostka biznesowa mogła obsługiwać wiele obszarów roboczych i zarządzać nimi.
- Skróty OneLake zmniejszają przenoszenie danych, a także zmniejszają użyteczność danych między obszarami roboczymi.
Możesz wdrożyć ten wzorzec wdrażania z co najmniej jednego z następujących powodów:
- Twoja organizacja chce wdrożyć struktury architektury, takie jak siatka danych lub sieć szkieletowa danych.
- Chcesz określić priorytety elastyczności w sposobie tworzenia struktury pojemności i obszarów roboczych.
- Działasz w różnych regionach geograficznych. W takim przypadku aprowizowanie oddzielnej pojemności i obszaru roboczego jest siłą napędową przechodzenia do tego wzorca wdrożenia obejmującego wiele pojemności i wielu obszarów roboczych.
- Działasz na dużą skalę i masz wymagania dotyczące skalowania poza limity jednostki SKU pojedynczej pojemności lub jednego obszaru roboczego.
- Masz obciążenia, które muszą być zawsze wykonywane w określonym czasie lub spełniają określoną umowę SLA dotyczącą wydajności. Możesz aprowizować oddzielny obszar roboczy wspierany przez pojemność sieci szkieletowej, aby spełnić gwarancje wydajności dla tych obciążeń.
W poniższej tabeli przedstawiono zagadnienia, które mogą mieć wpływ na decyzję o wybraniu tego wzorca wdrażania:
| Aspekt | Kwestie wymagające rozważenia |
|---|---|
| Nadzór | — Masz wysoki stopień ładu i zarządzania i potrzebujesz niezależności dla każdego obszaru roboczego. — Możesz zarządzać użyciem na dział lub jednostkę biznesową. — Można spełnić wymagania dotyczące rezydencji danych. — Dane można odizolować na podstawie wymagań prawnych. |
| Zabezpieczenia — płaszczyzna danych | — Dostęp do danych można kontrolować dla poszczególnych działów, zespołów lub użytkowników. — Dane można izolować na podstawie typu elementu sieci szkieletowej. |
| Zabezpieczenia — płaszczyzna sterowania | — Możesz zapewnić kontrolowany dostęp do elementów sieci szkieletowej według roli, aby uniknąć przypadkowego uszkodzenia lub akcji złośliwych użytkowników. |
| Administracja | — Szczegółowe możliwości administratora są ograniczone do działów, zespołów lub użytkowników. — Masz dostęp do szczegółowych wymagań dotyczących monitorowania dotyczących użycia lub wzorców obciążeń. |
| DevOps | — Środowiska DTAP można odizolować przy użyciu różnych pojemności. — Niezależne wydania są oparte na dziale, zespole lub obciążeniu. |
| Użyteczność — Administracja istratorzy | — Uzyskujesz szczegółowy wgląd w użycie według działu lub zespołu. — Masz delegowane prawa pojemności do administratorów pojemności dla poszczególnych działów lub zespołu, co ułatwia skalowanie i szczegółową konfigurację. |
| Użyteczność — inne role | — Obszary robocze są dostępne dla warstwy medalonu i pojemności. — Elementy sieci szkieletowej są izolowane dla każdego obszaru roboczego, co pomaga zapobiec przypadkowemu uszkodzeniu. - Masz więcej opcji, aby zapobiec ograniczaniu, które jest spowodowane przez wzrosty pojemności udostępnionej. |
| Wydajność | — Wymagania dotyczące wydajności są wysokie, a obciążenia muszą spełniać wyższe umowy SLA. — Masz elastyczność skalowania w górę poszczególnych obciążeń na dział lub zespół. |
| Rozliczenia i zarządzanie kosztami | — Wymagania dotyczące ładowania krzyżowego można łatwo spełnić, przypisując dedykowane pojemności do jednostki organizacyjnej (działu, zespołu lub projektu). — Zarządzanie kosztami można delegować do odpowiednich zespołów do zarządzania. |
Wzorzec 4. Wiele dzierżaw sieci szkieletowej
Po wdrożeniu oddzielnych dzierżaw sieci szkieletowych wszystkie wystąpienia sieci Szkieletowej są oddzielnymi jednostkami w odniesieniu do ładu, zarządzania, administrowania, skalowania i magazynu.
Podczas korzystania z wielu dzierżaw sieci szkieletowej są spełnione następujące kwestie:
- Zasoby dzierżawy są ściśle segregowane.
- Płaszczyzny zarządzania między dzierżawami są oddzielne.
- Dzierżawy są oddzielnymi jednostkami i mogą mieć własne procesy zarządzania i ładu, ale można administrować nimi oddzielnie.
- Możesz użyć potoków danych lub możliwości inżynierii danych, aby udostępniać dane dzierżawcom sieci szkieletowej lub uzyskiwać do nich dostęp.
Możesz wdrożyć ten wzorzec wdrażania z następujących powodów:
- Organizacja może trafić do wielu dzierżaw sieci szkieletowej z powodu przejęcia firmy.
- Organizacja może zdecydować się na skonfigurowanie dzierżawy sieci szkieletowej specjalnie dla jednostki biznesowej lub mniejszej jednostki zależnej.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
- Holly Kelly | Główny menedżer programu
- Gabi Muenster | Starszy menedżer programu
- Sarath Sasidharan | Starszy menedżer programu
- Amanjeet Singh | Główny menedżer programu