Trenden med mjukvara i separata userspaces, så kallade containrar, har knappt börjat ersätta traditionell virtualisering förrän nästa trend kan urskiljas. Det handlar om mjukvara med inbyggda kärnor.
Precis som tekniken utvecklas allt snabbare, så förändras verktygen för att utveckla för den. De utvecklare som vill ligga i framkant måste hålla ett öga på nyheterna nästan dagligen. Det handlar om bland annat programmeringsspråk, bibliotek, utvecklingsverktyg, databassystem och metodik. Till detta kommer sedan hela maskineriet för att hålla igång systemen, där ”devops”-rörelsen har ökat takten.
Virtualisering började ta form under 60-talet när hypervisorn gjorde sitt intåg i IBM:s stordatorsystem. Fram till dess var parallella användarapplikationer så mycket virtualisering systemen klarade. Det var hypervisorn som gjorde det möjligt att köra flera operativsystem sida vid sida.
Fram till slutet av 70-talet fortsatte IBM att satsa på virtualisering, men efter en rad interna strider förlorade tekniken till förmån för traditionell batch-processering. Som teknik och koncept låg virtualisering sedan och slumrade fram till tidigt 2000-tal. De stora aktörerna sålde virtualiserad hårdvara men till en kostnad i mångmiljonklassen. Dessutom med en komplicerad mjukvaruteknik som kompenserade för avsaknaden av virtualiseringsstöd bland dåtidens processorer.
Först 2005-2006 började det plötsligt hända saker, när både Intel och AMD introducerade stöd för virtualisering direkt i sina processorer. Till en början erbjöd detta knappt någon kännbar prestandaökning, men i senare generationer förbättrades det successivt. Detta blev startskottet för en explosionsartad återkomst. Hårdvaran hade dessutom blivit så pass kraftfull att virtualiseringen kunde flytta utanför stordatorn och ända in i persondatorn. Förutom större organisationers jakt på kostnadsbesparingar och hantering av större serverparker ger virtualisering också bättre säkerhet genom isolerade körmiljöer.
Hur går virtualisering då egentligen till?
Virtualisering i olika former
Virtualisering kan ske via antingen mjuk- eller hårdvara. Det som kallas för mjukvaruaccelererad virtualisering känner nog de flesta igen i form av emulatorer, exempelvis för retrospel eller mobilplattformar.
Denna form av virtualisering går ut på att emulera ett system, från hårdvara via processorinstruktioner ner till BIOS eller annan firmware. Den främsta fördelen med denna variant är att den inte kräver någon direkt koppling mellan värd- och gästsystemet. Prestandan blir dock lidande genom detta omvandlingssteg.
Hårdvaruacccelererad virtualisering erbjuder betydligt högre prestanda, då gästsystemet kan köras direkt på hårdvaran med ingen eller minimal hjälp av värdsystemet. Nackdelen är att både värden och gästen måste använda samma plattform. Dessutom måste den underliggande hårdvaran ha stöd för detta, till exempel med Intel VT eller AMD-V.
För att värdmaskinen ska kunna köra ett eller flera gästsystem måste den ha en hypervisor. Det är denna som presenterar en virtuell plattform för de olika gästsystemen. Numera finns en handfull populära alternativ, beroende på behov och plattform. Fast trots många lösningar med öppen källkod så står sig VMware ESXI starkt, kanske lika mycket på grund av gamla vanor som de utmärkta verktygen runt omkring.
Xen och KVM är två likartade hypervisors som båda är en del av Linuxkärnan. Den förstnämnda har i princip alltid varit en del av Linuxkärnan, medan KVM har sina rötter i en kommersiell produkt som sedan köptes av Red Hat. Det finns alltså två delar av Linuxkärnan som i stort sett gör samma sak, ett hett debattämne i Linuxkretsar.
Hyper-V är Microsofts hypervisor. Den gick tidigare under namnet Virtual PC. Den kan köras på x86-system med Windows som värdsystem. När det gäller gästsystem stöds Windows, Linux och FreeBSD.
Lite mer bekant för privatpersoner och hemanvändare är förmodligen Virtualbox. Detta är en öppen mjukvara från Sun som numera ägs av Oracle. Lösningen gör det riktigt enkelt att provköra framför allt Linux inuti Windows och Mac, men mjukvaran har även gjort succé bland utvecklare tillsammans med Vagrant.
Men även om klassisk virtualisering gör det möjligt att köra flera system på en och samma hårdvara, så utnyttjas inte hårdvaran på bästa möjliga sätt. Det blir framför allt tydligt i en arkitektur med mikrotjänster, där varje liten tjänst fortfarande måste ha ett helt eget operativsystem. Hur vore det om tjänster istället kunde dela resurser men fortfarande hållas isolerade?
Trenden med isolering
Detta med att använda så kallade containrar i mjukvarusystem har exploderat de senaste åren. Skillnaden mot tidigare virtualisering är att flera mjukvaror kan köras på samma kärna men isolerade i olika så kallade userspaces. LXC, Linux Containers, är virtualiseringsmetoden som gör detta möjligt.
LXC utnyttjar Linuxkärnans funktioner för att begränsa och prioritera användningen av systemresurser samt stödet för olika userspaces. På så sätt kan applikationers gränssnitt mot övriga operativsystemet isoleras fullständigt utan att någon virtuell maskin behöver användas. En applikation ser då inga andra processer, nätverksenheter, användarkonton eller filsystem än den har tillåtelse till.
Med åren har flera verktyg byggts ovan på LXC. Några exempel är LXD, Docker och Rocket. För att bringa ordning i floran av olika containerformat bildades förra året Open Container Initiative, dit Docker donerade sin specifikation.
En ny spelare på planen är Microsoft, från och med Windows Server 2016. I den senaste versionen av operativsystemet finns stöd för containrar. När det gäller Server 2016 kan Hyper-V dessutom lyftas in för att skapa en nästlad container-struktur, i de fall du vill köra containrar på en helt egen kärna.
Containrar som kör en egen kärna är också nästa trend. För ibland har det sina fördelar, både sett till säkerhet och prestanda. Så varför inte bygga in kärnan direkt i applikationen?
Kärnan flyttar in
En grundläggande säkerhetsmekanism i alla vanliga operativsystem är att applikationer inte kan läsa och manipulera andra applikationers del av primärminnet. Det skyddet är dock behäftat med en viss ”overhead”, och när det gäller en servermiljö (där applikationer ändå ofta hålls isolerade) börjar en gammal idé se ut att ha potential, nämligen ”unikernels”.
En vanlig kärna är den i alla operativsystem, den första mjukvaran som körs vid start. Den startar och hanterar sedan alla andra processer så att ordning upprätthålls. När det gäller trenden med isolerade serverapplikationer börjar allt fler prata om att ge varje applikation en egen kärna, en slags hybridisering av traditionell virtualisering och containrar.
Tanken är att en applikation ska paketeras med endast de systembibliotek som krävs samt en kärna med endast en adressrymd. På så sätt blir systemavbilden bara en bråkdel så stor som en traditionell systemavbild och kan även starta blixtsnabbt. Säkerheten förbättras också, då systemet är mindre och helt enkelt har färre attackvektorer. Likaså ger det kompakta formatet bättre prestanda, då varje system kan specialiseras och optimeras.
Nu är ”unikernels” inte något nytt påfund, utan har funnits i olika former sedan 1990-talet. Det försvann bara från radarn under ett antal år för att nu åter bli populärt.
Start vid anrop
De ”unikernels” som finns ute i det fria har visat sig starta på under 20 millisekunder med vanlig serverhårdvara. En applikation förpackad med ”unikernel” kan alltså starta i samband med att ett HTTP-anrop inkommer till servern. Det innebär dels att stora delar av serverparken skulle kunna gå på lågvarv och spara energi, dels ger det helt ny energi till trenden att betala bara för det du använder.
Drift av applikationer i molnet visar tydligt att trenden finns. Några exempel på tjänster är Amazon Web Services Lambda, Google App Engines Cloud Function och Azure Function. Dessa spinner upp i varv och kör kod endast när de anropas. Precis som ”unikernels”.
Det finns en uppsjö med ”unikernels” för olika språk och plattformar. För att göra det enklare att komma igång har bland annat EMC sponsrat projektet Unik.
Med det verktyget kan du enkelt ta applikationer skrivna i C/C++, Java, Go, Node och Python och förvandla dem till ”unikernels”. Tanken med Unik är att snabbt kunna testa och analysera om ”unikernels” ger högre prestanda för en given applikation.
Även Docker är med på banan. Tidigare i år gjordes ett förvärv av företaget Unikernel Systems och förhoppningen är integration direkt i Dockers egna verktyg.
Nu använder Unik också Docker-avbilder för sitt byggsystem, men i skrivande stund har ”unikernels” inte gjort något intåg hos Docker.