Having a CLI doesn't mean they are close. In Google cloud, you still work with VMs, cluster, schedulers. In Hyper, you work only with Docker, everything is container native!
Per-second is perfect for Serverless, Data mining, CI/CD, etc. It is simply not cost effective to go with per hour/minute rate.
I admit I'm a little behind on Docker but I thought google provided that with Kubernetes [1]?
I work with JVM and servlerless is just not worth it for the JVM (not yet but maybe someday with better AOT). Thus I know very little on instant serverless deployment. I'm sure it is useful though.
Kubernetes lets you do stuff similar to this, but you still have to manage the infrastructure and the platform.
It seems like with Hyper, you literally are just deploying an image to be run in a container. You don't have to worry about configuring and managing a Kubernetes or Swarm cluster. Probably not worth it for very large companies, but for startups and hobby projects, this greatly lowers the barrier to entry.
Yeah but is still not as managed as I want. You still need to populate a Kubernetes cluster which is 3 node minimum. Instances show up in your instances list and you still have to be careful to pop your instances in different zones/region for availability.
In an ideal world I just want to run containers in a region with a LB in front, I don't care on which Kubernetes cluster they are. That the use case hyper.sh seems to address (but I didn't test it to be honnest).
Once you've got the GKE cluster stood up (two clicks or so), you don't need to care which cluster you are on. The gcloud CLI remembers whatever you set.
It's very hands-off. And if you ever do want to take more direct control, you've still got the option of doing more or all of it on your own.
Let's say you have two images: web and db. Web containers ask for high cpu, but small disk. DB requires big mem and disk.
With GKE, you either have different instance types for different container sizes; or you launch the BIG&TALL VMs for all.
The same story applies to public/private network as well. Point is that in GKE, there are two layers to manage: VM and Containers. In Hyper, the container is the infra.
That's a terrible argument considering Hyper gives you no fine-grained control over instance types. You just get a linearly-increasing allocation of CPU cores and RAM.
Right, but the point is that __someone__ has to set that up. Internally, you could use Kubernetes to build something very similar to this. But, then you have to support that yourself and need to hire people to manage that. As Hyper advertises, this takes away from your concern as a software developer: software development.
Hyper allows for the creation of a minimum viable product that you can move around. I can start on Hyper and then move to pure AWS/Kubernetes/mesos/swarm when and if I determine it makes sense to have people spending time managing the AWS infrastructure and handling deployments.
I haven't used Hyper, but this idea is really cool in principle. I'm excited to see how well they actually do it. It really seems like the Heroku of containers.
