I've been watching Joyent with interest for a while now, but I don't think I or my employer will be using their public cloud any time soon. Frankly, the pricing standard set by DigitalOcean a couple of years ago, and since followed by Linode (my and my employer's current favorite) and Vultr, is pretty hard to beat. I don't know how I'd justify 2x the price (not even counting bandwidth) when the performance of Linode is good enough. So I'll just continue to watch with interest. Now that SmartDataCenter is open source, maybe someone else will set up an SDC cloud with pricing that's competitive with DigitalOcean and the like. That would suck for Joyent though, so I shouldn't really wish for it.
there are about 60 mentions of the word "container" on that page, including a full chart of questions "Compared to Docker in a VM", such as "Where are containers run"?
But the real question that should be at the top of the file, or at least that table of questions, is "what is a container"?
The term "Virtual Machine" has a variety of meanings, depending on who you talk to - Kernels are using LLVMs, Java runs inside a VM, and hypervisors create sandboxed full-OS VMs. The full-OS VM requires/provides its own binaries, frameworks, and DLLs; not having to depend on the Host to provide these.
A Container is like a Hypervisor, but instead of hosting a full-OS VM, the Container holds a Docker, which is just the code and data. Containers are similar to Application Pools or SQL Instances, and there are "Container Databases" which are much more self-contained than the traditional database. Containers depend on the Container OS for binary files, frameworks, and DLLs.
I like to look at it as a spectrum: Bare metal - Virtual Machine - Container
At one end, you're both running the binaries and scheduling threads. In the middle you're running binaries but not scheduling threads. On the other end, you're depending on the Host to do both.
Yes, the QEMU process that underpins the hardware virtual machine lives within a container on the host. It means that a vulnerability in QEMU that allows for guest escape will land you in an otherwise empty container, rather than out on the host where other tenants are accessible.
But Triton is first and foremost about _container-based_ virtualisation: which involves no HVM at all!
Surprising that Joyent used an extremely similar name as Amazon's extremely similar product, EC2 Container Service (EC2 expands to Elastic Compute Cloud, so the full name is Elastic Compute Cloud Container Service)
The name is very similar but the products are not so similar -- ECS simply schedules Docker containers across the virtual machines you already have running on AWS. Triton schedules and runs containers on bare metal. Virtualization of course has performance and I/O overhead.
SmartOS runs just fine on AMD CPUs. KVM support for AMD hasn't been merged to illumos-kvm yet (mostly just due to time), but you can do your own builds with it (https://github.com/jclulow/illumos-kvm/).
But Triton containers don't run in KVM anyway. They run natively on the OS with no VM. So you can download and run Triton on AMD today, just as you can with Intel CPUs.
[+] [-] johannesboyne|10 years ago|reply
[+] [-] mwcampbell|10 years ago|reply
[+] [-] logicallee|10 years ago|reply
But the real question that should be at the top of the file, or at least that table of questions, is "what is a container"?
So: what is a container? (As opposed to a VM.)
[+] [-] stephengillie|10 years ago|reply
A Container is like a Hypervisor, but instead of hosting a full-OS VM, the Container holds a Docker, which is just the code and data. Containers are similar to Application Pools or SQL Instances, and there are "Container Databases" which are much more self-contained than the traditional database. Containers depend on the Container OS for binary files, frameworks, and DLLs.
I like to look at it as a spectrum: Bare metal - Virtual Machine - Container
At one end, you're both running the binaries and scheduling threads. In the middle you're running binaries but not scheduling threads. On the other end, you're depending on the Host to do both.
[+] [-] dmpk2k|10 years ago|reply
[+] [-] gtirloni|10 years ago|reply
Can't we just describe VMs as VMs and be done with it? So it's a container that has a VM inside it?
[+] [-] jclulow|10 years ago|reply
But Triton is first and foremost about _container-based_ virtualisation: which involves no HVM at all!
[+] [-] bcantrill|10 years ago|reply
[1] http://www.slideshare.net/bcantrill/illumos-lx
[2] https://www.joyent.com/blog/triton-docker-and-the-best-of-al...
Edit: I think I misunderstood the question -- apologies!
[+] [-] robbiet480|10 years ago|reply
http://aws.amazon.com/ecs/
[+] [-] omarforgotpwd|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] kstenerud|10 years ago|reply
[+] [-] bahamat|10 years ago|reply
But Triton containers don't run in KVM anyway. They run natively on the OS with no VM. So you can download and run Triton on AMD today, just as you can with Intel CPUs.