@K4270X
Theo is really not a numbers person. Miscalculating the amount of requests per month and thus monthly price. His final calculation was 2625 req/s * 60 seconds per minute (or 60 minutes per hour) * 24 hours per day * 30 days per month * 0.5GB * 0.5 seconds per request * 0.000016667 Lambda GB/s cost, which comes to that ~$472.5/month. The real number is 60 times higher at ~$28350/month, which would blow the concept of serverless out of the water. Even if we would use the 90ms mean response time from the tweet as the request length final price would be ~$5103/month, which would still be twice the baremetal estimation. While serverless offers other benefits over baremetal/dedicated setups(like worldwide response to loadspikes etc.), this all sound to me really hard sell. Just my 2 cents.
@SpeakChinglish
27:03 if you want to skip all the explanation about what serverless is
@danBhentschel
"The idea of a database platform being servers that are separately running from your application code was ... a kind of new concept." This doesn't match my experience. I was writing 3-tier (client, server, DB) applications (in VB of all things) at Kodak in 1998. The DB was an Oracle enterprise DB on who knows what server, maintained by a completely separate group. This was common practice, at least in corporate development.
@T___Brown
Last 20m of pointless numbers was painful
@MadsterV
The "old way" was called a LAMP stack: Linux, Apache, MySql and PHP. Your SQL database was separated in a different machine (or cluster) back then as well, that is NOT what Mongo brought to the table. Mongo brought easy horizontal scaling through sharding. Now, on Serverless: "does serverless mean the dependencies get installed for every call?" NO. Instances spin up and hang around as needed. The cost of spinning up PER REQUEST would be INSANE. The first request that triggers the new instance will usually fail, so unless you want every request to fail, that's not a way forward. Regular AWS instances are like docker containers that get started/stopped, while Lambdas use that scheme where the server is already waiting with one of their containers and only your "function" gets loaded, IIRC, so Lambdas can load balance more aggressively, but they do hang around for quite a bit and if there's traffic to handle, they won't unload. Serverless (lambdas, scaling to zero, as opposed to "cloud") is not cheaper though: it's way more expensive at the same throughput. If your traffic is predictable, you're much better off with regular containers.
@ivypierlot
15:18 i love async rust and ive programmed a lot if it, i enjoy it, i fw it heavily, the speed, the ease of programming, and the scalability
@shadeblackwolf1508
The dirty secret of cloud computing, the providers just renting out their overspec to customers, like landlords rent out homes they don't live in.
@hschimpf
For everyone that is complaining about the calculation costs. Yes, the calculations are wrong. Yes, it's 48,5k /month on arm and 60,2k /month on x86 (including computing + request + storage charges) But, that's on peak traffic. If you take Theo's point, that the rest of the time you would have less traffic, maybe (a big maybe), you can go below fixed costs of having the hardware. Also, you can have all of your environments and deployments available forever like he show. He's not only pointing at the compute costs of your main/production environment, it's all the doors that serverless opens to you can have a better overall experience for your team. And, it's not for every project, not all projects should run on serverless. His uploadthing project for example, he do has a dedicated server/vps for the ingest of files. Again, it's not for every project or every part of a project. And lastly, if you go full serverless, you should use all the tools. For ex: from that amount of requests, how many are assets like js, css, or images? You can serve those through an S3 bucket, and avoid paying the costs of serving them from a Lambda. In most cases, one requests will be followed by 5+ requests of assets. If you build your app environment using all serverless tools the right way, you can lower the costs drastically.
@bluecup25
Imagine being in a relationship with Theo. You'd constantly hear "we need to talk".
@mmhnef
I love the proliferation of these tech influencers. Because if this is the standard of knowledgeable, i know that Ill be perpetually employed.
@brennan123
We've gone from dedicated servers, to VMs, to containers, to functions. Next up is Logic Gates as a Service (LGaS). Just spin up however many you need, and wire them all together with a bunch of YAML files.
@redcrafter502
52:40 of course we want to hear you talk about CloudFlare
@notsoluckycharm
If you were doing anything fairly large, the history is kind of inaccurate. You could have database clusters, your reverse proxy, and application code on different servers. AWS didn’t really invent that. What AWS (also didn’t invent) did was make “infinite” scale a thing for anyone with the budget. In 2012 I worked for a startup they had to plan bandwidth around. You could also spin up ec2 instances in under a minute for app code, you just had your AMI setup. Scaling your database was a whole different animal though, which is what makes RDS amazing.
@dumboluzz
I think your calculations are wrong: Lambda cost 1GB/s 0.0000167 DHH req per month: 2500 * 60 * 60 * 24 * 30 = 6,480,000,000/month Lambda cost/month: 6,480,000,000 * 0.5 * 0.5 * 0.0000167 = 27,054 USD API Gateway cost 1$/million req: 6,480$/month
@SageMadHatter
When you describe “the old way” of doing server architecture, sounded more of the experience at a company not having to deal with high concurrency. In 1999, at the company I worked for we had to separate our apache and java layer into separate boxes, backed by an oracle db, to deal with our concurrency. AWS did not invent the concept. What Amazon brought to the table was giving companies the ability to spin up server software, without having to own their own data centers and the tooling to manage those servers and the software on them.
@DevMastery
As others have mentioned, it’s not entirely accurate to say that AWS invented or even popularized the concept of ‘database-on-a-separate server’. It might be helpful to differentiate between the ‘history of tech’ and ‘your personal journey with tech’. For instance, saying ‘I used LAMP and then MEAN, and I didn’t realize that putting databases on a separate server was a thing until AWS came along’ might have been a more accurate way to describe things. That being said, there’s a lot of valuable information here, and I really appreciate all the hard work and effort you put into creating this content.
@kittydlyw
I do wish in your price comparison of baremetal vs serverless, you also mentioned autoscaling managed databases (non scale-to-zero), as I think it leads people without that context into wrong conclusions (that I fear as the platform engineer I'll have to teach people myself later). Also maybe would've been good to re-record the calculations since I got a bit distracted with my other monitor half way through ahahaha. Other than these notes, amazing video! Thank you so much, it gives me a greater appreciation of serverless, and especially, it makes me reconsider how I want to optimize for these scenarios (extreme changes in requests per second) while thinking about modern solutions like Vercel and Turso as great examples of how to do it right. Stay awesome!
@MacDBroski
I believe the math wrong assuming that 5250 req/s was consistent it would be 5250 * 60 * 60 * 24 * 30 for it to be per month
@bobbycrosby9765
I'm sorry, but the beginning of the video makes this whole thing hard to continue. It sounds like you were a new developer with the lamp stack. Running a DB on a different server from your app code was nowhere near a new concept when AWS came out. Every professional web developer I knew was already doing it by the time AWS came out.
@gabrielbianchi2246