Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

551–560 of 733 posts

Re: Serverless: slower and more expensive

#551

Post by anderspitman »

com2kid wrote: post #526
anderspitman wrote: post #517

Earlier quoted context omitted.

Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?

> Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit? Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month. As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test. My long running and CPU intensive stuff is running on a VM of course. I'm sure if I had spe…

Only 2 endpoints per month? What exactly are you comparing to that doing it twice a month would waste way more time adding an endpoint vs serverless?

Re: Serverless: slower and more expensive

#552

Post by [deleted] »

mrich wrote: post #550

The AWS bill seems high already. $90 dollars for m1.small, which has 1 vcpu and less than 2GB memory? At my current hosting provider that machine costs less than 5euro! What am I missing? Looking at the hourly usage it seems to be the equivalent of 3 machines running 24/7, so 15 euro, but still?

[deleted]

Re: Serverless: slower and more expensive

#553

Post by milesward »

michaelmrose wrote: post #534
munns wrote: post #511

Earlier quoted context omitted.

Miles and I know each other, what's wrong with a friendly hug? Do you need a hug hesburg?

I recall a certain uptight code of conduct which explicitly forbids unasked for virtual hugs.

Yah, but I know him and we hug.

Re: Serverless: slower and more expensive

#554

Post by com2kid »

learc83 wrote: post #546
com2kid wrote: post #526

Earlier quoted context omitted.

> Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit? Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month. As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test. My long running and CPU intensive stuff is running on a VM of course. I'm sure if I had spe…

Almost anything you were competent in would let you write and deploy and endpoint in half an hour (particularly in the early stages of app development), so I'm not sure that this is positive for serverless.

The amount of infrastructure I have to setup/maintain to do all of that is, well, nothing.

That is where the mental savings comes in.

When I first started, I went from "never wrote an HTTP endpoint" to "wrote a secured HTTP endpoint that connects to my DB" in under 20 minutes.

There is nothing for me to maintain. Setting up a new environment is a single CLI command. No futzing with build scripts. Everything will work and keep working pretty much forever, without me needing to touch it.

The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.

(As an example, trying to tell my mobile app's build system that I want a build with production code but pointed at my test environment? Hah! Good luck, the build system is hard coded to only have the concept of dev/prod! I've had enough of that.)

It is frustrations like that Serverless solves.

Re: Serverless: slower and more expensive

#555

Post by acd »

In AWS it is better to use Fargate. You can use standard docker containers with Fargate, you do not need to baby sit and patch servers. Fargate has warm caches in comparison to Lambda. Also it is easier to version control a docker container vs serverless functions. Plus if you do not like Fargate you can move, if you have written everything in proprietary Lambda code you are locked in.

Performance comparison between Fargate and Lambda. AWS Fargate Deep Dive https://www.learnaws.org/2019/09/14/deep-dive-aws-fargate/

Re: Serverless: slower and more expensive

#556

Post by com2kid »

anderspitman wrote: post #551
com2kid wrote: post #526

Earlier quoted context omitted.

> Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit? Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month. As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test. My long running and CPU intensive stuff is running on a VM of course. I'm sure if I had spe…

Only 2 endpoints per month? What exactly are you comparing to that doing it twice a month would waste way more time adding an endpoint vs serverless?

With Firebase if I need a new env I just type 1 command and get it.

With VMs I have the joy of managing my own keys.

VMs need security patches, updates, and I have to maintain images. I have to think.

It is hard to explain how simple firebase functions are.

There is literally no mental overhead. There is no worrying. There is nothing to maintain or think about, no settings up quotas or managing what machine something is running on or getting user auth setup. No certs that can expire or daemons that can crash.

I can come back 2 months later and count on everything I setup functioning just as I left it.

Some months I wrote a bunch of endpoints, I average 2 a month maybe, but if I am adding a new feature, I can pop out 3 or 4 a day, and then go on my way and work with the front end again.

Getting debugging up and running for them can be interesting (painful and bad), but everything else is just smooth.

I don't want to maintain a bunch of infrastructure, I want my users to ask for some data and get some data back.

If someone is doing non-trivial processing, serverless is probably not for them. But I have a bunch of 20-50 line functions that are all independent of each other and have 0 state.

I realize I'm paying a premium, but it is worth it to have this stuff that just works.

Re: Serverless: slower and more expensive

#557

Post by anderspitman »

redisman wrote: post #509
Illniyar wrote: post #381

Earlier quoted context omitted.

Firebase now makes most of these painless. They've done a really good job. If your starting from the grounds up and can stomach using a google product Firebase is the easiest to work with by far.

Do you have some more to read about that? Sounds interesting but I'm now confused as to what FireBase is/does.

Firebase does a lot of stuff. Originally it was a small company that focused on providing a real-time JSON-like backend store for web apps. But then they got bought by Google and seem to have evolved into Google's answer to a lot of AWS services, ie hosting, real-time DB, serverless, and probably more I'm not aware of.

Re: Serverless: slower and more expensive

#558

Post by anderspitman »

wolco wrote: post #346
holografix wrote: post #48

Disclaimer: I work for Salesforce, Heroku’s parent organisation. I have had so many conversations with devops managers and developers who are individual contributors and the Lambda hype reached frothing levels at one point. Contradictory requirements of scale down to zero, scale up infinitely with no cold starts, be cheap and no vendor lock in seemed to all be solved at the same time by Lambda. Testability? Framework…

Heroku is owned by salesforce? You learn something everyday.

Yeah I actually didn't know that either. Interesting

Re: Serverless: slower and more expensive

#560

Post by anderspitman »

I would be interested to see the latency averaged over all their requests, not just a few test runs from Iceland. Surely for many of their customers Lambda would be faster than wherever the closest EC2 instance happens to be running.

My personal default is to control as much of my infrastructure myself as possible, but at a certain point the edge model can have some huge benefits. Same reason I use a CDN even though it introduces another point of failure.

Post reply on HN