31–40 of 266 posts
I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...
"serverless" is just "managed hosting" under a new name, I believe.
Earlier quoted context omitted.
Do you mind writing a blog post somewhere explaining to noobs how this can be done? This will be a great post with lots of traffic I imagine! Thanks, great work!
I am actually thinking on writing it since long ago... But not motivated enough... :/
I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...
I still fail to understand why 4 years in, people seem to be confused about the idea that definitions of words involve over the years and that the computer industry has both been coining and adopting phrases. But a quick Google search is all that it would take to “understand it” https://en.wikipedia.org/wiki/Serverless_computing
I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...
Serverless: Somebody else's server
And the shackles will be broken...
I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...
Yeah, it's a really dumb term. > Serverless computing is a cloud-computing execution model in which the cloud provider runs the server ...so, there is a server? What's with the name, then?
Earlier quoted context omitted.
It's pretty well understood by now that serverless is meant to connote that you (the firm owning the application) don't manage the server(s). Someone else does it while you just bring your application code.
Correct. It is a misleading term, imo.
Nowhere else on HN is willfully not taking the time to learn about technology celebrated except when it comes to cloud concepts.
I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers. [1]: " rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...
I still fail to understand why 4 years in, people seem to be confused about the idea that definitions of words involve over the years and that the computer industry has both been coining and adopting phrases. But a quick Google search is all that it would take to “understand it” https://en.wikipedia.org/wiki/Serverless_computing
Wow, this is cool! JSON structures resemble JMAP. I wonder what'd be the effort to add JMAP endpoint to this?
Earlier quoted context omitted.
Another drawback is that while yes, you can scale up fairly easily with terraform, your server can also fall over if you get a heavy burst of traffic, and you'll return errors until you're able to provision more machines. Depending on what you're doing, how fast you're growing, and how much tolerance your users have for downtime, that might be a pretty big deal.
Yeah, this is normal. One bus can't fit more people than it physically can. The high load can be alleviated by the use of more MX server DNS records (and the MX servers of course, across the different locations), LBs, smarter thresholds. Of course nothing is a panacea. Either way you will hit the AWS's limits or will get a huge bill. And then, even if you set up the budget limits, it still won't make the service more…
But apart from that, there's a huge benefit in saying "I'm happy to spend any amount up to X" and not needing to do any capacity planning beyond that vs. continually trying to guess what's the right % to over-provision your VMs and having downtime when you get it wrong.