Serverless: slower and more expensive • Hacker News Board

Re: Serverless: slower and more expensive

#731

Post by arthens » Mon, Sep 30, 2019, 7:10 AM UTC

nailer wrote: post #650

arthens wrote: post #647

Earlier quoted context omitted.

I see your point, but this definition is so lax that it applies almost perfectly to any application I've ever deployed to the cloud. Using external services to save state isn't unique to lambda, any app hosted on a normal ec2 instance needs to follow the same pattern because the instance and its filesystem can go away at any time (unless you attach a volume, but I've always considered that to be bad practice).

No it's not. There's no in memory state. Your Django rails phoenix app has in memory state.

What in memory state?

Re: Serverless: slower and more expensive

#732

Post by Avalaxy » Tue, Oct 01, 2019, 3:43 PM UTC

CosmicShadow wrote: post #665

Avalaxy wrote: post #561

Earlier quoted context omitted.

You can just use application insights for this. It can also show you the results of the ping over time in a scatter chart.

Oh interesting, maybe I should look into this more, I feel like it would be useful, but one day it just showed up in my projects and spammed out and drowned all my debugs in the log so now I rip it out as soon as I can because it drives me nuts and I couldn't find an easy way to turn down the messaging.

If you're still reading this, you can disable Application Insights during debugging (why would you need it anyway during debugging). To do this you make an application variable like 'EnableApplicationInsights' in your web.config so you can set per environment whether or not it should be on.

Then if this is false, in your Application_Start() you can set this: TelemetryConfiguration.Active.DisableTelemetry = true;

Re: Serverless: slower and more expensive

#733

Post by pas » Wed, Oct 02, 2019, 9:00 PM UTC

scarface74 wrote: post #262

pas wrote: post #229

Earlier quoted context omitted.

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, yo…

It’s not a “knowledge gap”. I know how to set up databases, queueing/messaging servers, software load balancers, etc., but maintenance takes time and companies pay to save time.

That's true. And that's one of the things that a FaaS/PaaS gives you. Heroku's 24 time limit is perfect for eliminating the problems with starting the environment for each request, but still completely absolves the client from doing the grunt OS maintenance.