[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Publicity] Seems the VM vs container debate is heating up



I like Stefano's point about Xen building bridges here -- seems like a new twist on the VM vs. container debate. The fact that Xen is evolving with the times and it's not a binary choice might play reasonably well.  

Are there are any major technical differences between the miniOS approach and containers? 

Thanks,


On Tue, Apr 8, 2014 at 1:13 PM, Lars Kurth <lars.kurth@xxxxxxx> wrote:
I think it's a great post
Lars


On 08/04/2014 14:54, Russ Pavlicek wrote:
I've got the following blog post queued for open.citrix.com later
today (it was my turn and this topic seemed timely).

I am leaving for the airport in a couple hours, so if anyone has
concerns, please let me know in the next hour or so if you can.
Otherwise, I may have to edit after it is autopublished later tonight.

It isn't a Xen Project piece per se, but I wanted to highlight the
MirageOS/OSv/etc. solution to highly dense VM app farms.

---

Are Containers the Right Answer to the Wrong Question?

Next-Gen, High Density App Servers Don't Require Scrapping Your Hypervisor

Recently, I sat in a conference session extolling the seemingly
endless virtues of Linux Containers.  I heard claims that hypervisors
were old hat: ancient bloated engines which rely on inefficient
replication of a large operating system stack in order to serve up
applications.  The speaker painted a picture of a future where
hundreds of applications are virtualized on each piece of hardware.
"What is really needed," glowed the speaker, "is a lightweight,
efficient means of serving up application: containers."

Containers are cool, but not a panacea

Containers share the same kernel as the host, so they are not burdened
with the extra memory and CPU cycles it costs to replicate a full
operating system stack in a hypervisor scenario.  Compared to
hypervisor-generated virtual machines, containers can be fast and
lean.  But they are also limited.

Since Linux containers share the same kernel as the host, it is
impossible to run Windows.  Or FreeBSD. Or NetBSD.   Or another
version of the Linux kernel.  Or another Linux distribution which
requires a different kernel.  All of those scenarios are best handled
by a real hypervisor.  And the security aspect of hypervisors is huge,
worthy of a separate blog entry of its own.  Still, if you need an
environment within your organization where many workloads can leverage
a single kernel environment, containers can be a viable solution.

However, some of the most vocal container advocates insist that these
problems relating to containers are really application problems in
disguise.  Issues about kernel support and security are the results of
improper application design, they claim.  When we raise the bar on
applications so that they are based solely on access to application
servers, then the objections to containers will melt away -- and so
will hypervisors, for the most part.  Or that's what some of these
advocates claim, at least.

The death of the hypervisor is greatly exaggerated

But is there another scenario which could answer the call for highly
responsive and lightweight virtual instances which does not use the
container solution?  Maybe one that can actually leverage the
flexibility and security which is part and parcel with most
hypervisors?

Yes, in fact, there is.  And the key is in the very
application-centric future which some container advocates believe will
cause the hypervisor to become obsolete.

Behold the birth of the Cloud Operating System

Instead of deriding hypervisors for the "bloat" of replicating a full
operating system, we can replicate ultra-light application-centric
operating systems which are meant to live in a VM.  A number of these
lean, mean virtual operating systems have arisen recently, including
the Xen Project team's MirageOS and Cloudius Systems' OSv.  These
lightweight operating systems, sometimes called "cloud operating
systems", lack the expensive drivers needed to talk to hardware --
because they aren't meant to run on hardware.  And they lack
multiprocess capabilities because they are not intended to be general
timesharing systems, but dedicated application server systems.  As a
result, they are very small, very lightweight, and can start up
amazingly quickly in a VM environment.  They enable the vision of
light and fast application servers, while preserving the superior
security and flexibility of true hypervisors.

Don't throw the hypervisor baby out with the dirty application bath water

So if you are intrigued by the vision of masses of small, efficient
application VMs packed into a minimum of number of servers, but
cringing at the notion of totally retooling your virtualization
infrastructure and rethinking your entire security mindset, don't
fret.  That vision is achievable while maintaining the flexibility and
security that mature hypervisors deliver.  Focus on a streamlined
application stack, and the vision of dense, efficient application VMs
is achievable -- regardless of whether you are using hypervisors,
containers, or both.


On Tue, Apr 8, 2014 at 9:42 AM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxcom> wrote:
Also this tells us that whatever tecnology we choose to have upstream
QEMU stubdoms, we should make sure it is easy to use for other POSIX
applications too, so that we can advertise it as a generic solution for
Xen micro-VMs and position it as a secure alternative to containers.

On Tue, 8 Apr 2014, Stefano Stabellini wrote:
Given that most people only use one VM for one task, the rise of
"micro-VMs" makes sense, whether they are based on OSv (miniOS or rump
kernels) on traditional hypervisors or on Docker, ZeroVM or other types
of containers.

However what these articles don't take into account is that Xen can
already handle both kind of workloads extremely well: Xen can handle fat
old-style VMs, with HVM guests, and new style lightweight micro-VMs,
with miniOS (or rump kernels or OSv) inside a PV guest.

If I manage to carve the time to do it I might be able to write a blog
post about it.

On Tue, 8 Apr 2014, Lars Kurth wrote:
See:

* http://blogs.bromium.com/2014/04/07/vms-the-new-infrastructure-anachronism/
* On the other hand there is this article:
http://www.zdnet.com/hypervisors-are-the-pillars-of-the-cloud-not-the-achilles-heel-7000027931/
(both by Simon Crosby)

Generally for the security discussion, which is related, the following
articles may be relevant:
*
http://www.zdnet.com/hypervisors-the-clouds-potential-security-achilles-heel-7000027846/
* http://www.economist.com/blogs/babbage/2014/03/computer-security
The following two may also be useful (and contain quite a few useful links)
despite also being partly a product pitch:
*
http://blogs.bromium.com/2013/03/27/micro-virtualization-for-the-security-architect/
*
http://blogs.bromium.com/2013/04/24/micro-virtualization-for-the-security-architect-2-of-2-isolation-%E2%89%A0-protection/

Lars

_______________________________________________
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
_______________________________________________
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



--
Sarah Conway
PR Manager
The Linux Foundation
sconway@xxxxxxxxxxxxxxxxxxx
(978) 578-5300  Cell
Skype:  sarah.k.conway
_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.