gnepzhao

Well, the container here refers to HyperContainer or virtualized container. "run container in VM" is even more misleading, don't you think?

No, very similar conceptually, but totally different implementations.

Thanks. I remember a blog post that coined a term "virtualized container", but cannot find the link right now.

I wouldn't use the word VM, as it reminds us of the heavy full-blown images. It is probably more misleading to say that HyperContainer launches your Docker image in VMs. But you are right, it is still new and requires efforts to get people understand.

I fully respect Joyent guys. My message isn't exactly right. The only (probably trivial) difference I can see is that with hypervisor you can BYOK.

1) Hyper_ offers EBS-like volume and snapshot for your container. You can failover volumes cross containers 2) Given the instance startup time, you can program the APIs to do the scaling/HA, etc. 3) Yes, think Hyper_ as a virtual container host with unlimited capacity, but under the hood, it is still a cluster of machines.

Cool, will check it out. Thx!

Depend on how one define OS. If kernel=OS, then yes, it is stripped down one. But HyperContainer is different from container OS, like coreos, that it is just a kernel, no rootfs.

Yes, somewhat close. The difference here is that Hyper_ follows the native Docker interface. So working with it is the same as on your laptop.

Cheers!

Hi,cofounder of Hyper_ here.

1) AFAIK, this is the first secure container cloud. 2) You can play with it, but better wait till out of beta 3) We are funded :)

Basically it uses a hypervisor to launch your docker image, but not a full blown VM, since there is no guest OS, like ubuntu or coreos in the VM. There is only one tiny kernel in the HyperContainer to run your Docker app.

Yes, it gives you the native docker interface, but remove the cluster mgmt.

Yes, but the nature of lxc makes it much easier to exploits.

Not sure how secure they are. But sounds a bit scary to run my app in a shared-kernel environment.

What if you can automate your AWS infrastructure, so there will NoOps, like using Heroku: CD/CI, AutoScaling, AutoHealing, just battery included?

The point is that you have the 100% control of the infra, but the orchestration service can get you covered. And of the orchestration service went down, your instances will continue to run. Not like in Heroku, their downtime is your downtime!

+1

If you want to do orchestration of both the infra and the app, you need things like opsworks.

seriously, don't host your own PaaS. It simply add more complexity into the game. When things went wrong, you have no clue how to bring the PaaS back at the first place.

Learning how to secure your servers and scale your app is not an overhead, it is a competence compared with those who don't.

+1

I'd like quote Adrian Cockcroft: "the undifferentiated heave lifting". However, the heavy lifting is the daily operation work, not the knowledge to scale your app, HA/DR, CD/CI, etc.

Compared with the black-box model of Heroku, I vote for infra-as-code+desired state, e.g. you order, we cook.

Disclosure: I am the founder of visualops.io, a white-box devops automation service for AWS.

Checkout visualops.io. We are language-independent devops automation service.

Similar value with Heroku: autoscaling, auto-healing, push-to-deploy, but not blackbox. Instances runs in your own account. Even if we go down, your app will not be impacted.

No. But that's a problem to be solved with how we leverage the tool, not the tool itself.

IMO the idea is about the capability of "automation, reproducible system config systems", not who should do what.

founder here. Yes, the UI looks similar. However VisualOps is not an editor to create your app, it continuously manages the apps to make sure they runs in the desired state.