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

401–410 of 733 posts

Re: Serverless: slower and more expensive

#401

Post by EGreg »

That's because serverless IS NOT REALLY SERVERLESS.

Remember when mainframes were king, and then people got desktop computers?

The broadband explosion got everyone addicted to always-on Internet. Before this, we had some pretty awesome protocols, like IRC and USENET, etc. which didn't assume your dialup connection was always on.

We need to have the software autonomously link up with one another, with servers just being dumb hubs that store encrypted data. Then they would be commodities that can get paid in crypto. Have you seen MAIDSAFE?

Re: Serverless: slower and more expensive

#402

Post by pmlnr »

tus88 wrote: post #164
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…

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.

> There are valid reasons for serverless

Those scenarios are probably just as happy with a PHP script on Apache.

Re: Serverless: slower and more expensive

#403

Post by vkou »

sgustard wrote: post #374
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…

> top-down organisational pressure created by technically incompetent strategic management Do most people work in this kind of environment? At my company our management couldn't care less what technologies we use. They want to see reasonable cost and solid uptime, and they ask engineering to deliver that.

Imagine a new CTO or middle manager coming in, with a small ego, and a big need to prove himself, and initiating a make-work project.

What defense mechanisms does your firm have against this? Unless your team leads are golf buddies with the C-suite, it is unlikely that their opinions are going to be taken seriously.

Re: Serverless: slower and more expensive

#404

Post by guitarbill »

x86_64Ubuntu wrote: post #224
scarface74 wrote: post #108

Earlier quoted context omitted.

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.

> Thing looked like an absolute nightmare to get up and running.

So you tried it? I don't remember it being hard to set up, at least compared to a DB. Or, you can use the underlying docker images (open source, https://github.com/lambci/lambci) to run your Lambdas in. SAM provides some nice abstractions, e.g. API gateway "emulation", posting JSON to the function(s), or providing an AWS SDK-compatible interface for invoking the functions via e.g. boto3. This way you can run the same integration tests you would run in prod against a local testing version.

Re: Serverless: slower and more expensive

#405

Post by TickleSteve »

eternalban wrote: post #378
TickleSteve wrote: post #319

Earlier quoted context omitted.

Thats not really true as generally IoT nodes will manage the traffic they generate to avoid synchronisation with other nodes. For example, to avoid the 00/15/30/45 issue you offset yourself randomly over a few minutes within that range to avoid overloading mesh & cellular radio networks. This has a smoothing effect on the traffic as a whole (as seen from the server) which reduces the "dynamic-range" as you're terming…

> generally IoT What you propose is one way of doing so. Again, I remind you that an IoT SaaS has multiple tenants and these tenants can't be expected to collectively coordinate. And in certain domains, it is not possible to dictate timing requirements to the client tenant and thus enforce the (SaaS) providers traffic requirements.

I don't know the specifics of your architecture, but if your (multiple) tenant applications are sharing code on the node-side, then it follows that they can self-organise in a similar manner.

Re: Serverless: slower and more expensive

#406

Post by guitarbill »

k__ wrote: post #351
vips7L wrote: post #335

Earlier quoted context omitted.

I honestly have no problems developing on windows (except when my macos coworkers dont consider windows). Docker is the only real issue.

Yes, it's unusable on macos and windows. Hopefully WSL2 will solve this.

Docker largely works fine on macOS? At least for testing, haven't run into any issues other than bad filesystem performance if you're writing a lot of data to a mounted FS. Our team uses it daily - a far cry from "unusable".

Re: Serverless: slower and more expensive

#407

Post by bastawhiz »

I've seen great success with Lambda in two specific cases:

1. Highly variable load with lots of concurrency

2. Services that are mostly idle

In the former case, you avoid needing to scale up and down. Lots of excess compute is avoided (and periods of underprovisioning are eliminated while load is increasing). In the latter case, simply not keeping a machine warm during long periods of idle time can save a bit of money, with the ability to pick back up almost instantly.

I would think you'd find it tricky to gain meaningful cost savings with Lambda over another option if your use case doesn't fall into one of those two buckets.

Re: Serverless: slower and more expensive

#408

Post by dclowd9901 »

tus88 wrote: post #164
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…

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.

It sounds like what you're saying is for OP to have been able to leverage serverless properly, he should have fired a devops engineer?

Re: Serverless: slower and more expensive

#409

Post by nimish »

missosoup wrote: post #377
tgeek wrote: post #347

Earlier quoted context omitted.

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…

> And so for data processing/streaming/batch [...] serverless actually does work out pretty well. This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the que…

Quite a lot of ETL ends up being some minor transforms + a query or two.

Not all of it is massive ML models doing a lot of computation, and I've had a lot of success using pandas and numpy in it (and gcp cloud functions).

Serverless has its niche and is a great little tool to smooth the impedance mismatch between data stores.

Re: Serverless: slower and more expensive

#410

Post by chrshawkes »

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…

GraphQL makes caching a real bitch.
Post reply on HN