51–60 of 266 posts
Earlier quoted context omitted.
No it’s not just managed hosting. Managed hosting still means there is a server to maintain, patch, and that it is always running.
There's a firecracker VM and a Linux OS under the Lambda. Both of which need to be maintained by Amazon. Edit: "managed cgi-bin" is perhaps more apt.
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...
The term serverless is such a misnomer. While this is a cool project, you'd use 3 different servers at a minimum here.
Earlier quoted context omitted.
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…
If you're running a saas and the increased traffic comes from paying customers, you likely prefer a huge bill to downtime. 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.
> If you're running a saas and the increased traffic comes from paying customers, you likely prefer a huge bill to downtime.
Well, in such situation, I would probably run more advanced container orchestrators such as Kubernetes which you will then configure to automatically spawn the additional server instances.
Of course there are certain advantages in running a serverless code as you have just mentioned, but since my primary concerns are "my data is mine" + "no vendor lock-in" + "I control all the gears", it is not the best option for me. Unless I want to run & provide the serverless services by & for myself.
It's always a game between the security (more freedom) and the convenience (less freedom). Though, for some, there is more freedom in the convenience (until they start to see their hands are in the digital cuffs :P)
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 suspect the "serverless" word was created due to the emotional appeal to a specific (majority) group that is strongly opinionated against having servers at all.
Reading from the README.md file:
There are two major limitations with SES:
For security reasons, AWS defaults to 200 emails sent per 24 hour period at a rate of 1 email/second. If you need to send more than that, you'll need to ask AWS to increase your limit.
By default, you can't send emails to unverified addresses. If you'd like to be able to send (as opposed to just receiving), you'll need to reach out to AWS to remove this limitation from your account.
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...
Indeed. I suspect the "serverless" word was created due to the emotional appeal to a specific (majority) group that is strongly opinionated against having servers at all. Reading from the README.md file: There are two major limitations with SES: For security reasons, AWS defaults to 200 emails sent per 24 hour period at a rate of 1 email/second. If you need to send more than that, you'll need to ask AWS to increase y…
Also, it is incredibly easy to ask AWS support to increase the limit. A startup I worked with had only thousands of users; we told AWS about it and they gave us 5 million emails per 24 hours.
Earlier quoted context omitted.
"serverless" is just "managed hosting" under a new name, I believe.
No it’s not just managed hosting. Managed hosting still means there is a server to maintain, patch, and that it is always running.
See because only science has a concrete fixed point for measuring which is the speed of light.
Human culture is subjective buzzwords where the only relative fixed point is when they learned a term.
Serverless is “managed hosting 3.0”.
First there was bare metal, run your cage. Then ec2/traditional VMs. Now just an ephemeral thread.
Computer people need to stop thinking in terms used by product & marketing people. Reasoning around it from the perspective of how it’s implemented specifically helps with the understanding.
It’s a Linux OS wrapped in layers of UX to facilitate composition of services. Unix command line tools at scale.
Cloud provider is just an OS at scale. They handle CPU, memory, scheduling, etc., all the same things a desktop OS does from the end user perspective, using a different process model we don’t generally care about as end users
Hopefully OpenAPI will help normalize this interface. Who knows though. Rich people like to drag their feet when they think sticking with the status quo gives them an advantage. Bezos may feel like making it easy to copy paste away from his cloud is a shitty idea
Earlier quoted context omitted.
Probably this means that there is no server you can SSH to nor need to maintain. It could probably be called a serverhostage/server-lock-in computing, where someone else keeps the _shared_ server(s) away from you and runs other people's, potentially harmful, instructions as well :-)
So how is it different than running it in the cloud?
To me it's like having one hand tied behind your back while someone else uses their hand to do what you'd have done with the one tied behind your back. It's cheaper, sometimes it works the way you want it to, but you always feel a bit restricted.