One Dynamics One Platform: co przeniesienie F&O na Power Platform oznacza dla Twoich kosztów storage

Przez lata funkcjonował na rynku popularny żart: nikt sobie nic nie robi z ograniczenia przestrzeni bazodanowej w Dynamics 365 Finance & Operations. Zapis w podręczniku licencyjnym istniał, konsumpcję dało się sprawdzić, ale konsekwencji nie było. Dlatego temat lądował na dnie listy priorytetów. Ten żart właśnie traci puentę, a odpowiada za to program, który Microsoft wdraża iteracyjnie od kilku lat: One Dynamics One Platform (ODOP).

ODOP bywa opisywany jako projekt administracyjno-infrastrukturalny: przeniesienie F&O do ekosystemu Power Platform. To prawda, ale niepełna. Dla klientów najważniejszy skutek programu jest licencyjny: zbliżenie rozwiązania ERP do Dataverse przybliża również zasady licencjonowania Dataverse do F&O, w tym model, w którym limit pojemności nie jest zapisem w podręczniku, lecz mechanizmem platformy. W tym artykule wyjaśniamy, co program już zmienił, jak działa model Dataverse, który F&O przejmuje, i co z tego wynika dla planowania na najbliższe kwartały.

‍

Czym jest program ODOP i dlaczego daty się przesuwają, ale kierunek nie

One Dynamics One Platform to wieloletni program ujednolicenia: administracja, infrastruktura i model działania środowisk F&O mają docelowo funkcjonować w ramach Power Platform, tak jak pozostałe aplikacje Dynamics 365. Sceptycy słusznie zauważają, że daty poszczególnych etapów bywają przesuwane. Najlepszym przykładem jest decommissioning LCS, którego terminy korygowano. Z przesuwania dat nie wynika jednak zatrzymanie kierunku: krok po kroku każdy z fundamentalnych elementów programu jest wdrażany, a te już dostarczone nie zostaną cofnięte. Planowanie „może się rozmyje” jest więc zakładem przeciwko trendowi, który od lat konsekwentnie się materializuje.

Elementy już wdrożone: Unified Admin Experience w GA

Najbardziej namacalnym dowodem jest Unified Admin Experience, czyli przeniesienie funkcjonalności znanych z LCS do Power Platform Admin Center, które zostało wypuszczone w trybie ogólnej dostępności (GA). Popularne jest stwierdzenie o brakach występujących w nowym środowisku administracyjnym i częściowo jest ono zasadne; niemniej braki uzupełniane są z kolejnymi wydaniami, a status GA oznacza, że Microsoft traktuje nowe centrum jako docelowe, nie eksperymentalne.

Routing nowych klientów do Power Platform Admin Center

Drugim sygnałem są wskazywane przez Microsoft kolejne terminy kierowania nowych klientów bezpośrednio do Power Platform Admin Center, z pominięciem LCS. Innymi słowy: żywotność LCS jest już określona i choć może on przeżyć jeszcze wiele miesięcy, klienci F&O będą finalnie zobligowani do rezygnacji z tego środowiska i przeniesienia się do nowego centrum administracyjnego. Przygotowanie prac administracyjnych pod tę zmianę jest obowiązkowe dla zachowania ciągłości usług. Każda organizacja, która zarządza środowiskami przez LCS, powinna mieć ten punkt w planie.

‍

Model licencyjny Dataverse jako zapowiedź przyszłości F&O

Aby zrozumieć, dokąd zmierza licencjonowanie storage w F&O, wystarczy spojrzeć na to, jak od lat działa ono w Dataverse, bo to właśnie te zasady program ODOP przybliża do rozwiązania ERP.

Jak działa próg capacity w Dataverse: ograniczenia automatyczne

Dataverse, obok subskrypcji użytkowników, od lat słynie z twardego progu pojemności. Klient dysponuje określonym capacity i jego przekroczenie nie jest kwestią interpretacji podręcznika. Po przekroczeniu operacje administracyjne zostają ograniczone automatycznie, przez samą platformę. Nie ma tu „smutnych gentlemanów z audytu”, którzy muszą zapukać do drzwi: mechanizm działa sam, niezależnie od tego, czy ktokolwiek po stronie Microsoftu zainteresuje się danym klientem.

Blokada tworzenia środowisk i przywracania backupów: konsekwencje operacyjne

Ograniczenia dotyczą operacji, których organizacja potrzebuje najbardziej w najgorszych możliwych momentach: zakładania nowych środowisk oraz właściwego zarządzania istniejącymi. W praktyce oznacza to, że przekroczony limit potrafi zablokować postawienie sandboxa pod pilny projekt albo operacje na środowiskach w trakcie incydentu, czyli zamienić problem licencyjny w problem operacyjny, z terminami biznesowymi w tle.

Mechanizm trzykrotnego requestu o przekroczenie

Model Dataverse przewiduje wentyl bezpieczeństwa: możliwość trzykrotnego wystąpienia o zgodę na czasowe przekroczenie wartości, tak aby zachować ciągłość działania. Konstrukcja tego mechanizmu mówi jednak wszystko o jego charakterze. To odroczenie, nie rozwiązanie. Po wyczerpaniu puli requestów pozostają dwie drogi: redukcja konsumpcji albo zakup dodatkowej pojemności.

‍

Infrastruktura: z Azure Service Fabric na Power Platform Compute

Zmiana licencyjna ma też swój fundament techniczny. Środowiska F&O w modelu Microsoft Managed są dziś postawione na Azure Service Fabric; w ramach ODOP infrastruktura ta zostanie przeniesiona na zasoby obliczeniowe Power Platform. Wraz z tą zmianą materializuje się koncept „tier X”, czyli odejścia od sztywno zdefiniowanych warstw środowisk (Tier 2–5) na rzecz nieokreślonej z góry warstwy infrastruktury danego środowiska. Konsekwencja dla naszego tematu jest bezpośrednia: gdy środowiska F&O fizycznie działają na platformie, której mechanizmy egzekwują limity pojemności, oddzielenie „zasad Dataverse” od „zasad F&O” przestaje mieć techniczne uzasadnienie. Podsumowując: licencjonowanie oparte na capacity będzie miało taki wpływ na F&O, że ograniczenie pojemności przy rozwiązaniu ERP również będzie weryfikowane i będzie obligatoryjne dla każdego klienta, aby je utrzymywać.

‍

Oś czasu ryzyka: co zrobić w tym roku, a co można odłożyć

Precyzyjnych dat nikt odpowiedzialny nie poda. Program już pokazał, że terminy bywają korygowane. Zarządzać można natomiast własną ekspozycją, i tu kolejność działań jest jasna. W pierwszej kolejności: diagnoza, czyli zestawienie należnej i konsumowanej pojemności tenanta w Power Platform Admin Center. Piętnaście minut pracy, które zamienia „chyba nas to nie dotyczy” w liczbę. Równolegle: inwentaryzacja zależności od LCS, bo migracja administracyjna nastąpi niezależnie od wątku storage. W drugiej kolejności, jeżeli diagnoza pokaże przekroczenie lub niebezpieczny trend: redukcja konsumpcji: zadania czyszczące, nieużywane indeksy, odchudzenie sandboxów i archiwizacja, przeprowadzone we własnym tempie, zanim wymusi ją mechanizm platformy. Odłożyć można wiele; nie warto odkładać diagnozy, bo to ona decyduje, czy cokolwiek innego jest pilne. Organizacje, które uporządkują konsumpcję przed przejściem na nowe zasady, przejdą je bezboleśnie; te, które poczekają, będą robić porządki pod presją. Prace na danych produkcyjnych wykonywane pod presją kosztują więcej i niosą wyższe ryzyko.

Wolisz uporządkować storage we własnym tempie niż pod presją platformy? Skontaktuj się z nami. Wyślemy prostą instrukcję self-checku. Wystarczą zrzuty z Power Platform Admin Center i wynik skryptu SQL badającego rozmiary tabel na środowisku testowym, a przygotujemy estymację możliwych uzysków i ofertę fixed price na ich realizację.