Live data from Hacker News

The Serverless Revolution Has Stalled

infoq.com

161–170 of 670 posts

Re: The Serverless Revolution Has Stalled

#161
I'm not sure about the hater-ade in this article (old, dead languages?). I've built infrastructure for multiple companies on top of AWS Lambda. Usually bog-standard REST endpoints in Node or Python. There are a few weird bits and a few "huhs" (DB connection timeouts after a Lambda wakes up from sleep) but that's true of most systems.

True, we were only doing a few req/s but Lambda was easy to setup/use and was mostly maintenance free. As is said so often on this site: it's a tool; use it for its intended purpose.

Our development environment was very reasonable: Express or Django locally; aws-lambda->Express/Django on the lambda.

Re: The Serverless Revolution Has Stalled

#163
post #144

Earlier quoted context omitted.

I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to t…

> I realized that local development was difficult because I was coupling my code to the delivery. Of interest, I've spent some free time crunching on CNCF survey data over the past few months. Some of the strongest correlations are between particular serverless offerings and particular delivery offerings. If you use Azure Functions then I know you are more likely to use Azure Devops than anything else. Same for Lambd…

I think his point was that you should be able to run and test the Lambda code independently of Lambda. After all the entry point is just a method with some parameters, you can replicate that locally.

Re: The Serverless Revolution Has Stalled

#164

Only tangentially related but why haven’t Unikernels become a thing? why does every container need a unix userland? Sure, I understand people need their libc but all the other bloat? Why?

Drivers are major pain with Unikernels - you basically need to rewrite all the drivers for your Unikernel; this gets especially painful with application accelerators and GPUs, since those cannot easily be replaced by virtual devices (like storage or networking).

More importantly, app development is way harder since you don't have all OS libraries available to you and cannot easily benefit from previous R&D and workflows.

You basically need to start from scratch or rewrite your app, which simply isn't always an option. There's currently no mature tooling that I'm aware of that would allow you to simply recompile existing apps to turn them into Unikernels (I just discovered Unikraft [1], but I cannot comment on whether it's any good). Edit: [1] http://www.unikraft.org

Debugging is a pain as well compared to more standard development.

Re: The Serverless Revolution Has Stalled

#165

Earlier quoted context omitted.

People on HN seems to believe that outside of Google it is impossible to have problems that are complex and high scale, therefor if you use microservices and/or serverless and/or nosql etc etc it's just that you're following the hype, not that you legitimately benefit from them.

I think people are jaded because a lot of these use cases stem from ignorance and/or incompetence of the underlying tech. The majority of people arguing the benefits of NoSQL aren’t professional DBA’s, they’re people that don’t know how to use EXPLAIN. The majority of people touting the “infinite scale” of serverless haven’t even benchmarked their server, never mind optimised it. Prove to me that what you’re trying t…

I think people simultaneously underestimate how many jobs out there are extremely low volume, and also underestimate how many are high volume. I'm in a data analytics space, every product in my space is talking about 10's or 100's of terabytes a day per customer, and running many different forms of analytics on that data as quickly as possible.

It's always so strange, being in this space where everyone is dealing with tons of data, and hearing constantly on HN about how "you don't need this level of scale unless you're Google".

Re: The Serverless Revolution Has Stalled

#167

Earlier quoted context omitted.

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to mak…

I never got the hand of cloud formation. I suppose it is nice from a visual (drag and drop) point of view, but I couldn't use it in production and moved on to manage my architecture with terraform.

I manage a handful of projects with Terraform and it works well in many situations. It has improved a lot recently but for a long time I really hated the syntax. I still do to some extent but have learned to cope with it most of the time.

If you are working on a project where all of your infrastructure will live on AWS I would definitely urge you to give it a second look. The amount of infrastructure I manage right now with a single .yaml file is really killer.

Re: The Serverless Revolution Has Stalled

#168
Kind of also surprised I think this author has not heard of Google Cloud Run (https://cloud.run/).

Cloud Run employs a vendor-neutral container runtime and API (from Knative open source project). It simply accepts any OCI container that can listen on $PORT number.

Similarly, the author talks about serverless not being able to run "entire applications", which again, doesn't apply to Cloud Run. Many people run fully-fledged .NET Core or Java apps on it with a single command to deploy.

Ditto for the author's "Limited Programming Languages" point, Cloud Run is container-based serverless runtime and it runs any language. Furthermore, you don't even have to write Dockerfiles anymore to build containers for plenty of languages thanks to Buildpacks https://github.com/GoogleCloudPlatform/buildpacks.

Furthermore, in my opinion, the serverless revolution is still going on with more services adding edge lambdas support or storage support for edge workers like Cloudflare did with Durable Objects Beta or Workers KV and there's definitely more to come.

Overall I'm not sure what the author was thinking while writing this. It seems they are aware of the intersection of containers & serverless and note that serverless is not just FaaS, but I note an intentional omission of many products that directly respond to his points in the article.

Disclaimer: I work on Cloud Run.

Re: The Serverless Revolution Has Stalled

#169
post #25

Kind 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…

we use the serverless framework and use

> serverless invoke local

All the time for doing testing. You can pass in a json file that contains a simulated event to test different scenarios. Works very well for us.

Re: The Serverless Revolution Has Stalled

#170

An interesting rant to be sure, but what the author misses (in my opinion of course) that serverless isn't new, it just isn't recognized by a lot of programmers for what it is. Serverless computing is exactly mainframe computing. And by exactly I mean exactly. You see when I was taking CS classes for my degree students bought something called "kilocoreseconds" (kCs) and they are exactly what they sound like, they are…

I generally agree that there is nothing new under the sun. But I also think history doesn't repeat, it rhymes.

> When to mainframes kind of suck? Well when you don't know whether or not you want to use them. ... Ending up, nearly exactly back where they started except that now one company owns a mainframe and dozens of companies use it to run their bits of code.

I think this reveals that there is an economic distinction between mainframes and serverless, along two fronts: size of commitment and economies of scale. Mainframe time could be extremely precisely subdivided when billing users, but the capital cost of getting to the first kilosecond was extremely high. In serverless settings the capital cost for the first unit of consumption is experienced as zero by everyone except the vendor.

(Yes, IBM runs mainframes-as-a-service, but they don't do it on the cheap).

The second difference is that the hyperscalers enjoy economies of scale and scope that no other organizations can match, including mainframe operations. If IBM is choosing between two different parts for a mainframe, they can pick the more expensive part and foist most of the cost onto their buyers, for whom there is little alternative. Meanwhile, for the hyperscalers, customers are much more price sensitive. More expense falls to their bottom line. But because they operate at such high scale, even tiny improvements are rational to pursue.

Similarly, economies of scope come from the fact that they can pool much larger amounts of variance, which makes their workloads more predictable overall than any smaller organisation can achieve. This is just the central limit theorem mercilessly steamrolling noise into smooth, predictable shapes.

But at least no punched cards.

Post reply on HN