Show HN: Serverless Cloud – By the Creators of the Serverless Framework

I'm a DevOps engineer, so take my thoughts with a grain of salt here...

This is an interesting idea: charging an abstraction layer tax on compute and execution time vs the underlying raw AWS resources.

But also... sorry, I hate the idea that using this abstraction means incurring additional ongoing infrastructure costs vs other competing tools. And not being able to deploy to your own AWS account is quite the showstopper. The 2k requests per second seems like another odd limitation too... considering that a single API Gateway in front of a Lambda function can do 10k requests per second out of the box before getting rate limited.

It's really just shifting the lock-in from one cloud to one serverless service ¯\_(ツ)_/¯... I wonder if Serverless Cloud is fully open source?

I don't see myself using something like this personally for production projects compared to a tool like Terraform. But I do appreciate AWS Chalice for small simple serverless projects. If someone builds a Terraform escape hatch like Chalice has, that would make Serverless Cloud more appealing to me.

That said, my experience has been that the benefits and developer experience of these types of tools breaks down fast when you: (1) need to interact with cloud resources created from outside of the magical interference process, (2) the magical inference process gets it wrong or does not support the full variety of configuration options required, and (3) the magical inference abstraction doesn't support the resource types you need at all.

Multi-could abstraction is a hard problem as soon as you go beyond using pure cloud primitives to any of the fancier services that make life easier but are apples to oranges comparisons across clouds.

I've yet to be convinced that multi-cloud abstraction is a valuable problem that most companies actually need to solve, much like most companies don't need to be (directly) running their own Kubernetes clusters... but enterprises sure will throw a lot of money at chasing it, so I get why they're aiming for that market.

Thanks for this feedback. Couple of points of clarification. The infrastructure interpretation happens at build/deploy time, not at execution time, so there isn't any additional tax. The deployment engine isn't open source, but we are evaluating ways to have optional eject paths. In terms of deployment across cloud providers, the abstractions we've built (and are working on) use all those fancy AWS managed services like DynamoDB. Our abstractions focus on use cases, not primitives, so when we eventually deploy to Azure, we'll be able to replicate the service using native services like Cosmos DB.

I see lots of green names in the comments on this particular thread, so not surprised I'm getting downvoted here.

Reminder that it's more productive in the HN ethos to engage in discussion to the points raised vs downvote silently without expressing why / how your thoughts may differ and more valuable for everyone to engage in constructive criticism.

Looks like the mobile version of the pricing page hides the rest of the table (sorry about that). Extra execution time will be $0.003/minute and billed by the millisecond. There are no request charges or data transfer charges in our model, which we hope will simplify billing for the average users. For users that need more capacity and execution time, we will customize pricing for them.

It feels disingenuous that this thread is dominated by green names. It communicates that you're just here for the promotion, and you'll be gone when your thing isn't the topic of convo anymore. Either use your actual accounts, controversial opinions and all, or sit back and let the community discover your product on their own. We are capable of sorting out the nuances ourselves without the guided experience.