Dygresja mode on. Ten tekst jest trochę luźniejszy niż poprzedni, traktuje o programowaniu może na nieco ogólnym poziomie, ale wydaje mi się, że przy okazji dotyka kilku ważnych kwestii. Tak czy owak, jest niezbędnym wstępem przed kolejnym odcinkiem, w którym będzie już trochę kodu. Dygresja mode off.

Na początku wyjaśnijmy sobie jedną rzecz. „Chmura” brzmi marketingowo dobrze, ale dla kompetentnych technicznie ludzi to przecież nie wystarcza. Chcesz wiedzieć, o czym ten ewangelista mówi: czy naprawdę powinieneś przejmować się tylko swoimi danymi i aplikacją? Czy dostawca faktycznie może stworzyć odpowiednie środowisko dla twojej aplikacji? Mówią: uruchom bazę, stwórz tabele, dodaj dane i wdróż aplikację. Chmura zadba o wszystko, sama skonfiguruje sieci, storage, a na koniec zadba o aktualność oprogramowania. Oczywiście mowa tu o chmurze PaaS (Platform-as-a-Service), takiej jak Windows Azure czy Google App Engine.

Później dostaniesz okrągły rachunek od Microsoftu czy Google'a. Przecież te wszystkie wygody nie są za darmo. Gdyby zaś rachunek przestał się podobać, albo gdyby okazało się, że jednak na tej konkretnej chmurze nie jest tak dobrze, jak ewangelista mówił, to wyjście wcale nie jest łatwe. Jesteś gotowy pisać znaczną część aplikacji od nowa?

Projektując Oktawave, od początku byłem przekonany, że chmury-platformy to z jednej strony wygoda, z drugiej trochę pułapka na firmy, startupy i ich programistów. Jednocześnie wcale nie byłem przekonany, że chmury infrastruktury (IaaS: Infrastructure-as-a-Service) z konieczności muszą być dla programistów czymś mniej wartościowym. Tak, to prawda, uruchamiając swoją aplikację w chmurze IaaS, takiej jak Amazon EC2, Rackspace czy naszej Oktawave, będziesz musiał się więcej napracować. Żeby nie było, to powtarzam: więcej napracować. Samodzielnie uruchomisz i skonfigurujesz wirtualne instancje pod serwer aplikacji, sam zainstalujesz middleware i środowisko uruchomieniowe, sam postawisz serwer baz danych (choć tutaj, jeśli korzystasz z PostgreSQL-a czy MySQL-a, to mamy dla ciebie w Oktawave niespodziankę – gotowe bazodanowe instancje ORDB), wypełnisz bazy, wdrożysz aplikację, skonfigurujesz load balancing, a potem będziesz sam dbał o swoje serwerowe instancje.

Twoje instancje, z normalnymi systemami operacyjnymi – dystrybucjami Linuksa czy może Windows Serverem – które już znasz i wiesz, czego można się po nich spodziewać. Bez niespodzianek, wszystko na standardowych technologiach. Bez względu na to, czy Twoja aplikacja była pisana w tradycyjnym PHP na LAMP-ie, czy też na wciąż w Polsce egzotycznym połączeniu Node.js czy Railsa z MongoDB, możesz ją przenieść w chmurę IaaS, i możesz ją z tej chmury zabrać. Nie jesteś. Nie musisz przerabiać kodu pod platformę – a te wszystkie atuty chmur, o których opowiadał ewangelista, wciąż są prawdziwe.

Zdecydowałeś się więc na chmurę IaaS, mam nadzieję, że wybrałeś najlepszą ;). Co teraz? Jak sprawić, by aplikacja mogła rozmawiać z chmurą? Przyznaję – nie jestem aż tak "kreatywny", by burzyć to, co dobre. Nie chcę, byś uczył się czegoś nowego. Jeśli pracowałeś kiedykolwiek z Web Services czy protokołem SOAP i jeśli znasz podstawy XML-a, to z łatwością połączysz się z chmurą z wykorzystaniem interfejsu programowania - API (jeśli dana chmura takowy oczywiście udostępnia; nie wszystkie to robią). Potrzebne definicje Web Services w plikach WSDL możesz pobrać z odpowiednich stron dostawcy chmury. Zazwyczaj wszystkie usługi udostępniane są po HTTPS, zaś autoryzacja odbywa się po LDAP i Kerberosie – otrzymujesz więc rozwiązanie bezpieczne, w którym operacje na obiektach może wykonać jedynie uprawniony użytkownik.

API jest „ciche” – samo nie inicjalizuje żadnej komunikacji z aplikacją, pozwala zaś na programistyczny dostęp do wszystkich funkcjonalności chmury. Możesz za jego pomocą zarządzać serwerowymi instancjami (w tym obsługiwać autoskaler czy tworzyć migawki), zarządzać bazami danych usługi ORDB, dyskami wirtualnymi OVS, konfigurować sieci prywatne OPN, loadbalancing i kontenery.

Czy jednak nie obiecywałem wolności? Pomyślisz teraz pewnie, że gdy twoja aplikacja zostanie zintegrowana z API, to już przeniesienie jej gdzieś indziej będzie bardzo trudne. Bez obaw – w przeciwieństwie do np. Amazon Web Services, których API faktycznie przywiązuje programistów i ich aplikacje do siebie, w Oktawave (ciężko uniknąć tych porównań, ale staram się je minimalizować), wszędzie tam, gdzie to możliwe, korzystamy z otwartych standardów. Na przykład REST-owy interfejs do naszej usługi storage'owej (OCS) jest niemal całkowicie zgodny z interfejsem storage'owej usługi platformy OpenStack – drobne różnice dotyczą jedynie sposobu logowania. Niebawem zapewnimy jego zgodność z API chmury Amazon S3, dzięki czemu przeniesienie z niej aplikacji będzie sprowadzało się do zmiany parametrów połączenia. Myślę też nad metodami zwiększenia interoperacyjności głównego API Oktawave. Zanim jednak podejmę jakieś strategiczne decyzje, chcę poznać opinie społeczności, a może nawet zaangażować ją do współpracy.

Chcesz dowiedzieć się więcej? Dokumentacja głównego API Oktawave dla niezależnych programistów dopiero powstaje, ale zainteresowanym już teraz możemy wysłać to, co mamy. Wiele się także możesz dowiedzieć z analizy kodu narzędzia Oktawave-CLI, służącego do zarządzania serwerowymi instancjami w naszej chmurze bezpośrednio z konsoli. Przejrzysta składnia, dostęp do większości funkcji API, czytelny kod w Pythonie – w zasadzie to wszystko, czego trzeba, by „na szybko” zautomatyzować obsługę naszej chmury. Tak, wiemy, inne chmury też na to pozwalają. Po prostu chcemy, byście wiedzieli, że i w tej kwestii nikomu nie ustępujemy. Już dostępne są paczki Oktawave-CLI dla Debiana, Ubuntu, OpenSUSE i CentOS-a, po zainstalowaniu których będziesz mógł ze swoimi serwerami w chmurze zrobić, co zechcesz.

Mówiłem wyżej przede wszystkim o IaaS, ale niektóre chmury dostarczające infrastrukturę dają pewną namiastkę PaaS (czyli utrzymywanych w pełni przez dostawcę środowisk uruchomieniowych). Otóż są to prekonfigurowane obrazy środowisk programistycznych. Co z tego wynika? Otóż możesz uruchomić instancję "czystą" i konfigurować ją we własnym zakresie lub uruchomić ją "na gotowo" - z systemem operacyjnym, frameworkiem, odpowiednią bazą danych etc. Czym to się różni od PaaS? Głównie tym, że oszczędza etap wstępny - instalacji i konfiguracji, pozostawiając jednak kwestię dalszego zarządzania software'em (po momencie uruchomienia) po stronie użytkownika.

W ten sposób można od ręki uruchomić: LAMP (Linux, Apache, MySQL, PHP), środowiska dla .NET, a także Ruby'ego, Pythona lub JavaScriptu, skonfigurowane tak, by od razu można było wdrożyć i uruchomić na nich swoją aplikację. Dla przykładu, maszyna wirtualna z Railsami może od razu zawierać interpreter Ruby'ego 1.9.3, framework w wersji 3.2.8, serwer aplikacji Unicorn, serwer HTTP nginx i menedżer gemów RVM. Oczywiście masz pełen dostęp do ustawień konfiguracji takiej wirtualnej maszyny i możesz dostosować środowisko do potrzeb swojej aplikacji.

Więcej, tak naprawdę to być może trzeba powiedzieć, że nie ma PaaS bez IaaS, czyli to, że na końcu dnia to właśnie chmury infrastruktury służą doskonale do budowania na nich rozwiązań platformowych. I wiecie co, tak chyba nie jest źle. Bo każdy może się w ten sposób skupić na zrobieniu swojej roboty jak najlepiej - dostawcy IaaS na infrastrukturze, a chłopaki od PaaS na software.

W większości firm to nie programiści podejmują decyzje zakupowe. Programiści powinni siedzieć jak Dilbert w swoich przegródkach i pisać kod, prawda? Nie do końca – jestem przekonany, że ci dostawcy cloud computingu, którzy będą mówili tylko do biznesu, językiem biznesowym, skazani są na marginalizację. Chmury obliczeniowe zmieniają bowiem naturę biznesowego IT, uwalniając deweloperów od procedur decyzyjnych, wskutek których wdrożenie prostej aplikacji może zająć całe miesiące (w końcu dyrektor IT musi wyrazić zgodę na udostępnienie firmowego serwera, a firmowy administrator musi ze ściśniętym sercem pozwolić na to, by w jego pięknym homogenicznym środowisku Windows jakiś wywrotowy programista zainstalował Linuksa z Railsami).

Odkąd rozwiązania Software-as-a-Service zostały zaakceptowane przez firmy, zaczęły być chętnie wykorzystywane przez jednostki biznesowe jako sposób na obejście procedur firmowego IT. Wreszcie można było bezpośrednio zwrócić się ze swoim problemem do programisty, by załatwił gdzieś środowisko w chmurze, w którym szybko uruchomił to, co biznesowi było akurat potrzebne. Dlatego z naszej perspektywy, to Ty, programista, jesteś kimś, z kim chcemy jako dostawca chmury rozmawiać. Steve Ballmer krzyczał kiedyś: „developers, developers, developers” (choć chyba o tym trochę już zapomniał). Ja nie jestem może tak ekspresyjny jak Ballmer, ale chętnie podpisuję się pod tymi trzema wyrazami.

P.S. Zachęcam również Czytelników Spider's Web do zadawania pytań i pogłębiania wiedzy. Jestem tutaj, by pomóc Wam w adopcji optymalnych i oszczędnych rozwiązań dla Waszych projektów.

Maciej Kuźniar - dyrektor projektu Oktawave. Pasjonat technologii związanych z przetwarzaniem i przechowywaniem danych, posiadający 10 lat doświadczenia w pracy dla klientów klasy enterprise (banki, telekomy, fmcg). Autor koncepcji technologicznie wspierających rozwój startupów oraz rozwiązań architektonicznych gwarantujących wysokie HA i SLA dla systemów IT.