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 is one example

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!

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.

Thanks for the detailed input. They are tremendously valuable.

Part of the reason we chose to open source is that we want the community to innovate. We are continuing to build the feature set, however I need to say that the workflow varies from app to app. Therefore, by providing the base building block and allowing others to create different solutions, we could enable more options to the market.

Yeah that makes sense. If there's enough of an enticement to adopt the infra service and you standardize the API at the bottom, any developments/contributions on top of it could co-exist and be more share-able. I'm reminded of the addon marketplace in Heroku. The underlying infra was consistent and general, which made third party plugins/addons/contributions easier (even to make money). Heroku ended up getting a lot of specialized support for platform customers that they probably couldn't have built out themselves.

I could totally see even seeding a possible 'marketplace' with your own services. Like perhaps Func as a service, powered by Hyper. And others also benefiting from the underlying infra being so simple. Why wouldn't a platform-provider use an infra service that's flexibly scalable on perf+price? They probably have the skillset on hand for that too and don't need any more finesse than already exists, beyond stability.

Anyway, that's just my own ramblings. Hope you're having fun with Hyper! It sure looks like a lot of love/tears went into it.

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.

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.

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.

What would be some example use cases for this?

Off the top of my head, this could be used for backups, database migrations, auditing software, report generations, email blasts, CPU/memory intensive operations... The possibilities are endless because the execution layer is just a container, so you're not limited on what exactly is being run inside it.

Off the top of my head, I'd say anything you might use Lambda and it's ilk for.

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"

Good catch - thanks.

Just FYI, the text still has the rounded number too:

> You are charged $0.000013 for every Core-s used

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."

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.

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/

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.

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.

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.

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.

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

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.

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

That number seems like a rounded version of the GB-seconds (0.0000125 => 1.3e-5)

You're right - if you look at the calculations further down the page the 0.0000125 number is quoted.

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.

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.