You Don't Want Serverless - Erik Onarheim - NDC Oslo 2024

[@ErikOnarheim]

❤ Woo! Thanks for having me! I had a lot of fun in Oslo!

[@dandogamer]

Great talks, sums up all my gripes and PTSD I've had with serverless

[@PavelKostenko]

In my case the issue with server-less was a Cloud Watch bill which was bigger than Lambda bill 10 fold, be careful with console.log statements in your Lambdas. Also experienced a lot of cases mentioned in the video. Thanks for presentation 👍🏻

[@thegrumpydeveloper]

So true - aws services are just a way to sell more cloudwatch

[@berkayyerdelen927]

Thanks for presentation Erik to pointing out tradeoffs. I think all presentation remind me something about being cautious. awareness and acceptance of risk when making decision

[@alvaromoe]

To be fair a lot of the "issues" mentioned are perfectly reasonable limitations for what is supposed to be simply *a function*. For example the 4kb limit on env vars. It's fine, it's reasonable. What's not reasonable is having hundreds of env vars for one function. If you hit that limit you shouldn't be using lambdas in the first place. The same with timeouts, if you ever need to increase the default timeout your lambda is doing too much. Either split it or choose a different stack. Lambdas are great for any task that doesn't need to scale and doesn't have a user waiting. Because if you get too many requests you will pay a lot. Lambdas are not "cheap", as you say, they are EXPENSIVE. If you pay little is because you don't use them much, but not because they are cheap. Also, you just can't get around cold starts. Accept it. Embrace them. Don't waste time and resources implementing workarounds. Use them whenever a longer wait is not a problem. Follow these simple guidelines and you'll be fine. Lambdas are amazing, but for a very (VERY) limited set of problems.

[@ErikOnarheim]

Totally agree, lambdas can be a great tool for the right problems.

[@sergeypichkurov8757]

Great talk, would be good to have GCP in the mix ...

[@deniskvasnevsky4221]

very interesting, thanks!

[@JulianSildenLanglo]

I use a couple serverless functions at work and it's perfect for stuff that I don't want or need to fiddle with every year and are invoked on a weekly basis.

[@ErikOnarheim]

Totally a great use case IMO

[@panosdotnet]

Shared it with my boss hahahaha

[@mileselam641]

Secrets don't belong in environment variables. Those aren't solutions when they've broken something. Putting sensitive info in your code or your stack is just plain wrong.

[@kahnfatman]

I don't want serverless.. I want O(1).

[@rngesus8057]

9:30 i count on the opposite! its how we get the most out of lambda

[@ErikOnarheim]

For sure! Definitely how you get the most out of your warm contexts, but I'm not sure all people expect this when they start (I didn't).

[@rngesus8057]

44:46 yep great for message queues, definitely not api calls

[@bobfunk5055]

Is there anything of value in the first 5 mins ?

[@ShawnMilo]

In my experience, you can always skip the first 10% or 20% of *any* conference talk and miss nothing.

[@johndunderhill]

Not convinced. Just a bunch of whining about potential problems that could affect any architecture (not just serverless), and very reasonable limitations, most of which can be adjusted if needed. No contrasting what serverless gets you, in return for learning a few caveats. I think the developer experience is actually quite good, compared to setting up a similar environment manually. Of course platform companies want to make money. Why is that a conflict, if it also helps you make money? You pays your money and you makes your choices. You can run your whole back end as a monolith on a hockey-puck-sized computer in your basement, if you want. Serverless isn't necessarily better than that, until you start to reach a certain level of traffic. Then it's better.

[@dandogamer]

I'm not sure how you can defend the developer experience its worse than the 90's