Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

31–40 of 670 posts

Re: The Serverless Revolution Has Stalled

#31

Has the noisy neighbor been solved when running serverless?

On Azure, I haven't really seen this problem. But you can also pay for dedicated serverless via Premium (but you pay per core/mem allocated vs. number of executions). It seems pretty interesting since multiple function apps can share the same infrastructure (allowing for more dense deployments).

Re: The Serverless Revolution Has Stalled

#32
Caching is another big one. Beyond the simplest of services you typically need to cache some info in memory, create connection pools, etc at startup to improve latencies. With serverless that is not possible without killing your cold start time. So it's hard to go serverless except for the simplest of applications.

Re: The Serverless Revolution Has Stalled

#33
I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to throw more resources at a specific part of the whole.

Second - with each cloud provider's serverless service, I've noticed that the underlying complexity is shifted into your application and provisioning. They're a great example of leaky abstractions. The name 'serverless' may lure you into thinking that you don't need to think about servers any more, but actually you do have to adjust to the way they've implemented a service that you're using. Think of Lambda cold starts, or have a look at the DynamoDB pricing page. There's still a server running somewhere.

Personal experience: I've found that ECS (Fargate) is a decent step into the serverless realm, if you've been running normal containers on normal EC2s. It does take away the EC2 management aspects, and it's especially useful if you have some applications that are resource hungry, and some are not. It's a cheap way to run ETLs (we use the ECS Operator from Apache Airflow, which itself is on EC2). It doesn't take long to learn, and it's a good place to start. It does come with its own baggage... the 'stack' that you had on a single EC2 is now scattered about; you may need AWS Cloud Map for service discovery, ALBs for networking, SSM/KMS for secrets, Cloudwatch for logging.

That's when you realize, those sticker infested laptops at Devops conferences are actually modern architecture diagrams.

Re: The Serverless Revolution Has Stalled

#34
Most of these seem like fairly weak reasons at this point.

Some degree of vendor lock-in is pretty much inevitable no matter what solution you go with.

Limited programming languages may have been an issue a few years ago, but with the support of Java, Go, Python, Javascript to name a few - most of the core user bases are covered.

Additionally, after the introduction of API gateway, most CRUD applications, including those that require async tasks, can be served by the lambda and serverless.

After having used serverless for a while, the biggest turn off for using it (still) seems to be the performance issues. Provisioned concurrency, i.e leaving function containers running, is really just a bandaid and runs counter-intuitive to the original motivation of serverless to begin with.

Re: The Serverless Revolution Has Stalled

#35
post #5

Serverless is the new microservice. Fortunately, for the most part it’s fallen flat on its face and for good reason - most companies don’t need it: it adds unnecessary complexity for minimal gains.

Except that people actually used microservices and microservices are actually additive and helpful.

They are helpful in probably 10% of cases where they are indeed the right tool for the job and the benefits outweigh the downsides.

For the majority of companies out there it's just a tool to overcomplicate your stack and turn it into an engineering playground so you can justify 2-3x the headcount despite no significant productivity increase. But hey, at least your company can now be giving talks about how they solve their (self-inflicted) problems managing all the microservices and throw that buzzword on the careers page.

Re: The Serverless Revolution Has Stalled

#36
post #7

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these e…

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 receive a webhook a few times a day and send a Slack message to your team? Perfect.

Not the core of your app, but a tool of great utility. On the other hand, this isn't exactly the Serverless Revolution either.

Re: The Serverless Revolution Has Stalled

#37
post #7

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these e…

To be honest, the serverless environments I dealt with had worse deploy experience than plain servers. There's a bit of a ritual around deploying a lambda for example and it requires a specific packaging process. I can't easily use poetry for python projects there.

I guess if we count fargate as serverless, it's much better for this use case.

Re: The Serverless Revolution Has Stalled

#38

Earlier quoted context omitted.

Part of the problem is that the hobbyist market is overwhelmingly PHP, which Lambda doesn't support natively.

I’d be curious to see the data behind that claim that the hobbyist market is overwhelmingly PHP. I must not have any exposure to that ecosystem because PHP does not come to mind when I think of hobbyist development.

Maybe not hobbyists, but wordpress alone powers like a a third of the web.

Re: The Serverless Revolution Has Stalled

#39
Serverless just moves complexity around and makes some things a bit more awkward, like debugging and logging. You have to be all in on the platform. I’ve just taken over a serverless app after the lead left and there are so many moving parts to make it all work.

Not yet a fan.

Re: The Serverless Revolution Has Stalled

#40
post #7

I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these e…

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…

This is why Serverless will be huge in enterprise IT. You just described 90% of workloads.
Post reply on HN