Cloud computing robi od pewnego czasu zawrotną karierę medialną. Tematem zajmują się nie tylko tytuły poświęcone branży IT, ale także biznesowe i popularno-naukowe. Nawet Dilbert wspomina już o cloud computing. Warto zatem zastanowić się czym jest, a czym nie jest cloud computing i jak wpłynie na tworzenie i zarządzanie oprogramowaniem.

Autor: Michał Kuratczyk
Źródło: Software Developer’s Journal 02/2010 (182) http://sdjournal.org

Definicja dopiero się krystalizuje, ale najważniejszym jej wyróżnikiem jest udostępnianie zasobów IT za pośrednictwem sieci i pobieranie opłat za stopień ich wykorzystania. Klient nie ponosi nakładów inwestycyjnych z góry i nie musi obawiać się niedoszacowania ani przeszacowania swoich potrzeb. Jednocześnie specjalizacja usługodawcy oraz efekt skali powoduje, że usługi takie powinny być wyższej jakości, a koszty dla klienta niższe, niż gdyby sam utrzymywał środowisko IT. Czy cloud computing jest zatem czymś nowym? I tak i nie. Tak, ponieważ do niedawna nie było takich platform jak Google App Engine czy Amazon EC2. Są to bez wątpienia rozwiązania innowacyjne, dające nowe możliwości. Czy jednak stary, poczciwy, hosting stron WWW nie pasuje do podanej definicji? Pasuje. Podobnie jak odpłatne konta pocztowe w serwisach internetowych, czy aplikacje biznesowe dostępne przez internet. Cloud computing nie jest zatem koncepcją rewolucyjną, a jedynie kolejnym krokiem w ewolucji branży IT. Usługi IT stają się dobrem powszechnym, co pociąga za sobą zmiany w sposobie ich świadczenia.

Rysunek 1. Schemat koncepcyjny architektury IaaS/PaaS

Różne rodzaje cloud computingu
Ze względu na olbrzymią pojemność pojęcia cloud computingu, należy wyróżnić kilka jego rodzajów. Po pierwsze, usługodawcą może być firma zewnętrzna lub dział IT klienta. Mówimy wówczas o chmurze publicznej (public cloud) lub prywatnej (private cloud).

Po drugie, usługi świadczone w tym modelu mogą dotyczyć jednej z trzech warstw – infrastruktury, platformy programistycznej lub aplikacji biznesowych. Nazywamy je odpowiednio Infrastructure as a Service (IaaS), Platform as a Service (PaaS) lub Software as a Service (SaaS). Przykładem IaaS jest Amazon EC2 – możemy tu wykupić potrzebny nam czas procesorów, miejsce na dyskach i przepustowość sieci. Usługodawca nie wnika w jaki sposób korzystamy z tej infrastruktury, ale odpowiada za jej gotowość do pracy. Google App Engine jest już przykładem usługi PaaS, gdyż usługodawca daje nam konkretne narzędzia, z których możemy korzystać do stworzenia potrzebnej nam aplikacji. Co prawda w dalszym ciągu płacimy za zasoby fizyczne (procesor/pamięć/sieć/dysk), ale jednak dostajemy już nie tylko infrastrukturę, ale kompletne, ustandaryzowane, środowisko do rozwoju i działania aplikacji – możemy co prawda wybrać jeden z dwóch języków (Java, Python), ale nie możemy zastosować dowolnej dostępnej na rynku technologii. O Software as a Service, ostatnim wariancie cloud computing, mówi się dużo już od dłuższego czasu. Jest to po prostu udostępnianie aplikacji biznesowych w formie usługi, a nie licencji. Dzięki temu klient nie ponosi kosztów początkowych, nie musi utrzymywać swojego środowiska, ani zatrudniać specjalistów do zarządzania nim. W tym wypadku podstawą rozliczenia jest zazwyczaj ogólna ilość użytkowników lub ilość równolegle otwartych sesji.

Przykładem oprogramowania dostarczanego wyłącznie w modelu SaaS jest Google Apps, zaś dostępnego zarówno w modelu tradycyjnym (licencyjnym), jak i w modelu SaaS jest Oracle CRM i jego wersja SaaS – CRM On Demand.

Enterprise private clouds
Enterprise private cloud, to nic innego jak prywatny cloud danego przedsiębiorstwa, udostępniający usługi IT działom biznesowym i partnerom (spółkom zależnym, itp). Z punktu widzenia programistów, najciekawszym wariantem takiej chmury, jest Platform as a Service.

Korzystanie z prywatnego PaaS oznacza dla programistów kilka zmian, w porównaniu do tradycyjnego modelu. Wspomniałem już, że w modelu PaaS programista jest ograniczony do narzędzi i technologii dostępnych na platformie. Może to budzić niechęć ze względu na osobiste preferencje, ale daje wymierne korzyści biznesowe firmie, dla której przecież pracujemy. Standaryzacja i konsolidacja środowisk pozwala wyraźnie obniżyć koszty sprzętu, licencji, pomocy technicznej oraz personelu. Oczywiście powinna istnieć możliwość dodania określonej technologii do zestawu narzędzi dostępnych na platformie, ale nie ma co liczyć na pełną dowolność, jak w przypadku zupełnie niezależnych projektów i środowisk. W zamian programista otrzymuje jednak wiele korzyści. Po pierwsze dostaje możliwość prostego tworzenia dodatkowych środowisk na żądanie. Z założenia chmura powinna być łatwa w rozbudowie i powinna pomieścić dodatkowe instancje, jeśli ich potrzebujemy. Co więcej, tworzenie środowisk powinno być zautomatyzowane, a zarządzanie nimi oddane w ręce użytkowników. Programista może zatem zażądać utworzenia nowego środowiska, czy to z jakiegoś wzorca (np. czyste środowisko z aplikacją w wersji X), czy też poprzez skopiowanie innego środowiska (potrzebuję identycznego środowiska jak Y, żeby zdiagnozować problem, który występuje tylko tam). Środowisko takie powinno zostać utworzone w czasie minut lub godzin, a nie dni czy tygodni, jak to często bywa, gdy utworzenie środowiska wymaga akceptacji przełożonych, zamówienia sprzętu i ręcznej pracy. Idąc tym tropem, możemy także przenieść środowiska testowe ze stacji roboczych na platformę PaaS, dzięki czemu nie musimy sami nimi zarządzać, możemy przywracać je do poprawnego stanu, gdy coś pójdzie nie tak, a wszystkie zmiany konfiguracyjne (np. podłączenia do baz danych, adresy serwerów aplikacji czy web services) są centralnie zarządzane i nie musimy się tym zajmować. Warto także zaznaczyć, że prywatny PaaS nie ogranicza możliwości debugowania systemu – o ile publiczny dostawca niekoniecznie udostępni nam wszelkie możliwości diagnostyczne, o tyle prywatny PaaS daje możliwość włączenia odpowiednich opcji i podłączenia się z narzędziami diagnostycznymi.

Zmiany organizacyjne
Cloud computing, zwłaszcza prywatny, wymaga przede wszystkim zmiany sposobu myślenia o zasobach IT. Tak jak SOA nie jest technologią opartą na web services, tylko architekturą wymagającą zmiany sposobu i szerszego spojrzenia na tworzenie i ponowne wykorzystanie aplikacji, tak cloud computing nie wymaga żadnej szczególnej technologii, ale przede wszystkim zmiany w procesie zarządzania zasobami. Technologia jest rzeczą wtórną, która usprawnia ten proces i umożliwia zapewnienie dostępności, wydajności i bezpieczeństwa w tych nowych warunkach. O ile korzystanie z usług publicznych dostawców cloud computing może być (i często jest) decyzją oddolną, o tyle projekt budowy wewnętrznej platformy PaaS w firmie, wymaga konkretnych nakładów początkowych, zmiany procesu zakupów sprzętu i licencji oraz rozliczania innych działów za korzystanie z nich. Należy zwrócić uwagę, że wiele aplikacji, ze względu na poufność przetwarzanych danych lub inne uwarunkowania, nie może być uruchomiona na publicznych środowiskach, dlatego korzystanie z nich decyzją oddolną powinno być zgodne z polityką bezpieczeństwa firmy, a budowa prywatnej platformy może być niezbędna. Na czas budowy takiego środowiska można z kolei skorzystać z publicznego IaaS, w którym od ręki będziemy mogli wynająć sprzęt potrzebny do rozpoczęcia projektu.

Techniczna realizacja PaaS
Udostępnianie platformy aplikacyjnej jako usługi oznacza przede wszystkim zmianę modelu sprzedaży/współpracy między działem utrzymania systemów, a działami rozwoju i utrzymania aplikacji. Niemniej jednak, aby zapewnić sprawne działanie takiej platformy, co jest warunkiem koniecznym osiągnięcia sukcesu, przydatne są odpowiednie rozwiązania techniczne. Jeśli tworzenie środowisk potrzebnych do rozwoju aplikacji będzie trwało zbyt długo lub utworzone środowiska będą wymagały ręcznych poprawek, programiści powrócą do rozwijania kodu na własnych komputerach. Jeśli wzrost obciążenia w jednej aplikacji będzie powodował spadek wydajności całej platformy, menedżerowie poszczególnych aplikacji będą żądać separacji środowisk, co zniweczy korzyści wynikające z konsolidacji.

Wirtualizacja
Można stworzyć środowisko bez problemu spełniające definicję PaaS nie korzystając z żadnego rozwiązania wirtualizacyjnego, ale zastosowanie takiej technologii pozwala osiągnąć znacznie większe korzyści z wdrożenia platformy PaaS. Wirtualizacja pozwala zwiększyć utylizację zasobów sprzętowych, zachować ciągłość pracy w czasie prac konserwacyjnych (np. wymiana sprzętu) oraz pomaga zarządzać środowiskami. Pozwala tworzyć wzorcowe instalacje dostępnych na platformie komponentów, np. komponent baza danych zawierający odpowiednio skonfigurowany system operacyjny z podłączeniem do przestrzeni dyskowych, bazę danych w odpowiedniej wersji i ze wszystkimi poprawkami, narzędzia diagnostyczne i tak dalej. Po przygotowaniu odpowiednich komponentów, gdy będziemy zaczynać nowy projekt, programista będzie mógł zażądać nowego środowiska ze wszystkimi potrzebnymi komponentami, a po wprowadzeniu niezbędnych zmian wymaganych dla danej aplikacji (np. schematy bazy danych, połączenie z odpowiednim modułem repozytorium kodu), zachować obraz jako wzorcowy dla innych osób pracujących nad tym projektem.

Sprawnie działająca platforma PaaS powinna pozwolić na stworzenie środowisk dla wszystkich zainteresowanych w ciągu kilku godzin.

Warstwa middleware
W warstwie oprogramowania middleware, przydatnych może być kilka funkcji. Po pierwsze klastrowanie z synchronizacją sesji użytkowników, jako podstawowy mechanizm skalowania i zapewniania ciągłości pracy tej warstwy. Po drugie, możliwość jednoczesnego korzystania z różnych wersji tych samych bibliotek, bowiem nasza aplikacja niekoniecznie będzie działać na zupełnie niezależnym środowisku. Instalacja nowej aplikacji wraz z zależnościami nie może powodować zmiany wersji biblioteki używanej przez już działającą aplikację. Kolejna sprawa, to możliwość testowego uruchomienia aplikacji na platformie. Dopóki całe środowisko nowej aplikacji jest niezależne – możemy testować aplikację do woli bez udostępniania jej użytkownikom. Jeśli jednak chcemy przeprowadzić ostateczne testy przed upublicznieniem aplikacji na platformie PaaS, musimy mieć możliwość uruchomienia nowej aplikacji tylko dla wybranych użytkowników (testerów). Kolejna kwestia bardzo ułatwiająca zarządzanie tak dynamiczną platformą, z wieloma środowiskami i aplikacjami, to mechanizm skryptowy pozwalający zautomatyzować czynności administracyjne. Nawet jeśli korzystamy z wirtualizacji i
możemy tworzyć obrazy wzorcowe, to po każdym skorzystaniu z takiego wzorca, potrzebujemy zmienić kilka parametrów (adresy, porty i tym podobne). Do tego należy doliczyć późniejsze zmiany, które trzeba w powtarzalny sposób wykonywać na wszystkich środowiskach (np. dodanie nowego data source). Ręczne wykonywanie zmian mogłoby spowodować niespójność środowisk i tym samym zniwelować korzyści wdrożenia PaaS.

Bardzo ciekawym rozwiązaniem, dopiero wchodzącym na rynek, są serwery aplikacji działające bezpośrednio na hypervisorze – bez klasycznego systemu operacyjnego. Takie podejście pozwala nie tylko podnieść wydajność, dzięki lepszemu zarządzania pamięcią (normalnie system operacyjny i JVM częściowo pokrywają się funkcjonalnością w tym zakresie), ale również pozwala wyraźnie uprościć całe środowisko (skoro nie ma systemu operacyjnego, to nie trzeba go konfigurować, optymalizować, ani aktualizować). Dodatkowo uzyskujemy mniejsze obrazy maszyn wirtualnych, gdyż nie zawierają one binariów systemu operacyjnego. Pozwala to obniżyć koszty przestrzeni dyskowych, zaoszczędzić miejsce na urządzeniach backupowych i skrócić czas migracji maszyny wirtualnej między fizycznymi serwerami.

Poza samym kontenerem, warto również zastosować technologię in-memory data grid. Pozwala ona przechowywać duże ilości danych obiektowych (w tym obiekty sesji HTTP) w pamięci operacyjnej, dzięki czemu odciąża kontener JEE. Rozwiązania wyraźnie przyspieszają działanie aplikacji i pozwalają skalować aplikacje praktycznie w nieskończoność.

Warstwa bazy danych
Podobnie jak w przypadku serwerów aplikacji, w warstwie baz danych zastosowanie klastrów również pozwala zachować ciągłość pracy i umożliwia skalowanie systemów w razie takiej potrzeby. Kluczowe staje się także zarządzanie przestrzenią dyskową. Zastosowana technologia powinna nie tylko umożliwiać łatwą rozbudowę, ale również równomiernie rozkładać obciążenie między dostępne dyski. W przeciwnym wypadku, w krótkim czasie mielibyśmy analogiczną sytuację jak z serwerami bez wirtualizacji – gdy do aplikacji przypisane są na stałe określone zasoby sprzętowe, to prawie zawsze część z nich jest przeciążona, a część niedociążona. Podobnie jak w przypadku serwerów, aby w pełni czerpać korzyści z konsolidacji, potrzebujemy zatem warstwy wirtualizacji dla zasobów dyskowych.

Zarządzanie zasobami
W praktycznie każdym systemie, także nie korzystającym z platformy PaaS, warto korzystać z mechanizmów ograniczania dostępu do zasobów pojedynczym użytkownikom, czy aplikacjom. Użytkownicy nie powinni odczuwać wyraźnego spadku wydajności w sytuacji, gdy jeden z nich generuje skomplikowany raport. W tym wypadku baza danych powinna odpowiednio ograniczyć zasoby dostępne dla sesji tego użytkownika, umożliwiając normalną pracę pozostałym. Zarządzanie zasobami staje się jeszcze ważniejsze, gdy na jednym fizycznym komputerze mogą działać na przykład dwie maszyny wirtualne, każda ze swoim systemem operacyjnym i bazą danych, a każda z baz danych obsługuje kilka różnych aplikacji. Jeśli nie zdefiniujemy odpowiedniej polityki przydziału zasobów, nie będziemy w stanie zapewnić wymaganego poziomu świadczenia usług dla poszczególnych aplikacji.

Cykl życia “chmury”
Jednym z głównych założeń cloud computing jest samoobsługa użytkowników. To oni tworzą kolejne środowiska, gdy ich potrzebują, są odpowiedzialni za odpowiednie ich kategoryzowanie (test/produkcja), żądają dodatkowych zasobów, jeśli wiedzą, że będą potrzebne (w sytuacjach nieprzewidzianych za taką rozbudowę odpowiada już dostawca platformy) i wyłączają instancje, których dłużej nie potrzebują. Dostawca chmury PaaS, także prywatnej, musi zatem zapewnić interfejs do zarządzania środowiskami klienta.

Rozliczanie wykorzystania zasobów
Zgodnie z definicją, rozliczanie klientów jest oparte o zużycie określonych zasobów. Czynnikami wpływającymi na koszt korzystania z clouda mogą być zarówno wartości techniczne (czas procesora, zużycie sieci, etc), jak i biznesowe – na przykład ilość kampanii marketingowych przeprowadzonych przy użyciu danej aplikacji. Można sobie łatwo wyobrazić sytuację, w której dostępne są również różne taryfy, podobnie jak to jest u operatorów telefonicznych. Opłata składa się zwykle z części stałej (abonamentu) oraz zmiennej – zależnej od wykorzystanych zasobów. W celu minimalizacji kosztów zmiennych, konieczna może się okazać optymalizacja aplikacji – czynność, o której niestety wiele osób zapomniało w dobie wydajnych i często przeszacowanych serwerów (analizy pokazują, że średnie obciążenie serwerów rzadko przekracza 20%).

Podsumowanie
Budowa prywatnej chmury Platform as a Service pozwala osiągnąć cele, do których dąży praktycznie każde przedsiębiorstwo – skrócenie czasu od pomysłu do realizacji (time to market), a co za tym idzie wzrost przychodów. Konsolidacja sprzętu i licencji oraz łatwa dynamiczna rozbudowa zapewnia jednocześnie niższe koszty utrzymania, oraz brak konieczności ponoszenia dużych kosztów na początku każdego projektu. Z punktu widzenia programisty, to przede wszystkim likwidacja barier organizacyjnych i większa swoboda w korzystaniu z zasobów firmy, a jednocześnie mniej czasu straconego na zarządzaniu środowiskami i mniej problemów wynikających z różnic między nimi. Dobrze zrealizowana platforma powinna zatem przynieść korzyści wszystkim zainteresowanym.

MICHAŁ KURATCZYK
Principal solution architect, Oracle Polska