dougmoscrop

Avoiding scaling the stateful part is also a path to hammer-nail syndrome - you start using less and less of the database system because you keep pulling things out since that's the only place you've established the ability to add CPU capacity and with that come a host of new and old issues.

I can't decide if I would enjoy reading real examples of these cycles. Just knowing how precarious the supply of natural rubber is, and how inadequate artifical solutions are (including prospective ones from continental), makes me uneasy, but I'll be damned if there isn't some kind of allure there as well.

It seems almost certain that climate change is going to severely disrupt several of these cycles in decade or two, and a slightly different failure mode of what you allude to in C. is that our tech and processes become capped before we adequately scale up renewables, and overshoot kicks in and it's actually a negative feedback loop that certainly doesn't just stop with computers.

I live in Canada, things don't quite work like the US in terms of ownership incentives, but generally nobody is renting a house here for less than what it costs to finance and maintain it, so rather than "renting with extra step", an entire generation of people are being told they can not afford to own the home, but they can go ahead and pay the bills of the person who does.

Buying a house ten years ago has added about $450,000 to my net worth, without me making any extra payments. Had we stayed renting an apartment, saving the difference would have produced about $57,000 at 8% annualized, and had we rented a house that was comparable, would have yielded nothing.

Buying a house here can be highly leveraged - you start off only having to pay 5, 10, 20 percent of the price, but until very recently houses appreciated more than the interest on the mortgage, furthermore, as you pay your mortgage off, you can take a loan out against a certain portion of the value of the house and use that money to invest in other things, while tax deducting the interest from that loan. Never actually paying your house off is a thing for both the rich and the poor, but with very different outcomes.

Can you imagine if even a fraction of the effort poured in to k8s tooling had gone in to the Erlang/OTP ecosystem instead?

Agreed, we have our work cut out for us but the team is fantastic and I can't wait to share more of our vision with the world!

Honestly, looking at Oracle Cloud, I think the best thing they could do is spin off and just completely remove any trace of the name Oracle. You have some absolutely fantastic products that are being criminally neglected because people won't go anywhere near the name, and can you blame them?

Totally agree. Lambda needs to 1/10 their costs or start billing for real CPU time and get rid of invocation overheads to really compete at these scales.

Now I have dozens of serverless projects for smaller use things because there is still a point where the gross costs just don't matter (as in, if my employer was worried about lambda vs EC2 efficiency, there are probably a few meetings we could cancel or trim the audience of that would make up for it.)

But not at this scale.

Most if not all AWS services are really just HTTP APIs. A Lambda invocation is really just a POST to a public AWS endpoint. You can absolutely come up with login flows that obtain a set of temporary STS credentials that are only allowed to invoke your "API" function. (Agreed this is not most workloads)

I responded lower, but dude! 2000 requests a second is hardly anything at all, unless the application server is doing some seriously heavy lifting in which case the architecture is wrong.

You should redo the calculations with 1gb of memory for Lambda and like 30 machines would be generous

Concurrency is key. Requests don't cost much when they're just waiting for other things, but Lambda continues to pile costs on for every increase in concurrency.

APIs should maybe use a tiny fraction actual real CPU time. Perhaps BBCs are different - In order to make an actual fair comparison and properly predict what they would need in servers, greater detail is needed than what you have available to you, but I think your estimations are off by a significant amount.

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.