Jeśli Twoja organizacja planuje migrację do chmury, postaraj się być w zespole głosem rozsądku. Częste nieporozumienia a nawet brak rozumienia kluczowych cech infrastruktury chmurowej prowadzi do brzemiennych w skutki (głównie finansowe) błędów. A można ich uniknąć.
Tematy związane z migracją infrastruktury i aplikacji do chmury publicznej znajdują się obecnie na agendzie departamentów IT w sporej grupie przedsiębiorstw. Chociaż prognozy analityków różnią się od siebie w detalach, eksperci firm doradczych szacują, że firmy z Global 2000 są obecnie w około 20 procentach zmigrowane do chmury publicznej, uwzględniając PaaS, IaaS i SaaS. Można zauważyć pewne powtarzające się błędy związane z migracjami, których jednak da się w prosty sposób uniknąć jeśli wiadomo na co zwrócić uwagę i zadając na początku odpowiednie pytania.
Przenoszenie aplikacji
Typowym błędem jest założenie, że dotychczas wykorzystywane aplikacje biznesowe w przedsiębiorstwie można przenieść na platformę chmurową dokonując niewielkich lub nawet żadnych modyfikacji. Po prostu wystarczy przygotować środowisko i przenieść kod i dane. Takie podejście oczywiście wydaje się pozornie efektywne – oszczędzamy czas i pieniądze na development. Jednak z dużym prawdopodobieństwem nie doprowadzi do celu migracji, jakim jest obniżenie kosztów operacyjnych i podniesienie wydajności. Aby korzystać z platformy chmurowej w optymalny sposób niezbędne będzie dostosowane aplikacji zgodnie z wymogami architektury dostawcy chmury, na którego platformę aplikacje są migrowane oraz wykorzystanie w możliwie największym stopniu funkcji natywnych. Poza tym, mamy też do czynienia z zupełnie nowym modelem bezpieczeństwa.
Konsekwencje są łatwe do przewidzenia: przeniesienie aplikacji bez zmian, przy najniższym możliwym koszcie na platformę chmury publicznej przynosi po roku lub dwóch zaskoczenie kosztami hostowania, spowodowanymi nieefektywną architekturą. Kolejnym krokiem jest podjęcie zadania modyfikacji aplikacji tak, aby wykorzystywała funkcje natywne – zatem koszt tak czy inaczej trzeba ponieść. Przez ten czas jednak organizacja z jednej strony poniosła ok 50% większe koszty utrzymania wykazując jednocześnie 30-40% niższą wydajność.
Baza danych
Kolejnym błędem zaraz po przenoszeniu aplikacji 1 do 1 na platformę chmury publicznej jest brak wystarczającej uwagi poświęconej zarządzaniu danymi po migracji – a konkretnie wyborowi bazy danych. Powszechnym trendem jest wybór identycznej bazy danych jak ta, z której organizacja korzysta dotychczas w modelu on-premise. Dzieje się to bez rozważenia jakie koszty utrzymania w chmurze będzie takie rozwiązanie generować i jest bezpośrednią konsekwencją opisanego wcześniej podejścia do przenoszenia aplikacji. Może to podważyć sens dla którego przedsiębiorstwo podjęło się migracji.
Obecnie dostawcy chmury publicznej oferują zoptymalizowane pod daną platformę mechanizmy baz danych zapewniające szerszy pakiet usług, wyższą wydajność przy znacznie niższej cenie. Rozważenie migracji do bazy danych oferowanej przez dostawcę chmury powinno być jednym z kluczowych punktów agendy w procesie migracji.
Zaangażowanie DevOps
Brzemiennym w skutki błędem może okazać się separacja zespołu odpowiedzialnego za wybór dostawcy chmury a następnie za sam proces migracji od zespołu DevOps. Czyli zespołu, który ma następnie odpowiadać w organizacji za utrzymanie i rozwój aplikacji w nowym modelu. Ten błąd jest poważniejszy, niż się z pozoru wydaje – jest to błąd organizacyjny, który może kosztować miliony utraconej wydajności i pogrzebać benefity prawidłowo przeprowadzonej migracji do chmury publicznej.
Systemy IT organizacji działające w chmurze publicznej są jeszcze ważniejszym elementem łańcucha narzędzi i procesów DevOps, niż miało to miejsce w modelu on-premise. Zaangażowanie funkcji i zespołu DevOps od samego początku do procesu migracji jest kluczowe dla końcowego sukcesu – sukcesu mierzonego efektywnością działania IT w organizacji po migracji.
Czytaj także: CloudOps, czyli automatyzacja odpowiedzią na złożoność chmury
Przyjrzyjmy się jeszcze wybranym, często spotykanym w dyskusjach stwierdzeniom dotyczącym chmury, na które należy zwrócić szczególną uwagę ze względu na to, że są albo błędne albo odpowiedź jest uzależniona od wielu czynników:
| Każda aplikacja jest dobrym kandydatem do chmury | Organizacje posiadają setki aplikacji używanych w różnych procesach i powiązanych ze sobą, z czego spora część jest obciążona długiem technologicznym, co wyklucza jej transfer na inną platformę.
Utrzymywanie aplikacji legacy, często opartych na przestarzałych technologiach jest jeszcze możliwe, gdy działają na własnym serwerze. Utrzymanie aplikacji w chmurze to zupełnie innym model, w którym organizacja dzieli się obowiązkami z usługodawcą. |
| VM to VM, nie ma znaczenia czy działa w chmurze czy na naszym serwerze | Porównywanie kosztów między serwerem lokalnym a instancją chmury nie jest proste. Obliczając całkowity koszt posiadania (TCO), należy wziąć pod uwagę fakt, że koszt instancji w chmurze obejmuje wszystkie usługi oferowane przez dostawcę w jednym pakiecie, nie tylko sprzęt i oprogramowanie VM. Może to obejmować dodatkowe funkcje jak DBaaS czy serverless. |
| Nie ma większych różnic pomiędzy dostawcami chmury publicznej | Poczynając od modeli rozliczeń: każdy duży dostawca usług w chmurze używa innego. Stosują różne jednostki czasu, rozmiary instancji i oczywiście ceny. Dostawcy oferują unikalne zestawy funkcji, ale zdarzają się te same funkcje, ale o różnych nazwach. Nie mniej ważna uwaga, każdy dostawca ma swój własny zestaw interfejsów API i konsol, które są ogólnie niezgodne ze sobą. |
| Multi-cloud pozwoli nam na elastyczność | Wybór jednego dostawcy usług w chmurze wymaga wielu badań i przygotowania. O ile bardziej złożony i wymagający będzie ten proces, gdy zdecydujemy się wybrać więcej partnerów w chmurze do różnych operacji, z których wszystkie muszą być następnie zintegrowane w jednym pakiecie zarządzania. |
Czytaj także: Architektury i scenariusze dla Multi-cloud
