Good talk. I needed a lot of ammo to calm down the younglings in my company who were extremely agitated to introduce serverless into our product. In the end we ended up moving a bunch of microservices to elixir and brought down node count from 20+ to 6!
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 👍🏻
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
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.
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.
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.
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.
❤ Woo! Thanks for having me! I had a lot of fun in Oslo!
Great talks, sums up all my gripes and PTSD I've had with serverless
Good talk. I needed a lot of ammo to calm down the younglings in my company who were extremely agitated to introduce serverless into our product. In the end we ended up moving a bunch of microservices to elixir and brought down node count from 20+ to 6!
Erik is a fantastic speaker and this talk has been featured in the latest issue of 💥Tech Talks Weekly as it was the most-watched this week.
Congrats 👏
Thanks! This comment made my day ❤
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 👍🏻
So true - aws services are just a way to sell more cloudwatch
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
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.
Totally agree, lambdas can be a great tool for the right problems.
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.
Totally a great use case IMO
Great talk, would be good to have GCP in the mix ...
very interesting, thanks!
Seems way more applicable to AWS Lambda than Google Cloud Run
44:46 yep great for message queues, definitely not api calls
9:30 i count on the opposite! its how we get the most out of lambda
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).
I don't want serverless.. I want O(1).
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.
Is there anything of value in the first 5 mins ?
In my experience, you can always skip the first 10% or 20% of *any* conference talk and miss nothing.
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.
I'm not sure how you can defend the developer experience its worse than the 90's