Hyper.sh – Effortless Docker Hosting
61–70 of 218 posts
Re: Hyper.sh – Effortless Docker Hosting
#62Re: Hyper.sh – Effortless Docker Hosting
#63Building a cloud from the ground up is no small task, even more so when you build it on your own hardware, and your own virtualization technology. Any idea who these people are / this company is? Seems to have come out of virtually nowhere.
Looks an awful lot like Heroku.
Outside of that you're limited to specific stacks.
Re: Hyper.sh – Effortless Docker Hosting
#64Earlier quoted context omitted.
Edit: I went ahead and signed up for an account and made a container. The floating IP for the container appears to be an LA IP address. Their host appears to be ZenLayer, a Chinese hosting company that can apparently do co-location in LA, so while the IPs geolocate to China, it's possible they are indeed hosting in LA. The CPU is a E5-2630 v4. Original: I'm pretty sure they're entirely hosted on AWS. Given that they…
Not on aws at all. The hyper.sh API address is us-west-1.hyper.sh, which looks like the AWS style, however, it is not an AWS address and it is located in an independent IDC around Los Angels.
Original: Not on AWS at all doesn't seem possible
The docs for Floating IPs [1] list 52.68.129.19 as an example, which is an AWS Elastic IP.
The docs for the API [2] says "Hyper.sh API signature algorithm is based on AWS Signature Version 4", and then proceeds to explain the differences, which is variable names. The API Domain is us-west-1.hyper.sh, which is the same URL schema as AWS (us-west-1 is also AWS's North California region).
Maybe the containers themselves are somehow not on AWS? Sure. But not on AWS at all doesn't seem to be the answer.
1. https://docs.hyper.sh/Feature/network/fip.html 2. https://docs.hyper.sh/Reference/API/2016-04-04%20[Ver.%201.2...
Re: Hyper.sh – Effortless Docker Hosting
#65Google Cloud is not far from this. Basically instead of "hyper" you are typing "gcloud". Google Cloud is far more complicated but its tools so far are pretty good. I couldn't find how you do custom networks with Hyper. Also as a Java + Postgres shop 16 Gigs memory (L3) is just not enough. Per second also seems overkill. Google Cloud has per minute. It doesn't seem to make sense for "effortless". If you are that inter…
How could it possibly be the case that it takes longer to create a Docker image than a VM image?
Besides we don't always blow away a VM for all services (ie the ones that don't need a cluster of nodes). We reuse them (yes this is eschewed but we get super fast deploys). I suppose this could be said for docker as well though.
Also with Docker our build artifacts would be much bigger since instead of a executable Jar we would have images. The IO of transferring images from the CI server can shockingly take some time.
Re: Hyper.sh – Effortless Docker Hosting
#66For anyone looking for easy to use docker hosting, I would heartily recommend docker cloud(1st node free, then 14$/node/month), along with bare metal providers like packet.net or scaleaway. I Have a 8GB/4-core atom based bare metal server running on packet.net for only 35$. Is running 30+ moderately used containers without any trouble. Got me off heroku finally!
There seems to be about a gazillion ways to get "some code running somewhere" but I'm not aware of many budget options for data persistence.
Re: Hyper.sh – Effortless Docker Hosting
#67Building a cloud from the ground up is no small task, even more so when you build it on your own hardware, and your own virtualization technology. Any idea who these people are / this company is? Seems to have come out of virtually nowhere.
Re: Hyper.sh – Effortless Docker Hosting
#68Earlier quoted context omitted.
How could it possibly be the case that it takes longer to create a Docker image than a VM image?
Well I can't speak for all IaaS but both gcloud, digital ocean and even Rackspace can make a VM in less than 5 minutes which is how long it was taking to make docker images on a good day for us. Besides we don't always blow away a VM for all services (ie the ones that don't need a cluster of nodes). We reuse them (yes this is eschewed but we get super fast deploys). I suppose this could be said for docker as well tho…
Large images aren't an issue anyway, since the base layers will just be cached...