191–200 of 266 posts
Earlier quoted context omitted.
No, especially if you’re expecting emails with large attachments. SES charges $0.09 per 1000 mail “chunks”, where a chunk is 256 Kb of data. This is on top of the base SES fee and S3 operation and storage fees.
But it only charges for each complete chunk. So < 256KB is free, 256KB is $0.09/1000, etc.
Say I've installed this.
I now want to write my own lamba service to handle contact form POSTs or something. Then I decide to delete it, but I accidentally delete one of these crazy email things. What happens?
Earlier quoted context omitted.
Again you only spend more time if you don’t know what you’re doing. I’m not a front end developer by any stretch of the imagination. Would it be a valid argument if I said that React isn’t a good solution because I have years of experienced with server side rendering? Again, don’t blame the tools just because you didn’t take the time to learn how to use them efficiently. If my name doesn’t give you a clue,I was aroun…
> If my name doesn’t give you a clue,I was around and developing way before AWS or hosted solutions was a thing. Being able to provision resources by writing yaml and not having to deal with the infrastructure gatekeepers is a godsend. Take some time to learn some soft skills, just enough to be able to convince people to do stuff for you, if you are the "throw over the wall ones" I recommend to get out of your sillo…
Don’t get me started on the “cloud consultants” who were just a bunch of old school net ops folks who only knew how to click around on the web console and duplicate and on prem infrastructure.
Yes, working for small companies I’ve had to manage servers and networks back in the day in addition to development.
We would even go with “Aurora Serverless” for our non production environments if it had feature parity with regular Aurora.
Earlier quoted context omitted.
> Not a single post on Hacker News can use the term "serverless" wits nhout the exact same replies being posted every time. As a serverless skeptic/critic, the buzzword bingo aspect of serverless computing is far from being the problem, and it's a gross missrepresentation of the problems posed by serverless computing. The main problem with server applications such as AWS lambda, along with lack of control, is how utt…
Okay, it may very well be true that one particular serverless product is very expensive or overly complex. That’s a fine argument to make. But that has nothing to do with whether the term “serverless” has a well-established meaning. It’s not just a buzzword, or at least it’s not always used as a buzzword and does in fact have a straightforward meaning. If I don’t like serverless products, or I think people need to be…
You're confounding two independent issues: "serverless" being a buzzword, and "serverless" not having a precise and well established meaning.
The fact that "serverless" is indeed a buzzword is indisputable. Thus the only issue that's up for debate is whether "serverless" has a precise and well established meaning.
The problem with the assertion that "serverless" is a meaningful term is that it turns a blind eye to the fact that "serverless" is expected to be an umbrella term that refers to multiple concepts, some of which are well established. For example, "serverless" is used by some people to refer to a more concrete and specific and well established concept of Function-as-a-Service (FaaS). Yet, albeit FaaS is portraied as a subset of "serverless" concept, FaaS does not represent the concept, which is assumed to be more broadly defined.
This ambiguity and vagueness opens the door to discussions on whether pain old "managed services" warrant the "serverless" buzzword, which would underline the buzzword factor by the way an old and well established concept is being rebranded. Then there are futile discussions on whether irrelevant and secondary implementation details of managed services, such as the degree of automation and auto-scaling, are in line with what is true "servelessness".
But in the end this collective grasping at straws just underlines the lack of substance behind the "serverless" keyword.
I’ve been working on a small side project that involves processing incoming email. In particular, it’s an app that needs to do something for each email it receives from (hopefully paying!) users. I am not interested in storing user mail, so SES is just too costly, at least according to a quick worst-case calculation. That leaves me with two options: 1. Self-hosted Postfix 2. Mail service like Mailgun With (1), there…
I’m actually doing something similar, I opted for SES, S3 and Lamda, I am a bit worried about costs, especially when i need to scale up, and handle larger emails.
Earlier quoted context omitted.
> There is no “overreaching area”. Amazon Aurora falls under RDS along with all of their other database offerings. You mean AWS Aurora serverless? https://aws.amazon.com/rds/aurora/serverless/ You're underlining the failing of buzzword-driven development. > No one on HN would accept an argument that technology is “confusing” Good. No one other than yourself ever made the mistake of doing so. If you have a hard time a…
Yes Aurora Serverless is a distinct offering. Regular Aurora you have a certain server of a certain size. Aurora Serverless autoscales - just like lambda.
Again, you're quite (and patently) wrong. Aurora Serverless is quite bluntly a configuration of AWS Aurora to add autoscaling to AWS Aurora instances.
https://aws.amazon.com/rds/aurora/serverless/
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
> Aurora Serverless autoscales - just like lambda.
If you're confused to the point of confounding autoscaling with serverless then I'm afraid there is no point to continue this discussion. You're just underlining the fact that "serverless" is a fad being mindlessly disseminated by clueless proponents.
Earlier quoted context omitted.
It's an annoying marketing term, sure enough, but the ideas it names aren't terrible. It's not always a mistake to pay someone else to take care of maintenance, scaling and security. Perhaps managed service would be better?
It’s more than just a managed service. RDS is Amazon’s managed database cloud service, but you still provision and pay for a specific virtual server with a certain number of CPUs and amount of RAM. “Serverless” generally implies that you do not provision any server hardware (even virtual) and instead only provide application code.
If the instance fails, you're insulated from that, right?
> This stack was created out of frustration due to the fact that to this day there's no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages. Interesting approach, though I solved this frustration by the use of a Docker and kept "my data is mine" + "no vendor lock-in" + "I control all the gears" approach. (Though, it's not…
> Interesting approach, though I solved this frustration by the use of a Docker and kept "my data is mine" + "no vendor lock-in" + "I control all the gears" approach. Yeah, I totally understand the desire. And even hosting this on a cloud, you benefit from SMTP TLS sometimes, presuming no active MITM and the cloud service not actively abusing its privileges on your VM or storage. Which is probably not happening widel…
Seems like a crazy amount of architecture. Does AWS keep all this stuff organized in some way, or will my personal experiments in Lamba accidentally break this because it's all merged together? Say I've installed this. I now want to write my own lamba service to handle contact form POSTs or something. Then I decide to delete it, but I accidentally delete one of these crazy email things. What happens?
Earlier quoted context omitted.
Serverless is beautiful. You just need to try some basic serverless concepts. Like run a website on S3. But to your second point, I agree. the technical hurdle required to learn all the configuration and moving parts ... And then to know that this language is vendor specific... Makes it less palatable. That's why I expect the cloud vendors to normalize their offerings over time. I should be able to take a CloudFormat…
How is running a website on S3 different from uploading your website to a shared hosting provider 20 years ago? How is it “beautiful”?