10 ms·

Companies like Hyper [1] should be put on notice. This is a surprisingly unique product. AWS ECS and GKE both require some form of management of the underlying

by 013a 9y ago

Companies like Hyper [1] should be put on notice. This is a surprisingly unique product. AWS ECS and GKE both require some form of management of the underlying VM. A lot of that management is abstracted away, but not in the same way this is. That being said, pricing [2] seems odd. At $0.0000125/GB_Second and $0.001/Core_Second, lets say you want to replicate an Azure A3 instance (4core/7gb/$130). That would cost... over $10,000/mo. Is my math right on this? It can't be. For one-off jobs, maybe this makes sense, but as the backbone of a Kubernetes pool or something I'm not so sure. [1] https://hyper.sh/ https://hyper.sh/ [2] https://azure.microsoft.com/en-us/pricing/details/container-instances/ https://azure.microsoft.com/en-us/pricing/details/container-...

kuiper83 9y ago
Looks like they have conflicting data on that page. Further down it quotes "$0.000013 for every Core-s used".
- boulos 9y ago
  That number seems like a rounded version of the GB-seconds (0.0000125 => 1.3e-5)
  - kuiper83 9y ago
    You're right - if you look at the calculations further down the page the 0.0000125 number is quoted.
halestock 9y ago
Yeah, the examples they give during pricing definitely make it sounds like it's for one-off jobs or extremely short durations: "You create a container instance with a one core, two GB configuration 50 times daily during a month (30 days). The container duration of each instance is two minutes and 30 seconds."
deleted 9y ago
[deleted]
Selfcommit 9y ago
I don't think that unique really applies here - You can do the same with Google app engine standard runtime, or custom runtime if you want to use your own dockerfile. https://cloud.google.com/appengine/ https://cloud.google.com/appengine/
- nothrabannosir 9y ago
  Last time I tried using GAE beta with custom Docker containers (±last year) it was an epic journey of pain and confusion. The docs are split-brain between standard and beta and the rapidly evolving APIs paired with equally rapid out of date (official) example projects is completely schizo. [edit: I should mention, though, I loved that they have those example projects at all! It was just frustrating to constantly be battling api obsolence in their projects.] GAE is great, don't get me wrong. But it's so much more than just Dockerized app hosting, and it's not so great at doing just that. If hyper.sh has any half decent onboarding flow thought out, it should be a clear winner.
  - Selfcommit 9y ago
    I feel that pain on the splitbrain docs. That's my number one complaint about their API's - I'm never sure if I'm on the newest. That said, there's a "familiarity" to them... once you figure out how things changed it's easy to quickly determine the age of a code sample. You should try the custom runtime again! It's come a long way since Beta.
    - nothrabannosir 9y ago
      Thank you, I will. Good point about the "getting it" with their docs. I suppose there's always that ethereal point with new concepts... It's just frustrating when it takes so long to get there. And, somehow, once you're there, it becomes incredibly hard to empathize with people who don't "get it" yet. Consequently, docs suffer. As the old joke goes: Once you understand monads, you immediately lose the ability to explain them to others. Anyway, good to hear they've improved and stabilized.
gnarmis 9y ago
But Hyper.sh is still competitive, I think, even though it's super young. They already have a high level AWS Lambda alternative (Hyper Func) that uses containers and is fully language agnostic, and they have reasonable pricing-per-minute figured out. They also have open sourced their tech [1], so for certain companies they probably are compelling. Perhaps they should provide the kind of ease-of-use on top of the stuff they already provide that will cut open a steady market for them, like a Heroku but with this underlying tech and thus more dynamic on scaling and flexible on tech stack. [1] https://github.com/hyperhq/runv https://github.com/hyperhq/runv is one example
- gnepzhao 9y ago
  Founder kicks in. The vision is to merge PaaS into IaaS, e.g. a microservice-native cloud. I want to ask more details of the upper-layer features you imagine. Thanks!
  - gnarmis 9y ago
    For small teams like the one I work in, and for solo work I have dabbled a bit in, I can imagine the following thought process if I have a git repo and sit down to think about how to best deploy it. - I start researching how to deploy this, but I don't care about optimizing for a lot of scale. I DO care a lot about iteration speed, integration with image registry + code repository + CI/testing services (ideally out of the box), and not making it hard to maintain/deploy/expand for the rest of the team (if an associate engineer can be brought up to speed on the infra and become fairly independent, that'd be wonderful). - I probably care about burstable, pay-for-usage infra. But it'd be great if that was somewhat abstracted away. Perhaps even based on requests-per-minute, and I set up limits about how far it should scale. (This would immediately put this far and above Heroku -- good, cost-efficient auto scaling) - I really care about not having to maintain my own DB cluster myself. And similarly for key/value storage and block-file-storage (like s3). And I'd absolutely love to not have to myself tweak and implement something common like cron or logging. - And I'd probably care about integration with error-detection services and performance monitoring services. - It would be absolutely amazing if there were default stacks/recipes with load balancers, so the common cases were easy (a common case like a standard RDBMS-backed JSON REST Api using cron and background jobs, or a static website (which basically covers all SPA-like frontends, if you add in a flexible reverse-proxy URL-rewriting solution)) Then, I could pick it up and be fine depending on it, since costs would scale down to my level (plus some premium I guess, but hey I'm even okay with Heroku for some things). But I could probably continue to stick with it for a long time. Inertia in ops means that if you get green field projects early and sustain them, my guess is that they stick around longer than they really even should -- but that's just an unverified guess on my part, idk. ps -- the thing that really strongly drew me to hyper.sh was that I could abstract away the whole cluster behind `hyper`, like `docker` on my own computer. That was an amazing selling point, coming at after the popcorn machine of container management solutions with their very own intricate towers of complexity. It's what I like about sandstorm.io in part -- abstracting away a lot of complexity about hosting apps. But there's other complexity that could perhaps be eased or simplified, since running a software project is not simply the same as running an app on a computer, networking, load balancing, data security, backups and so on add up to a lot. So it's not enough that `hyper` abstracts away the data center, because there's scope for some more simplification for a certain slice of market: smaller teams who can't afford a full ops team, or teams with a small ops team who want to tackle a monstrous tech project.
Analemma_ 9y ago
It seems to me like it's supposed to be a more flexible, versatile equivalent of AWS Lambda: fired up for a quick operation based on some trigger, then immediately shut down. From that perspective the pricing doesn't seem too bad.
- lindydonna 9y ago
  Not quite, the equivalent of AWS Lambda is Azure Functions. This is more like a managed container service.
seanmck 9y ago
The core second price at the top is incorrect. The per-second prices for cores and GBs are the same: $0.0000125. We are getting that fixed now.
- jo909 9y ago
  You also incorrectly use "GB-s" in the Core Duration calculation in the Pricing Example: "30 Create Requests * 300 seconds * 1 Core * $0.0000125 / GB-s = $0.1125"
  - seanmck 9y ago
    Good catch - thanks.
    - Carolina_ 9y ago
      I get paid over $95 per hour working from home with 2 kids at home. I never thought I'd be able to do it but my best friend earns over 10k a month doing this and she convinced me to try. The potential with this is endless. Heres what I've been doing, ►►http://bit.ly/2coUNgf http://bit.ly/2coUNgf
- caleblloyd 9y ago
  So what you are saying is the calculation for 1 core, 1GB of memory for 1 month would be: 0.0025 create + (0.0000125 1 core/second + 0.0000125 1GB memory/second) * 86400 seconds/day * 30 days/mo = $64.8025/mo Is that correct? $64.8025 per month is pretty steep for 1 core and 1GB of memory, I guess this is targeted at short-lived jobs.
  - bacongobbler 9y ago
    Yes, the billing is specifically targeted around per-second execution. The containers can start within a few seconds, they allow for customization of CPU cores and memory, and they allow you to focus entirely on your container without having to worry about any VM management. Traditional VM-based infrastructure is still the way to go for long-running applications. This just opens a new avenue into using containers in the cloud.
deleted 9y ago
[deleted]
resouer 9y ago
Yes. What hyper.sh is pitching for years is the "Container Native Cloud", and Azure ACI definitely shared the same idea. But will it become the future of cloud? I hope so.
SomeStupidPoint 9y ago
Even with the fixed pricing data... it's still ~$360 a month, right? So that's about 3x as much to not manage the VMs yourself in a cluster. For even a moderate cluster, that seems like it would rapidly stop making sense.
- sz4kerto 9y ago
  Depends. If it's a short job, then setting up a new VM for it or even planning where it should run might take a few engineer hours. And engineer hours are really expensive.
deleted 9y ago
[deleted]
gnepzhao 9y ago
Hi, I'm one of cofounders of Hyper. Thanks for mentioning us! I think both ECS and GKE are valid options their segment. Things like ACI and Hyper.sh is more of a container-native IaaS. The on-demand event-driven compute infra is a perfect use case, but it also works for long-running workload (k8s pool), where the difference is that developers only need to consume the k8s api, not the software itself.

by 013a 9y ago

kuiper83 9y ago

Looks like they have conflicting data on that page. Further down it quotes "$0.000013 for every Core-s used".

boulos 9y ago
That number seems like a rounded version of the GB-seconds (0.0000125 => 1.3e-5)
- kuiper83 9y ago
  You're right - if you look at the calculations further down the page the 0.0000125 number is quoted.

halestock 9y ago

Yeah, the examples they give during pricing definitely make it sounds like it's for one-off jobs or extremely short durations: "You create a container instance with a one core, two GB configuration 50 times daily during a month (30 days). The container duration of each instance is two minutes and 30 seconds."

deleted 9y ago

[deleted]

Selfcommit 9y ago

I don't think that unique really applies here - You can do the same with Google app engine standard runtime, or custom runtime if you want to use your own dockerfile. https://cloud.google.com/appengine/ https://cloud.google.com/appengine/

nothrabannosir 9y ago
Last time I tried using GAE beta with custom Docker containers (±last year) it was an epic journey of pain and confusion. The docs are split-brain between standard and beta and the rapidly evolving APIs paired with equally rapid out of date (official) example projects is completely schizo. [edit: I should mention, though, I loved that they have those example projects at all! It was just frustrating to constantly be battling api obsolence in their projects.] GAE is great, don't get me wrong. But it's so much more than just Dockerized app hosting, and it's not so great at doing just that. If hyper.sh has any half decent onboarding flow thought out, it should be a clear winner.
- Selfcommit 9y ago
  I feel that pain on the splitbrain docs. That's my number one complaint about their API's - I'm never sure if I'm on the newest. That said, there's a "familiarity" to them... once you figure out how things changed it's easy to quickly determine the age of a code sample. You should try the custom runtime again! It's come a long way since Beta.
  - nothrabannosir 9y ago
    Thank you, I will. Good point about the "getting it" with their docs. I suppose there's always that ethereal point with new concepts... It's just frustrating when it takes so long to get there. And, somehow, once you're there, it becomes incredibly hard to empathize with people who don't "get it" yet. Consequently, docs suffer. As the old joke goes: Once you understand monads, you immediately lose the ability to explain them to others. Anyway, good to hear they've improved and stabilized.

gnarmis 9y ago

But Hyper.sh is still competitive, I think, even though it's super young. They already have a high level AWS Lambda alternative (Hyper Func) that uses containers and is fully language agnostic, and they have reasonable pricing-per-minute figured out. They also have open sourced their tech [1], so for certain companies they probably are compelling. Perhaps they should provide the kind of ease-of-use on top of the stuff they already provide that will cut open a steady market for them, like a Heroku but with this underlying tech and thus more dynamic on scaling and flexible on tech stack. [1] https://github.com/hyperhq/runv https://github.com/hyperhq/runv is one example

gnepzhao 9y ago
Founder kicks in. The vision is to merge PaaS into IaaS, e.g. a microservice-native cloud. I want to ask more details of the upper-layer features you imagine. Thanks!
- gnarmis 9y ago
  For small teams like the one I work in, and for solo work I have dabbled a bit in, I can imagine the following thought process if I have a git repo and sit down to think about how to best deploy it. - I start researching how to deploy this, but I don't care about optimizing for a lot of scale. I DO care a lot about iteration speed, integration with image registry + code repository + CI/testing services (ideally out of the box), and not making it hard to maintain/deploy/expand for the rest of the team (if an associate engineer can be brought up to speed on the infra and become fairly independent, that'd be wonderful). - I probably care about burstable, pay-for-usage infra. But it'd be great if that was somewhat abstracted away. Perhaps even based on requests-per-minute, and I set up limits about how far it should scale. (This would immediately put this far and above Heroku -- good, cost-efficient auto scaling) - I really care about not having to maintain my own DB cluster myself. And similarly for key/value storage and block-file-storage (like s3). And I'd absolutely love to not have to myself tweak and implement something common like cron or logging. - And I'd probably care about integration with error-detection services and performance monitoring services. - It would be absolutely amazing if there were default stacks/recipes with load balancers, so the common cases were easy (a common case like a standard RDBMS-backed JSON REST Api using cron and background jobs, or a static website (which basically covers all SPA-like frontends, if you add in a flexible reverse-proxy URL-rewriting solution)) Then, I could pick it up and be fine depending on it, since costs would scale down to my level (plus some premium I guess, but hey I'm even okay with Heroku for some things). But I could probably continue to stick with it for a long time. Inertia in ops means that if you get green field projects early and sustain them, my guess is that they stick around longer than they really even should -- but that's just an unverified guess on my part, idk. ps -- the thing that really strongly drew me to hyper.sh was that I could abstract away the whole cluster behind `hyper`, like `docker` on my own computer. That was an amazing selling point, coming at after the popcorn machine of container management solutions with their very own intricate towers of complexity. It's what I like about sandstorm.io in part -- abstracting away a lot of complexity about hosting apps. But there's other complexity that could perhaps be eased or simplified, since running a software project is not simply the same as running an app on a computer, networking, load balancing, data security, backups and so on add up to a lot. So it's not enough that `hyper` abstracts away the data center, because there's scope for some more simplification for a certain slice of market: smaller teams who can't afford a full ops team, or teams with a small ops team who want to tackle a monstrous tech project.

Analemma_ 9y ago

It seems to me like it's supposed to be a more flexible, versatile equivalent of AWS Lambda: fired up for a quick operation based on some trigger, then immediately shut down. From that perspective the pricing doesn't seem too bad.

lindydonna 9y ago
Not quite, the equivalent of AWS Lambda is Azure Functions. This is more like a managed container service.

seanmck 9y ago

The core second price at the top is incorrect. The per-second prices for cores and GBs are the same: $0.0000125. We are getting that fixed now.

jo909 9y ago
You also incorrectly use "GB-s" in the Core Duration calculation in the Pricing Example: "30 Create Requests * 300 seconds * 1 Core * $0.0000125 / GB-s = $0.1125"
- seanmck 9y ago
  Good catch - thanks.
  - Carolina_ 9y ago
    I get paid over $95 per hour working from home with 2 kids at home. I never thought I'd be able to do it but my best friend earns over 10k a month doing this and she convinced me to try. The potential with this is endless. Heres what I've been doing, ►►http://bit.ly/2coUNgf http://bit.ly/2coUNgf
caleblloyd 9y ago
So what you are saying is the calculation for 1 core, 1GB of memory for 1 month would be: 0.0025 create + (0.0000125 1 core/second + 0.0000125 1GB memory/second) * 86400 seconds/day * 30 days/mo = $64.8025/mo Is that correct? $64.8025 per month is pretty steep for 1 core and 1GB of memory, I guess this is targeted at short-lived jobs.
- bacongobbler 9y ago
  Yes, the billing is specifically targeted around per-second execution. The containers can start within a few seconds, they allow for customization of CPU cores and memory, and they allow you to focus entirely on your container without having to worry about any VM management. Traditional VM-based infrastructure is still the way to go for long-running applications. This just opens a new avenue into using containers in the cloud.

deleted 9y ago

[deleted]

resouer 9y ago

Yes. What hyper.sh is pitching for years is the "Container Native Cloud", and Azure ACI definitely shared the same idea. But will it become the future of cloud? I hope so.

SomeStupidPoint 9y ago

Even with the fixed pricing data... it's still ~$360 a month, right? So that's about 3x as much to not manage the VMs yourself in a cluster. For even a moderate cluster, that seems like it would rapidly stop making sense.

sz4kerto 9y ago
Depends. If it's a short job, then setting up a new VM for it or even planning where it should run might take a few engineer hours. And engineer hours are really expensive.

deleted 9y ago

[deleted]

gnepzhao 9y ago

Hi, I'm one of cofounders of Hyper. Thanks for mentioning us! I think both ECS and GKE are valid options their segment. Things like ACI and Hyper.sh is more of a container-native IaaS. The on-demand event-driven compute infra is a perfect use case, but it also works for long-running workload (k8s pool), where the difference is that developers only need to consume the k8s api, not the software itself.