Mastodawn

The argument is: "we use language X, and we use it for all, no matter what. It is easier to maintain, and all devs can change the code". I think this is not the best tool for the job, and I believe the runtime could be a game changer at the Disney scale.

Even using #Golang will give you better performance and price reduction. It is not #Rust but the best tool for the job that, in this case, is not #java

sabz Nov 11, 2022

@dfrasca80 I agree with you java lags vs Go but often the choice of runtime also dictated by what kind of devs you have . Because adoption of serverless is still new orgs often have devs who are used to in JVM lang so there is also a cost involve to retrain them and gain operational excellence . So if one have devs for Go then sure use it otherwise graal native gives a fighting chance.

@sabz, it is true. But we are #developers, so that we can write the same code in different languages.
#Serverless for #Disney is not new, for example. However, single functionality #Lambda reduces the complexity. I am not saying it is easier to have Lambda written in multiple runtimes or to write a Lambda in a different runtime without some practice. Still, you know insisting and covering behind my dev are only #JAVA dev. It is not right to me anymore.

Sebastian Stein 🇺🇦Nov 11, 2022

@dfrasca80 @sabz Maybe they are having very fat lambdas and not really single purposes one?! I could imagine that their lambda is build on big framework.

@steinchen @sabz, maybe it is all possible, but # disney showcases many things in the past on #aws, and to me, they are the edge. I am just talking aloud to get other opinions 😉

Sebastian Stein 🇺🇦Nov 11, 2022

@dfrasca80 @sabz I think it is also about developer productivity. I also looked extensively at #Rust with >20yrs of programming experience and I really find it hard to adopt.

@steinchen @sabz I get it.
I come from #dotnet, moved to #node years ago for #lambda, and now I am doing #rust #golang based on the project.
People with only #javascript or #python background found it more challenging to adopt, but I think it depends from person to person.

I do not know the darker corners of those languages, and it is fine (I hope)

sabz Nov 11, 2022

@dfrasca80 @steinchen sometimes there's need to be a synergy between developer's wish vs orgs goal. As developer we all like to learn and use new tech . I use both JVM , Go and python daily basis. But from orgs perspective sometimes you need to also stop the proliferation of tools and tech and sometime a good enough solution is better than a perfect one. Having said that I do not know background of Disney and what motivates the decision.

@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”

@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?

Peter Lawrey Nov 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.

Peter Lawrey Nov 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.

@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.

Peter Lawrey Nov 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

@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

@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).

@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.

@moelholm @PeterLawrey it is not about convincing each other I think we are having a lovely discussion

@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

@dfrasca80 @PeterLawrey me too => me to 😩 (My mastodon server doesn’t yet support editing)

@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.