Per-minute billing makes more sense to EC2, given the reason above.
HN user
nogox
Or Azure ACI.
Per-second billing doesn't add much value to EC2.
I think the per-second billing is off the point. How does it help, if the EC2 instance takes tens of seconds to launch, and tens of seconds to bootstrap?
To make the most of per-second billing, the compute unit should be deployed within seconds, e.g. immutable. prebaked container. You launch containers on demand, and pay by seconds.
Try hyper.sh. They are the new Heroku for Docker.
Is it Docker Mac?
5 seconds boot + per-second billing is the killer feature.
If you have the Docker images, try hyper.sh. The easiest and fastest way to deploy apps with Docker.
If you use Docker, try Hyper.sh
Did you try runV. It launches a Docker image into a micro VM in 100ms. github.com/hyperhq/runv
Are you using Docker to deploy your project? If yes, check out hyper.sh. Insanely easy!
Where do you run the CI containers? AWS?
That's the point.
Serverless is only cost effective in low traffic cases. If you get a stable or high volume of request, a traditional server is way cheaper.
How is rancher related?
Looks very simple to deploy a few containers. Nice work!
I'm curious how scalable Hypernetes is. As it is based on K8s, will it support 1k nodes?
Check www.hyper.sh and https://github.com/hyperhq/runv
They can boot a new VM with Docker images in 200ms, which is very close to LXC, and perfectly isolated by hypervisor.
The problem of "Virtual Machine" is not "Virtual"/Virtualization, the problem is the full blown guest OS, aka "Machine".
Hi Solomon,
It is great to hear you guys are working on that. I find Hyper is pretty interesting to run Docker on Mac https://hyper.sh/blog/post/2015/07/30/running-containers-fro....
It also runs on Mac! https://hyper.sh/blog/post/2015/07/30/running-containers-fro...
Why? unikernel is quite opinioned imo.
Been following Hyper. Absolutely love this!
How do they handle the isolation in a multi-tenant environment?
check out hyper.sh, this is the future of public CaaS. After all, you don't need EC2 to host your containers, if you can run them directly with a hypervisor.
Check out https://medium.com/@hyperhq/docker-hyper-and-the-end-of-gues...
I think this is the way Container-as-a-Service to go, instead of the current form of AWS ECS.
I like the idea of immutable infrastructure. If I can manage my app as code, I'm in.
CaaS is definitely the future of cloud. However I don't think ECS (IaaS+Container) is the way to go. In this approach, you still need to take care of the cluster capacity planning, scaling, failover, etc. And at most time, there always are some capacity sitting idle in your ECS cluster.
The evolution of CaaS would be sth. like hyper.sh. Due to its hypervisor nature, the whole cluster+scheduling thing can be made transparent to developers, who simply "compose" the app spec and submit to run.
How is this different from Hyper?
mainframe still exists with x86, but the real question is: who cares mainframe. The similar argument when VM is introduced. People say virtualization only fits a subnet of use case. Now what? Look for the nextt 5 yrs, you will see vmware in a really bad position.
I don't really understand this:
"Non-cooperating services often use service discovery information in configuration, such as the backends for a load balancer defined in an HAproxy configuration. A generalized configuration rendering system is used to tie service discovery into most non-cooperating services."
The problem is to generate the config file, which etcd doesn't help.
Will it be easily outgrown by users as heroku? It is better than heroku by giving the capability to compose your app from a vast docker image collection. But I guess that's good until you reach some scale/complexity.