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

591–600 of 733 posts

Re: Serverless: slower and more expensive

#591

Post by matchagaucho »

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…

RE: #3. This still requires a Lambda to pre-sign the URL. No?

Granted, this approach is much lighter than uploading an image directly.

Re: Serverless: slower and more expensive

#592

Post by jacques_chester »

tedk-42 wrote: post #153
skrebbel wrote: post #129

Earlier quoted context omitted.

> I'm in the container camp Can anyone explain to me why there's "camps" to this debate?

I'd say modern API deployments are either containerised or go the serverless route. On one hand you have a docker image with your source code/static binary baked in. The other you have your source code/binary encapsulated in a serverless framework (with an Event handler of sorts as your input). The container doesn't lock you into a particular ecosystem, but hasn't solved how you deploy and run your container (Heroku,…

Heroku gives you a runtime environment also, using Buildpacks. In that respect it's already "Serverless".

Re: Serverless: slower and more expensive

#593

Post by microcolonel »

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…

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

I always sorta assumed that Amazon pre-initialized runtimes and processes and started the lambdas from essentially a core dump. Is there some reason they don't do this, aside from laziness and a desire to bill you for the time spent starting a JVM or CLR? Does anyone else do this?

Re: Serverless: slower and more expensive

#594

Post by myrryr »

overgard wrote: post #564
missosoup wrote: post #120

Earlier quoted context omitted.

> going all in on serverless will let you deliver better products faster Can you show some empirical evidence that supports this? In my experience this is another nebulous serverless hype claim that doesn't withstand scrutiny.

Is there really that much hype? I feel like I haven't heard that much. Serverless isn't even really much of a new thing, there have always been providers that hid the underlying aspects of running a web site on the internet. I think for most people they just don't want to have to worry about patching a machine, rolling logs, watching disk space, etc, if they don't need to.

We tried to go down the serverless path, but it took WAY more dev resources than using ec2.

It is not at all obvious what it just can't be used for. In our case, Julia.

Re: Serverless: slower and more expensive

#595

Post by rifung »

abiro wrote: post #133
missosoup wrote: post #120

Earlier quoted context omitted.

> going all in on serverless will let you deliver better products faster Can you show some empirical evidence that supports this? In my experience this is another nebulous serverless hype claim that doesn't withstand scrutiny.

I don’t think it’s possible to produce empirical evidence to prove or disprove this claim, but it’s just common sense: Using managed services leads to writing less code and minimizing devops work, both resulting in more time for feature development that takes less time overall and produces higher quality service (latency, availability, etc). Then there is the added benefit of clear financial insight into the inner wo…

> Using managed services leads to writing less code and minimizing devops work, both resulting in more time for feature development that takes less time overall and produces higher quality service (latency, availability, etc).

Well, not necessarily? This assumes that the implementation is sound but it is not at all uncommon for abstractions to leak which end up causing more pain than they solve

Re: Serverless: slower and more expensive

#596

Post by rogem002 »

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…

Once you factor in the learning time for AWS per a developer the cost is even higher.

At my previous company we had project with an AWS deploy process that only two developers could confidently use. Teaching a new developer & keeping them up to date was a big time sink.

For comparison we had a Rails app setup on heroku that on day one junior devs were happily deploying to (plus we had Review apps for each PR!)

Re: Serverless: slower and more expensive

#597

Post by learc83 »

com2kid wrote: post #554
learc83 wrote: post #546

Earlier quoted context omitted.

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…

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

You could have had the exact same experience with Heroku or many other similar products that have been around for almost a decade and a half--it has nothing to do with serverless.

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

It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.

>Everything will work and keep working pretty much forever, without me needing to touch it.

If you believe that, you haven't been doing this long enough.

Re: Serverless: slower and more expensive

#598

Post by scarface74 »

TheCoelacanth wrote: post #589
scarface74 wrote: post #472

Earlier quoted context omitted.

How so? With lambda you give AWS a zip file with your code in it and with Fargate you give AWS a Docker Container. The only difference is that AWS doesn’t support the event triggers with Fargate out of the box.

A docker container is not just your code. It's basically the entire userspace portion of an OS plus your code.

It’s not any more “operationally complex”. The fact that Docker containers include the OS doesn’t make it more complex to run.

My Docker file that I used to convert my Node/Express API that was running in lambda consisted of...

- setting environment variables (I had to do the same thing in my CF template for lambda)

- retrieving the Node Docker image (one line of code - I had to specify one line of code in my CF template with lambda to specify that is was using the Node runtime)

- copying the files from the directory to the container (as opposed to specifying the locsl path of the source code in the CF Template)

- Specifying the Docker Run command (as opposed to specifying the lambda handler).

- running “Docker build” as opposed to “CloudFormation package”.

How it does it is an implementation detail.

In fact, if you use lambda layers, it’s almost equivalent to building Docker images.

Re: Serverless: slower and more expensive

#599

Post by scoot »

Angostura wrote: post #131
scoot wrote: post #110

Earlier quoted context omitted.

/disclaimer/disclosure/ When you disclose something, it's a disclosure.

Unless its a disclaimer, because the poster knows that there is likely to be bias in their post, is aware of that and doesn't want to fix that.

Uh, no [1].

Why do HN folks find this so difficult? It's like putting your shoes on the wrong way around. After you've done it, it's clearly uncomfortable. So don't do it.

https://en.wikipedia.org/wiki/Disclaimer

Re: Serverless: slower and more expensive

#600

Post by zinckiwi »

PKop wrote: post #574
zinckiwi wrote: post #569

Earlier quoted context omitted.

I've often looked at and played with Firebase since it does so much of what I need to back a React Native-based app for simple mobile games and utilities. I always end up talking myself out of it due to Google's history of pulling the plug on (what seem to an outsider to be) perfectly good, stable products that wouldn't do any harm to keep around indefinitely. As a hobbyist, I wouldn't have the time or motivation to…

This seems more applicable to consumer products, not business / cloud services, though I imagine I might be overlooking something.

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.
Post reply on HN