Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#341

Post by nailer » Mon, Sep 23, 2019, 2:55 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.

On-disk state isn't what people mean when they say stateless. * They mean there is no memory state, which is true and which absolutely means serverless functions are easy to test.

* you could argue that 'stateless' should include no long term persistence, but you'd be fighting an uphill battle. Like saying 'serverless' isn't correct because there are servers.

Re: Serverless: slower and more expensive

#342

Post by darkwater » Mon, Sep 23, 2019, 2:56 PM UTC

owenmarshall wrote: post #295

darkwater wrote: post #151

Earlier quoted context omitted.

This "TCO" thing usually comes out always from people interested in making companies migrate (i.e. consultants). Do you account into this TCO the time spent in retraining an gaining operational, production grade experience with serverless for all the teams involved? It's a one-shot cost, true, but it's a long one. And laying off perfectly capable employees because they are now redundant because serverless has a cost…

> Do you account into this TCO the time spent in retraining an gaining operational, production grade experience with serverless for all the teams involved? Hopefully, or else it wouldn't be a total cost of ownership! > And laying off perfectly capable employees because they are now redundant because serverless has a cost too (financial and emotional) No doubt. But if your capable employees aren't providing value outs…

> No doubt. But if your capable employees aren't providing value outside of "keeping the servers humming"

But you would usually consider serverless to need less people to manage it. So, even if they all work hard, someone will be not that useful one day or another. Anyway I really don't see all this fuss about doing more with less (or doing more with the same) going serverless if you are already using infra as code and have a 100% automated CD/CI pipeline.

A greenfield project? Totally! But in an established org with good practices? Dunno.

Re: Serverless: slower and more expensive

#343

Post by sl1ck731 » Mon, Sep 23, 2019, 2:56 PM UTC

ilimilku wrote: post #197

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…

Exactly. This guy nails it. The serverless paradigm is a managed service, so you are paying extra for that management. Serverless also is built for automated connectivity within the AWS ecosystem, i.e. as a nerve center for all of AWS's nifty gizmos. This is why Amazon places such an emphasis on training certified solutions architects who know what works best for each situation.

Amazon puts emphasis on "certifying" solutions architects to turn them into marketing mouthpieces and AWS proponents.

Source: Seen it happen, am certified.

Re: Serverless: slower and more expensive

#344

Post by shams93 » Mon, Sep 23, 2019, 2:56 PM UTC

cle wrote: post #231

188201 wrote: post #220

Earlier quoted context omitted.

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.

You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.

Most Enterprise are still married to java, they still write off node as "not a real language" most likely node is your best bet for the most efficient lambdas Java is a poor for for that.

Re: Serverless: slower and more expensive

#345

Post by scarface74 » Mon, Sep 23, 2019, 2:56 PM UTC

matthewbauer wrote: post #334

mywittyname wrote: post #266

Earlier quoted context omitted.

I've found unit testing to work fine for Lambdas. The biggest difference between running as a Lambda and running locally is the entry point. With a Lambda you have an event payload that (usually) needs to be parsed and evaluated. I'll typically write all the core functionality first, test it, then write the lambda_handler function.

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.

Re: Serverless: slower and more expensive

#346

Post by wolco » Mon, Sep 23, 2019, 2:57 PM UTC

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…

Heroku is owned by salesforce? You learn something everyday.

Re: Serverless: slower and more expensive

#347

Post by tgeek » Mon, Sep 23, 2019, 2:58 PM UTC

missosoup wrote: post #300

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.

> 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 Sharepoint, SAP, or similar) and then look at how many business applications take on a trivial amount of load over time, then the author's post becomes more of an outlier. Few folks have apps that do 100rps realistically. And so for data processing/streaming/batch or web/api workloads serverless actually does work out pretty well. Is this 80%, I am not sure.

There is 100% an inflection point where if your operator cost is low enough(human work+3p tools+process+care and feeding) then the "metal to metal" costs can be comparable. Even the author admits that's leaving something on the floor and so it really comes down to what your organization values most.

I would love for most of our serverless app workloads to be top-down organizationally driven but the reality of it is that it comes often from developers themselves and/or line of business organizations with skin in the game of seeing things move faster in most organizations. This will then typically require buy in from security and ops groups. If these folks you know have the trick to driving top down incompetent strategic management towards serverless I'd buy in on that newsletter.

In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. I think there's also a larger number of people that represent IT vendors that would love to see AWS fail here :)

Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns

Re: Serverless: slower and more expensive

#348

Post by erikerikson » Mon, Sep 23, 2019, 2:58 PM UTC

dradtke wrote: post #292

wongarsu wrote: post #288

Earlier quoted context omitted.

Whenever I've spoken with engineers from AWS and Google Cloud they saw serverless as a platform for glue code, webhooks, cronjobs and the like. In that role it works great: you don't care if it takes 300ms to start and it's genuinely easier and cheaper than running that code on a server. But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. May…

Wasn't it originally called Function as a Service? That seems to be a better name for its intended use-case than serverless.

FaaS is one example of a serverless service. Workflow or object storage services are others. It was the arrival of FaaS that stimulated the term.

Re: Serverless: slower and more expensive

#349

Post by fogetti » Mon, Sep 23, 2019, 2:58 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…

I haven't thought about step 3 before, but makes sense. Maybe I should show this to the guy who used Google Cloud Functions to upload images in our previous project :)

I guess the reasoning would be that this way the actual time spent in serverless code is shorter and by proxy the service becomes cheaper?

Re: Serverless: slower and more expensive

#350

Post by bt848 » Mon, Sep 23, 2019, 2:58 PM UTC

waffle_ss wrote: post #280

lrem wrote: post #33

"Serverless", or "App Engine" as it was called for the few years prior the hype, actually delivers pretty good results for a range of parameters. It might even be a wider range of parameters than the ones where the results are subpar... Or not, I'm not sure how to weight the "I have a predictable base load large enough for its cost to dominate the other factors" vs the other cases. But as always - popularity of a too…

App Engine is a PaaS, not serverless/FaaS

Is that your personal definition? On App Engine I deploy a function that gets invoked whenever an HTTP endpoint is requested. It clearly maps to the semantic of "function as a service" and I don't know about or control the number of servers so it also has the properties of "serverless".