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

681–690 of 733 posts

Re: Serverless: slower and more expensive

#681

Post by akoumis »

drieddust wrote: post #671
akoumis wrote: post #637

Earlier quoted context omitted.

I worked on a service a year ago that would stream a video from a source and upload it to a video hosting service. A few concurrent transfers would saturate the NIC. Putting each transfer job in a separate lambda allowed running any number of them in parallel, much faster than queuing up jobs on standalone instances

Yes but running multiple lambda jobs in parallel would still add upto more time than 12 minutes. What am I missing?

If I was running 10,000 transfer jobs in parallel and the longest of them took 12 minutes, the job would take 12 minutes

Re: Serverless: slower and more expensive

#682

Post by akoumis »

ses1984 wrote: post #668
akoumis wrote: post #637

Earlier quoted context omitted.

I worked on a service a year ago that would stream a video from a source and upload it to a video hosting service. A few concurrent transfers would saturate the NIC. Putting each transfer job in a separate lambda allowed running any number of them in parallel, much faster than queuing up jobs on standalone instances

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

Re: Serverless: slower and more expensive

#683

Post by weberc2 »

foxtr0t wrote: post #679
hallman76 wrote: post #677

Earlier quoted context omitted.

We developed a web-based tool that described water quality based on your location. We generated screenshots of every outcome so the results could be shared to FB/titter. It was something on the order of 40k screenshots. Our process used headless chrome to generate a screenshot then it was uploaded to S3 for hosting. Doing that in a series took forever. It took something like 14 hours to generate the screenshots, then…

The parallelism argument doesn’t pass muster because you can do the same thing with a cluster of free tier t2.micro machines with any good orchestration platform, not just lambda. This argument is basically: no counterpoint to the original post, but you can do things that are also easy on any other comparable platform. Tell me again what I don’t understand?

> Tell me again what I don’t understand?

As someone who has done both, it's far, far easier to stand up a lambda than it is to manage a cluster of servers.

Re: Serverless: slower and more expensive

#684

Post by Bartweiss »

karlmdavis wrote: post #678
jbverschoor wrote: post #646

Earlier quoted context omitted.

20 years ago. We had enterprise java, it’s still “there”, but running spring is very different from what it used to be. You’d simply upload an ear or ear and the server and deployed would handle configuration like db etc. It worked perfectly (ear/war, the persistence framework was too verbose and high level imo, but that was replaced by hibernate/jpa). There was too much configuration in xml, but that could easily be…

> Again.. we are running in circles, and this industry will never learn, because most “senior” people haven’t been around long enough. And that likely won't change in our lifetime, given the rate of growth in demand for software: we literally can't create senior engineers fast enough for there to be enough to go around. As an aside, I have the privilege of working with a couple of senior folks right now in my current…

The percentage of seasoned engineers is so low that 'senior' as a title often seems to stretch to "whoever is most experienced around here". That's probably fine, since people understand that experience is not reducible to that title. But this does bring to mind a metric for finding "objectively" senior engineers:

What's the biggest idea you've seen abandoned and then reinvented with a new name?

Re: Serverless: slower and more expensive

#685

Post by dlanouette »

frenchman99 wrote: post #289
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…

I can't support point 7. enough. People often forget about the cost of labor. We migrated our company webapp to Heroku last year. We pay about 8 times what a dedicated server would cost, even though a dedicated server would do the job just fine. And often times, people tell me "Heroku is so expensive, why don't you do it yourself? Why pay twice the price of AWS for a VM?" But the Heroku servers are auto-patched, I ge…

I'm curious. Did you look into Googles AppEngine? It seems to have a lot of the benefits that Heroku offers, but is much cheaper.

Granted that it does impose some limitations, and therefore isn't right for all apps. But it does seem like it would work for a large percentage of web apps and REST api's.

Re: Serverless: slower and more expensive

#686

Post by ownagefool »

matchagaucho wrote: post #475
ownagefool wrote: post #469

Earlier quoted context omitted.

Those SRE infra skills pretty much crossover with knowing what your app is doing in FaaS environment. How do you know those async requests are completing? What's the percentage of failures? Are you meeting those SLAs? Who's patching the code? How do you test and deploy new versions? Those are all typically seen as ops tasks, now you're doing them. Small bit of concern around you saying you're using the console, becau…

AWS Cloudwatch pretty much delivers every metric imaginable. Whether leasing EC2 servers or running serverless Lambdas, the logs all rollup to the same place. We're gradually using more AWS CLI for things like deployment and policy management. But the console is sufficient for 80% of Serverless DevOps.

Getting metrics into the system is only half the battle; using them is arguably more important and complicated half.

And well, I mean if all your guys are just trusted to directly use the CLI or Console, then what you doing for governance and insider threats? Using logs? Blind trust?

As I said, how you're doing things might be fine for your risk profile, but probably not when you could suffer a $1m GDPR penalty, and actually, more than just the money, the ethical issue of fucking over your users matters to some of us.

Not having a go, just saying there are reasons people use terraform, stick it in gitlab, and use CI/CD. You might be too small for that, or you might not have the data, but we aren't doing it for fun :p

Re: Serverless: slower and more expensive

#687

Post by _ivvf »

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…

I measured startup of the runtimes a long time ago, and back in the days of node.js 010.x at least, Python 2's startup time was twice as fast as Node.js's, and Java's wasn't much worse than Node.js. I don't know how .NET fares compared to Java, but I imagine it's about the same.

Furthermore, eople like to compare runtime startup times, but this tells a very small portion of the story. For most applications, the dominant startup cost isn't the startup of the runtime itself, but the cost of loading code the app code into the runtime. Your node.js runtime has to load, parse, compile, and execute every single line of code used in your app, for instance, including all third-party dependencies.

Compare, for instance, the startup cost of a "hello world" node.js function with one that includes the AWS SDK. At least, six years ago, the Node.js AWS SDK wasn't optimized at all for startup and it caused a huge (10x?) spike in startup time because it loaded the entire library.

I would argue that the only languages that are a really good fit for Lambda are ones that compile to native code, like GoLang, Rust, and C/C++. The cost to load code for these applications is a single mmap() call by the OS per binary and shared library, followed by the time to actually load the bytes from disk. It doesn't get much faster than that.

Once you've switched to native code, your next problem is that Lambda has to download your code zip file as part of startup. I don't know how good Lambda has gotten at speeding that part up.

Re: Serverless: slower and more expensive

#688

Post by dlanouette »

foxtr0t wrote: post #602
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…

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…

I think the comment is exactly opposite of what you are suggesting.

The comment is saying that Lambda has limitations and works best when considering those limitations. If those limitations don't fit your use case, you shouldn't be using Lambdas - or, at least, don't expect it to be an optimal solution.

Re: Serverless: slower and more expensive

#689

Post by Bartweiss »

shangxiao wrote: post #633
Bombthecat wrote: post #626

Earlier quoted context omitted.

You are not wrong. But it is all about saving money on labor. The rest are just the constraints of the system you use. (Aka requirements) its like complaining about the need to use posix for Linux.

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

I think you're right about this.

Optimistically, it could represent a positive trade-off that replaces perpetual upkeep with upfront effort, and all-hours patching and on-call with 9-5 coding.

In practice, I think a lot of those fixed costs get paid too often to ever come out ahead, especially since ops effort is often per-server or per-cluster. The added dev effort is probably a fixed or scaling cost per feature, and if code changes fast enough then a slower development workflow is a far bigger cost than trickier upkeep.

Moving off-hours work into predictable, on-hours work is an improvement even at equal times, but I'm not sure how much it actually happens. Outages still happen, and I'm not sure serverless saves much less out-of-hours ops time compared to something like Kubernetes.

Re: Serverless: slower and more expensive

#690

Post by sideral »

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.

Salesforce has stock in many companies through Salesforce Ventures, including Optimizely, Twilio, Box, Dropbox and Stripe.
Post reply on HN