Ask HN: Skeptical about my company going “full serverless”. What am I missing?

I have a hard time believing serveless will be cost effective as a full replacement for a high traffic webapp. Higher ups do care about costs, so you should encourage some due diligence on pricing.

Was going to comment this same thing. We've been finding that the cold-start times are somewhat worse, but not disastrously so.

There are quite a few benefits you can gain from moving to serverless and some trade-offs. Rearchitecting your app is generally a pretty severe way to achieve a goal and means you've had an issue recently that you need to solve or a company wide initiative to mitigate a specific risk, The best way to play this is usually to look at it from an opportunity cost perspective.

Some of the possible reasons why you'd go down this path would include 1. Cost optimisation, generally not a good driver unless you have very spikey workloads (which you don't) 2. Resilience/availability, this is a pretty good driver especially if you've had issues recently, moving to serverless takes away almost all maintenance tasks and solves a lot of potential problems

Some of the main trade-offs include 1. Developer velocity, generally it's pretty hard to debug locally which you will need to spend time working out how to do it or do your debugging in the cloud 2. Cold start ups, this can be largely solved with solutions such as GraalVM however you do need to invest time to implement these solutions 3. More complex internal application architecture, you need to either deploy your entire application as a single function or break it out into multiple and you'd need to do the analysis of how it should work and the performance tuning of each option

That being said, I find the best way to look at these situations from a political perspective is to have a quick chat with the architect and look to understand what problem he's trying to solve and for you to mention your costs and take it into a cost/benefit discussion

If he says its for cost benefits, you could say it will be a x week migration timeline, which has a developer salary cost of y and delay a new feature which is expected to bring z revenue, 10-20% operational delay to pushing out new features. So what would be the cost saving total and ROI?

We use Lambda to handle lots of scale-out tasks & extensions to AWS services too - it works really well for this.

For example:

- resizing images - we can do a size per lambda all in parallel. This means we can process images quickly (with minimal latency) without having to have loads of slack memory & CPU on our backends

- queue processing - we have an app that needs to copy files from user provided URLs to S3. We do this by dumping them in a SQS queue and having a lambda fire for each queue item. Means we can do lots in parallel without filling up an EC2/fargate instance’s network port

- dynamically processing images using Lambda@Edge & Cloudfront - similar to my first one, but on the fly when requested, instead of ahead of time

Goodbye to local development experience. New architect hire suggesting big changes does not have anything else to do to justify their excistence.

Some Async use cases is great but large scale apps becomes clusterfuck. Experience: we made a whole feature on AWS lambda. Sucked. 2 years later its a spring app in a container now.