 Oké, goed, afteroemd, FOSDEM. Mijn naam is Martin Hoogendorn. Ik werk voor Containers Solutions in Amsterdam. En ik zou willen praten voor een paar minuten om je bedrijven in de bedrijven in de oude ploeg te manageen. En om je bedrijven te manageen, ik ga niet alleen over je bedrijven.txt, bijvoorbeeld voor je Python project, maar ook dingen zoals de lid-xml, die je normaal krijgt van je opende systeem, en linken in je Python interpreter, of zelfs uitgeleid naar KRAFIS. En zo, dit is niet geleden, het was gedaan door jouw assist-admin, door gewoon het app get instelling, alles tot het soms werkt. Dat is niet heel goed gesteld bij een assist-admin, een programma, en een server. Dus configuratie management was inventeerd om dat te zorgen. In essence, configuratie management is instelling packages, removable packages, en write files. Er zijn natuurlijk 2 problemen met deze. De eerste is dat updates niet automatisch zijn, en je kunt geen stappen doen. Deze 2 problemen maken configuratie-drifting overigend, en ze zijn vervolgd met werkbedrijven, maar het is niet inerend voor de model, en het is te hard om het juist te krijgen. In de laatste paar jaar hebben we gezien dat layer-based-systemen populair zijn, en dat is vooral voor het docker. En het probleemt om deze configuratie-problemen te proberen. Het boelt op dat je verschillende layers hebt dat je kunt builden, dat is immuutabel en kan op de top zijn om ze te composeren. Er is ook een probleem. Als je bijvoorbeeld 2 programmen installeert, programma A en B, en dan update A, dan zou je nog steeds veel meer. Het andere ding is dat mensen het gebruiken voor build-backs, zodat ze eigenlijk je compiler in een stappen gaan, en dan builden je programma en publiek je image, including je compiler, om te publisheren op je productie en environment. Je kunt deze in verschillende manieren, maar het is niet weer inerend voor de model. Dus ik zou willen een shortbreak doen en zien wat we gaan doen, de configuratie-management dat gaat in lineaire, dan de docker-image gaat in een 3-shape en de volgende logische ding te kijken is natuurlijk graphs. En graphs is iets anders, daar je eigenlijk specifie wat je wilt declaratief hebben. Dus ik wil een square en een try-and-gold, maar het betekent niet waarom ik ga declaratief in mijn container. Je pushed de composing van wat in je container tot de laatste moment eigenlijk. Dus hoe zou het in praktijk zijn? Ik heb een state met both vim en mijn applicatie, dat is de blue circle op de leftop en dan gaan we een details look naar mijn applicatie. Er zijn twee types van dependies, de dotted line denoert een build-dependentie en de rest zijn dependies. Dus we hebben de graphis, de lipp-xml zoals we hadden in het origineel examen en dan mijn applicatie in dit geval gebouwd met rust. Het heeft source en creëren en build-instructies. Dus we kunnen schip gewoon de runtime systeem tot je container en tot je productie environment by default, want we maken de distingtie tussen de twee types van dependies. Conversly, we hebben ook een heel mooie adviezen dat we precies weten dat we de precies build environment hebben en je kunt een runtime systeem maken voor deze during-development zodat je de dependies during-development hebt als during-build. Dus tot het einde. Player's appear to compose pretty well, but actually they don't. Graphs do compose really nicely. The one that I'm most familiar with is NixOS. Check out NixOS on free-node. The other one is Habitat by Chef and I actually then discovered a build system by Google yesterday called Bazel, which is implementing exactly the same model, actually. So thank you very much for your time. Yes, that's all actually what I wanted to say. So thank you very much.