Rozwiązania chmury publicznej z kwartału, na kwartał zwiększają swój udział na rynku. Fakt ten nie dziwi nikogo, coraz więcej firm skupia się na strategi w której chmura publiczna odgrywa coraz większą rolę. Ci najwięksi dostawcy oferują coraz szarszą paletę usług pozwalających zbudować architekturę spełniająca praktycznie każde wymagania. Model hybrydowy, rozwiązania dla Disaster Recovery czy Cloud Bursting, to tylko niektóre z nich. Model usługowy pozwala firmom skupić się głównie na strategi biznesowej. Przechodząc na ideologię “płać za to co używasz” można dość łatwo szacować koszty rozwiązania. Budując nowy produkt osiągnąć niskie koszty “wejścia”, co jest dużym udogodnieniem dla małych bądź rozpoczynających działalność firm.
W dużych firmach jest trochę inaczej, gdyż tam zmiana wypracowanych reguł, przyjętych procedur i strategii wymaga trochę więcej czasu. Jednak nawet wśród tych najbardziej opornych zmiana następują bądź nastąpi w niedalekiej przyszłości. Już dziś w firmach klasy Enterprise około 16% workload’u realizowane jest obecnie w chmurze publicznej, a wynik ten potroi się w kolejnych pięciu latach (JP Morgan CIO Survey).
Wszyscy by chcieli, nie wszyscy potrafią.
Ostatnio przelała się spora fala artykułów nt. problemów adaptacji chmury publicznej. Wszystko za sprawą przeprowadzonej przez IDC ankiety wśród 6159 kierowników różnych firm. Wyniki tej ankiety pokazują, że około 1/7 firm działających w modelu multi-cloud (14%) posiada aktualnie jasno sprecyzowaną strategię i procesy związane z wykorzystaniem i zarządzaniem usługami w chmurze.
Pozostała część to firmy nie posiadające żadnej strategi (22%), działające w modelu Ad-hoc (28%), bądź okazyjnie (19%) korzystają z rozwiązań chmury. Powodów takiego stanu jest wiele, przede wszystkim firmy bardzo często nie wiedzą jak taka strategia w ich przypadku powinna wyglądać. Brak kompetencji, silosowa struktura organizacji czy brak dobrego zrozumienia między biznesem a IT, to przykładowe powody w wyniku których wdrażanie chmury w organizacji jest nieefektywne.
Migracja do chmury to nie tylko Virtualne Maszyny.
W różnych rozmowach nt. chmury, gdy zazwyczaj wyjaśniając komuś, kto poraz pierwszy zainteresował się tą tematyką pada czasem pytanie “no dobra, a ile będzie kosztować 10 wirtualnych maszyn?”. Inne podejście to, “no dobra musimy szybko coś odpalić, przerzućmy to chmury, zobaczymy jak będzie”. Jak się jednak okazuję, nie zawsze takie podejście kończy się sukcesem. Bo nie dla wszystkich systemów chmurę można zaimplementować w stylu Plug&Play. Chcąc wykorzystać w sposób optymalny, to co oferują dostawcy chmurowi, trzeba zmienić trochę koncepcję myślenia i działania, a także sposób budowania aplikacji (przeczytaj to ). Zmiany wymagane są nie tylko w departamencie IT, ale w całej firmie. Np. dział finansowy musi zmierzyć się ze zmianą sposoby myślenia z tradycyjnego Capex, Opex, amortyzacja itp. na usługowy “pay as you go”.
Dlatego zbudowanie dobrego planu migracji do chmury pomoże w osiągnięciu sukcesu. Poniżej kilka rad, które mogą Ci pomóc w realizacji tego celu.
1. Ustalić wspólny front.
W momencie podjęcia decyzji o używaniu chmury, warto usiąść i zbudować spójną wizję. Na takim spotkaniu pojawić się powinni przedstawiciele działu bezpieczeństwa, specjaliści z dep. finansowego i procurement’u, architekci infrastruktury a także osoby z działów operacyjnych. Warto aby po takim spotkaniu wszyscy jasno wiedzieli, dlaczego firma decyduje się na wykorzystanie chmury obliczeniowej.
2. Czynniki ekonomiczny.
Aspekt kosztowy to jeden z pierwszych tematów nad którym będą się wszyscy zastanawiać. Niestety nie jest tak łatwo z góry oszacować czy w danym wypadku chmura będzie bardziej czy mniej opłacalna. Ale z pewnością należy oszacować koszty różnych rozwiązań architektownicznych danego systemu. Dla przykładu, koszty systemu w modelu Active/Active działającego w różnych ośrodkach Data Center, będa znacząco się różniły od środowiska w modelu np. Warm Standby.
3. Znaleść porozumienie.
Zawsze w organizacji pojawią się osoby/działy, przeciwne nowej koncepcji. Wiadomo, ludzie nie lubią zmian. Ignorowanie ich, może przyczynić się do komplikacji i utrudnić całe przedsięwzięcie. Dlatego warto dołożyć starań i dojść do porozumienia z takimi jednostakami, zwłaszcza na szczeblu osób decyzyjnych.
4. Dedykowany zespół.
Cloud Businnes Office, Cloud Council, Dream Team, czy cokolwiek takiego. Chodzi o stworzenie zespołu, którego zadaniem będzię realizacja przyjętych założeń. Zespół ten będzie składał się z cloud engineers, compliant/risk officers, właścicieli Aplikacji, IT oraz Finanse. Ich zadaniem będzie decydowanie w jaki sposób rozwiązania chmurowe będą wykorzystywane.
5. Analiza architektury.
Teraz czas na dokładną analizę i plan. Mając już CBO (patrz pkt. 4), czas na zbudowanie precyzyjnego schematu danego środowiska. Jakie komponenty z czym się komunikują, jakie dane wymieniają, cała siatka relacji i powiązań. Dopiero po takim zinwentaryzowaniu systemu, można decydować które elementy tej układanki będą przenoszone do chmury.
6. Bezpieczeństwo!
Przed rozpoczęciem migracji należy dokładnie określić w jaki sposób zrealizwać konkrente aspekty bezpieczeństwa, regulacje prawne czy właściwe standardy, PCI, ISO? Warto korzystać ze wszelakich dostępnych materiałów jak design guide, best practice czy Cloud Security Alliance.
7. Minimum Viable Cloud.
Nie ma co szaleć. Najlepiej zacząć od prostych i łatwych do przeniesienia systemów. Zdobyte doświadczenie i wiedza będą podstawą do łatwego powielenia podobnych rozwiązań oraz pomogą w przeniesieniu tych bardziej złożonych aplikacji.
8. Zarządzanie/utrzymanie/optymalizacja.
To ogromny aspekt całego rozwiązania, aby mieć ciągły pogląd na to co się dzieje w naszym środowisku chmurowym. Dedykowany team operacyjny, którego zadaniem będzie ciągłe monitorowanie i reagowanie na alarmy, niestandardowe sytuacjie. Również kontrola i weryfikacja polityk bezpieczeństwa, tego kto co robi i jakie ma uprawnienia, to zadania tego zespołu. Do tego dochodzi również analiza i monitoring kosztów, czy np. wybrany typ maszyn wirtualnych jest właściwy, albo wykrywanie nieużywanych a działających zasobów, za które trzeba płacić. Ma to znaczenie zwłaszcza przy dużej skali. Sytuacja, w której ogarnianie infrastruktury chmurowej jest pobocznym zadaniem developerów, niesie różnorakie ryzyko w obszarach bezpieczeństwa, wydatków itp.
Patrząc na to w jakim tempie dostawcy rozwijają swoje produkty i dostarczają nowe funkcjonalności, potrzebny jest zespół, który będzie się skupiał na tym aby być up2date. Dzięki temu możliwe jest osiągnięcie jak największej optymalizacji swojego systemu.
9. Automatyzacja.
To co jest dużym atutem chmury publicznej, zwłaszcza AWS, Azure, to dostępność gotowych narzędzi wspomagających automatyzację, CI/CD itp. Dlatego warto automatyzować wszystko co możliwe, zwłaszcza powtarzalne procesy. Ręczne wykonywanie jest nie tylko czasochłonne, ale również niesie za sobą ryzyko popełnienia błędu pod kątem np. konfiguracji czy bezpieczeństwa. Dlatego warto używać narzędzi do automatyzacji deploymentu, czy prowizjonowania nowych zasobów. Pomoże to nie tylko w codziennej pracy, ale również przy przenoszeniu kolejnych systemów.
10. Gotowi na więcej.
Mając już za sobą zmigrowane pierwsze aplikacje, a rezem z tym doświadczenie i pewne wypracowane procedury, czas na więcej. W pierwszej kolejności warto określić, które aplikacje nadają się do przeniesienia, a które nie. Warto podzielić je na kilka kategorii. Te, które wymagają tylko drobnych zmian, takie które wymagają refaktoringu (zmiany części kodu). Kolejna kategoria to systemy, które muszę być przepisane na nowo, a na koniec te które zostaną z czasem wycofane. Mając taki podział można ruszyć z planem i migracją kolejnych aplikacji. Wykorzystując narzędzia stworzone w pierwszej fazie, ponownie zaczynając od tego co w danym momencie będzie najprostsze i tak schodząć coraz głębiej. Dla systemów należących do dwóch ostatnich kategorii zespół CBO musi wypracować długofalowy plan działania.
Jeśli zatem w Twojej firmie chmura jest co raz cześciej rozważanym kierunkiem, mam nadzieję, że ta lista będzie pomocna. A jeśli masz już jakieś doświadzczenia za sobą i chciałbyś się nimi podzielić, pisz śmiało!
Zbuduje swoje bezpieczne środowisko AWS.
