Hacker News Reader

> Lambda seems to be a fast prototyping tool.

My thoughts EXACTLY. The great power in "serverless" architecture (i.e. AWS Lambda + AWS RDS + AWS Gateway) is how it empowers prototyping a new product.

Counterintuitively, it's future-proofing. You should know in advance that it's too slow & expensive. But you get to spin up a prototype backend very rapidly, pay only for what you're using while prototyping, and Lambda's inherent limitations force devs to build modularly, start simple, & stay focused on the product's main goals.

When the time comes to need scale, either at launch or even later when user count goes up, your "serverless" backend can be relatively easily replaced with servers. Then, just like that, in response to scale need your product's costs and response time go down instead of up.

It's a nice way to build a software product: rapid prototyping plus easy future cost decreases built-in.

The problem is mainly that people think "Cool I can build everything with FaaS and it will be cheaper and scale well"

Which is wrong and can be attributed to bad serverless evangelism in the past.

Serverless is building your system with managed services and only drop-in a FaaS here and there when you need some special custom behavior.

See how far you come with AppSync, Firestore or FaunaDB. Throw in 0Auth or Cognito and then when you hit a wall, make it work with FaaS.

I don't understand the prototyping angle.

Can't you just do something on your local machine?

There's stuff like dotnet new for .NET where I can just run that and have a skeleton project for a backend and I can start writing code immediately. I assume there's template creators for other languages as well.

My use case was a prototype for an iOS app I had in beta testing. It had a tiny but globally distributed user base, and serverless was a fun thing to learn on top of being relatively quick to set up. I'm sure if I had wanted to, some dynamic DNS and a small machine in my house would've sufficed. But hey--that's future decreases in cost. :)

If you're doing a prototype, wouldn't firebase or AWS AppSync be better options? You're going to lose a lot of time dealing with devops tasks (setting up IAM accounts, configuring storage services, etc.)

It's the same argument for Python over C development. Prototype in python and migrate portions to C as performance is needed. You'll often find that large portions of your codebase will never need to migrate out of the "prototype" stage.

For me, the absolute best use cases for serverless is for really infrequent, small tasks.

For example, I have a few data scrapers written in JavaScript but my regular stack is lamp.

So I don't have any need to run a node server 24x7 just for those once a day tasks.

But I have even found myself not needing serverless for that because everything is running in a kubernetes cluster. So I can just setup a cron to run them which launches the needed node containers.

So I guess in effect, I am just using a sort of self-managed "serverless".

> ... Me thinking: Uhh, start small and STAY SMALL?

This does happen. We have a serverless API forwarding service on Azure that was designed to simply format and forward calls from a vendor. We know the volume, there will not be any surprises, and it is immensely profitable over the old solution to the tune of thousands of dollars per day. Our use case is probably pretty uncommon, however.

It's a good sign that people who only talk about FaaS when they say "serverless" didn't understand serverless at all. And I see this as a failure on the serverless proponents side.

The serverless proponents are selling their paradigm as simple solution, which leads many people to believe simple means FaaS.

Throwing Lambda on all backend problems is a setup for failure. Often transfer and simple transform of data can be done serverless without a Lambda, which cuts costs AND leads to better performance.

The keep alive is still practically scale down to zero, you’re paying for 100ms every 5 minutes.

I’d be curious about how much memory/cpu was allocated in your experience and the OPs, there’s nothing magical about lambda to make it slow.

Keeping all of your feedback to yourself sounds like a great way to maintain a bias.

Keep-Alive daemon doesn’t work during scale up. If you go from 1 simultaneous request to 3, it will have to slowly spin up those 2 lambda’s in response to a user a request.

It’s useful for services which fit its design: using an extremely heavy environment like Java will rarely be a good fit but for even Python/Node it works much better, without even considering things like Go/Rust.

Your “thoughts” are applying his solution to the wrong problem. “Start small and stay small” I’m not sure what that even means. Are you saying every service has to grow to some size or required amount of compute? LOL

The 100ms extra time is nothing. I mean - are you trying to solve at Google or Amazon scale?

I run simple Lambdas that read from some SNS topics, apply some transforms and add metadata to the message, and route it somewhere else. I get bursts of traffic at specific peak times. That’s the use case and it works well. The annoying part is Cloud Formation templates but that’s another topic.

100ms of unneeded latency IS NOT nothing (except for some limited use cases). Anything user facing shouldn't be slower than it needs to be.

You’re making some bizarre assumptions. Not everything is front end user facing.

Let’s say I’m processing messages off a queue. P90 @ 50ms vs p90 at 100ms doesn’t necessarily make a difference. What are my downstream dependencies? What difference does it make to them?

At the end of the day, value is what you care about - not necessarily chasing a metric because lower is absolutely better. What’s the cost of another x milliseconds of latency considering other trade offs (on going operational burden, extensibility, simplicity, scalability, ease of support etc etc).

If 50 ms latency means I can have a solution that can auto scale to massive spikes in traffic due to seasonality or time of day vs a reduction of that latency but I have to spend time capacity planning hardware and potentially holding extra capacity “just in case”, then again, optimizing for a single metric is pointless.