This is an introduction to unikernels and their impact on architecture and IT organizations (in French, I'll translate it in short terms). I produced this talk for the first Paris Unikernels Meetup.

1. INTRODUCTION
UNIKERNELS
Adrien Blind [@adrienblind]
21 sept. 2016

2. Une histoire d’argent et de partage
• Historiquement, on bâtissait de
gros systèmes coûteux que l’on
mutualisait: il a alors fallu créer
des systèmes multi-utilisateurs,
leur permettre de répondre aux
différents besoins
• L’avènement de la micro-
informatique à ensuite contraint à
créer des OS de plus en plus
universels (fonctionnant sur une
large palette de matériel,
s’adaptant à des besoins de plus
en plus variés, etc.)
• Cela à progressivement conduit à
rendre les systèmes obèses

3. Principales caractéristiques
• Images systèmes construites pour un objectif précis
• Compilées sur la base de modules sélectionnés d’un OS
bibliothèque et de l’application elle-même : elles ne contiennent
que le strict nécessaire au fonctionnement de celles-ci.
• Opérées sur un hyperviseur ou directement sur du hardware
• Espace mémoire partagé

4. Différence avec les VMs et les conteneurs

5. Plusieurs orientations différentes
• Pas de silver bullet, une offre plurielle pour adresser des
besoins différents : 10+ projets à ce jour !
• ClickOS est orienté performance
• Clive est conçu pour le calcul et l’informatique distribuée
• Drawbridge est un proto. pour envisager le sandboxing des
applications
• Runtime.js fait fonctionner une machine virtuelle javascript
• ... Et bien d’autres : Graphene, HaLVM, IncludeOS, Ling,
MirageOS, Osv, Rumprun, UniK...
• Deux axes principaux
Généralistes
Bas niveau
(ex. Rumprun)
Spécialistes
Haut niveau
(ex. Runtime.JS)
VS

6. Avantages
• Démarrage très rapide (jusqu’à quelques
millisecondes)
• Surface d’attaque très retreinte
• Taille des images limitées au strict minimum
(Quelques Mo seulement)
• Optimisation full-stack du fait de leur
spécialisation

7. Les unikernels répondent aux enjeux d’ajd.
• Leur granularité fine les inscrit parfaitement dans
une logique d’architectures en microservices
• Ils portent des vertues DevOps tel que :
• Une approche full-stack fusionnant le cycle de vie de l’appli
et de l’infra sous-jacente: gains qualitifs, plus de degrés de
liberté et d’autonomie pour l’équipe portant l’app.
• L’immuabilité: on ne modifie pas une image, on en
reconstruit une nouvelle
• Dans une approche Continuous Delivery, l’image
d’un système unikernel devient donc un artefact
applicatif autosuffisant produit de façon
automatique

8. L’automatisation, vertue cardinale
• Parallèle avec les conteneurs : les vertus citées
précédemment ont fortement contribué au succès des
conteneurs il y a quelques années
• Docker n’a pas invité les technologies sous-jacentes aux
conteneurs: ils ont créé le concept les définissant et
surtout inventé l’outil permettant de les manipuler
• Peut-on appliquer les paradigmes de Docker à un autre
artefact que le conteneur?
• Docker l’a déjà démontré pour piloter de véritables images unikernel
• ... Et Docker a acquis Unikernel Systems en 2015

9. Un tsunami d’unikernels ?
• Les paradigmes des unikernels les rendent
particulièrement séduisant pour certains
cas d’usage  microservices mais aussi
l’IoT par ex.
• Mais moins intéressant pour d’autres :
progiciels/systèmes complexes faiblement
automatisables, difficiles à configurer, dont
le cycle de vie est long (ex. DB)...

10. Impact sur les hommes et les orgas
• Des équipes infra encore un peu plus
dépossédées de leur pré-carré, et une charge de
travail régressant
• Des équipes applicatives qui requièrent plus que
jamais de compétences d’infrastructure puisqu’on
fusionne progressivement le cycle de vie de
l’app. et de l’infra dans un artefact full-stack
 Un déplacement du barycentre... une histoire
DevOps en fait

11. Le PaaS a t’il fait long feu?
• En se déplaçant du IaaS vers le PaaS, on a tenté d’abstraire l’infra et la plomberie
aux équipes applicatives traditionnelles pour qu’elles se concentrent sur leur
valeur ajoutée, mais cela au prix de contraintes paradoxalement grandissantes
sur les applications (patterns d’archi limités, frein à l’innovation...). Cette approche
tend également à alimenter le fantasme du No-Ops
• En redescendant vers le CaaS porté par les conteneurs et maintenant en
redescendant vers les unikernels, on a rétrocédé de l’autonomie et de la liberté
aux équipes projets, mais engendré en contrepartie un besoin de renforcer leurs
compétences Ops  une orientation DevOps
• Le renouveau du IaaS? Dans tous les cas les unikernels n’obèrent pas le shift
vers le cloud  les images fonctionnent sur les principales solutions publiques et
on-premises ; l’enjeu porte plus que jamais sur la capacité de ces solutions à être
pilotables de façon automatique et programmatique
• Les unikernels ne sont pas des réponses à tout, plus que jamais l’enjeu porte
sur une capacité d’orchestration composite permettant de bâtir des
applications faites de composants variés (services PaaS, conteneurs, unikernels,
etc...)

12. Et vous, qu’en pensez vous ?