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

711–720 of 733 posts

Re: Serverless: slower and more expensive

#711

Post by tracer4201 »

modoc wrote: post #607
tracer4201 wrote: post #431

Earlier quoted context omitted.

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, an…

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.

Re: Serverless: slower and more expensive

#712

Post by StellarTabi »

panpanna wrote: post #663
abiro wrote: post #639

Earlier quoted context omitted.

Think about serverless as framework-as-a-service. It has a learning curve, but if you buy in, it is an amazing productivity boost. (If Reddit’s video hosting being built and operated on a serverless stack by a single a engineer won’t convince you, I don’t know what will.)

If Reddit video is the poster child then serverless is in big trouble. That thing almost never works.

They've already ruined React!

Re: Serverless: slower and more expensive

#713

Post by danillonunes »

abiro wrote: post #539
unicornmama wrote: post #468

Earlier quoted context omitted.

The technology age isn’t the issue. The issue is how many projects have successfully deployed large scale reliable systems built with Lambda.

The internet is full of success stories if you care to look. My favorites: - iRobot (maker of Roomba) has been running its entire IoT stack serverless since 2016 (architect Ben Kehoe is a worthwhile follow on Twitter) - Reddit’s video hosting service is built and operated by a single engineer on a serverless stack

Reddit’s self hosted video is terrible. Using them to advocate serverless is like using Twitter on the fail whale days to advocate Rails.

Re: Serverless: slower and more expensive

#714

Post by jozzas »

VvR-Ox wrote: post #638
foxtr0t wrote: post #602

Earlier quoted context omitted.

So, to summarize, you should: 1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system 2. lock yourself into managed services wherever possible 3. choose your api design style based on your orchestration system instead of your application. 4. Use a specific frontend rpc library because why not. ... I've hacked a few lambdas toget…

That's so true and I'm happy people begin to realize that. The worst for me is the vendor lock in, directly followed by the costs.

There are some HUGE benefits to this type of architecture (services + lambda where required) for large corporations, the main one being an insane reduction in a bunch of worthless crap that you no longer have to do:

- OS version patching, patch windows & outages, change mgmt relating to patching and reporting relating to OS patching

- antivirus, the same patching management and reporting as above

- intrusion detection / protection, host based firewalls, the same patching and management as above

- Other agents (instance health monitoring, CMDB, ...)

- Putting all this junk on a clean OS image any time something changes, re-baking and regression testing everything

This all adds up, and can be a significant cost to an organisation - team(s), licenses, management, etc.

Re: Serverless: slower and more expensive

#715

Post by mathw »

jozzas wrote: post #714
VvR-Ox wrote: post #638

Earlier quoted context omitted.

That's so true and I'm happy people begin to realize that. The worst for me is the vendor lock in, directly followed by the costs.

There are some HUGE benefits to this type of architecture (services + lambda where required) for large corporations, the main one being an insane reduction in a bunch of worthless crap that you no longer have to do: - OS version patching, patch windows & outages, change mgmt relating to patching and reporting relating to OS patching - antivirus, the same patching management and reporting as above - intrusion detectio…

That's basically why we're doing it, and we're seeing some really good costing implications from implementing various things using Azure Functions. Not perfect, but an extremely capable system, and there are things some of our teams are doing with Durable Functions that I was completely stunned by when they explained how it all works. Microsoft have some very good technology there.

The only thing I'm sad about is that you can only host it on Azure. I'd love an open standard for function-like programming and hosting.

Of course, not everything is suitable for this model, and it certainly won't be the most cost-effective or performant way to do it for everything either.

Re: Serverless: slower and more expensive

#716

Post by pas »

scarface74 wrote: post #260
dragonwriter wrote: post #243

Earlier quoted context omitted.

> Heroku is not Serverless in the modern definition of the word Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.

Heroku is just an easier way to deploy to servers. It doesn’t scale down to zero, scale up as needed, etc. You still have distinct servers that you know about, can manage. S3, Fargate (Docker), DynamoDB, even SNS/SQS are considered Serverless by AWS’s nomenclature.

It doesn't scale to zero, but the article was about how much more it costs running only serverless 0-24, but how hard it is to fiddle with Linux/deployment/CNAMEs/etc. (Especially that they have constant load, 10+M req/day.)

And so it seems to miss the obvious middle ground between raw EC2 (or Elastic Beanstalk managed EC2) and full on-demand Lambda, which is modern managed hosting (PaaS, Deis/Dokku/Heroku).

Re: Serverless: slower and more expensive

#717

Post by jroper »

abiro wrote: 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…

Number 3 - thinking in events instead of REST actions, can't be stressed enough. Of course, some things must be actions (or another for that is commands), and in those situations, you need something that will turn a command into an event, this is one of the features of CloudState (https://cloudstate.io), which offers serverless event sourcing - you handle commands, and output events that can be further processed downstream by other functions.

Re: Serverless: slower and more expensive

#718

Post by wodenokoto »

abiro wrote: 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…

> Below is a report for one request, you can see we're using 3.50ms of compute time and being billed for 100ms, which seems like a big waste.

Doesn't sound like your point number 1 is valid at all, quite the opposite.

Re: Serverless: slower and more expensive

#719

Post by rumanator »

Bombthecat wrote: post #661
shangxiao wrote: post #633

Earlier quoted context omitted.

I feel like we're just transferring the labour from ops to dev though. Where I work we still haven't got as good a development workflow with lambdas as we did with our monolith (Django).

Paying one guy is cheaper than two. So... You are not wrong :)

> Paying one guy is cheaper than two.

Now that guy's workload doubled and needs another colleague to be able to deliver.

Re: Serverless: slower and more expensive

#720

Post by richmarr »

vkou wrote: post #545
richmarr wrote: post #451

Earlier quoted context omitted.

How would your hypothetical defence mechanism tell which C-suite initiatives are worthwhile, and which are ego driven make-work?

That's the thing. The two are indistinguishable, unless you give people with strong technical skills veto power on projects. If you don't work in such an environment, the only reason you haven't ran into a dangerous, idiot manager, is luck. For some reason, in most firms, the c-suite isn't super keen on delegating that power.

> The two are indistinguishable, unless...

So are they indistinguishable or not? Two things can't be a bit indistinguishable.

Post reply on HN