Zastosowań chmur obliczeniowych – czyli takich, gdzie możemy uruchomić wirtualne maszyny lub storage – jest cała masa. Jednym z nich jest możliwość uruchomienia w takim środowisku testów i innych narzędzi developerskich, np. automatyczne budowanie oprogramowania. Poniżej przedstawiam krótkie porównanie wykorzystania chmur IaaS na właśnie takie potrzeby. Będzie ono dotyczyło:

• chmur prywatnych, hostowanych we własnym zakresie
• chmur prywatnych, kolokowanych w datacenter
• chmur publicznych

Nie będzie jednak porównania z chmurami opartymi o kontenery – te zwykle, ze względów bezpieczeństwa są hostowane na chmurze IaaS (np. Google Cloud container engine)

Chmury prywatne – do czego lepiej nie używać?

Środowisko IaaS daje ogromne możliwości skalowania uruchamianej w nim infrastruktury. Bez dotykania sprzętu możemy dowolnie przekonfigurować sieci, w kilka sekund utworzyć wirtualne maszyny lub zaalokować miejsce na wirtualny dysk.

Wszystkie te właściwości mają swoje zalety zarówno dla zastosowań DevOps, zwłaszcza nakierowanych na Continous Integration jak i na hostowanie serwisów www. W pierwszym przypadku zwykle największym atutem chmury jest jej wspomniana elastyczność i możliwość szybkiego tworzenia i usuwania zasobów, co dla np. testów integracyjnych może być kluczową funkcjonalnością. Dzięki niej mamy możliwość łatwego przetestowania tego, jak zachowuje się rozwijane oprogramowanie, praktycznie na żądanie, bez żmudnego przygotowywania środowiska testowego.

Dla drugiego, bardzo popularneg zastosowania chmur IaaS, czyli hostingu serwisów WWW są to nieco mniej istotne cechy takich środowisk (aczkolwiek równie ważne, w przypadku skalowania tych serwisów). Dużą zaletą środowiska chmury dla hostingu jest niewątpliwie dostępność usług. O ile pojedyncza wirtualna maszyna może być co najwyżej tak stabilna jak serwer, na którym stoi, to przeniesienie całej aplikacji do chmury i uruchomienie jej na wielu maszynach pozwala bardzo dobrze uodpornić się na awarie sprzętu. Zwykle profesjonalne serwerownie, z jakich korzysta Amazon AWS, Google Cloud lub OVH posiadają redundantne łącza z Internetem, zasilanie oraz zapasowy sprzęt, który jest wymieniany przez obsługę natychmiast. Dodatkowo, duże, publiczne chmury potrafią też migrować swoje zasoby w przypadku awarii sprzętu na inny, a koszty takich udogodnień, rozłożone na wielu klientów są znikome.

Innym aspektem jest fizyczne bezpieczeństwo – dostęp do dużych serwerowni zwykle jest ograniczony. Dostęp do “serwerowni” zaadaptowanej w naszej firmie z nieużywanego, małego pomieszczenia zwykle jest rozszerzony o tzw. “poziom sprzątaczka” – osoby, która musi wszędzie posprzątać 🙂 Z drugiej strony, jak plotki głoszą, duże firmy mogą wpuszczać różne agencje wywiadowcze, ale to tylko plotki.

Krótkie porównanie poniżej będzie dotyczyło jednak tylko kwestii finansowych związanych z używaniem chmur IaaS.

Chmura publiczna

Jest to chyba najprostszy sposób przeniesienie się w chmurę i uruchomienia swoich serwisów, zarówno na potrzeby DevOps (z całą otoczką) jak i serwisów. Za co płacimy? Jedynie za to, co wykorzystamy. Rozliczanie zajętego miejsca na dysku, wirtualnych maszyn, transferu danych i innych usług jest zwykle rozliczane co godzinę.

Jeśli dobrze zautomatyzujemy swoją infrastrukturę, to możemy się nawet pokusić o dokładanie maszyn w godzinach, w których nasze serwisy są bardziej obciążone lub w momencie uruchamiania testów, przez Jenkinsa. Dzięki takiemu podejściu możemy znacznie ograniczyć koszty infrastruktury, poświęcając za to swój (albo pracowników) czas na przygotowanie odpowiednich skryptów, które zautomatyzują wszystko.

Jak wyglądają ceny? W zależności od potrzeb, za pojedynczą wirtualną maszynę z szablonu f1-micro z 0.6GB RAM i 1 vCPU zapłacimy miesięcznie 3.88USD, czyli około 15zł, w zależności od kursu PLN/USD. Domyślnie taka instancja posiada 10GB przestrzeni dyskowej. Warto przy tym pamiętać, że jest to instancja Shared-Core, która de facto nie posiada jednego pełnego rdzenia CPU, a jedynie współdzieli go z innymi, uruchomionymi na danym fizycznym serwerze w chmurze Google.

Instancja utworzona z szablonu n1-standard-1, który posiada już przypisany fizyczny 1 CPU oraz 4 GB RAM kosztuje miesięcznie 24USD, czyli około 100zł.

Natomiast jeśli potrzebujemy na prawdę sporo zasobów, to za maszynę z szablonu n1-standard-16 posiadającą 16 CPU z 60GB RAM zapłacimy co miesiąc 388USD, czyli ponad 1400zł, co jest całkiem sporą kwotą.

Jak można obniżyć te koszty? Od pewnego czasu Google daje podczas rejestracji bon o wartości 300USD, co jest znaczną kwotą, zwłaszcza dla małych firm, zaczynających swoje przygody z publicznym cloudem lub szkolącym pracowników. Dodatkowo, możemy się zobowiązać, że dana instancja będzie uruchomiona przez zadeklarowaną ilość czasu (rok lub trzy lata), co daje też obniżkę z 388USD dla n1-standard-16 do 349USD miesięcznie.

Jeśli nie potrzebujemy wirtualnej maszyny przez długi okres czasu, a jedynie chwilowo (np. do uruchomienia testów naszego oprogramowania) można pójść w innym kierunku. Bardzo często obciążenie chmur publicznych wacha się w zależności od regionów. Dla regionów usytuowanych w Europie, będą to nasze godziny pracy, czyli od ok. 8 do 16, gdy ruch w Internecie statystycznie wzrasta. W tym czasie zapotrzebowanie na zasoby cloudu publicznego jest zwykle większe. W nocy, gdy zapotrzebowanie jest mniejsze, zasoby chmury są mniej wykorzystane. Możemy wykorzystać to i uruchamiać instancje korzystając z tzw. giełdy instancji w Amazonie lub instancji Preemptible w Google Cloud (tak, wiem, że to się spolszcza, ale łatwiej będzie Ci znaleźć pod tą nazwą). W skrócie – instancje tego typu są nawet 3-krotnie tańsze, ale Google zastrzega sobie prawo do usunięcia ich w razie potrzeby. W praktyce taka instancja może działać miesiące, lub tylko kilka godzin, w zależności od obciążenia danego regionu w chmurze. Jest to rozwiązanie, które jest warte rozważenia dla osób, które potrzebują instancji tylko na chwile, tylko do uruchomienia pojedynczych zadań, a nie do hostowania serwisów.

Chmura prywatna

Można też pójść w inną stronę – uruchomić prywatną chmurę we własnej infrastrukturze. Wiąże się to oczywiście z kosztami zakupienia sprzętu i jego serwisowania, włączając w to koszty prądu, jednak późniejsze koszty są znacznie mniejsze.

Jaki mamy wybór? Jeśli decydujemy się na tego typu rozwiązanie, to warto rozważyć wykorzystanie sprzętu refurbished (używany, odnowiony sprzęt z gwarancją), który jest znacznie tańszy od nowych serwerów, a w przypadku środowiska chmury awaria jednego serwera nie jest aż tak uciążliwa.

Koszty mogą być bardzo różne, w zależności od tego jak duże środowisko chcemy uruchomić. Dla przykładu za 4 serwery HP Proliant G6 z roczną gwarancją (dość stare konstrukcje, ale sprawdzone) możemy zapłacić ok. 1400zł za sztukę, czyli razem około 5600zł. Do tego należy doliczyć ok. 500-1000zł na dodatkowy sprzęt, taki jak switche, okablowanie i szyny do montażu w szafach RACK. Przykładowa konfiguracja w powyższej cenie może być następująca:

• Serwer zarządzający: 4GB RAM, 16CPU, 4x Ethernet 1Gbit, storage 300GB RAID 1
• 3x serwery robocze: 46GB RAM, 16CPU, 4x Ethernet, storage 300GB RAID 1)
• 2x Switch 1GBit

Miesięczna cena prądu, jaką taka instalacja zużywa to około 160zł (0.kW * 24 godziny dziennie * 30 dni w miesiącu, przemnożone przez średnią cenę prądu, 0.44gr za kWh).

Zakładając, że taka instalacja posłuży nam przez co najmniej dwa lata, mamy zatem około 7000zł kosztów początkowych. Podzielone na powyższy okres daje 291zł, plus prąd, co ostatecznie daje ok. 450zł miesięcznych kosztów. Może się wydawać, że to dużo, w końcu najmniejsza instancja w Google Cloud kosztowała 15zł miesięcznie. Jednak jeśli popatrzymy na większe, które kosztowały miesięcznie 100 albo 1400zł, to opcja ta może się opłacić.

Co dostajemy w zamian? Każdemu serwerowi roboczemu pozostawimy 4GB pamięci RAM, co daje ostatecznie 42GB dla wirtualnych maszyn, na każdym z nich. Powyższa instalacja pozwoli zatem uruchomić:

• 210 instancji f1-micro, ze współdzielonym procesorem (2,90zł/miesiąc)
• 126 instancji odpowiadających n1-standard-1, ze współdzielonym procesorem (3,57zł/miesiąc)
• 48 instancje n1-standard-1, bez współdzielonego procesora (każda instancja dostaje własny rdzeń), 9,37zł/miesiąc
• lub 3 instancje n1-standard-16, bez współdzielenia procesorów (150zł/miesiąc)

Wszystko za powyższe 450zł miesięcznie, zakładając pełne wykorzystanie zasobów. W zamian za niższe ceny jesteśmy również odpowiedzialni za utrzymanie takiej infrastruktury i reagowanie na jej awarie. Potrzebny jest też ktoś, kto będzie potrafił administrować takim środowiskiem. Dodatkowo, gdy skończą się nam zasoby, będziemy musieli dostawić kolejne serwery do chmury, co jest procesem trywialnym, ale jednak spoczywającym na naszych barkach. Oczywiście nie mamy tego problemu w publicznych chmurach, podobnie jak nie mamy możliwości zrezygnowania z posiadanych zasobów – jeśli nie używamy takiej instalacji, to jej zasoby się nie amortyzują.

Czy instalacja takiej chmury jest trudna? W przypadku środowiska OpenStack można takie zadanie zlecić zewnętrznym firmom, które zajmują się przygotowaniem takich środowisk i administracją. Można też użyć nieco prostszych rozwiązań, które nie są nastawione na ogromne datacenter tak jak OpenStack i dobrze sprawdzą się w małych instalacjach, do kilku tysięcy rdzenie. Przykładem może być CoreCluster, który jest nastawiony właśnie na proste i bezobsługowe użytkowanie w małych, prywatnych instalacjach. Jeśli decydujemy się na samodzielną instalację, to wprawnemu administratorowi może to zająć od niecałego dnia (CoreCluster) do ok. tygodnia pracy (OpenStack, dostosowany do potrzeb). W przypadku OpenStacka możemy też potrzebować nieco większej ilości sprzętu do obsługi naszej chmury niż w instalacji z CoreCluster.

Private cloud w datacenter

Jak wspomniałem na początku, publiczna chmura daje dość dużo elastyczności i zwalnia nas z myślenia o wszelkich awariach, skalowaniu sprzętu i jego serwisowaniu w porównaniu do prywatnej, jednak jest znacznie droższa (f1-micro kosztuje 2,90zł z CoreCluster na przykładowej instalacji refurbished vs. 15zł z Google Cloud).

Możemy jednak zrobić coś jeszcze, co przybliży nas z bezawaryjnością działania do publicznej chmury – włożyć własny sprzęt do datacenter. Wiąże się to oczywiście z wizytą w być może odległej serwerowni i całym dniu instalacji, jednak w zamian dostaniemy bezawaryjny dostęp do Internetu, zasilanie, klimatyzację i czyste powietrze. O ile to ostatnie może sie niektórym wydać dziwne, to trzeba mieć świadomość, że serwery przepuszczają przez siebie ogromne ilości powietrza. Jeżeli nie jest ono filtrowane, tak jak w większości datacenter, to po pewnym czasie serwery będą musiały być czyszczone.

Kolokowanie sprzętu w profesjonalnym datacenter wiąże się oczywiście z pewnymi kosztami – dla serwerowni S3 w Katowicach jest to około 800zł miesięcznie za połowę szafy RACK. Patrząc na koszty naszej prywatnej instalacji może to zwiększyć ponad trzykrotnie koszty wykorzystania infrastruktury.

W zależności od instalacji, jaką chcemy uruchomić, powyższe koszty mogą się różnie kształtować.

Podsumowanie

Co i kiedy się opłaci? Ta decyzja należy do Ciebie. Jeśli potrzebujesz stabilności lub sporadycznie potrzebujesz środowiska chmury, to publiczna chmura będzie w sam raz. Jeśli natomiast nie boisz się administracji albo masz administratora, który może się tym zająć i duża część pracowników będzie wykorzystywać zasoby chmury IaaS po potrzeb Continous Integration i podobnych – możesz rozważyć prywatną instalację, która w niedługim czasie powinna się zwrócić.

Koszty używania/miesiąc [zł]	f1-micro	n1-small-1	n1-small-16	n1-small-1 shared vCPU
Google Cloud	15	100	1400	–
Private cloud	2.90	3.57	150	9.37
Colocated private cloud	~ 9	~ 10.50	~ 450	~ 29.30

Warto też zauważyć, że pozostają nam też takie technologie jak Docker (i kontenery), które coraz łatwiej jest przenieść w chmurę, jednak nie dają takiej separacji jak wirtualizacja, która jest znacznie bardziej dojrzałą technologią.