Daniele Frasca 🇮🇹🇩🇪🇪🇺Nov 11, 2022

I read this article https://aws.amazon.com/blogs/opensource/improving-developer-productivity-at-disney-with-serverless-and-open-source/

Disney reduced cold start using #GraalVM

When I look at the image, I see:
- High memory settings
- High Duration

It means high cost.

Don't get me wrong, they improved a lot with the native image, but this is not the point of #serverless.

With #serverless you can write different #lambda with another runtime.

With #rust, you can run 256MB #Lambda and still get a better cold start of native-java at 3000M

Improving Developer Productivity at Disney with Serverless and Open Source | Amazon Web Services

Disney Streaming's use of serverless and open source technologies has improved their ability to deliver business value safely and reliably.

Amazon Web Services
Show threadmoelholm🏃🏻‍♂️Nov 11, 2022
@dfrasca80 for a #java savvy loving house this may still be fine. Not everybody wants to code in other languages just to cut cost extremely low. And perhaps performance is “good enough”
Show threadDaniele Frasca 🇮🇹🇩🇪🇪🇺

@moelholm is also very accurate, but it is a bit strange a dev is not willing to develop or learn a new language. Not an ancient language but a “contemporary” language. But I get the point. I was like this many years ago.
From a company point of view:
- You can reduce costs
- You can improve latency
- You can gain higher throughput

Will you be against this?

Nov 11, 2022 at 10:24amWeb
Show threadPeter LawreyNov 11, 2022
@dfrasca80 @moelholm
If the objective is to reduce cost, improve latency, and gain higher throughput, why would you use serverless unless you have extremely low throughputs?
If a system takes 100 ms to start, why stop it if you are getting a throughput of 10 per second.
If you want 100/sec, just have the service running all the time, same for 1,000/s or 1 million/s.
Show threadPeter LawreyNov 11, 2022
@dfrasca80 @moelholm
If your throughput is once a minute or less, and only runs for a second or less, you could save money by not having a service running when it wouldn't be doing anything most of the time.
Show threadDaniele Frasca 🇮🇹🇩🇪🇪🇺Nov 11, 2022
@PeterLawrey @moelholm it is a good point. I guess now we are moving to #Serverless vs #Containers.
My guess is: if you are in constant traffic, the advantage of Serverless is that it can handle better unpredictable traffic and concentrate on the application's business value without worrying about networking, etc. Of course, you can achieve the same with Containers, but there is overprovision. Perhaps, it would be more challenging to move to a multi-region setup...but now it is fantasy guessing.
Show threadPeter LawreyNov 11, 2022
@dfrasca80 @moelholm
Except for very low throughput, or a very spiky behaviour, at what point does a serverless environment cost less to run than a server running all the time.
I can see that not having to worry about the network is an advantage, but surely you can achieve that without serverless
Show threadDaniele Frasca 🇮🇹🇩🇪🇪🇺Nov 11, 2022
@PeterLawrey @moelholm for pure bare metal comparison, perhaps it is cheaper, but you have to consider the ToC. Maintaining the servers and people doing the ops etc., this why serverless is also considered cheaper at scale. I think the issue with #serverless is the scalability that is not the same in each region, making it challenging to adapt closer to the user. I know many that deploy far away to get better quotas with #containers would not happen
Show threadmoelholm🏃🏻‍♂️Nov 11, 2022

@dfrasca80 @PeterLawrey phew a lot happened in this thread while I was at work today 😂

I have to state that lowest possible cost isn’t at all the most important driver on the teams I’m at. Never have been. Never once did we talk about it as the most important thing. Misused cost: yes (bad dymnamodb scans etc). But that’s about it. We would never choose an entire language tool chain based on that (alone).

Show threadmoelholm🏃🏻‍♂️Nov 11, 2022

@dfrasca80 @PeterLawrey

Containers vs serverless. Never ending battle. You won’t convince each other. Both can and will be used. We’re using both on many teams in #LEGO. For various reasons. Not so much cost (again). But architectural impact, ease of development, competencies, vendor lock in, etc

Diplomatic right? 🤪😅 Have a wonderful weekend guys.

Show threadDaniele Frasca 🇮🇹🇩🇪🇪🇺Nov 11, 2022
@moelholm @PeterLawrey it is not about convincing each other I think we are having a lovely discussion
Show threadmoelholm🏃🏻‍♂️Nov 11, 2022
@dfrasca80 @PeterLawrey yes indeed a good one👍🏼😎 - and I must say highly interesting for me too get both view points 👌🏼. I see both of them - and believe in both but … for me it’s always been a “it depends” decision. As in: skills, passion, greater technology radar standpoint from a company perspective, what other enabler teams do we have (or not), what’s our policy wrt depending on cloud providers in a higher or lesser degree (lock in), tooling etc
Show threadmoelholm🏃🏻‍♂️Nov 11, 2022
@dfrasca80 @PeterLawrey me too => me to 😩 (My mastodon server doesn’t yet support editing)
Show threadDaniele Frasca 🇮🇹🇩🇪🇪🇺Nov 11, 2022
@moelholm @PeterLawrey, you are right. It always depends, and it is more complicated than it looks. But we can discuss and make our assumptions.
At the enterprise level is much more difficult to change because of everything you said. But if you do a change for speed as they did, why not correctly pick the best stable tech and gradually roll it out? Maybe they do it, but I would showcase the best of the best.
Show threadDaniele Frasca 🇮🇹🇩🇪🇪🇺Nov 11, 2022
@moelholm @PeterLawrey regardless of runtime, #Disney did a good job improving the cold start using #GraalVM