3 ms·

Thanks, peer review is what I'm after The GB/sec calc is there My assumption was that even with k8s there'll be an API gateway, GTM etc Comparing AWS Lamda =

Thanks, peer review is what I'm after The GB/sec calc is there My assumption was that even with k8s there'll be an API gateway, GTM etc Comparing AWS Lamda = 147,167.87 USD to K8s with autoscaling: DS32a_v4 at spot pricing = 66 * 0.5704 * 24 * 365 = 329782.46 USD With 2 FTEs @ 100k total is 529782.46 USD Caveat application can tolerate autoscaling delays Summary: AWS Lambda is 3.5x cheaper than a Kubernetes solution

BackBlast 6y ago
The devil is in the details of how this is implemented. You're ignoring architecture and simply saying that equivalent raw capacity is required. If a request or process comes in, and it hits 10 services to fulfill. The entry service will be open for the entirety of the request, while billing a full 128MB even while waiting for other services and regardless of how much memory is actually used. This is also true of every nested service, which multiplies the required resources. Through the chain there will often only be one active lambda on the request though many are billing. A monolithic design will only use the actual resources dedicated towards serving the request. To put it another way, you change your memory and compute granularity from per-container scope to per-request scope. The finer or microized your services the higher minimums you have on serving a request. In my experience with such implementations this ratio is somewhere in the range of 2x-10x.
dougmoscrop 6y ago
The calculations are still a little more complicated. I think serverless is the future, but I also think we need to continue to put pressure on AWS to lower costs Lambda and servers are not equal, you can't just calculate the number of servers one would need for an equivalent Lambda load. It's entirely possible that they could get away with significantly fewer servers than you think. Your cost calculation includes 128mb provisioned. You cannot run an API with 128mb Lambdas. Try 1gb or even 1.5gb. It's not that you need that much memory of course, but if you want to have p98 execution and initialization times that are palatable, you need the proportional speed benefits that come with the additional memory. And no, you won't need API gateway because you'd likely be including your own in your cluster and it will handle far more load without needing nearly as much autoscaling as the app servers. Lambda autoscales too - it's not instant, and there are steps it goes through as it ramps up. If Lambda removed the per-invocation overhead and billed for actual CPU time used, not "executing" (wall) time, I think that would be fantastic. Again, I still think it's the future, but it has a ways to go before it's appropriate for certain use cases and load profiles. Edit: oh, and I think the managed ROI is also a case by case basis. Do you have people who know how to run a cluster for you already? Completely different conversation. I will also say that Lambda is still not maintenance-free, either.

BackBlast 6y ago

The devil is in the details of how this is implemented. You're ignoring architecture and simply saying that equivalent raw capacity is required. If a request or process comes in, and it hits 10 services to fulfill. The entry service will be open for the entirety of the request, while billing a full 128MB even while waiting for other services and regardless of how much memory is actually used. This is also true of every nested service, which multiplies the required resources. Through the chain there will often only be one active lambda on the request though many are billing. A monolithic design will only use the actual resources dedicated towards serving the request. To put it another way, you change your memory and compute granularity from per-container scope to per-request scope. The finer or microized your services the higher minimums you have on serving a request. In my experience with such implementations this ratio is somewhere in the range of 2x-10x.

dougmoscrop 6y ago

The calculations are still a little more complicated. I think serverless is the future, but I also think we need to continue to put pressure on AWS to lower costs Lambda and servers are not equal, you can't just calculate the number of servers one would need for an equivalent Lambda load. It's entirely possible that they could get away with significantly fewer servers than you think. Your cost calculation includes 128mb provisioned. You cannot run an API with 128mb Lambdas. Try 1gb or even 1.5gb. It's not that you need that much memory of course, but if you want to have p98 execution and initialization times that are palatable, you need the proportional speed benefits that come with the additional memory. And no, you won't need API gateway because you'd likely be including your own in your cluster and it will handle far more load without needing nearly as much autoscaling as the app servers. Lambda autoscales too - it's not instant, and there are steps it goes through as it ramps up. If Lambda removed the per-invocation overhead and billed for actual CPU time used, not "executing" (wall) time, I think that would be fantastic. Again, I still think it's the future, but it has a ways to go before it's appropriate for certain use cases and load profiles. Edit: oh, and I think the managed ROI is also a case by case basis. Do you have people who know how to run a cluster for you already? Completely different conversation. I will also say that Lambda is still not maintenance-free, either.