HN user

nogox

19 karma
Posts7
Comments33
View on HN

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.

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.

Docker and VMWare 12 years ago

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.

Flynn Beta (YC S14) 12 years ago

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.