Felietony

Nie wszystko chmura co się kłębi

Grzegorz Marczak
Nie wszystko chmura co się kłębi
19

Jest to tekst Jacka Artymiaka, który tworzy serwis texy.co Dziś kontynuujemy cykl artykułów o "cloud computing". W publikowanym poniżej tekście przyjrzymy się jakie technologie oraz usługi "chmurkowe" możemy dziś kupić i jak mogą one pomóc startupom. Cloud computing jest dziś modne i kto może prób...

Jest to tekst Jacka Artymiaka, który tworzy serwis texy.co
Dziś kontynuujemy cykl artykułów o "cloud computing". W publikowanym poniżej tekście przyjrzymy się jakie technologie oraz usługi "chmurkowe" możemy dziś kupić i jak mogą one pomóc startupom.
Cloud computing jest dziś modne i kto może próbuje dołączyć do pochodu, ale nie wszystko co się chmurą zowie chmurą jest w rzeczywistości. Nie wystarczy podpiąć przycisk RESET do internetu i nazwać serwer dający się w ten sposób restartować przez przeglądarkę "serwerem cloudowym".

Cloud computing to więcej niż podpięcie zaawansowanych paneli zarządzania do serwerów dedykowanych. To zmiana sposobu myślenia o mocy obliczeniowej, składowaniu danych, sieciach, i aplikacjach. Pierwszą ważną zmianą w myśleniu jest pozbycie się myślenia o serwerach jako o konkretnych maszynach. Zamiast zastanawiać się który serwer da radę udźwignąć obciążenie naszego serwisu szukamy dostawcy usług hostingowych, którego maszyny wirtualne oferują parametry potrzebne do poradzenia sobie z takim obciążeniem. Kupujemy hurtowo moc obliczeniową a nie konkretny sprzęt. Zaletą takiego myślenia jest uwolnienie się od zmartwień np. o to czy uda nam się znaleźć maszynę o konfiguracji podobnej do tej, która właśnie wyzionęła ducha i np. o to kiedy ta maszyna będzie dostępna. W przypadku serwera wirtualnego po prostu uruchamiamy nową maszynę i w ciągu kilku-kilkunastu minut jesteśmy znów online.

Skoro kupujemy moc obliczeniową, przepustowość oraz przestrzeń dyskową, to możemy też zacząć dostosowywać nasz serwis do sezonowych zmian obciążenia. Np. sklep z ozdobami choinkowymi będzie potrzebował zwiększonej mocy obliczeniowej i przepustowości łącz w ostatnim kwartale roku, więc wtedy uruchamiamy np. cztery 64GB maszyny a w pozostałe miesiące wystarczy do utrzymania strony i sklepu jedna maszyna 4GB. Wszystko to możemy zautomatyzować za pomocą skryptów monitorujących obciążenie maszyn w czasie rzeczywistym więc nagłe zainteresowanie srebrnymi szpicami choinkowymi w lipcu nie zaskoczy nas we śnie.

W modelu dynamicznego hostingu jaki oferują "serwery chmurkowe" zamiast płacić za serwery "na wszelki wypadek", płacimy za moc i przepustowość rzeczywiście wykorzystaną i zmieniającą się dynamicznie. Nikt nie będzie się czepiał jeżeli przez cały rok będziemy utrzymywać blog o hodowli nutrii na maszynie z 512MB RAM a kiedy raz do roku zdarzy się, że odkryje nas Wykop powiększymy tę maszynę wirtualną w kilka minut do np. 32GB RAM i 8 rdzeni aby po godzinie znów powrócić do 512MB. Zapłacimy za faktycznie wykorzystaną moc, pamięć, przestrzeń dyskową i przepustowość. Kto myśli, że to się startupom nie opłaca, powinien prześledzić historię drop.io i foursquare.com, które zaczynały od hostingu w chmurze AWS EC2.

Wirtualne serwery

Najprostsze oferty hostingu na serwerach wirtualnych nie różnią się wiele od serwerów dedykowanych. Wiem, że to stwierdzenie może nie podobać się wielu czytelnikom, którzy słusznie wskazują na wyższe koszty miesięczne wynajęcia serwera wirtualnego oraz jego mniejszą wydajność (stan na początek roku 2012). To prawda, w przypadku serwerów produkcyjnych koszt wynajęcia serwera dedykowanego na miesiąc będzie dziś niższy od serwera wirtualnego. Ale z drugiej strony dostawca serwera dedykowanego nie przyjmuje zwrotów po trzech dniach i nie podstawi w ciągu 5 minut farmy 200 serwerów "na godzinkę". Czas dostawy serwera dedykowanego to zwykle kilka dni a minimalny okres wynajęcia to miesiąc.

Przykładem dostawcy, który oferuje prosty hosting "cloudowy" jest Storm on Demand (marka firmy Liquid Web). To co oferuje SoD jest podstawową usługą za dobre pieniądze. Nie znajdziemy tu większych fajerwerków "chumrkowych" poza serwerami wirtualnymi w różnych rozmiarach z możliwością zmiany rozmiarów maszyny i rozliczeniami godzinowymi, ale mamy za to dobre ceny za dane wysyłane z naszych serwerów. Za dane przyjmowane nie płacimy.

Hosting w oparciu o serwery wirtualne to jednak za mało, żeby mówić o "cloud computing" pełną gębą. W chmurze albo z chmurą zrobić można zrobić znacznie więcej. Najlepiej pokazuje to historia Amazon Web Services.

A programistom interfejsy (API) damy...

Amazon był pierwszym graczem, który pokazał do czego można stosować chmurę kiedy zaprezentował Amazon Web Services (AWS) w roku 2002. Na początku nie było jeszcze mowy o wirtualizacji serwerów, zaczęto od udostępniania interfejsów programistycznych (API) do ważnych funkcji analitycznych, np. rankingu sprzedaży lub do programu partnerskiego. Chociaż dział PR oraz zaprzyjaźnieni fani Open Source propagowali ten interfejs programistyczny jako wspaniały dar dla społeczności internetowej, ich pojawienie się nie było spowodowane chęcią podzielenia się własną mocą obliczeniową z resztą świata--prawdziwym powodem była podjęta przez Bezosa decyzja o ujednoliceniu komunikacji między serwerami w rozrastających się gwałtownie serwerowniach firmy. Osiągnięto to właśnie za pomocą ujednoliconych interfejsów programistycznych. Udostępnienie ich światu zewnętrznemu było przemyślaną decyzją biznesową--zewnętrzni programiści budowali sklepy oraz narzędzia analityczne podpięte pod Amazona, co zwiększało obroty firmy. Przy okazji Amazon wypromował modę na API jako narzędzie promocji serwisów internetowych; wkrótce udostępniali je prawie wszyscy: Google, Flickr, Skype, Yahoo!, Delicious, i inni.

Amazon stopniowo dodawał nowe interfejsy, w tym najbardziej nowatorski interfejs człowiek-maszyna-tłum, czyli Mechanical Turk. Pomaga ona szybciej realizować zadania, które dają się podzielić na proste czynności. Taką czynnością było sprawdzanie czy zdjęcie produktu w katalogu Amazon.com jest zgodne z jego opisem. Zamiast wynajmować na wiele miesięcy zespół ludzi do czyszczenia katalogu, Amazon zaproponował, że zapłaci każdemu kto poświęci parę minut dziennie na kliknięcie OK lub ERROR po kilkanaście centów od jednego kliknięcia. To za mało, żeby zrobić z tego karierę, ale gdy zbierze się odpowiedni zespół to wyklikane pienądze są jak najbardziej konkretne. I wszyscy są zadowoleni, Amazon.com ma uporządkowany katalog, klikacze dodatkowe pieniądze a pośrednicy organizujący zespoły klikaczy do wynajęcia też nie narzekają. Aby wszystko było dokładnie policzone Amazon stworzył API do crowdsourcingu pomagające proponować zdania do wykonania na platformie Mechanical Turk i analizować rezultaty.

Dlaczego Amazon udostępnił Mechanicznego Turka każdemu kto ma kartę kredytową? A czego innego mielibyśmy oczekiwać od firmy, której szef pierwsze biurko zrobił sobie ze starych drzwi a potem sprzedał je na aukcji ze sporym zyskiem? Amazon prędzej czy później sprzedaje wszystko co wymyślą jego pracownicy. Przy okazji, wymyślając rzeczy nowe zespół IT firmy zdobywa wiedzę, której inni dopiero od nich będą się uczyć. Amazon potrafi jak mało która firma zamieniać wiedzę na pieniądze. A co może mieć z MT startup? Może np. zamówić usługę testowania serwisu, kiedy jeszcze nie ma wystarczającej ilości użytkowników, porównywania ilustracji, transkrypcji nagrań, itp. zadań, które wymagają ludzkiej inteligencji, wyobraźni i doświadczenia, które nie dają się jeszcze zaprogramować. Listę oferowanych zadań można przejrzeć na stronach MT.

Po sukcesie Mechanicznego Turka przyszła kolej na kila innych ofert dla programistów, pojawiły się API pozwalające wyszukiwać produkty w katalogu Amazon.com, sterować pracą wyszukiwarki A9, itp. Ale to wszystko było za mało. Zmiany w architekturze procesorów pozwalające na podział komputera na kilka a nawet kilkadziesiąt mniejszych maszyn wirtualnych wykorzystujących jeden lub więcej rdzeni procesora umożliwiły działowi IT Amazona realizację planów wirtualizacji serwerów. Po co im wirtualizacja? Po to by lepiej zarządzać posiadanymi serwerowniami. Nie jest przecież tajemnicą, że obciążenie serwerów sklepu internetowego podlega dużym fluktuacjom. Aby sobie z tym poradzić Amazon musiał kupować duże ilości serwerów z dużym wyprzedzeniem wydając sporo pieniędzy na utrzymanie w ruchu serwerów, które przez większość roku nie przemęczały się zbytnio albo nawet wcale.

Bezos chciał więc zastosować model znany z rynku nieruchomości. Kiedy duża firma potrzebuje powierzchni biurowej, wynajmuje lub kupuje ją z dużym zapasem i wynajmuje niewykorzystane biura innym, mniejszym firmom. Amazon nie zamierzał jednak być firmą hostingową. Zamiast tego zaczęli w 2006 roku udostępniać pierwsze usługi "cloud computing": EC2 i S3, czyli serwery wirtualne oraz "nieskończenie" skalowalną hurtownię danych.

Serwery wirtualne EC2 były pierwszymi serwerami, które można było wygodnie backupować i odtwarzać on-line bez konieczności podłączania napędów taśmowych, robotów, i planowania zakupu taśm DAT. Plan backupów oraz procedury odtwarzania serwerów można zwyczajnie zaprogramować i zlecić narzędziom takim jak Chef, Fabric czy Puppet. Co jest przydatne, kiedy startupowa drużyna siedzi przy komputerach w Lublinie a serwery siedzą gdzieś w serwerowni w Kalifornii. Serwery EC2 były pierwszymi komercyjnie oferowanymi serwerami wirtualnymi, za które płacić można w cyklach godzinowych.

Sztandarowym przykładem tego jak chmura zmienia nasze myślenie o tym jak rozwiazywać skomplikowane problemy była cyfryzacja archiwum New York Times'a. Prowadzący projekt ludzie zorientowali się, że mogą uruchomić setkę maszyn, która w 24 godziny dokona cyfryzacji archiwum artykułów i ilustracji z ostatnich 150 lat. Koszt był identyczny jak w przypadku jednej maszyny pracującej przez setki godzin.

S3 to hurtownia danych, która działa w sposób podobny do nieskończenie skalowanego słownika przechowującego dane w parach hasło-wartość, bez stosowania drzewiastych struktur czy języka SQL. Dane mogą być przechowywane w oddzielnych "pojemnikach", ale na tym kończą się możliwości budowy struktur danych. W zamian za to dostajemy łatwość dostępu do danych dzięki zastosowaniu prostego interfejsu programistycznego. Olbrzymią zaletą S3 jest brak ograniczeń pojemności wynajmowanej hurtowi danych. Jeżeli potrzebujemy więcej przestrzeni dyskowej, po prostu wgrywamy więcej danych--zapłacimy za zajmowaną przestrzeń dyskową oraz za transfer danych z S3 do odbiorców. Jeżeli nasz startup potrzebuje przetwarzać bardzo duże ilości danych, S3 lub jego odpowiednik będzie ekonomicznym wyborem.

Spece of hostingu idą w chmury

Amazon nie mógł długo cieszyć się swoją pozycją monopolisty wśród dostawców platformy dla różnego rodzaju aplikacji "cloud computing". Dostawcy serwerów dedykowanych, którzy w roku 2006 oczekiwali podpisywania długoterminowych kontraktów na wynajem serwerów zorientowali się, że muszą zaproponować swoim klientom własną odmianę "serwerów w chmurach". Jedną z najlepszych odpowiedzi na parę EC2/S3 zaproponowała spółka Rackspace Hosting, która od kilku lat oferuje usługi Cloud Servers (odpowiednik EC2) oraz Cloud Files (odpowiednik S3).

Biały montaż dla startupów

Aby wyróżnić się na tle konkurencji, Amazon zaczął udostępniać w ramach AWS usługi, które rozwiązują problemy trudne lub czasochłonne dla małych zespołów, które chcą skupiać się na wykonaniu zadania a nie na szczegółach technicznych. Do takich problemów należą np. instalacja, testy i administracja kolejek, baz danych, obsługi płatności, sieci dystrybucji treści czy klastrów obliczeniowych.

Kto potrzebuje obsługi kolejek może skorzystać z Amazon SQS, komu potrzebna relacyjna baza danych może wynająć Amazon RDS. Cache? Jest Amazon ElastiCache.

Open Source na ratunek

Oferta Amazona, chociaż bardzo wygodna jest ofertą zamkniętą. Owszem, dział PR Amazona będzie przekonywał nas o otwartości oferowanych interfejsów programistycznych, ale kiedy podepniemy się pod np. bazę danych Amazon DynamoDB skazujemy się na to, że koszty, wydajność i dostępność bazy danych zależy od Amazona. Tak jest w przypadku wszystkich "czarnych skrzynek", także tych oferowanych w ramach Google App Engine. Owszem, możemy usunąć nasze dane i kod z infrastruktury Amazona czy Google'a, ale będziemy musieli przepisać sporą część kodu na nowo. Mamy tu więc do czynienia z przykładem tego co nazywamy "vendor lock-in". To nie jest dobre dla klienta ani dla rynku.

Jednym z najważniejszych projektów, które mają na celu uwolnienie klientów dostawców usług "cloud computing" jest OpenStack, którego celem jest udostępnienie podstawowej infrastruktury cloudowej każdemu, kto ma dostęp do przynajmniej dwóch średniej wielkości serwerów. Na zasadach Open Source (licencja Apache 2.0). Dlaczego firma hostingowa chce dać innym swoje oprogramowanie? Dlatego, że na rynku toczy się wojna.

Rackspace Hosting od początku swego istnienia była firmą hostingową, która dbała o odpowiednie wsparcie klienta. Ich oferta, chociaż niekoniecznie najtańsza zawsze była jasno zaprezentowana a "fanatyczne wsparcie" klienta stało się czymś co wyróżniało ich od samego początku. Ponieważ nie mogła konkurować z Amazonem i jego chmurowymi klockami, poszli w drugą stronę i zamiast zamykać klientów w swoim ekosystemie zaproponowali, że podzielą się ze światem swoim oprogramowaniem do zarządzania wirtualnymi serwerowniami. Jak pomyśleli, tak zrobili i w ten sposób dali światu projekt OpenStack, który na rynku usług "w chmurze" zaczyna robić tyle samo zamieszania co kiedyś Linux na rynku systemów serwerowych.

Rackspace każe konkurencji przenieść się na własne pole bitwy—niezawodność, wsparcie klienta, wydajność. Kto jest niezadowolony może przenieść swoje maszyny wirtualne z serwerowni Rackspace do innego dostawcy albo do własnej w ciągu kilku minut. Na razie OpenStack nie oferuje tych samych klocków co Amazon AWS ale model Open Source wygra walkę z zamkniętym modelem Google App Engine i Amazon AWS.

Co z tego mają startupy?

Oferta usług, platform, aplikacji w "chmurach" jest dziś bardzo bogata. Możemy dziś wynająć stabilne serwery wirtualne, hurtownie danych, zapory sieciowe, load balancery, sieci dystrybucji treści (CDN), gotowe do podłączenia bazy danych, kolejki, cache, i inne klocki. Możemy podpiąć się pod infrastrukturę Amazona lub Google'a. Skraca to czas potrzebny uruchomienia usługi za cenę utrudnienia przeniesienia kodu do innych dostawców. Jeżeli potrzebujemy możliwości przenoszenia naszego back-endu od dostawcy do dostawcy możemy budować na platformie OpenStack i parkować nasz kod i dane tam, gdzie będzie się o nie ktoś troszczył najlepiej. Możemy też pościgać się z dostawcami tradycyjnych serwerów dedykowanych i zacząć budować własną firmę hostngową w oparciu o OpenStack.

Chcemy czy nie, chmury będą coraz częściej wykorzystywane przez startupy oraz duże firmy. Lepiej zacząć się ich uczyć już dziś.

Autor uczestniczy w pracach nad dokumentacją projektu OpenStack. Opinie prezentowane przez autora nie są opiniami firmy Rackspace Hosting.

Jacek Artymiak tworzy serwis texy.co

Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu

Więcej na tematy:

cloud computing