|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Publicity] A thought piece: Docker and Unikernels
Hi folks, Thanks for sharing this and here are my 2cents. Please bear in mind that my background knowledge may be limited so I'm hoping people will *correct me where I'm wrong*. Apologies if the following is somewhat like a stream of conciousness - I'm writing it in one draft and have very little time today. First, here's my view on these tools: - Mirage is a library operating system and it produces unikernels — i.e. artefacts (VMs) that can be deployed on top of Xen (and Xen is a Type 1 hypervisor). - Docker is containerisation technology, which wraps up a bunch of code into a consistent and easily deployable artefact, that runs on top of a Host OS (Linux). If anything, it is closer to a Type 2 hypervisor. NB: If I'm correct about the above, then comparing a Type 1 hypervisor with a Type 2 hypervisor is already a ridiculous argument to me. They solve different problems for different use-cases at different layers in the stack. I find Docker's site to be somewhat disingenuous in glossing over this [1]. Maybe this is my lack of knowledge, hence my earlier appeal for corrections. Now let's continue. Remember that Mirage is an *entire operating system*. That's already more than Docker does and will *ever* do but let's examine what that means in practise and compare it to how things are today. Attached are two slides extracted from a recent talk I gave but **don't look at them yet!** Let me explain them first and I'll tell you when to look. The first slide attempts to describe a workflow from left (code development) to right (deployment) in terms of the *ecosystem of tools* that are used. The top half of the slide describes what happens when you build on the current technology stack and the number of things you need to (1) give your developers a consistent environment and (2) make sure the things you deploy are consistent. All of these are geared to describing *in code* what you want your system to do or be like. The lower half of the slide describes the unikernel/Mirage workflow, where everything is *already code*. This is at least one order of magnitude simpler than where workflows are currently heading. The deployment story is even better when you account for Xen-on-ARM (which I don't -- yet). The second slide describes the *trade-off* that you must make to achieve the glorious nirvana of the unikernel workflow. Note that I am still iterating on these slides. Now go look at them and then come back (reread the above paragraph if necessary). [pause] Attachment:
unikernel-workflow.pdf That complete slide deck is still in development including that particular slide, which will need a blog post of it's own. I just haven't had time to do the necessary research into the tools or the writing. Now that I've said the above. I can more clearly state my problem with Russ' post as it *currently stands* (esp if it goes on the Xen blog, as it will be considered authoritative). It currently takes only **one vertical slice** through that entire workflow and compares the benefits on both sides. That's an understandable thing to do but the consequence is that the rest of the workflow benefits are disregarded (and possibly forgotten). This is exacerbated when you have to consider the trade-off in order to benefit from 'the unikernel way' (and of course people will think about the trade-off). The real benefit is when you compare the horizontal axis and you realise that the world we're heading towards is ... convoluted. My larger concern is how such a post (if on the Xen blog) ends up inadvertently *positioning* Mirage OS in the wider community. I already have to deal with the 'sounds like Docker' question when I give talks but that's why I have to explain it better. The fact that deployment is convenient is a *side-effect* of the vastly improved workflow. Not the primary feature (recall that we're talking about an operating system here). We haven't really begun the work on how we position Mirage (and the unikernel workflow) for the long term and I'm concerned that focusing only on one side benefit — however wonderful — may lead us down a rabbit hole. If we need a response to the (ridiculous) 'Hypervisors are dead' statements, then talking about unikernels is only **part** of the answer. The larger response should come from understanding *why* people use (and should be using) Docker vs the cases where Xen is most appropriate. For example, one of my friends is CTO at a startup and could really benefit from Docker. He has around 10 developers and they all trust each other (and each other's code). When that team swells to 200 people will he still trust them all the same? Does Google trust their people the same? Or will each team have their own virtualised Host OS on top of which they put their Docker containers? Who knows but I feel topics like trust, isolation and scale are the things to focus on. [1] scroll down on https://www.docker.com/whatisdocker/ Ok, that turned out to be more like 2 dollars than 2 cents but I hope it was mostly coherent. I welcome feedback and corrections (I'll read the linked OSv posts later tonight). Best wishes, Amir On 20 Aug 2014, at 14:12, Russell Pavlicek <russell.pavlicek@xxxxxxxxxx> wrote: > Leandro, > > Is that the sound of you volunteering I hear? > > ;) > > Russ Pavlicek > Xen Project Evangelist, Citrix Systems > Home Office: +1-301-829-5327 > Mobile: +1-240-397-0199 > UK VoIP: +44 1223 852 894 > ________________________________________ > From: Leandro David Cacciagioni [leandro.21.2008@xxxxxxxxx] > Sent: Wednesday, August 20, 2014 9:06 AM > To: Lars Kurth; Tzach Livyatan; Russell Pavlicek > Cc: Libby Clark; George Dunlap; publicity@xxxxxxxxxxxxxxxxxxxx > Subject: Re: [Publicity] A thought piece: Docker and Unikernels > > I think that maybe one killer move could be the creation of a GOLANG > Unikernel!!! > > Cacciagioni, Leandro David > leandro.21.2008@xxxxxxxxx > System Administrator - Development Operations > lcacciagioni.github.io - about.me/cacciald > Cel: +549 341 3673294 > > El 20/08/14 a las 09:33, Lars Kurth escibió: >> I thought about it and it would be ok on our blog. But we are sort of >> preaching to the converted there, so another channel may be better >> Lars >> ________________________________________ >> From: Tzach Livyatan [tzach@xxxxxxxxxxxxxxxxxxxx] >> Sent: 20 August 2014 10:06 >> To: Russell Pavlicek >> Cc: Anil Madhavapeddy; Libby Clark; Lars Kurth; George Dunlap; >> publicity@xxxxxxxxxxxxxxxxxxxx >> Subject: Re: [Publicity] A thought piece: Docker and Unikernels >> >> On Wed, Aug 20, 2014 at 5:42 AM, Russell Pavlicek >> <russell.pavlicek@xxxxxxxxxx<mailto:russell.pavlicek@xxxxxxxxxx>> wrote: >> Revised version. I've added Libby (whom I saw in the lobby earlier) and the >> Publicity list. New title. >> >> Lars has indicated he wants this divorced from the Xen Project blog, since >> it has the potential to irritate some people. I'm fine with that; I >> irritated people on my own for years. ;) >> >> I have a feeling someone in the 11:15 AM slot tomorrow will make this piece >> necessary. >> >> Comments? >> Good post. >> Just wanted to point a related 3 parts post from the OSv blog >> http://osv.io/blog/blog/2014/06/19/containers-hypervisors-part-1/ >> >> >> Russ Pavlicek >> Xen Project Evangelist, Citrix Systems >> Home Office: +1-301-829-5327<tel:%2B1-301-829-5327> >> Mobile: +1-240-397-0199<tel:%2B1-240-397-0199> >> UK VoIP: +44 1223 852 894<tel:%2B44%201223%20852%20894> >> ________________________________ >> From: Anil Madhavapeddy [anil@xxxxxxxxxx<mailto:anil@xxxxxxxxxx>] >> Sent: Tuesday, August 19, 2014 9:55 AM >> To: Russell Pavlicek >> Cc: Lars Kurth; George Dunlap; >> sconway@xxxxxxxxxxxxxxxxxxx<mailto:sconway@xxxxxxxxxxxxxxxxxxx> >> Subject: Re: A thought piece: Docker and Unikernels >> >> I need a cup of tea now... >> >> On 19 Aug 2014, at 08:52, Russell Pavlicek >> <russell.pavlicek@xxxxxxxxxx<mailto:russell.pavlicek@xxxxxxxxxx>> wrote: >> >> Splendid thank you! >> >> And as to the aggressive tone: welcome to America! ;) >> >> Sent from my Android phone using TouchDown >> (www.nitrodesk.com<http://www.nitrodesk.com/>) >> >> -----Original Message----- >> From: Anil Madhavapeddy [anil@xxxxxxxxxx<mailto:anil@xxxxxxxxxx>] >> Received: Tuesday, 19 Aug 2014, 8:37AM >> To: Russell Pavlicek >> [russell.pavlicek@xxxxxxxxxx<mailto:russell.pavlicek@xxxxxxxxxx>] >> CC: Lars Kurth [lars.kurth@xxxxxxxxxx<mailto:lars.kurth@xxxxxxxxxx>]; George >> Dunlap [George.Dunlap@xxxxxxxxxx<mailto:George.Dunlap@xxxxxxxxxx>]; >> sconway@xxxxxxxxxxxxxxxxxxx<mailto:sconway@xxxxxxxxxxxxxxxxxxx> >> [sconway@xxxxxxxxxxxxxxxxxxx<mailto:sconway@xxxxxxxxxxxxxxxxxxx>] >> Subject: Re: A thought piece: Docker and Unikernels >> >> It's an aggressively toned article, but not offensively so. I like it... >> >> A couple of minor tweaks: >> >>> There is no multi-user operating system, no shell scripts, and no massive >>> library of utilities to take up room – or to employ in some nefarious >>> exploit. There is just enough code to make the application run, and >>> precious little for a malefactor to leverage. It's not the “end-all be-all” >>> of security, but it is certainly facing the right direction. >> could have a note on type safety added: >> >> There is no multi-user operating system, no shell scripts, and no massive >> library of utilities to take up room – or to employ in some nefarious >> exploit. There is just enough code to make the application run, and precious >> little for a malefactor to leverage. All the code that is present is >> statically type-safe, from the application stack all the way down to the >> device drivers themselves. It's not the “end-all be-all” of security, but it >> is certainly facing the right direction. >> >>> I fully expect that 5 years from now we will look back at the unikernels of >>> 2014 and see these as the seedlings of what will be a growing forest of >>> unikernel-type systems. Frankly, I can't wait to see what will develop in >>> this space. >> Could note that unikernels and containers may well converge: >> >>> I fully expect that 5 years from now we will look back at the unikernels of >>> 2014 and see these as the seedlings of what will be a growing forest of >>> unikernel-type systems. They can be viewed as the natural evolution of >>> Linux containers - maintaining their packaging and deployment benefits, but >>> adding much more specialization into the mix to reduce resource wastage and >>> external attack surface. >> -a >> >> On 19 Aug 2014, at 07:24, Russell Pavlicek >> <russell.pavlicek@xxxxxxxxxx<mailto:russell.pavlicek@xxxxxxxxxx>> wrote: >> >>> Folks, >>> >>> I woke up this morning with this going through my head. It was pretty much >>> written in one shot (which I never do), so it may take some polishing, but >>> I think the thoughts are all there. >>> >>> I see James Bottomley on the Keynote list for Wednesday morning and I >>> anticipate another round of the "Docker has won" message that James has >>> become famous for. >>> >>> I'd like your feedback. Ideally, I'd like to propose this for >>> Linux.com<http://Linux.com> in order to temper the flawed notion of Docker >>> as the panacea of virtualuzation, hopefully before the media swell around >>> his prognostications dies down. >>> >>> What do you think? >>> >>> Russ Pavlicek >>> Xen Project Evangelist, Citrix Systems >>> Home Office: +1-301-829-5327<tel:%2B1-301-829-5327> >>> Mobile: +1-240-397-0199<tel:%2B1-240-397-0199> >>> UK VoIP: +44 1223 852 894<tel:%2B44%201223%20852%20894> >>> <Docker has not won the war-the battle is just beginning.odt><Docker has >>> not won the war-the battle is just beginning.pdf> >> >> _______________________________________________ >> Publicity mailing list >> Publicity@xxxxxxxxxxxxxxxxxxxx<mailto:Publicity@xxxxxxxxxxxxxxxxxxxx> >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity >> >> >> >> _______________________________________________ >> Publicity mailing list >> Publicity@xxxxxxxxxxxxxxxxxxxx >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > _______________________________________________ > Publicity mailing list > Publicity@xxxxxxxxxxxxxxxxxxxx > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |