Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

481–490 of 670 posts

Re: The Serverless Revolution Has Stalled

#481

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…

Well, when will it be mature and what will it take to get there?

My first experience with serverless architecture was back in 2007 or so when trying to port Google News to App Engine. That was a thoroughly painful experience, and things haven't exactly gotten much easier since. If you go back in time a decade, Google's strategy for selling compute capacity was App Engine. Amazon went the EC2 route. Reality suggests AWS made the better choice.

I can understand the superficial notion that having idling virtual machines is inefficient (because it is). But this reminds me a bit of tricks we did to increase disk throughput in systems with lots of SCSI disks back in the day. Our observation was that if we could keep the operation queues on every controller full as much of the time as possible, we'd get performance gains when controllers were given some leeway to re-order operations, resulting in slightly better throughput. Overall you got higher throughput, and thus higher efficiency, but from the perspective of each process in the system, the response was sluggish and unpredictable. Meaning that if you were to try to do any online transactions, it would perform very poorly.

For a solution to be desirable it has to be matched with a problem that needs solving.

As the article points out, there are some scenarios where serverless architectures might be a good design paradigm. But extrapolating this to the assumption that this paradigm is a universal solution requires not only a leap of faith, but it also requires us to ignore observed reality.

So you owe me some homework. Tell me what needs to happen for serverless architectures to reach "maturity".

Re: The Serverless Revolution Has Stalled

#482

Earlier quoted context omitted.

You seem to forget there is are a ton of people who grew up on bare metal and know it quite well. And they can squeeze far more performance out of it then you could ever hope to see with outsourcing business-critical infra to a supplier who literally doesn't give a shit about you. Have fun with an army of one-trick pony hires. One old-school diehard computer nerd knows enough to supplant 10 of those fools, but only c…

And many of them already work for AWS, who I can pay a small premium to to take advantage without having to hire one myself and then worry about replacing them when they decide to leave.

I think the point is sometimes that AWS small premium is really large. It varies a lot. For some the AWS costs are free or tiny. For others, AWS costs are larger than salaries, and it creeps up over time.

About staff, maybe consider finding a good consulting/support firm that can look after your servers for That solves the worry about replacing people, as well as the cost.

But as with people, it can take some luck to find a good one :-)

(I used to provide that kind of consulting/support service. Not as much now because there isn't much demand, and development & research work is more satisfying. But still a little, ticking along in the background.)

Re: The Serverless Revolution Has Stalled

#483

Earlier quoted context omitted.

> Maintaining your own server is completely nuts I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sense. There are kernel people who maintain the kernel and there are Debian devs who maintain the operating system. The server may be mine (but more often that not, it isn't) but only in very specific circumstances do I ever concern myself with maintaining any part…

That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it g…

One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of luck to you if you're about to catch a big customer but they demand your application to run on their premises.

There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".

Re: The Serverless Revolution Has Stalled

#484

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…

Those are the same arguments as the ones put forth in the article under "the promise of serverless computing". It remains to be seen if they can be realized without the downsides.

Re: The Serverless Revolution Has Stalled

#485
post #371

Earlier quoted context omitted.

Serverless and microservices aren’t the same thing. You can deploy a monolith to lambda, and make a thousand small services on VMs or orchestration platforms. It’s purely a question of how to organise your code.

I'd say that is misleading at best. Lambdas are inherently unsuited for monoliths due to payload, RAM and execution time limits and cold start times. Lambdas are inherently suited to "real" micro-services, because by nature can only do 1 thing and have strict limits.

Depends entirely on workload - there's 3GB RAM available, which is more than what we use for normal monoliths on Heroku. Payload limits are 6MB or something, which isn't hit for a majority of sites on the internet (each request, not total page size). And there's nothing in the nature of Lambdas that force them to do only one thing. HTTP events can be fed through the normal router (lots of adapters for many web frameworks out there). Non-HTTP events can either go through a switch-case-board. There's no inherent "nature" to lambda, it'll execute whatever code you give it. There are limitations, but those are constantly changing.

Re: The Serverless Revolution Has Stalled

#486
post #478

I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can o…

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 spots just like everything else.

Re: The Serverless Revolution Has Stalled

#487

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…

I don't do any server admin. My code runs in docker on pretty much any server I can get my hands on. Some of my code runs on a ThinkPad stashed behind my desk, on DigitalOcean, on my Macbook. I could deploy to a Raspberry Pi and it would run just the same. It takes 10 minutes to deploy an exact copy to a new environment.

None of that requires OS maintenance. My house plants require far more maintenance than my software. I sometimes forget where some things run because I haven't touched them in years.

Serverless code runs on the cloud you built it for. I don't want that. I don't want to invest years of my life becoming an Amazon developer, writing Amazon code for Amazon servers.

That's without delving into the extra work serverless requires. There isn't a dollar amount tied to my import statements. I don't need software to help me graph and make sense of my infrastructure. I can run my code on my computer and debug it, even offline.

Re: The Serverless Revolution Has Stalled

#488

Here's why I love serverless. I cannot tell you the number of times I have implemented "upload your photo and it'll get resized to (profile avatar size from design specs)". It's ridiculous, and it's one of those things that everyone burns time implementing their fun hook into Imagemagick. Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done. I cannot tell you the number of ti…

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 maintain it.

Re: The Serverless Revolution Has Stalled

#489

Earlier quoted context omitted.

> Maintaining your own server is completely nuts I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sense. There are kernel people who maintain the kernel and there are Debian devs who maintain the operating system. The server may be mine (but more often that not, it isn't) but only in very specific circumstances do I ever concern myself with maintaining any part…

That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it g…

Because you can reproduce that environment locally. Often useful for fixing bugs.

Re: The Serverless Revolution Has Stalled

#490
post #171

Earlier quoted context omitted.

I'm not really interested in having the 1,000th discussion about the definition of "serverless". The parent was wondering what the value of the paradigm is, so I provided a list of specific features that many companies consider valuable with serverless offerings.

I hope this "risk aversion" mindset starts to apply to code as well. Can't wait for codeless, zero code, nocode, whatever name it gets called... something where normal people can build their own ideas without having meaningless discussion about tdd, frameworks and etc, nor the need to maintain codebases, ci/cd and all the jazz

It actually does:

"Low-code" is the buzzword to search for. It's been around a while now.

Of course like all the things the idea has existed a long time, but "low-code" development services seem to be increasingly popular and visible in the last couple of years, and they do seem to be getting more advanced and ergonomic.

Post reply on HN