Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

541–550 of 733 posts

Re: Serverless: slower and more expensive

#541
post #371

Earlier quoted context omitted.

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

Right, but, the "feature" of a popular standard isn't that it's a standard, but that it's popular.

The thing that was new about Facebook wasn't that it was different than MySpace, but that it was the first social network that managed to scale such that all your friends and relatives ended up using it without your pushing them to do so.

The differentiator of the serverless model is that it's a Schelling-fence development practice, such that you can find real infrastructure components in the wild that are targeted at "serverless deployment" and use them.

Or: there was likely no version of Wordpress developed specifically for your stack; but there is likely some version of Wordpress developed to be deployed on a FaaS cluster. That's what makes "serverless" worth paying attention to. Like Kubernetes, or even Linux: they're the first ubiquitous examples of their archetypes.

Re: Serverless: slower and more expensive

#542
post #164

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.

Managed servers also exist and are in quite of a sweet spot if you need the performance.

Re: Serverless: slower and more expensive

#543
post #394
post #70

Earlier quoted context omitted.

Counterpoint to that though: "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly "accessible" for someone trying to get running ASAP. I agree tech is getting democratised, but when talking abou…

I've found https://github.com/Miserlou/Zappa to be super useful for simple Lambda deployments. It's only for python, but I am pretty sure you have other solutions for node, ruby...

We use http://apex.run/ but mainly because that’s what we started with and it hasn’t given us a reason to look around yet.

Re: Serverless: slower and more expensive

#544

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…

FWIW. It has worked great for us, saving us mid six figures per year or more. The savings keeps increasing as we figure out ways to move more of our workload over to Lambda, we are even running PHP there. Step functions, lambda, sns, sqs and api gateway are pretty cool tools for a lot of projects when used properly. I think the paradigm shift in how you need to make things work is frustrating for some, but once you g…

mid-six figures is $500k?? Are you factoring in salaries to get to that number or merely AWS spend? I'd love to see a spreadsheet with this analysis.

Re: Serverless: slower and more expensive

#545
post #403

Earlier quoted context omitted.

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.

How would your hypothetical defence mechanism tell which C-suite initiatives are worthwhile, and which are ego driven make-work?

That's the thing. The two are indistinguishable, unless you give people with strong technical skills veto power on projects. If you don't work in such an environment, the only reason you haven't ran into a dangerous, idiot manager, is luck.

For some reason, in most firms, the c-suite isn't super keen on delegating that power.

Re: Serverless: slower and more expensive

#546

Earlier quoted context omitted.

Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit?

> Is your API so large and/or unstable that optimizing for time needed to add an endpoint is your lowest hanging fruit? Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month. As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test. My long running and CPU intensive stuff is running on a VM of course. I'm sure if I had spe…

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.

Re: Serverless: slower and more expensive

#547
At the end of the day, it all comes down to usage patterns. It often makes total sense for low-volume tasks to be processed by Lambda. If your company only has low-volume usage, or even just bursty usage, then Lambda is a slam dunk.

Now, say your company has a mix of low-volume and high-volume tasks--sure, you could comingle your low-volume work use some of the cycles from the high-volume workloads--e.g. add some endpoints to your high-volume application that handles low-volume tasks. But, isn't this trending towards the monolith of yesteryear? Which, is fine, I guess--monoliths aren't pure evil--but with microservices and serverless we've finally been able to apply the tried-and-true design patterns of separation-of-concerns/do-one-thing-well to entire applications (not just to little utilities and libraries).

The point is, there's nothing wrong with embracing the right-tool-for-the-right-job and using a mix of infra strategies is often what's best for an org. You don't have to go all serverless, nor do you have to go all containerized. Let your big-dog 24/7 high-volume applications do their thing in Kubernetes and let your one-off admin tasks spin up for 100ms and die and not bother anyone else.

Re: Serverless: slower and more expensive

#548

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…

Here's an anecdote: I'm a one man shop who has been planning, developing and deploying Django applications for six years. I have not got to the point where my deploys are automated because I am swamped with work just keeping my clients up to date and my servers ticking along. I usually deploy one client per $5 DO VPS. I just deployed my first project to PythonAnywhere and I am blown away at how much easier is. I'm go…

That just looks like a standard PaaS to me--Heroku has been doing that forever.

Re: Serverless: slower and more expensive

#549
post #142

Earlier quoted context omitted.

> but it’s just common sense No. There's nothing common sense about it. It only seems plausible if you read the sales brochure from a cloud vendor and have no experience with all the weird and whacky failure modes of these systems and the fact that none of the major selling points of serverless actually work as advertised unless you dedicate significant engineering time to make them work - as the GP comment has demon…

> Serverless only makes sense if you have a fairly trivial problem That’s exactly the point. The web application needs of most startups are fairly trivial and best supported by a serverless stack. Put it another way: If your best choice was Rails or Django 10 years ago, then it’s serverless today.

> The web application needs of most startups are fairly trivial and best supported by a serverless stack.

Pretty subjective statements, I suppose we don't have the same definition of "trivial".

> If your best choice was Rails or Django 10 years ago, then it’s serverless today.

Comparing the features of Rails or Django with serverless is like comparing a spaceship with a skateboard.

Re: Serverless: slower and more expensive

#550
The AWS bill seems high already. $90 dollars for m1.small, which has 1 vcpu and less than 2GB memory? At my current hosting provider that machine costs less than 5euro! What am I missing? Looking at the hourly usage it seems to be the equivalent of 3 machines running 24/7, so 15 euro, but still?
Post reply on HN