Gdzieś w ostatnio usłyszałem, że serverless is so 2016 a teraz to jest unikernel ;) Nigdy o tym wcześniej nie słyszałem, więc zacząłem badać sprawę. Na “rozum” ja to zrozumiałem, że mamy z unifikowany kernel – to znaczy, że nie interesuje nas hardware i dystrybucja, kod będzie działał wszędzie. Byłem w błędzie :) dużym? Trochę.

Po pierwsze unikernel to nic nowego, znów jak serverless, jak unit testing czy jak już wiemy wiedza o tym, że zespół musi się dogadywać by był wydajny…. Podobnie zresztą jak MVC itp. Ale nurt w IT jest taki: coś wymyślono dawno temu – eee do d z tym, nie mamy takich problemów by z tego korzystać. 20-30 lat później: JaAAAAAAa to idealnie rozwiązuje mój problem! Unikernel nie jest taki stary, bo chyba pierwsze raz został on wykorzystany w latach 90 no a potem się zaczęło i miejsc w których jest wykorzystywany jest dużo więcej.

Bardzo krótko można powiedzieć, że unikernel to aplikacja skompilowana do i zintegrowana na poziomie systemu operacyjnego który może zostać uruchomiony zarówno jako stand alone, na VM jak i w chmurze – taki specjalny build windows z jedną aplikacją. Rozwiązanie to przeważnie ma rozmiar 4% tego co by naturalnie nasze rozwiązanie potrzebowało. Unikernel jest możliwy dzięki dwóm technologiom: SASOS (single address space operating system), czyli system który działa na jednej globalnej wirtualnej przestrzeni adresowej (VAS) (to znaczy, że wszystkie procesy systemu operacyjnego mogą działać jedynie w tym obszarze) oraz Library Operating System, czyli system operacyjny który można budować jak z klocków dokładając lub odejmując odpowiednie biblioteki – tak jak teraz wyglądają aplikację node (npm, yarn) czy .NET (nuget).

Dokładnie mówiąc, unikernel to jest obraz SASOS stworzony z odpowiednim doborem bibliotek (Library Operating System) które są wymagane do tego by działała nasza aplikacja. Tak skompilowaną aplikację/obraz możemy potem wykorzystywać jak chcemy.

Czyli zamiast ładowania pełnego systemu, by na tym postawić kontener zawierający naszą aplikację czy też ładowania całego systemu by odpalić z miejsca skrypt uruchamiający nasza aplikację (tak by nie było “dostępu” do OS), możemy zastąpić systemem który ma tylko i wyłącznie naszą aplikację. Nie potrzebuje narzutu pełnego systemu operacyjnego czy też nawet wirtualizacji by działać. Jest małe, przenośne i wydaje się, że idealnie pasuje do chmury.

Jednym z przykładów na bazie którego możemy stworzyć unikernel jest runtime.js – Library Operating System w JavaScript ;) Tak, tak…. OS i JS :) Innym przykładem jest Mirage OS czy też LING – unikernel bazujący na Erlang/OTP! :) a że wspomniałem o Erlang to wypada też o Go ;) Clive to unikernel napisany w GO :) Jest też i projekt Microsoftowy – Drawbridge.

Ogólnie temat ciekawy, warto o nim wiedzieć. Ale czy opłaca się z niego korzystać? To już pozostawiam wam – możliwe, że macie IDEALNE zapotrzebowanie na coś takiego?

PS.: w 2016 roku w Technology Radar, unikernel był wymieniony jako Assesscoś o czym warto zobaczyć pod kątem tego jak to może wpłynąć na nasz biznes.

PPS. Od rozpoczęcia do skończenia pisania (temat zacząłem tak rozpoznawać w sierpniu) powstała nowa strona która fajnie wszystko linkuje :)

2 KOMENTARZE

Comments are closed.