Jak i za co płacimy w chmurze publicznej?

Za co tak naprawdę płacimy

Każda z chmur oferuje wiele możliwości. Nie wnikając w szczegóły, w AWS mamy na chwilę obecną prawie 200 różnych usług. Usług, które różnią się od siebie bardzo mocno. Nie da się np. porównać maszyny wirtualnej z API do wykrywania celebrytów na zdjęciach. Każda z tych usług ma jednak przypisany do siebie swój cennik.

Ale jak to pogodzić? Jak rozliczyć poszczególne usługi, godziny pracy konkretnego procesora vs. wywołania API – mamy tutaj przecież różne zasoby, jednak sam proces nie jest zbyt skomplikowany. Z czegokolwiek byśmy nie korzystali, używamy mocy przerobowych (compute) i miejsca na dane (storage) - to są właśnie dwie podstawowe rzeczy, za które my musimy zapłacić.

Coś za darmo?

Tak, jak najbardziej możemy dostać coś za darmo. Ta specjalna oferta składa się z dwóch rzeczy, np. właśnie w AWS przez rok od założenia nowego konta dostaniesz coś w ograniczonym zakresie za darmo, a część z tych usług na określonym poziomie wykorzystania będzie dostępna „za free” na zawsze.

Przykłady? Proszę bardzo. Szczegóły zobaczysz tutaj, ale tak w skrócie. 750 godzin miesięcznie małej maszyny wirtualnej z Linuxem przez rok? Korzystanie z niej jest możliwe za darmo. 5 GB danych w usłudze S3? Mała relacyjna baza danych? Tak, też nie musisz za to nic płacić przez rok.  Dalej, np. przez 30 dni możesz za darmo korzystać z Guard Duty. A co później? Trzeba będzie już jednak sięgnąć do kieszeni i przygotować się na wydanie na to pieniędzy.

Ale oczywiście są także usługi dostępne za darmo przez cały czas m.in. milion wywołań funkcji Lambda, 25GB miejsca w DynamoDB, 50 tysięcy aktywnych użytkowników w Cognito.

I tutaj może pojawić się pytanie, czy warto patrzeć na te darmowe usługi. W mojej ocenie - i tak i nie. Jeżeli rozkręcasz biznes, masz mało klientów, uczysz się nieustannie, więc na tym etapie warto wykorzystać darmową ofertę i rozwijać swój biznes. Z drugiej strony, trzeba się przygotować na płatności i nie opierać się wyłącznie na tym, że mamy coś za darmo.

Korzystasz z darmowych kredytów od AWS? Fajnie, oszczędzasz. Ale nie warto na tej podstawie planować swojego biznesu. Kredyty się skończą, nadejdzie codzienność i z Twojej karty kredytowej zaczną znikać realne pieniądze.

Modele płatności

Wiemy już, że płacimy za compute i storage i że wcale nie jest to takie proste. Nie każde usługi da się w tak prostym modelu rozliczyć. Korzystając np. z usługi Rekognition nie wiemy, co dokładnie pod spodem AWS dla nas wykorzystał. Z naszej perspektywy wykonaliśmy request do API i dostaliśmy odpowiedź.

Spróbujmy to jednak lekko uprościć. Tak szczerze mówiąc to nawet rozłożyć na czynniki proste. Sprowadźmy to do dwóch modeli płatności:

• za użycie,
• za gotowość.

Brzmi dziwnie? Być może. Ale ma sens. W terminologii chmurowej możemy to przetłumaczyć na lepiej brzmiące frazy:

• SaaS i Serverless,
• Compute i Storage (PaaS i IaaS).

To pierwsze korzysta też oczywiście z drugiego, ale abstrakcja pozwala o tym zapomnieć. Dostawca się tym zajmuje i my o tym nie myślimy To co ważne to to, że cenniki wyglądają zupełnie inaczej.

Serverless

Popatrzmy, jak to wygląda w przypadku AWS Lambda, czyli chyba najszerzej znanej usłudze typu serverless. Tutaj płatności mamy podzielone na dwie składowe:

• ilość uruchomień,
• zasoby użyte podczas pracy funkcji.

Każdy milion uruchomień będzie kosztował nas 0,20$. A każda gigabajtosekunda (tak, taka nowa jednostka) 0.0000166667 $. Czym jest ta gigabajtosekunda? Otóż każde wywołanie funkcji powoduje użycie jakichś zasobów compute przez określony czas. Jeśli chodzi o funkcję, to możemy jej przydzielić od 128 MB do 10GB pamięci. I te zasoby alokowane są dla funkcji za czas jej określonej pracy.

Pamiętajmy o free tier dla Lambdy, czyli 1 milionie darmowych wywołań i 400000 GB-s za darmo. Często przy mniejszych projektach to w zupełności wystarczy.

Przy usługach tego typu pamiętajmy też po prostu, że płacimy tylko za to z czego rzeczywiście skorzystamy. Ilość zapytań do bazy DynamoDB, liczba przesłanych wiadomości w kolejkach SQS czy także ilość powiadomień rozesłanych przez usługę SNS będą miały wpływ na nasz rachunek. Samo utworzenie tych usług nie spowoduje naliczenia kosztów.

Maszyny wirtualne

Posłużę się tutaj przykładem kosztów dla usługi EC2 i pokażę, jak to wygląda w przypadku innego rodzaju usług. Wszędzie tam, gdzie pod spodem używane są maszyny wirtualne płacimy za czas, w którym te usługi były uruchomione. I nie ma znaczenia czy daną maszynę czy bazę danych wykorzystywaliśmy czy nie. Koszt będzie taki sam dla maszyny obciążonej w 100 % jak i tej, z której w ogóle nie korzystaliśmy.

Tu także cennik zależy oczywiście od tego jakiego rodzaju i jakiej wielkości zasoby utworzymy. Inny będzie koszt dla maszyny z jednym procesorem, a inny dla 96 procesorów i podpiętej karty graficznej.

Storage

Miejsce na nasze dane też rozliczane jest na dwa sposoby. W przypadku części usług jak na przykład Amazon EBS (dyski twarde) zapłacimy za samo utworzenie zasobów. Natomiast w przypadku innych jak S3 lub EFS koszty poniesiemy w wysokości proporcjonalnej do rzeczywistego użycia.

O czym należy pamiętać

Na rachunek w chmurze mamy oczywiście większy wpływ niż to o czym napisałem do tej pory. Koszt maszyny wirtualnej będzie się także różnił w zależności od tego czy płacimy za godziny, czy rezerwujemy maszynę na dłużej. W przypadku storage możemy korzystać z różnych klas - Ale o tym jak możemy zaoszczędzić napiszę już w kolejnym artykule.

W wielu przypadkach na wysokość naszego rachunku będzie miał znaczący wpływ także wychodzący ruch sieciowy. Dostawcy pozwalają nam za darmo wrzucać dane do chmury, ale ich "eksport" jest już niestety płatny. Często zapomina się o tym czynniku, a naprawdę może on bardzo mocno wpłynąć na koszty rozwiązań.

Sprawdźmy też zawsze jak kształtują się ceny w różnych regionach. To, że nasza aplikacja uruchomiona np. w Frankfurcie kosztuje 100 $ miesięcznie nie znaczy, że takie same koszty poniesiemy w Cape Town.

Podsumowanie

Cenniki usług u poszczególnych dostawców chmury publicznej nie różnią się od siebie zbyt dużo. Koszt rzadko jest czynnikiem, który wpływa na wybór vendora, ale jest tym czynnikiem, który często decyduje czy w ogóle z chmury będziemy chcieli skorzystać.

Dlatego pamiętajmy jednak, aby przy estymacjach kosztów nie porównywać zasobów jeden do jednego z tym, co mamy w on-premises. To naprawdę tak nie działa.

Tak jak już wspominałem wcześniej, w następnym artykule pokażę jak różne wybory i konfiguracje naszych zasobów mają wpływ na rachunek, który przyjdzie nam zapłacić na koniec okresu rozliczeniowego.