I don't release software to the cloud without running it on my computer first.
I'm attracted to 'serverless' about as much as I'm attracted to 'version-control-less' or 'testless'
The Serverless Revolution Has Stalled
61–70 of 670 posts
Re: The Serverless Revolution Has Stalled
#62Earlier quoted context omitted.
Another niche where it shines is the small, low-volume tool. You don't want to give it an entire VM, because that's a major waste. You don't want to have it share one "tools box," because it is awkward sharing like that, security becomes more of an issue, and it generally devolves into a mess. So if you've got other things running on AWS, then AWS Lambda is great for this. Do you need a random web-facing snippet to r…
I'd add on top of that, that it provides even more value when volume is usually low and sparse, but unpredictable. If you have a server that can handle up to 100 requests at a time, but you're only getting one or two a day, you could probably save money by switching to serverless. On the flip side though, you're also a bit screwed if 1000 requests all come in at once, since, even if you have some autoscaling solution…
[deleted]
Re: The Serverless Revolution Has Stalled
#63Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in.
I tried AWS, and then IBM's offering which is based on an open source (Apache OpenWhisk) project, thinking that it might be easier to work with, but that was also a pain.
I just lost interest as I was only checking it out. For something constantly marketed on the ease of not having to manage servers, it fell a long way short of "easy".
Re: The Serverless Revolution Has Stalled
#64I think it's more a case of it coming full circle. People realising that it's just another tool in the toolbox rather than 1 tool that can replace their entire toolbox. Much of the cynicism seems to come from that. I do agree with jason though - open ended serverless things charged per use are no fun. Now you can bankrupt yourself at scale with that bug & the 1000 instances.
Pay per request needs to be within 2x magnitude of an always on server. Really one should be paying for latency, scale, cpu time and bandwidth.
>Pay per request needs to be within 2x magnitude of an always on server.
Are any of them? Stuff like cloud run is very competitively priced when assuming base case...but by its very nature it can scale up near infinitely. And with it bugs & bills.
The ability to cap things by 2 order of magnitudes would make me sleep much better. (1 would be better).
Re: The Serverless Revolution Has Stalled
#65Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
GCP has https://cloud.google.com/functions/docs/functions-framework but I will not use it. I have found the best solution is to abstract away the serverless interface and create a test harness that can test the business logic. This adds some extra complexity in the code, but iterations are fast and do not rely on the overly complex and bug prone "platforms" like SAM and Functions Framework.
Re: The Serverless Revolution Has Stalled
#66Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
I found firebase functions pretty easy and painless. Worth a look.
Re: The Serverless Revolution Has Stalled
#67You mean the permanent AWS lock-in revolution?
Re: The Serverless Revolution Has Stalled
#68LOL infoq. Srsly.
> One of the advantages of serverless models is supposed to be that obscure, infrequently used programs can be utilized more cheaply,
No-one: Literally no-one: Infoq: thinks serverless is all about obscure programs.
> Vendor Lock
Well try migrating a massive Java codebase to .NET or a deep Oracle application to Postrges. That's life.
> Functions that have not been run on a particular platform before, or have not been run in while, take some time to initialize.
Boo-hoo mah warm up time. Get over it already.
> you (generally) can't run entire applications on severless systems.
You aren't supposed to - serverless is for developing systems based around microservices, claiming they are intended to replace servers for running COTS products is a disgusting strawman.
> Despite all these complaints, I'm not against serverless solutions per se. I promise.
Promise away. I promise not to care.
Re: The Serverless Revolution Has Stalled
#69The serverless marketing revolution has stalled
Re: The Serverless Revolution Has Stalled
#70Serverless has an edge usage case and its not in the middle of your web requests. Due to the load on AWS regional lambda compute pool, now your have a 500-2000ms cold start to your lambdas or you can't use it for tools and services with long-lived TCP connections (hi redis). Good luck. Not for me