Show HN: Serverless Cloud – By the Creators of the Serverless Framework(serverless.com)
serverless.com
Show HN: Serverless Cloud – By the Creators of the Serverless Framework
https://www.serverless.com//cloud
18 comments
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.
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.
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.
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.
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.
Hey tedmiston, I think you make incredibly good points, and as the GM of this product, I appreciate your candor and scrutiny. We don't expect Serverless Cloud to be a silver bullet, lots of team out there need more control and flexibility. But we hope that for many developers and teams, we can provide the right level of productivity, performance and cost to minimize their TCO and validate their ideas faster.
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.
> The infrastructure interpretation happens at build/deploy time, not at execution time, so there isn't any additional tax.
The service has a pricing page [1] that's non-free after the preview period with specific tiered included limits around execution minutes etc. For example, "$20/user/month for 5,000 minutes of execution time" and some amount of storage.
Is there something I'm missing about that pricing model? What about metered pricing beyond the limits listed? I didn't see that addressed in the FAQ, but perhaps I overlooked it.
[1]: https://www.serverless.com/cloud-faq
The service has a pricing page [1] that's non-free after the preview period with specific tiered included limits around execution minutes etc. For example, "$20/user/month for 5,000 minutes of execution time" and some amount of storage.
Is there something I'm missing about that pricing model? What about metered pricing beyond the limits listed? I didn't see that addressed in the FAQ, but perhaps I overlooked it.
[1]: https://www.serverless.com/cloud-faq
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.
Very interesting technology, if all plays out, you would not require to have knowledge to start their project / startups
This looks very interesting. I need to kick the tires a bit. It could be just what I was looking for a year ago :(
Congrats on the launch! I know this has been a long time coming for the team, and I'm looking forward to seeing what people build with Cloud!
So happy to finally be able to showcase what this talented team has been working on
Very cool. Looking forward to GCP support.
Looking forward to seeing what people will build with this. The team tried to address as many of the serverless development pain points as possible, with the goal of enabling an entirely new class of serverless developer. There's a lot more to do, so we're excited to hear your feedback!
So much more to do, but it's amazing how much you can build with the basic stuff that's already in place.
Agreed, we have our work cut out for us but the team is fantastic and I can't wait to share more of our vision with the world!
How are you accomplishing 1 second deployments??
Very cool stuff! Excited to see Serverless is supporting the frontend, backend, and other cloud providers!!
This might be a game changer in the space, I really like the idea of self-provisioning runtimes