Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#481

Post by [deleted] » Mon, Sep 23, 2019, 5:32 PM UTC

tgeek wrote: post #347

missosoup wrote: post #300

Earlier quoted context omitted.

> For the 80% or more, serverless works just fine. Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that loo…

Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless ( https://twitter.com/chrismunns ). I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing. If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sha…

[deleted]

Re: Serverless: slower and more expensive

#482

Post by mywittyname » Mon, Sep 23, 2019, 5:36 PM UTC

scarface74 wrote: post #386

mywittyname wrote: post #316

Earlier quoted context omitted.

Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.

There is no reason that Fargate can not be a replacement for lambda. There are three use cases for lambda: 1. Event based triggers where something happens externally that you want to process. You can do the same thing with Fargate by either having a continuously running process that reads from a queue or responds to an API request (AWS Event -> SNS -> API). 2. Timed events. You can do this with Fargate directly ( htt…

Fargate is slow to spin up and can only run 50 simultaneous instances. But they can run "forever" and have much higher memory constraints.

Lambdas relatively fast to spin up and thousands instances can be run at once. But they are time limited running for at most 5 minutes and using 3GB of RAM.

You can do most of the same things with either (after all, they just execute code), but you cannot ignore their very different limitations and that they are conducive to different workloads.

Re: Serverless: slower and more expensive

#483

Post by iamgopal » Mon, Sep 23, 2019, 5:37 PM UTC

I'm using firebase as it was best choice for single developer application. No need to worry about server side parts, and a healthy free tier means no need to worry about few mistakes you make about architecture. Sometime I worry as my app constrained to single supplier, but I doubt I would be large enough to actually worry about it, and when I will be that big, hopefully I would be afford to hire to move to better solutions or optimise to better suit to existing platform.

Re: Serverless: slower and more expensive

#484

Post by wolco » Mon, Sep 23, 2019, 5:37 PM UTC

coldtea wrote: post #146

goatinaboat wrote: post #141

Earlier quoted context omitted.

1 programmer/ops guy can do what it took 10 before. The myth: devs are expensive and hardware is cheap The reality: webdevs are a commodity and AWS is making record profits

The real reality: not all devs required are webdevs, especially if you want to build an infrastructure that can handle millions of people worldwide. It's not like some React and CSS will get you that. The amount you'll pay for a single additional developer, even if it's "just" 70K, is already close (if not double) your whole Clould costs when you start...

When you start you don't need to handle millions of customers worldwide. If all you need is to handle a million customers per month digitalocean can handle that on a single server and you wouldn't hire a single let alone many developers to manage that.

If you ever reach the point where you need to handle 100s of millions of customers a month / hiring someone can save you money but perhaps serverless makes sense.

99% of businesses will not reach that level.

Re: Serverless: slower and more expensive

#485

Post by mywittyname » Mon, Sep 23, 2019, 5:39 PM UTC

scarface74 wrote: post #345

matthewbauer wrote: post #334

Earlier quoted context omitted.

But how do you test lamba_handler then? Without a way to run lambdas locally, this sounds like a big black hole in your infrastructure.

You call it just like you call any other function. Your handler takes in either a JSON payload and a context object or a deserialized object depending on the language. You call it from a separate console app, your test harness etc.

Yup. You can log into the AWS console and generate an example test message. Copy that into your unit/integration test and bob's your uncle.

Re: Serverless: slower and more expensive

#486

Post by jririi82zxn » Mon, Sep 23, 2019, 5:39 PM UTC

derefr wrote: post #371

jririi82zxn wrote: post #264

Earlier quoted context omitted.

Wow everyone all excited about hosted FreeBSD jails Some of us had deploy pipelines into “containers” working like a Lambda in 2003. Nothing in software is all that novel these days, IMO. All these features that have been there for a decade plus are just wrapped in a corporate brand now. Progress.

The “feature” behind Lambdas aren’t the way they work; it’s the way they force you to work, exposing an ABI that forces “Lambda-compatible code” into a shape where it isn’t attempting to call into OS features of the local machine for things like state storage or IPC, but rather making calls to network-visible service endpoints to accomplish those tasks. In other words, the Lambda environment, as a development target,…

Like I said I was providing largely that pattern years ago to devs.

Not very net new for me, except I’m tethered to AWS.

As usual: ymmv

Re: Serverless: slower and more expensive

#487

Post by lurker458 » Mon, Sep 23, 2019, 5:43 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.

If (nearly) every implementation of a good idea turns out badly, is it still a good idea ? It smells like the No True Scotsman fallacy.

Re: Serverless: slower and more expensive

#488

Post by wolco » Mon, Sep 23, 2019, 5:47 PM UTC

bdcravens wrote: post #193

coldtea wrote: post #69

Earlier quoted context omitted.

> We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless…

If we really want easy, we’d all be writing ColdFusion or Visual Basic.

Why did we move away from VB? Great for writing for a single platform.

Cold Fusion had issues that would prevent it from taking over.

Re: Serverless: slower and more expensive

#489

Post by zidoo » Mon, Sep 23, 2019, 5:51 PM UTC

cryptica wrote: post #17

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

amen

Re: Serverless: slower and more expensive

#490

Post by nirvdrum » Mon, Sep 23, 2019, 5:53 PM UTC

guitarbill wrote: post #432

nirvdrum wrote: post #185

Earlier quoted context omitted.

It really depends what you're doing. I've been trying out serverless on-and-off for weeks now and still don't have a basic two tier application going the way I want. I'd have been substantially better off dropping $5/month on a DigitalOcean droplet and running PostgreSQL and Rails on it. DigitalOcean even has really helpful templates to start up basic servers. This may be a specific criticism of AWS Amplify, but all…

> DigitalOcean even has really helpful templates to start up basic servers. > I'll admit I'm a sucker for infrastructure as code. ... which you have to maintain, which probably means Ansible/Chef/Puppet/Salt/etc scripts. Which is fine, it's just a trade-off. I've spent weeks maintaining those kinds of things though, and inevitably when you come back in a year, something's broken. CloudFormation isn't great, but it us…

I guess my point is I'm going to have to maintain something, it's more useful for me to know how to maintain a PostgreSQL installation than it is some custom Amazon framework or tool. Serverless certainly hasn't been the "fire and forget" system I was sold on. And for just starting up, I can stage an Ubuntu server and set it to auto-update and really not have to touch it for quite a while. I happen to have extensive sysadmin experience and authored a reasonably popular provisioning tool, but I can appreciate not everyone wants to learn it. However, getting AppSync with its Velocity templates talking to DynamoDB and authenticating with Cognito requires quite a bit of knowledge as well. And time spent learning that only benefits you if you never leave the AWS ecosystem.

I suppose I could look at Aurora instead, although Amplify only supports MySQL Aurora, so no luck with Postgres again. Likewise, the price advantage goes away. And now I'm stuck figuring out a wildly convoluted TCO calculator. I could look at another hosted DB solution, but now I either need to move everything to a new provider or find a way to deal with WAN latency for simple DB operations. Moving means learning yet even more otherwise useless knowledge about a single provider.

I'm sure a lot of this is just growing pains. But as a lone dev just poking at something in his spare time, all these "get running in 30 min. or less" tutorials fall apart the moment you try to do something outside that tutorial. And the number of services available, their weird pricing structures, their implicit deficiencies and explicit limitations, just mean I'm still wasting time not building software :-/