W niedzielne popołudnie siedziałem oglądając jakiś serial na telewizorze rownocześnie pisząc posta na temat tworzenia Mikroserwisów za pomocą takich narzędzi jak Docker i Node.js. Będąc blisko ukończenia spostrzegłem, że nie publikowałem nic o tym czym jest Docker... ba, nawet o samej wirtualizacji nie wspomniałem słowem... Shame on me...
Zanim wykorzystasz narzędzie, musisz poznać jaki problem ma ono za zadanie rozwiązać.
Jako świeżo upieczony dotnet-owiec, jakiś czas temu, obejrzałem prezentację "8 Lines of Code". Wygłosił ją przez Greg Young podczas QCon London 2013. Polecam ją każdemu adeptowi sztuki programowania, nieżalenie od języka czy "skill"-a. Podczas swojego wystąpienia Greg poruszył bardzo ważny temat: odpowiedzialności za wszystkie zależności, które ładujemy do projektu. Cokolwiek nie załadujemy do naszego systemu to na nas spada obowiązek zapewnienia stabilności rozwiązania na produkcji.
Po kilku minutach refleksji nad swoim postem o Node.js i Docker-ze postanowiłem nieco przybliżyć Wam samą idę wirutalizacji, jak i pokrótce omówić wady i zalety rozwiązań technologicznych z nią zwiazanych.
Najpierw był serwer
Wszystko zaczęło się od architektury, gdzie jedna fizyczna maszyna była przyporządkowana pojedynczej aplikacji.
Niestety wraz z rozwojem aplikacji internetowych zaczęły pojawiać się problemy związane z taką wersją architektury, jak np.:
- Spore koszty utrzymania
- Powolny deploy aplikacji
- Ciężka migracja
Problemy tego typu zmusiły inżynierów do szukania rozwiązań optymalnych dla bardziej skomplikowanych aplikacji.
Wirtualne maszyny są całkiem fajne
W ten oto sposób pojawiła się architektura oparta na Hipernadzorcy(en. Hypervisor), narzędziu niezbędnemu do prowadzenia procesu wirtualizacji.
Możemy wydzielić dwa typy hipernadzorców:
- Natywny (Bare metal) - Operujący czysto na sprzęcie, mający nad nim pełną kontrolę i monitorujący uruchomione systemy operacyjne. Działają na wyższych poziomach niż hipernadzorca.
- Hostowany - Działa jak program uruchomiony na danym systemie operacyjnym (hoście). Są to rodzaje emulatorów. Zwirtualizowane systemy działają dwa poziomy ponad sprzętem.
Podstawowymi plusami tego rozwiązania są:
- Mniejsze koszty
- Łatwiejsza skalowalność
Jednak i te rozwiązanie nie obeszło się bez problemów z:
- Duplikacja zasobów kerneli
- Portowaniem aplikacji
Kontenery wychodzą przed szereg
Po Hipernadzorcy przyszła kolej na obecne cudowne dziecko... Kontenery!
Główne powody popularności metody:
- Rozmiar - bez potrzeby przechowywania kerneli, kontenery straciły bardzo dużo zbędnych danych.
- Izolacja środowiska - ułatwia to działanie w czasach popularności mikroserwisów, gdzie system składa się ze skończonej liczby małych aplikacji od siebie niezależnych. Jest to ważne, gdy aplikacje są napisane z wykorzystaniem różnych technologii. Dzięki kontenerom możemy to osiągnąć w dość prosty sposób. Wystarczy "pozamykać" te małe aplikację w kontenery (przykład: kontener A będzie zawierać aplikację A napisaną w JAVA, JRE 8 a kontener B będzie zawierać aplikację B napisaną w JavaScript na Node 6.9.4).
- Zmniejszone koszty
- Szybka możliwość deploy-u
- Gwarantowana portowalność aplikacji
Podsumowanie
W taki sposób przedstawia się krótka historia rozwiązań serwerowych. Mam nadzieje że miło się wam czytało tego post-a! W najbliższej przyszłości opublikuję tekst o początkach tworzenia mikroserwisu w Node.js i Docker.