Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#201

Post by pbalau » Mon, Sep 23, 2019, 12:32 PM UTC

hdra wrote: post #49

tedk-42 wrote: post #12

I disagree with all the comments posted so far. This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with. The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fo…

>The whole idea of serverless is so you don't have to manage infrastructure Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed. All in all, I can't really say Lambda is really all that "easy" considering options li…

> you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.

You know those url.py files in a django install? Those are the equivalent of ELB/APIGW thing. You don't manage those, you make them once.

Not sure where you personally draw the line between app development and infra work, but for me "request that comes on this path, calls this function", either via ELB -> backend or APIGW -> lambda, or you know, whatever you use for your django app -> a function defined in a view.py, is app, not infra.

Re: Serverless: slower and more expensive

#202

Post by danesparza » Mon, Sep 23, 2019, 12:33 PM UTC

dave_sid wrote: post #195

tus88 wrote: post #164

Earlier quoted context omitted.

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.

Truly: I would encourage you to develop something better, then. Please put your wisdom to good use.

Re: Serverless: slower and more expensive

#203

Post by echelon » Mon, Sep 23, 2019, 12:33 PM UTC

Has anyone migrated in the other direction, away from AWS onto their own servers?

There was a response to a comment I made some time ago that seemed to imply Netflix was doing this (beyond edge delivery) because of AWS costs or funding their direct competitor. A few of us asked for specifics but never got any confirmation that this was happening.

Has anyone been unhappy with cloud?

Re: Serverless: slower and more expensive

#204

Post by CosmicShadow » Mon, Sep 23, 2019, 12:34 PM UTC

joelthelion wrote: post #107

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…

> 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. Shouldn't this not be a problem if you're doing 10 million requests a day? If you have enough requests, your lambdas should stay hot most if not all the time.

I built an azure function that runs for free that just pings my .NET MVC pages periodically so they are always hot on my cheap hosting.

Re: Serverless: slower and more expensive

#205

Post by chucksmash » Mon, Sep 23, 2019, 12:35 PM UTC

dullgiulio wrote: post #150

nailer wrote: post #89

Earlier quoted context omitted.

> Testability? Serverless is specifically a stateless paradigm, making testing easier than persistent paradigms. > Framework adoption? Generally we use our own frameworks - I do wish people knew there was more than serverless.com. AWS throw up https://arc.codes at re:Invent, which is what I'm using and I generally like it. > Stability? Industry Skills? Proven Architectures...? These are all excellent questions. GAE,…

Just to be clear: lambdas are not stateless if you, for example, connect to a DB or use any other external service. State could be somewhere else, but if you are not also "pure", you don't have any improvement over a normal service.

State is saved somewhere, sure. How many useful applications are truly stateless when considered in their entirety?

This isn't the sense in which servers are usually said to be stateless, however. A Lambda that reads and writes state from a database when invoked is not maintaining state outside of the request-response cycle itself, so it can be said to be stateless.

Re: Serverless: slower and more expensive

#206

Post by jtdev » Mon, Sep 23, 2019, 12:35 PM UTC

Author doesn’t even attempt to explain the 15% performance hit, but I suspect it’s cold start related... ASP.NET is a poor choice for Lambda if you’re hoping for good performance.

The authors use case isn’t well suited to Lambda. In fact, something like ECS would be a much better fit and an improvement over Elastic Beanstalk.

Re: Serverless: slower and more expensive

#207

Post by restlake » Mon, Sep 23, 2019, 12:35 PM UTC

LunaSea wrote: post #170

k__ wrote: post #161

Earlier quoted context omitted.

I think you are right with your assumption that Docker images that don't resemble the production environment aren't sufficient to test. But isn't the idea of Docker that you can recreate the production environment? If you can't why use Docker in the first place?

You are absolutely right that you could recreate a similar environment to Lambda in Docker. But you would first need to reverse engineer Lambda's environment to discover how it is actually configured and the limits that are set. Even if you did find a way, you would still need to keep it up to date in case AWS decides to update that environment.

Logged in to say that this has actually been done (not by me) and my team has been finding it very helpful for local “serverless” SDLC: https://github.com/lambci/docker-lambda . It‘s billed as “ A sandboxed local environment that replicates the live AWS Lambda environment almost identically – including installed software and libraries, file structure and permissions, environment variables, context objects and behaviors – even the user and running process are the same.” We test our functions mocked and against local deployments of that lambci container . There also lambda “layers” (container images for building custom runtimes for AWS Lambda) but we have not used that feature at this point. Interesting space with lots of room for improvement in this tool chain though for sure

Re: Serverless: slower and more expensive

#208

Post by k__ » Mon, Sep 23, 2019, 12:39 PM UTC

restlake wrote: post #207

LunaSea wrote: post #170

Earlier quoted context omitted.

You are absolutely right that you could recreate a similar environment to Lambda in Docker. But you would first need to reverse engineer Lambda's environment to discover how it is actually configured and the limits that are set. Even if you did find a way, you would still need to keep it up to date in case AWS decides to update that environment.

Logged in to say that this has actually been done (not by me) and my team has been finding it very helpful for local “serverless” SDLC: https://github.com/lambci/docker-lambda . It‘s billed as “ A sandboxed local environment that replicates the live AWS Lambda environment almost identically – including installed software and libraries, file structure and permissions, environment variables, context objects and behavio…

Nice!

I saw that the SAM CLI uses an Alpine based image, does yours use Amazon Linux 2?

I'm jusz asking, because I compiled some libs on Cloud9 (which uses AL) and they worked on Lambda, so I assumed it's the same dist.

Re: Serverless: slower and more expensive

#209

Post by eternalban » Mon, Sep 23, 2019, 12:40 PM UTC

jacquesm wrote: post #124

eternalban wrote: post #106

Earlier quoted context omitted.

So possibly a good fit for IoT.

Yes.

Specially considering the staggering effect due to predisposition to picking a cardinal direction - 0/15/30/45 minute - in the clock. This is a real issue specially for SaaS offerings in the IoT space.

Re: Serverless: slower and more expensive

#210

Post by awinder » Mon, Sep 23, 2019, 12:43 PM UTC

I was ready to look past the title as just the cost of doing "business" in 2019, but the article has a lot of problems. Stuff like measuring latency from 1 computer in Iceland -- gaining empirical results from your actually running user-base (logs & analytics) would be a much better test, as it is you can probably effectively ignore that part of the article because that's not an effective test.

8x multiplier on ~1K a month ignores the actual value proposition of serverless. Which is that you're not spending staff hours designing, building, and maintaining scalable infrastructure. If you don't have scalability issues (which at 1K a month, you don't), then it's maybe not the right technology for your use case. If you do, then maybe it's the right technology -- yeah you're paying more but you gotta do the math on what you'd need to build and then discuss tradeoffs with the business. Classic technology cost analysis, this is not new.