The only drawback of this kind of comparison is that it deprives us from a reality of vendor-locking matter, the more you're reliant on cloud-native rather than Kubernetes, the more trouble you'll encounter later when you by any chance to move out

all your contents are to the point and very well explained, like this one, and please keep doing your interview prep Q&A it also helps alot. thanks Raj bhai you rock \m/

Very clear and in-depth explanation. Amazing.

Thanks much. Quite detailed and informative content.
How about the micro services perspective of comparing these services? For instance, the feature set and cross-cutting concerns that ECS/EKS provides along with service mesh,  in managing/governing MS cluster would be better than with Lambdas.
Can’t this also be a decision influencer?

amazing , no words to thank you

Great content!

Thank you.... A 1000 times!

Just found your channel. Excellent Content. Another sub for you sir!

This is very nice explainer! Thank you.

very informative, thank you!

Thank you, that was very informative.

Nicely articulated. Since Lambda scales up automatically as and when the incoming traffic goes high, is load balancer still required? Also, since lambda executes only one of the concurrent connections, isn't the load balancer redundant? Could you please clarify?

I guess it all comes down to the cost factor and performance to choose which technology to use. As far as I know if lambda memory is below 1.8GB, it has only 1 vCPU which may not suitable for computing intensive task which requires multi-processing. but again, increasing the memory also means more cost

2 questions - 1. can an EKS fargate be triggered by SQS 2. How can i scale up EKS fargate based on the SQS events and not based on CPU/Memory metrics

Great video !
10:40 Does this mean that when a new concurrent invocation of my function happens, Lambda will provision the new instance in a different AZ, or does it mean that every Lambda function runs with HA under the hood and invocations are load balanced across those 3 underlying instances (which would be in contradiction with your statement  saying that Lambda will provision a new instance for every new concurrent invocation) ?
I believe it is the former, rights ? In that case it would work as follows:
1) 1st time the function is being invoked =>it is provisioned in AZ1
2) a new concurrent invokation happens => a new lambda instance is provisionned in AZ2
3) the first invocation is over, but a new invocation occurs => that invocation is routed to the instance in AZ1