Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#221

Post by mfer » Mon, Sep 23, 2019, 12:55 PM UTC

Serverless has it's place. If you have lots of events and they don't fire all the time it's great. Or, for small additive things on a mostly static site (like one hosted out of s3). Or for some other specific cases.

Serverless may change the landscape of development but it's going to take time. The costs need to settle into place while tools and processes need to come together.

Right now it appears it takes longer to build something with serverless, is more difficult to manage for day-2 deployments, and it costs more to operate for things like API servers.

I look forward to serverless doing a lot more in a cost effective manner. It's just going to take time to get there if it ever does.

Re: Serverless: slower and more expensive

#222

Post by anherome21003 » Mon, Sep 23, 2019, 12:56 PM UTC

laumars wrote: post #72

It's not as clear cut as the article describes though. For low usage stuff serverless is cheaper. For "spiky" traffic - particularly when those spikes are unpredictable - serverless is often cheaper and sometimes faster too (eg if your spikes ramp up quicker than the spin up times of virtual machines). Also AOT compiled languages like C# will run slower on lambda than pre-compiled on an EC2. You shouldn't need benchm…

Yes but what about test driven development and agile? We can't see how serverless development is compatible with these so we don't use it. Docker FTW!

Re: Serverless: slower and more expensive

#223

Post by protonfish » Mon, Sep 23, 2019, 1:00 PM UTC

danesparza wrote: post #202

dave_sid wrote: post #195

Earlier quoted context omitted.

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.

How about using a server?

Re: Serverless: slower and more expensive

#224

Post by x86_64Ubuntu » Mon, Sep 23, 2019, 1:02 PM UTC

scarface74 wrote: post #108

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…

You’re always locked into your infrastructure. People don’t willy nilly change their infrastructure once they reach a certain size any more than companies get rid of their six figure Oracle infrastructure just because a bushy tailed developer used the “repository pattern” and avoided using Oracle specific syntax. And the “lock-in” in lambda is over exaggerated. If you’re using lambda to respond to AWS events, you’re…

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.

Re: Serverless: slower and more expensive

#225

Post by rgallagher27 » Mon, Sep 23, 2019, 1:04 PM UTC

188201 wrote: post #220

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.

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

Have been running our API on Gateway/Lambda for well over a year now, having migrated from EC2. We've spent almost no time "managing" API gateway, monitoring or logging since the initial setup and migration of our infrastructure.

If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.

Re: Serverless: slower and more expensive

#226

Post by giancarlostoro » Mon, Sep 23, 2019, 1:04 PM UTC

I meant to say this in another post I saw the other day about serverless. Serverless is mostly hyped up by marketing sure. But the benefit is not in just running a Function as a Service.

The real gem of Serverless is that if you're using a cloud say for example Microsoft Azure (I'm just more familiar with their offering) you can have events triggered when: a new file/blob is added to your Azure Blob Storage. Another case and I know there's likely a none cloudy way of doing this: when new records are inserted into a database you can run a function. It's cronjobs on crack that will only fail in your code usually, I've never seen a failure of an Azure Function getting triggered, can't speak to other cloud providers offerings.

Yes I agree, it's a lot of marketing hype, and it's even dumber IMHO that they emphasize on the RESTful aspects, and not the useful cronjob like aspects that save you time on figuring out when and how to work on something as it hits your cloud.

Re: Serverless: slower and more expensive

#227

Post by geodel » Mon, Sep 23, 2019, 1:05 PM UTC

It seems to me Serverless is meal kit delivery of IT. Expensive with dubious benefits. But it might just work because IT departments have lot more money and incompetent people to buy costly solutions and move on to next buzz when the current one fails.

Re: Serverless: slower and more expensive

#228

Post by lovetocode » Mon, Sep 23, 2019, 1:06 PM UTC

mocha_nate wrote: post #212

Thank you for writing this! It’s always interesting to see how other people set up their stacks. Recently, I created some twitter bots to test out for fun and put them on Lambda with a 12 hr schedule to run from SNS... I was sending 15 tweets a day (from ~15 accounts) and my bill was $35/mth... That is silly

There is a lot to ask here. There is no way you are operating outside of the free tier based on the description you provided.

Re: Serverless: slower and more expensive

#229

Post by pas » Mon, Sep 23, 2019, 1:07 PM UTC

scarface74 wrote: post #117

pas wrote: post #34

Earlier quoted context omitted.

There's already serverless where you don't have to do anything with OS/servers/infra: PaaS, like Heroku. But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|

Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?

Sure, it's not FaaS, but it fits the "you don't have to care for OS and servers" criteria, and it's always on (and auto-scalable).

Running FaaS on AWS without knowing anything about servers and "OS stuff" screams like building the roof without the foundation. And I know that it sounds convenient to run everything as isolated little abstract functions, and ... it works, but it's pricey. But you can do it for cheap, you can deploy Kubless or OpenFaaS (or OpenWhisk or whatever is Apache's equivalent). Naturally AWS exploits this knowledge gap for a lot of their managed services.

Re: Serverless: slower and more expensive

#230

Post by mnutt » Mon, Sep 23, 2019, 1:08 PM UTC

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…

Having used serverless a bit, I’ve run into many of the same issues and generally agree with the advice but depending on your use case it may not be worth contorting your architecture to fit serverless. Instead, I’d look at it as a set of criteria for if serverless would fit your use case.

At this point in time the only places I’d use lambda are for low-volume services with few dependencies where I don’t particularly care about p99 latency, or DevOps-related internal triggered jobs.