Po co w chmurze API?

15 stycznia 2013przeczytasz w 7 min.

Interfejs programowania aplikacji w chmurze - co to jest i dlaczego tak ważna jest jego kompatybilność? Tłumaczymy w naszym artykule.

Odpowiedź na pytanie, po co w chmurze API, jest na pozór oczywista. Jeśli jednak zagłębimy się w temat, dorzucimy szczegółowe pytania dotyczące tego, w jaki sposób skutecznie, efektywnie i efektownie wykorzystać API, może się okazać, że wiele spraw wymaga wyjaśnień. I że sam fakt, iż któraś usługa udostępnia API, jeszcze nic nie oznacza.

Kilka słów wyjaśnienia

Czym w przypadku rozwiązań IaaS jest API? Najprościej przyrównać to do samochodu, pod maską którego kryją się: potężny silnik, niezawodna skrzynia biegów i najlepsze wyposażenie, jakie kiedykolwiek zostało stworzone. Nie ma za to siedzeń, deski rozdzielczej, stacyjki, a nawet lusterka. Są tylko wystające kable, śrubki, bolce, szyny itp. No i tu jest rola dla API. Jeśli twórca tego supersprzętu do każdego kabla, śrubki i szyny dołączy opis, do czego owe części służą, gdzie za ich pomocą można się dostać i w jaki sposób je wykorzystać, to mamy API samochodu. Wykorzystując całą tę moc, możemy stworzyć samochód idealnie dopasowany do naszych potrzeb.

Dokładnie tak samo wygląda to w przypadku chmury obliczeniowej. Z tą różnicą, że zamiast silnika itp. dostajemy do dyspozycji nieograniczone moce obliczeniowe, zasoby dyskowe i parę innych gadżetów, a dostawca rozwiązania daje nam opis procedur, jak się do tych zasobów dostać. To, w jaki sposób je wykorzystamy, zależy tylko i wyłącznie od nas. W dużym uogólnieniu tak właśnie działa API chmury IaaS.

API w chmurze

Z API różnych dostawców cloud computingu też jest niestety pewien problem. Otóż idealnie byłoby, gdyby wszyscy stosowali tak zwane „kompatybilne” API. Wówczas użytkownik nie miałby problemu z komunikacją swoich zasobów postawionych na chmurach różnych dostawców. Ale tak się nie dzieje. Niemal każdy z dostawców buduje własne API, nieraz tylko w części kompatybilne z API innych dostawców, a zdarzają się tacy, którzy zamykają swoje API na świat. Dlatego od jakiegoś czasu na świecie trwa dyskusja o tym, jak wyglądać i funkcjonować powinno „cloud API”.

Jedna z koncepcji, zyskująca coraz większą popularność, mówi, że standardem w tym temacie powinno stać się EC2 API od Amazona. Dlaczego? Z banalnego powodu. Amazon to firma, która rozpowszechniła rozwiązanie cloud computingu na całym świecie. Jest największa i ma najbardziej rozbudowany portfel klientów.

O potędze Amazona może świadczyć choćby fakt, jak wiele powszechnie rozpoznawanych, dużych firm i aplikacji świadczy z ich usług. Na liście klientów AWS Cloud znajdziemy zarówno NASA, jak i Flipboard, „The Guardian”, „Newsweek”, Foursquare, Harvard Medical School, Futbol Club Barcelona i wiele innych (pełna lista dostępna tutaj).

AMAZON EC2 API

Amazon EC2 API został zaprojektowane, aby komunikować się z usługami Amazon Web Services. Tylko po to. Oznacza to, że nie został on przemyślany jako jeden standard dla wszystkich usług w chmurach na świecie i dlatego stosowanie go jako standardu wiąże się z wieloma problemami. Największym problemem EC2 API jako wzorcem do innych usług jest to, że właściwie nie ma czegoś takiego jak jedno EC2 API.

Do każdej z usług Amazona jest oddzielne API i każda ma dedykowany zestaw metod do kontroli usług. Zatem decydując się na wdrożenie API zgodnego z EC2 do swojego systemu, decydujesz się na wsparcie wielu API.

EC2 API jest podzielone na SOAP API oraz API „zapytań”. To pierwsze nie jest zbyt popularne w ekosystemie Amazona, ale cieszy się sporym zainteresowaniem pośród wewnętrznych aplikacji wykorzystujących chmurę EC2. API „zapytań” podzielone jest na kolejne dwie części. Na HTTP GET oraz HTTP POST. Każda usługa następnie ma własny protokół w (w niektórych przypadkach) wielu różnych wersjach. Kilka usług ma różne mechanizmy uwierzytelniania i podpisywania żądania. EC2 sam ma trzy różne wersje uwierzytelniania. Większość różnic nie jest dobrze udokumentowana (jeśli w ogóle).

Tak więc pisanie API „AWS compatibility” nie należy do najłatwiejszych zadań. Dodatkowo należy pamiętać, że nie każde rozwiązanie IaaS ma dokładnie taki sam zakres usług. Każdy dostawca infrastruktury w chmurze szuka innowacji, chce być lepszy niż konkurencja i oferuje najróżniejsze rozwiązania, najczęściej takie, których nie ma konkurencja. Wówczas API może być zgodne, ale wachlarz usług już nie. Np. w Amazonie tworząc maszynę, możesz wybrać opcję, iż będzie ona monitorowana (jej parametry będą zaczytywane). Tworząc maszynę tą samą metodą w Openstack, wybranie tej opcji nic nie da. Możesz ustawiać ją jako włączoną, ale openstack czegoś takiego nie wykona, ponieważ tego nie obsługuje.

Dlaczego warto zwrócić uwagę na API przy wyborze dostawcy chmury?

Wróćmy na chwilę do przykładu z samochodem. Będzie to przykład mocno hipotetyczny, ale za to obrazowy. Wyobraźmy sobie, że mamy do wyboru dwa samochody. Do pierwszego pasują części i akcesoria tylko od jednego producenta, natomiast części do drugiego auta możemy nabyć u dowolnego producenta na świecie. Pytanie, który samochód kupić, jest w takim przypadku pytaniem retorycznym.

Podobnie jest z dostawcami rozwiązań w chmurze. Nawet gdy w momencie wyboru najbardziej nam odpowiadającego modelu nie myślimy o tym, aby integrować się z innymi dostawcami, to warto zadbać o to, aby w przyszłości, gdy taka potrzeba nastąpi, mieć taką możliwość. Obecnie największy poziom bezpieczeństwa w tym zakresie dają te rozwiązania, których API jest w jak największym stopniu zgodne z EC2 API, które może być naszym integratorem z innymi rozwiązaniami.

e24cloud API

W e24cloud pracowaliśmy nad tym, aby nasze API było w maksymalnym stopniu kompatybilne z EC2 API. Trudno jest osiągnąć pełną zgodność ze względu na wspomniane duże rozdrobnienie API Amazona. W chwili obecnej testujemy zarządzanie usługami za pomocą aplikacji zewnętrznych. Chcemy, aby każdy, kto tworzy narzędzia, aplikacje, strony, usługi, które do swojego działania potrzebują naszych usług, miał możliwość dowolnego konfigurowania sposobu, w jaki będzie z niego korzystać. Dzięki e24cloud API użytkownik uzyskuje zdalny dostęp do wszystkich funkcjonalności dostępnych w ramach naszej usługi. Oczywiście daje to wiele korzyści, m.in.:

możliwość zautomatyzowanego zarządzania infrastrukturą
tworzenie własnych narzędzi do zarządzania infrastrukturą
automatyczne reagowanie na obciążenie
masowe tworzenie i zamykanie infrastruktury pod konkretne zadania obliczeniowe
zautomatyzowane tworzenie infrastruktury dla zadań testowych, developerskich (np. tworzenie nowego środowiska testowego przy pomocy jednego przycisku)
możliwość stworzenia infrastruktury do odsprzedaży, jak np. whitelabel.

Dzięki integracji e24cloud API z EC2 API zasoby trzymane w naszej chmurze mogą swobodnie komunikować się niemal z każdą inną usługą, której API jest zgodne z EC2.

Porównanie dostępnych usług

e24 API General API Support

Feature	Eucalyptus	OpenStack	CloudStack	Amazon EC2 API
e24 Query API
Web-based UI
Command line interface

e24 API High Level Feature Support

e24 API feature	Eucalyptus	OpenStack	CloudStack	Amazon EC2 API
Instance metadata
Public AMI's
Launch/Terminate Instance
Reboot Instance
Start/Stop Persisted Instance
Multiple Instance Types
Instance metadata
Instance Launch Time
Amazon EC2 API Compatability
Availability Zones
Region Support
Windows Support
AMI's backed by EBS

Amazon EC2 API Compatability

EC2 API method	Eucalyptus	OpenStack	CloudStack	Amazon EC2 API
DescribeAvailabilityZones
DescribeImages
DescribeInstances
DescribeRegions
RebootInstances
RunInstances
StartInstances
StopInstances

Integracja e24cloud API z EC2 API daje to nieograniczone możliwości wykorzystania cloud computingu. Ale przede wszystkim pozwala zaoszczędzić wiele pracy i pieniędzy. Środowisko Amazona jest bardzo popularne i szeroko wykorzystywane, w związku z tym nie ma problemu ze znalezieniem osób, które wiedzą, jak je wykorzystać. Można też w bardzo prosty sposób rozszerzyć funkcjonalność chmury Amazon o funkcjonalność, której jeszcze nie posiada, np. o lokalizację w Polsce. Dzięki kompatybilności z EC2 nie ma technologicznego lock-ina – zawsze można przenieść się do ASW czy RackSpace ze swoim zarządzaniem aplikacją. Nasze API umożliwia też proaktywne skalowanie maszyn, łącza czy innych parametrów.

Jeśli jesteś zainteresowany testowaniem naszego API, wyślij do nas e-maila na adres: [email protected].