Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

721–730 of 733 posts

Re: Serverless: slower and more expensive

#721
post #50

PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…

> The only valid options for performance sensitive functions are JS, Python and Go.

I can think of a number of other languages that would probably easily surpass these, especially on latency.

Re: Serverless: slower and more expensive

#722

Earlier quoted context omitted.

If you throw more resources at a bottlenecked problem, it will go faster.

Right, but without the lambda infrastructure it would be infeasible from infrastructure and cost perspective to spin up, let’s say 10,000 instances, complete a 10 minute job on each of them, and then turn them off to save money, on a regular basis

Isn't that also possible with EC2? Just set the startup script to something that installs your software (or build an AMI with it). Dump videos to be processed into SQS, have your software pull videos from that.

You'd need some logic to shut down the instances once it's done, but the simplest logic would be to have the software do a self-destruct on the EC2 VM if it's unable to pull a video to process for X time, where X is something sensible like 5 minutes.

Re: Serverless: slower and more expensive

#723

Earlier quoted context omitted.

I think the point is, with your Django approach, you'll be stuck doing ops work 9-5 once you start getting customers, whereas with serverless you can spend the time to do more feature dev work.

Not quite sure about that, nowadays I require a couple of 20 bucks/month servers to have one CI/staging and one training/production deployments. I'm at the point where I practice CD as in "deploy each git-push to branchname.ci.example.com and run cypress on it" and still am able to deliver in half a day what the customer would expect to happen in two weeks. And of course, baremetal provides a much better ROI than VMs…

You seem to have gotten your deployments down and I really think that's good. In my own experience, though, managing your own infra always works well until it doesn't anymore. And when it stops working well, it crashes and burns and sucks up all the time. Going with managed services like serverless helps to get around that.

Re: Serverless: slower and more expensive

#724

Earlier quoted context omitted.

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.)

Re: Serverless: slower and more expensive

#725

Earlier quoted context omitted.

That's a fair observation. I do go back and forth but in the end it's enough to swing me, in the principle-of-least-regret way.

So what do you use as the backend for now?

I usually go with a Django or RoR monolith, something that I know I can run on a cheap DO droplet or similar, and while there's a fixed monthly cost it's reasonable and I can scale up with ease (albeit manually). If I were explicitly needing the realtime DB aspect I'd probably look to Phoenix with the same hardware approach.

Re: Serverless: slower and more expensive

#726

Earlier quoted context omitted.

That first link makes no sense. The C# is not reflective us my real-world usage in the slightest bit. The 2nd link is more accurate to my experience, and obviously contradicts the first link. I haven't tested the new VPC stuff yet to know what the impact is. https://aws.amazon.com/blogs/compute/announcing-improved-vpc...

> That first link makes no sense. The C# is not reflective us my real-world usage in the slightest bit. The 2nd link is more accurate to my experience, and obviously contradicts the first link. They don't contradict each other. They're different graphs demonstrating different workloads. You'd be surprised just how much peoples "real-world usage" can vary from one customer to another. > I haven't tested the new VPC st…

His blog post is updated. Now it looks correct.

Re: Serverless: slower and more expensive

#727

A $10 VPS would've been enough to handle the kind of load his site sees too, which is about 15x cheaper again than AWS. If you're really looking to save money, don't touch AWS. Source: I run the frontend for an interactive "one-page-app" site about 3x larger on a $30 VPS with room to spare.

Which VPS provider do you use and what is your backend stack?

The frontend is a ~$30 bucks VPS with OVH. This thing serves about 2 million users / month and about 20k concurrent users (with persistent websocket connections etc.).

The backend is:

- $10 VPS with OVH + $10 VPS as a fallback with another provider for my DB. - $5 VPS with OVH to host my central debian package repository.

- About $500 worth of dedicated servers for serving hundreds of TB of files a month (usually below one petabyte though). This is not really relevant to this discussion, because OPs application doesn't have a file serving aspect to it. His application is basically just my frontend and a DB.

- Small files and thumbnails go through cloudflare for another $20 / month. But the main site and most files don't use cloudflare (they'd kick me out if I passed that kind of traffic through them). They serve about 30TB-70TB of traffic a month on my account.

Re: Serverless: slower and more expensive

#728

Earlier quoted context omitted.

fair question... $500k in measurable lowered AWS spend(cancelled RI's and end of term and never renewed). if i figured in salaries and was fair about it, id say about 80% of that was actual savings, 20% was related to costs involved with rewriting or porting code. i wouldn't count the costs of new features into that as that is still forward progress, just writing in Lambda rather then for life on a traditional web se…

Man, that makes no sense to me if it's just aws cost -- very basic back of the envelop calculating assuming you had $500k to spend per year on cpus on aws: A c5d.2xl (8 cores) on aws is about $1875 per year reserved, $500k per year would buy you over 2100 cores; if you only did 100 req/s per core, you'd be able to handle something like 213k req/s average. Just the alb costs on lambda at this request rate would cost y…

I'll color the picture in a little more, maybe that will help make sense of it.

We have a unique workload that includes very large bursts of work that need to be worked on ASAP. Spinning up instances on demand is not fast enough, so we had a lot of servers sitting idle. Lambda allows us to execute this same work for much cheaper because we aren't paying for idle CPUs. Lambda also allows us to execute at much higher concurrency than ec2 would, for the cost. 15000 Threads spread across 100's of IPs is easy and cheap on lambda, not so much on EC2.

We went from ~250 customers per cluster(our term for a set of dedicated workload servers) to 2600(haven't pushed it past there yet). The work that was done on those instances is slowly being moved to Lambda and all new work/features are added to Lambda directly. This has effectively allowed us to drop a few clusters and also move to lower resources per instance.

FWIW we don't use ELB for Lambda, they come in via API Gateway, to Lambda/Step Functions directly or into an SQS queue in the case of workloads that have rate limits. For Lambda based workloads it breaks down something like 56% of cost is Lambda, 34% of cost is Step Functions and 9% is API Gateway.

Re: Serverless: slower and more expensive

#729

Earlier quoted context omitted.

Man, that makes no sense to me if it's just aws cost -- very basic back of the envelop calculating assuming you had $500k to spend per year on cpus on aws: A c5d.2xl (8 cores) on aws is about $1875 per year reserved, $500k per year would buy you over 2100 cores; if you only did 100 req/s per core, you'd be able to handle something like 213k req/s average. Just the alb costs on lambda at this request rate would cost y…

I'll color the picture in a little more, maybe that will help make sense of it. We have a unique workload that includes very large bursts of work that need to be worked on ASAP. Spinning up instances on demand is not fast enough, so we had a lot of servers sitting idle. Lambda allows us to execute this same work for much cheaper because we aren't paying for idle CPUs. Lambda also allows us to execute at much higher c…

Yeah, cool, so very unique workload - I'm not surprised there are apps that fit lambda in a cost effective way, they're just not typical I think.

Thanks for the explanation ;)

Re: Serverless: slower and more expensive

#730
post #441

Earlier quoted context omitted.

That's not what I've understood "stateless" to mean. Sure, anything more complicated than a calculator app is going to rely on data stored elsewhere, and in Lambda world that means you're reading from DynamoDB, S3, RDS or whatever. Those are definitely dependencies and that's where the state lies. But the pattern encouraged by Lambda is that your instance contains no state of its own. The disk is used as scratch for…

I see your point, but this definition is so lax that it applies almost perfectly to any application I've ever deployed to the cloud. Using external services to save state isn't unique to lambda, any app hosted on a normal ec2 instance needs to follow the same pattern because the instance and its filesystem can go away at any time (unless you attach a volume, but I've always considered that to be bad practice).

Sure, it's a common pattern and the right one in many scenarios. But especially for non-cloud deployments it's very common to store session data in process memory or temp data to local disk, etc.
Post reply on HN