Wirtualizacja serwerów jaką znamy właśnie znalazła się na zakręcie. Wzrost skali środowisk wirtualnych zaczyna generować koszty niewspółmierne do uzyskiwanych korzyści biznesowych, m.in. przez nieproporcjonalnie dużą konsumpcję zasobów firmowego środowiska IT. Równolegle rośnie presja biznesu na szybsze wprowadzanie zmian w aplikacjach oraz możliwość skalowania ich praktycznie bez żadnych ograniczeń, bez istotnych zmian w ich architekturze. Ponadto zarządy oczekują od deweloperów, że tworzone przez nich aplikacje będzie można uruchamiać tam, gdzie aktualnie najtaniej. Technologie wirtualizacyjne będące w powszechnym użyciu nie podołają tylu oczekiwaniom jednocześnie. W zastosowaniach deweloperskich ich miejsce zajmą wkrótce dwie relatywnie nowe technologie kontenerowe, które zyskały wsparcie największych graczy na rynku wirtualizacji i usług PaaS.

Testowanie i dostarczanie nowych wersji oprogramowania powszechnie wykorzystuje wirtualizację. Cykl wydawania nowych wersji wygląda w uproszczeniu tak. Kod jest kompilowany i uruchamiany w środowisku testowym, na które składa się wiele odpowiednio skonfigurowanych maszyn wirtualnych. Po zakończeniu testów poszczególne maszyny wirtualne wraz z całą swoją zawartością, a więc aplikacjami, bazami danych, systemami plików, systemami operacyjnymi, oraz ich parametrami konfiguracyjnymi są zapisywane w plikach obrazów. Wdrożenie nowej wersji sprowadza się do skopiowania maszyn wirtualnych ze środowiska testowego do produkcyjnego.

Kilka lat temu to proste, przejrzyste i eleganckie rozwiązanie było objawieniem, ale potrzeby deweloperów nie stoją w miejscu. Rozwój środowisk wirtualizacyjnych odbywa się obecnie w dużej mierze pod wpływem oczekiwań działów utrzymaniowych. Z punktu widzenia deweloperów platformy wirtualizacyjne stały się „ciężkie”, złożone i mało elastyczne. W szczególności, nie pomagają im spełniać oczekiwań biznesu, który stale nalega na większą częstotliwości wprowadzania nowych funkcji oraz redukcję związanych z nimi kosztów.

To popycha deweloperów ku chmurowym platformom PaaS, zapewniających szereg udogodnień w tym zakresie. One jednak również nie są idealne, a nadto rodzą dodatkowe problemy. Niszę powstałą w wyniku rozdźwięku między potrzebami i możliwościami platform wirtualizacyjnych próbują zagospodarować nowe technologie. Na przestrzeni ostatniego półrocza upowszechniły się rozwiązania, dzięki którym deweloperom będzie zdecydowanie łatwiej nadążyć za oczekiwaniami biznesu. Mowa tu o technologii kontenerów Docker Engine, rozwijanej na zasadach open source przez firmę Docker, oraz  technologii AppStack autorstwa firmy CloudVolumes, przejętej właśnie przez VMware.

Wirtualizacja: waży i kosztuje

Dopóki firmowe środowisko wirtualne składa się z kilku czy kilkunastu usług działających w dedykowanych maszynach wirtualnych czy nawet małych klastrach, dotychczasowe podejście do zarządzania release’ami świetnie się sprawdza. Każde środowisko z biegiem czasu staje się jednak coraz bardziej złożone. Usługi są dzielone na mniejsze, łatwiejsze w zarządzaniu zestawy funkcji, powstają nowe warstwy abstrakcji, rośnie liczba współzależności, złożoność obiektów monitorujących i zarządzających, a ważniejsze usługi zaczynają działać w dużych klastrach wydajnościowych.

„Rozwój środowisk wirtualizacyjnych odbywa się obecnie w dużej mierze pod wpływem oczekiwań działów utrzymaniowych. Z punktu widzenia deweloperów platformy wirtualizacyjne stały się „ciężkie”, złożone i mało elastyczne”

Testowane rozwiązania często zachowują się niestabilnie, a ponadto wymagają izolacji dla jednoznacznej interpretacji testów. Dlatego w zastosowaniach deweloperskich mamy zwykle do czynienia z wirtualizacją pełną – każda usługa składająca się na środowisko aplikacyjne działa w odrębnej maszynie wirtualnej wraz z własną kopią systemu operacyjnego i pozostałymi przyległościami. W efekcie, środowisko wirtualne zaczyna zajmować bardzo dużo przestrzeni (wydajnej, zabezpieczonej, zarządzanej – czytaj: drogiej). Co więcej, owe Terabajty trzeba jeszcze pomnożyć przez liczbę kopii wykonaną w trakcie testów. To nigdy nie jest jedna kopia.

Środowisko produkcyjne to kolejne Terabajty. Tu także nie mamy do czynienia z jedną kopią. Co jakiś czas, np. co 30, a niekiedy do 15 minut, wykonywane są snapszoty środowisk, by w razie awarii móc dysponować ich aktualną, spójną kopią. Dopóki wszystko odbywa się w lokalnej sieci SAN, nie ma to wielkiego znaczenia. Czy jednak na pewno? Finansowy chętnie przypomni, że koszt nabycia pamięci masowych wraz z całym instrumentarium (backup, archiwizacja, zarządzanie itd.) nie był zerowy, a ich utrzymanie również bardzo wyraźnie widać w budżecie.

„Ich”, ponieważ posiadanie lokalizacji zapasowej to dziś raczej przymus, a nie ekstrawagancja. Większość organizacji nie zaryzykuje tylko kopiowania snapszotów między lokalizacjami. Trzeba je cyklicznie scalać i uruchamiać, by w razie awarii dysponować działającym środowiskiem. To koszt w postaci dodatkowych licencji na środowisko wirtualne. Do tego, przy dużym zapotrzebowaniu na pasmo, w związku z kopiowaniem dużych ilości danych między lokalizacjami praktycznie bez przerwy, koszty łączności przestają być pomijalne. I tak, to, co w momencie zakupu wydawało się źródłem pokaźnych oszczędności (ale to było kilka kwartałów temu, kto by to pamiętał…?), zaczyna być kosztowne – tu i teraz.

Idą chmury, a każda inna

Gdy Finansowy w końcu powie „dość” deweloperzy będą początkowo iść w zaparte. Chcą przecież sprawnie tworzyć i testować nowy kod, by biznes mógł uzyskać pilnie potrzebne funkcje. Budżety nie są jednak z gumy. Ktoś skonstatuje, że skoro lokalne zasoby są takie drogie, być może należy spróbować w chmurze. „bo ceny przecież ciągle spadają”. Deweloperzy spróbują. Dokonają rozlicznych zmian w kodzie, by uwzględnić specyfikę wybranego dostawcy usług PaaS. Gdy przenosiny i testowanie zostaną zakończone, będzie można oficjalnie odtrąbić zwycięstwo. I wtedy właśnie konkurencyjny dostawca wyśle maila do Finansowego z informacją, że ma ofertę o 30% tańszą.

Chcąc, nie chcąc, deweloperzy skontaktują się z konkurencyjnym dostawcą. Będzie wszystko, co potrzeba, i faktycznie taniej, tylko… w nieco innym wydaniu. Bazy danych będą w starszej wersji niż obecnie używana, co da deweloperom kolejną porcję pracy. Nieco inne będą narzędzia i API do zarządzania, i tu też trzeba będzie dostosować się. Inne będą zapatrywania dostawcy na klastrowanie oraz politykę automatycznego skalowania obciążeń. Również konstrukcja cennika będzie inna. Deweloperzy znów poświęcą więc czas na modyfikację i testowanie nowych wersji usług, adapterów itd., by rozwiązanie wpasowało się w nowy model „zachęt i ograniczeń”.

Niecały kwartał później nowy dostawca PaaS dokona istotnych zmian w infrastrukturze, by „zwiększyć elastyczność i wydajność usług dla klientów”. Nowe usługi będą atrakcyjniejsze, ale będą wymagać kolejnej porcji zmian w środowisku. Będą też droższe. Deweloperzy zorientują się, że znaleźli się w pułapce – utracili kontrolę nad środowiskiem w imię redukcji kosztów, które ostatecznie jednak nie zmalały. Co dalej? Jak długofalowo tworzyć rozwiązania, nadające się do uruchamiania lokalnie i środowisku chmurowym dowolnego dostawcy – bez modyfikacji kodu aplikacji, i bez zasadniczej zmiany architektury środowiska?

Stoczniowiec z przyszłością

Trudności w przenoszeniu aplikacji między środowiskami legły u podstaw Docker Engine – nowej technologii wirtualizacji aplikacji opartej na kontenerach, rozwijanej w modelu open source przez firmę Docker. Sam koncept nie jest nowy. Bynajmniej. Technologie konteneryzacji istnieją i mają się dobrze od wielu lat, by wspomnieć choćby o Solaris Zones, technologiach firmy Softricity, które po jej przejęciu przez Microsoft zostały wykorzystane w App-V, czy też kontenerach linuxowych (LXC). W przeciwieństwie do wirtualizacji pełnej, technologie kontenerowe, takie jak Docker Engine, nie tworzą pełnej abstrakcji sprzętu i nie uruchamiają na niej odrębnej kopii systemu operacyjnego. Każda aplikacja działa w wydzielonej przestrzeni nazw i może dysponować własnym systemem plików, system operacyjny pozostaje jednak jeden. Docker zarządza także limitami zasobów dostępnych poszczególnym kontenerom.

„W przeciwieństwie do wirtualizacji pełnej, technologie kontenerowe, takie jak Docker Engine, nie tworzą pełnej abstrakcji sprzętu i nie uruchamiają na niej odrębnej kopii systemu operacyjnego. Każda aplikacja działa w wydzielonej przestrzeni nazw i może dysponować własnym systemem plików, system operacyjny pozostaje jednak jeden”

Docker Engine to m.in.: (1) usługa systemowa zapewniająca izolację procesów poszczególnych kontenerów i zarządzanie dostępem do zasobów systemu operacyjnego, (2) kontenery, czyli katalogi zawierające wszystkie składniki aplikacji oraz pliki konfiguracyjne (Docker docs) z informacją o obiektach systemowych niezbędnych do poprawnego działania aplikacji, a także o jej zależnościach zewnętrznych, (3) obrazy kontenerów wykonane jako snapszoty (spójne kopie na poziomie blokowym), obejmujące aplikacje oraz pliki konfiguracyjne, a także (4) skrypty zarządzające procesem tworzenia i aktualizowania obrazów kontenerów.

Docker Engine pozwala na łatwe przenoszenie aplikacji między systemami w formie obrazów – analogicznie jak w tradycyjnej wirtualizacji. Obraz jest jednak nieporównywalnie mniejszy (kilkadziesiąt Megabajtów wobec wielu Gigabajtów). Nie zawiera bowiem systemu i innych przyległości, a jedynie pliki konfiguracyjne wskazujące na ich wersje i konfiguracje. W efekcie tworzenie kopii środowisk aplikacyjnych w środowiskach deweloperskich, testowych i produkcyjnych przestaje pochłaniać Terabajty kosztownej przestrzeni. Pozwala także zwiększyć częstotliwość wykonywania snapszotów środowiska produkcyjnego bez przyprawiania o ból głowy związany z kosztami. Zasadniczo mniejsza objętość obrazów oznacza również, że można je błyskawicznie przesyłać do zapasowych centrów danych, nawet jeśli nie posiada się dedykowanego światłowodu za „ciężkie pieniądze”.

Dla deweloperów ważniejsze jest jednak to, że aplikacja w kontenerze Docker może być uruchamiana praktycznie w każdym środowisku systemowym, dla którego powstała wersja Docker Engine. Wśród platform wspierających Docker Engine są wszystkie liczące się dystrybucje systemów Linux (m.in. RedHat, SuSE, Ubuntu, Gentoo), Mac OS X, oraz Windows 7 i 8. Technologię tę wspierają m.in. Google, Amazon Web Services, Microsoft Azure, chiński Baidu oraz rosyjski Yandex. Google jest jednym z aktywnych deweloperów Docker Engine, dzięki któremu oprogramowanie to nie jest już bezpośrednio zależne od kontenerów LXC (choć zachowało kompatybilność).

Docker przewiduje dalszy rozwój swojej technologii. Trwają już prace nad w umożliwieniem wzajemnej komunikacji kontenerów. W związku z tym możliwe stanie się także dodanie funkcji do maskowania zmian w środowisku. Przykładowo, kontener będący abstrakcyjnym reprezentantem usługi „baza danych”, będzie mógł wskazywać na różne bazy danych, w zależności od potrzeb dewelopera, testera czy administratora środowiska produkcyjnego. To zasadniczo usprawni obszar zwany dziś modnie DevOps. W efekcie deweloperzy będą mogli pisać aplikacje w sposób generyczny, wskazując jedynie na kontenery, które przekażą wywołania do właściwej w danym środowisku instancji obiektu. Aplikacje staną się dzięki temu jeszcze bardziej przenośne oraz skalowalne, zaś to, gdzie będą uruchamiane, rzeczywiście będzie decyzją bardziej finansową, niż techniczną.

Aplikacja jako wtyczka

Choć to nieoczywiste, podobne efekty można osiągnąć przez ewolucyjny rozwój istniejących technologii wirtualizacyjnych. Firma CloudVolumes opracowała technologię wirtualizacji aplikacji polegającą na zapisywaniu ich w dedykowanym pliku obrazu maszyny wirtualnej VMware (VMDK) lub Hyper-V (VHD). Oto jak to działa. Aplikacja jest instalowana w systemie operacyjnym, w którym działa aktywny agent CloudVolumes. Agent śledzi zapisy na dysku wykonywane podczas instalacji i kopiuje je do dedykowanego pliku obrazu VMDK lub VHD. Zapisywane są również powiązane z aplikacją pliki usług systemowych, aktywowane role systemowe, ustawienia uprawnień, wpisy do rejestru itd. Agent może zapisać także instalacje innych aplikacji lub narzędzi powiązanych z aplikacją, nawet jeśli po każdej takiej instalacji system będzie restartowany.

Gdy proces tworzenia finalnego środowiska aplikacji zostanie zakończony, obraz jest zapisywany jako AppStack, czyli kompletne, zwirtualizowane środowisko aplikacyjne w formie dysku wirtualnego VMDK/VHD, dostępnego w trybie tylko do odczytu. Po podłączeniu takiego dysku do dowolnej maszyny wirtualnej z agentem CloudVolumes, automatycznie i natychmiast, bez żadnych dodatkowych zabiegów, instalacji, restartu itd. aplikacja staje się widoczna w systemie jako uruchomiona. Działają wszelkie jej współzależności środowiskowe, aktywne stają się właściwe wpisy w rejestrze itd. Prostota i szybkość instalacji (lub roll-back’u) takiej aplikacji na dowolnie dużym klastrze jest wręcz powalająca. Mówimy o sekundach. Piękno tego rozwiązania polega także na tym, że w ogóle nie zaburza ono procesu przygotowania aplikacji przez deweloperów i testerów.

„VMware kupił właśnie firmę CloudVolumes. Jej technologia AppStack pozwala tworzyć obrazy aplikacji ze wszystkimi jej zależnościami jako dyski wirtualne VMDK lub VHD. Po podłączeniu takiego dysku do maszyny wirtualnej VMware lub Microsoft aplikacja staje się natychmiast widoczna w systemie jako działająca. Prostota i szybkość instalacji (lub roll-back’u) takiej aplikacji na dowolnie dużym klastrze jest wręcz powalająca. Mówimy o sekundach”

Wolumeny AppStack wydają się świetnym rozwiązaniem do zarządzania aplikacjami w środowiskach desktopów wirtualnych (VDI). Najwyraźniej jest to jeden z ważnych, choć na pewno nie jedyny, powód, dla którego CloudVolumes została właśnie kupiona przez VMware. Ten zakup pozwoli VMware sprzedać więcej licencji na swoją infrastrukturę wirtualną, a jednocześnie znacznie wzmocni jej usługi Horizon, którymi, jak się wydaje, chce odebrać udziały w rynku firmom Microsoft i Citrix. Niezależnie od tego, deweloperzy aplikacji i administratorzy środowisk skalujących się na setki, a nawet tysiące serwerów mogą zacierać ręce. Po kolejnym podwyższeniu wersji środowiska VMware ich praca stanie się prawdopodobnie znacznie łatwiejsza.

Gdyby dziś próbować szkicować główne zastosowania dla technologii firm Docker i CloudVolumes, linia podziału przebiegała by zapewne mniej więcej tak. Docker Engine jako rozwiązanie open source, wciąż jeszcze w fazie dynamicznego rozwoju, jest propozycją dla firm z dużym zapleczem deweloperskim lub dostawców usług internetowych. Brak opłat licencyjnych pozwala zaoszczędzić środki, z których można sfinansować wynagrodzenie dla co najmniej kilku wysokiej klasy inżynierów. Rozwiązania CloudVolumes (a w zasadzie nowe rozwiązania VMware) wyglądają na bardziej dojrzałe, a ich zakres funkcjonalny wskazuje, że w pierwszym rzędzie jest to produkt korporacyjny. Z biegiem czasu ten podział, już dziś bardzo umowny, będzie coraz bardziej zacierać się.

Zaangażowanie Google, Microsoft i Amazon Web Services na wczesnym etapie rozwoju technologii Docker Engine wróży jej szybkie dojrzewanie i upowszechnienie. Z kolei VMware najwyraźniej rozumie, że jej obecna pozycja jako światowego lidera technologii wirtualizacyjnych nie jest gwarantowana i musi dalej o nią walczyć. Bronią w tej walce będzie sprawna konwersja istniejącej bazy klientów korzystających z rozwiązań do wirtualizacji serwerów do rozwiązań wirtualizujących aplikacje. Patrząc na to, co firma właśnie nabyła, wydaje się, że plan ma spore szanse powodzenia. Najbardziej pocieszające jest to, że w dziedzinie wirtualizacji znów „się dzieje”. Klienci mogą dzięki temu tylko zyskać.