Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

541–550 of 670 posts

Re: The Serverless Revolution Has Stalled

#541

Earlier quoted context omitted.

> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

I use Google Cloud Run to run my serverless code for exactly this reason. GCR is literally just a container that runs on demand (with scaling to 0). Literally the only GCR specific part is making sure the service listens on the PORT env. If I was so inclined, I could deploy the exact same container on any number of services, host it myself and/or run it on my laptop for development purposes. There's also Kubernetes K…

How is the spin-up time for such a container?

Re: The Serverless Revolution Has Stalled

#542
post #495

Earlier quoted context omitted.

In my experience, having started and abandoned side projects in both aws lambda and google app engine, half your project becomes: * Well, obviously we use a hosted database * And obviously, AWS provides our logging and all our analytics. * Obviously when people call our lambda functions, they do so either through an AWS-specific API, or one constrained to a very limited set of forms. * Of course, we can't blindly let…

This, but it was told by serverless experts, on stage, in front of hundreds of people. If that was their sales pitch, their reality was likely even less impressive.

This sounds a bit like the posh workshop I went to on WAP (wireless access protocol) years ago when I worked for BT.

It was a complete omnishambles - to the point I avoided the fancy lunch and went to the Pub for a ploughman's lunch, In case I suddenly blurted out "this is all S*&T" and caused a political row with the mobile side of the company I worked for.

Re: The Serverless Revolution Has Stalled

#543

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

>> Like running your own power plant to serve your factory

With newer power technologies becoming more affordable and effective, solar, wind, & storage are increasingly being used to power factories and other businesses.

It's all about control of your product and operations. If it is economically feasible, it's always better to control your own stack all the way down.

Does serverleds actually deliver better control over your development, portability, reliability, security, etc. for your application & situation, or not?

This sounds a bit like the "When will they turn off the last mainframe?" arguments a while back - I wouldn't expect servers to disappear either...

Re: The Serverless Revolution Has Stalled

#544

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…

Anyone moving to Hitrust or SOC2 loves serverless for that exact reason. When asked how I maintain my infrastructure, I point to RDS, API gateway, and Lambda. This leaves my security mostly free to focus on application level security.

Re: The Serverless Revolution Has Stalled

#545
My company tried really hard to make serverless work on a new part of the platform we rolled out. Our cloud team and management drank the AWS koolaide on serverless and went 100% all in for all new use cases implemented in this particular platform. It was probably one of the biggest mistakes in the history of the company because doing serverless right is at least as much work and running workloads on well-managed servers (which we have). Management won't resource it appropriately because the whole point of higher costs in serverless is to eliminate Ops budget in the first place.

As for running actual code, many types of workloads currently do not map to serverless at all and you won't find out until you hit the limits. Anything that needs to read in a lot of data from a file or do a lot of in memory computations are a lot less efficient or impossible in Lambda given the memory constraints. If any single invocation of your lambda needs more than the alloted memory, it'll just fail and you'll either need to implement some heuristics based routing to the different lambdas (same code with the appropriate amount of memory) or you'll just eat cost on every lambda invocation. You'll find you end up doing things like re-writing lambdas from Python into Go to make it easier to fit more in memory. How is that not insane?

Although it's not 100% true anymore, at the time serverless development was often easiest using SAM which ties you directly to AWS CloudFormation which is the biggest mistake any company can make. CloudFormation is easily the worst thing that AWS has ever created. It's fine for infrastructure with lower rates of change but for applications it's an absolute nightmare to the point where it comes up in every sprint retro on some of our teams.

I /won't even go into how crappy testing is. It's a complete afterthought and it shows.

That team has started moving towards ECS/Kubernetes and even running Docker containers directly on EC2 instances in some cases because it's actually saving them time over futzing with Lambda and it's enabling them to do more faster.

Re: The Serverless Revolution Has Stalled

#546

Earlier quoted context omitted.

Tracking exactly what individual db entries ran and didn't run when there's one of these "serverless" "painless" interruptions to an ETL, ensures that you have an endless number of ever-changing status columns and re-run processes. Are you really sure that it all re-ran? No. You have to query your latest batch - which means you have to have arbitrary boundaries for when failures might have occurred like say, last 24…

Here's the beautiful thing about thinking serverless. "Are you really sure that it all re-ran?" Yes I am, because Dynamo streams or Kinesis streams guarantee message delivery. If my Lambda code has a bug in it, which yes sure that happens, I can as part of my exception catching, put that message into a dead letter queue and process it later or report on it. No polling, no querying, I know exactly what went wrong and…

> Dynamo streams or Kinesis streams

I can appreciate that. A lot more people than you might think, use Kafka or SQS because of various requirements (like that's all their infrastructure supports) and you end up with a massive "source" DB which is a duplication of all-time messages. Such is the reality of a larger byzantine organization. If it can't be audited by someone else, at their own pace, it's not approved.

Re: The Serverless Revolution Has Stalled

#547

Earlier quoted context omitted.

I don't know, it sounds like you've just implemented all of those things n+1 times.

I think a lot is hidden inside "which calls SES" versus "point it at your MTA, do a ton of configuration, then it may work." Email is unfortunately a moving target. What worked before, gradually stops working as the big providers put up increasing obstacles to your own MTA doing a successful delivery. I've heard Amazon SES also has delivery problems so take with a pinch of salt. But I would hope they generally try to…

I agree, but then I think then we're comparing using SES (or Mailgun/Sendgrid/Mandrill/whatever) versus maintaining your own MTA, which is orthogonal to the serverless vs non-serverless debate.

Re: The Serverless Revolution Has Stalled

#548
post #104

Earlier quoted context omitted.

>"I'd agree that it's stalled, but moreso out of fear and ignorance than anything else." How about simple common sense instead of "fear and ignorance". I have a C++ monolith that serves me just fine already for years. The performance is great and I am able to rent dedicated servers that can serve at least 10 times more requests that I have at a price that is a tiny fraction of AWS for the same work. Why would I switc…

Can your business adapt to change well? That’s the first issue with any monolith.

What change? I am not going to worry about some abstraction. You have to be more particular. In my case I change features on on need basis with no problems. Hence I have 0 issues with the monolith. Micro- services actually do not really make life any easier. All that immense cloudy push is driven by handful of very big corps who'd build architecture for scale that most of the businesses would never even dream to approach. So I'll let them worry about their problems and I'll worry about mine. I am not in business of transferring my money to cloud paying 10x and more comparatively to my current solutions.

Re: The Serverless Revolution Has Stalled

#549
post #511

Earlier quoted context omitted.

AWS in particular seem to have a carefully refined technical sales/certification/advocacy channel whose main product is those fucking stupid architecture diagrams. Hello world service with $4000/mo. worth of geo-replicated backing databases, CloudWatch alarms, API Gateway instances, WAF etc. But don't let it encourage you to think serverless has no value, or it can't be done portably or cheaply. It has its sweet spot…

Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.c…

[deleted]

Re: The Serverless Revolution Has Stalled

#550

Earlier quoted context omitted.

Eh? I was able to go from a docker image to live and 0 downtime deploys in a few hours?

But how many hours/days/years did it take you to learn how all the parts move before you became capable of setting something like that up within a few hours? Anecdotally, stories of businesses abandoning entire cloud automation projects because they wasted weeks and never had anything to show from it don't seem unusual, so evidently a considerable amount of knowledge and skill is required to get value out of these to…

None really? I don’t consider myself the worsts best Sysadmin, but the hard part was making an app docker. Making a docker k8s was easy.
Post reply on HN