Chmura staje się wiarygodną i wydajną alternatywą infrastrukturalną dla krytycznych aplikacji biznesowych w porównaniu z własnym data center. To sposób na uniknięcie przez biznes nakładów inwestycyjnych i kosztów utrzymania infrastruktury IT przy jednoczesnym wzroście skalowalności.
Systemy SAP, wymagające wydajnej infrastruktury i inwestycji z tym związanych, stanowią w przedsiębiorstwach strategiczny zasób, zarówno z punktu widzenia IT, jak i krytycznego znaczenia dla biznesu. Stąd też ostrożność, z jaką firmy podchodzą do zagadnienia migracji systemu SAP do chmury. Czy warto dokonać migracji systemu na platformę chmurową? Wiele analiz wskazuje, że w szczególności wdrożenie SAP w modelu chmurowym może przekształcić tradycyjny, ekosystem on-premises w zwinną, racjonalną kosztowo i skalowalną platformę, umożliwiającą organizacji transformację w kierunku szybszej reakcji na zmieniające się warunki rynkowe, wykorzystanie najnowszych technologii i modeli biznesowych bez konieczności znacznych nakładów inwestycyjnych (CAPEX). Mimo wszystkich tych zalet, migracje do chmury nadal stanowią wyzwanie, szczególnie w przypadku systemów o znaczeniu krytycznym, a takim z reguły jest SAP.
Przenoszenie SAP do chmury
Przeniesienie obciążeń związanych z działaniem aplikacji SAP do chmury może przynieść mierzalne korzyści finansowe w postaci ograniczenia zaangażowania środków w infrastrukturę oraz kosztów operacyjnych. Jednak osiągnięcie zadowalającego zwrotu z inwestycji (ROI – Return on Investment) wymaga starannego planowania migracji. Brak przygotowania jest jednym z głównych powodów, dla których migracje z SAP (jak i innych systemów krytycznych) on-premises do chmury nie udają się.
Jednym z problemów jest wymiarowanie, tj. szacowanie zapotrzebowania na moc obliczeniową, które odbywa się z wykorzystaniem standardowego narzędzia SAP Quick Sizer. Narzędzie to pozwala oszacować zapotrzebowanie w odniesieniu do SAP Application Performance Standard (SAPS). SAPS są używane przez certyfikowanych dostawców sprzętu w celu określenia optymalnej konfiguracji infrastruktury i oszacowania kosztów utrzymania.
W przypadku rezygnacji z własnej infrastruktury i związanej z tym migracji do dostawcy zewnętrznego konieczne będzie określenie wartości parametru IOPS, tj. operacji wejścia/wyjścia na sekundę. Tutaj jednak nie dysponujemy modelem porównawczym, który byłby punktem odniesienia przy konfiguracji zapotrzebowania na zasoby i usługi IaaS podczas migracji. Stąd tak ważna staje się możliwość przygotowania PoC (Proof of Concept) i uruchomień testowych, które pozwalają na obserwowanie zapotrzebowania na usługi i dobór odpowiednich parametrów konfiguracji. Dzięki nim możemy też oszacować koszty w różnych wariantach, bo choć w modelu chmurowym mamy możliwość płacenia za wykorzystane zasoby (pay as you go) i skalowania, to jednak ważne jest określenie np. wartości granicznych minimalnego i szczytowego zapotrzebowania na zasoby IaaS.
Zwinny SAP?
Choć można odnieść wrażenie, że stosowanie zwrotu „zwinność” jest zdecydowanie przesadzone, w tym konkretnym przypadku – przeniesienie SAP do chmury – jest jak najbardziej uzasadnione. Zacznijmy od kosztów. W większości przypadków analiza porównawcza TCO instancji SAP on-premises i w chmurze wykaże niższy koszt tej ostatniej opcji. „W większości” nie oznacza „zawsze” i w wielu specyficznych przypadkach przedsiębiorstw – np. kiedy obciążenia są dość równomierne w czasie, konieczna jest złożona komunikacja z wieloma lokalizacjami, urządzeniami bądź migracja do/z innych systemów wykorzystywanych przez firmę –w ostatecznym rozrachunku może okazać się, że migracja do chmury publicznej nie jest uzasadniona kosztowo, a rozważyć można np. prywatną chmurę hostowaną, jako alternatywę dla on-premises, z większymi możliwościami dostosowania do specyficznych potrzeb przedsiębiorstwa.
Jednak koszty to nie tylko rachunek zysków i strat, to również zarządzanie CAPEX-em i obiegiem gotówki. Model chmurowy daje nam możliwość odejścia od inwestycji CAPEX-owych w infrastrukturę i zamrażania kapitału w inwestycji, która amortyzuje się zazwyczaj wolniej niż jej faktyczna utrata wartości (i konieczność rozbudowy, wymiany, aktualizacji itd.). Stąd dla wielu firm możliwość przerzucenia wydatków do OPEX i zachowanie większej elastyczności w dysponowaniu gotówką, przy jednoczesnym zapewnieniu przez dostawcę wciąż aktualnej, nowoczesnej infrastruktury stanowi istotną wartość biznesową.
Zwinność w przypadku migracji posiada dwa wymiary – technologiczny i biznesowy. Elastyczność i skalowalność jaką zapewnia przetwarzanie w chmurze publicznej mają kluczowe znaczenie w przedsiębiorstwach o dużej zmienności zapotrzebowania na zasoby obliczeniowe, zmienności i ewolucji uruchamianych aplikacji. Chmura pozwala mierzyć i automatyzować wykorzystanie zasobów, optymalizując wydajność.
Drugi wymiar odnosi się do zapotrzebowania biznesu, który częściej wymaga możliwości szybkiego udostępniania zasobów związanych z nowymi projektami, jak otwarcie nowego oddziału, ekspansja na nowy rynek, fuzje i przejęcia czy szybkie reakcje na ofertę konkurencji.
Dwa podejścia
Szacuje się, że w Polsce jest ponad 1,5 tys. Instalacji SAP, które będą wymagały migracji do nowszej wersji S/4HANA. Mimo, że koniec wsparcia dla klasycznego SAP ERP/ECC, jak i baz danych innych niż SAP HANA przypada dopiero na 2025 r., temat ten już dziś staje się ważny ze względu na złożony proces przenosin posiadanych danych do nowego systemu oraz wybór odpowiedniej infrastruktury IT – mówi Tomasz Sobol CMO w Beyond.pl.
W przypadku wyboru infrastruktury IT SAP oferuje dwa podejścia do wdrażania: SAP HANA (On premises) – urządzenie In-Memory Appliance i Tailored Data Center Integration (TDI).
Pierwsze podejście In-Memory Appliance, często nazywane „podejściem „wszystko w jednym pudełku”, pozwala klientom uruchomić system SAP w oparciu wstępnie skonfigurowany system HANA i jego komponenty dostarczone przez certyfikowanych partnerów sprzętowych. Hardware i oprogramowanie są instalowane i utrzymywane przez SAP i wybranych partnerów technicznych. W rezultacie klienci korzystają z wiedzy i supportu obu stron po instalacji. Zmniejsza to odpowiedzialność klienta, pozwala mu na instalację środowiska w siedzibie lub zewnętrznym centrum danych. Wiąże się to jednak z bardzo dużym kosztem zakupu sprzętu, jego utrzymania oraz rozbudowy o kolejne całe instalacje. Nie ma również nic wspólnego ze współczesnym trendem w IT, jakim jest zwinność i elastyczność w dostarczaniu zasobów w czasie rzeczywistym.
Podejście to dedykowane jest firmom, które zdolne są do ponoszenia dużych wydatków lub mają inne ograniczenia regulacyjne, polityki bezpieczeństwa, które skłaniają je do tej opcji.
Z drugiej strony podejście TDI pozostawia instalację i utrzymanie systemu operacyjnego i urządzenia HANA uznaniu klienta – w granicach ustalonych i akceptowanych przez SAP.
TDI umożliwia klientom budowę zwinnych i optymalnych kosztowo środowisk IT w oparciu o certyfikowany przez SAP sprzęt udostępniany przez zewnętrznych dostawców tj. np. Beyond.pl. i chmurę VMware, która posiada certyfikację VMware Cloud Verified. Podejście zapewnia znaczne oszczędności w początkowej fazie projektu, ponieważ nie trzeba kupować nowego sprzętu oraz umożliwia ciągłą optymalizację infrastruktury, dostosowując ją do realnych potrzeb klienta w oparciu o analizę i monitoring obciążenia infrastruktury. Należy jednak pamiętać, że w odróżnieniu od pierwszej opcji, instalacja oprogramowania jest przeprowadzana przez wykwalifikowanych specjalistów SAP.
Podejście to dedykowane jest firmom, które poszukują optymalnych kosztowo rozwiązań, zdolnych do ciągłego rozwoju i adaptacji do pojawiających się wyzwań na rynku.
