mark242

But you're operating at the wrong scale-- 30k messages to a domain can happen in an hour by a spammer doing a directory attack. The point is that this solution is extremely open to abuse that happens all day every day over SMTP. Without a fixed-cost firewall to reject messages and only allow clean messages through to this solution, you are going to have escalating costs.

SPF and DKIM require opt-in by the sending domain, of which the majority of non-commercial non-US outgoing MTAs do not do. IP-based blocklists, including Spamhaus PSBL Mailspike etc, are all valuable to catch IP addresses that should not be directly connecting to your MTA. I agree that signing up for an outgoing MTA service such as Sendgrid makes some IP-based checks obsolete but that's not where the majority of spam is coming from. Botnets continue to be the number one source of junk email and will likely continue as we add more and more insecure doorbells, garage openers, refrigerators, etc, to our home networks.

SQS is just such an amazing tool in a developer's toolkit that is one of those transformational pieces to how you write software. Combine that with Lambda to consume messages, S3 as your object storage, and Dynamo as your state management, and you unlock the capability of a single engineer to write applications that would have taken teams and teams of people only a few years ago.

Again, does this mean anything to the Wordpress crowd? Probably not. But the ability to bring a new project to market quickly and grow that project is no longer bottlenecked by how fast you can get on your phone to your colo provider on Saturday night.

If you are treating cloud services as purely an apples-to-apples cost comparison then you've missed the point of deploying to (insert your favorite cloud provider here). What you get with cloud services is flexibility and speed. If the OP wants to undertake a new project that they have no idea of the resulting workload or popularity, they need to guess about the required underlying infrastructure. If you miss on your guess, you can either kill momentum for that new project, or you can wind up overprovisioning and paying way way too much on hardware.

I'm not sure how quickly their colo provider could spin up new hardware for this hypothetical new project, but you can assume it's not the dynamism that you get from deploying to an elastic cloud environment. Again, you're paying a premium on day-to-day costs in order to have this freedom to create and deploy. That's what cloud infrastructure is about.

To give an example -- I have a very-CPU-heavy workload that started its life out on prem. As more and more customers signed up, I would go through tiers of adding more hardware to a rack, where my overall margins looked like a sawtooth waveform when I would provision more hardware. I started out moving to EC2 and then finally to ECS/Fargate. If I want to spin up a new piece of functionality for my users, I don't need to provision any new hardware, set out any real new infrastructure, or do anything that you would consider prework in order to get that new functionality deployed. My margins are much much more predictable and I get faster time-to-market on feature development. That's what you're paying the premium for, that ability to just move faster.

Your 1mb webpage is approximately 60ms worth of Disney+ streaming.

Your 1mb webpage is approximately 1.7s worth of Zoom chat.

Your 1mb webpage is approximately 1.9s worth of Tiktok video.

Unless you are specifically targeting low-bandwidth users, you need to worry about product market fit long before you worry about slimming your js bundles down.

A ReplicaSet, as given in the OP's yaml, does not suffice here because it is not guaranteed that the failing pod (which triggers a new pod to start) doesn't come back to life. That will almost guarantee your postfix installation to break especially as one postfix instance starts cleaning up files possibly during the time period where another postfix instance hitting the same directory is trying to access them.

On edit: yes, Postfix 3.3 can be run as a container process. What I mean is running it within a standard container environment where you would expect multiple instances to run for failover etc.

"at least 2 database-touching requests for every person reading the post" should never be a blocker for 2 requests per second unless you truly do not understand your application infrastructure at all.

on edit: The better solution here would be to figure out where the MySQL server was being put under load -- hint, it probably was 99% idle, because unless that sidebar file was making an unindexed query there's no way things would take 500ms -- and then realize that you need to bump up the number of database connections in your php pool to be MYSQL_MAX_CONNECTIONS so that php isn't blocked on obtaining a new connection. Problem solved.

This is my point-- I am not in the hosting business. I am in the application creation business. Every minute that I even have to think about modifying /etc/localtime in order to make sure that the instance is running in UTC is a minute I'm not being productive. Multiply that by those million little things that you have to do in order to keep even an ec2 instance running, and it's such a colossal waste of time and effort. Similarly, I am not in the database tuning business. I plan out my data relationships, create the required Dynamo table or tables, and I never need to worry about replication or backups or any of those ancillary tasks that keep me from being productive.

Meanwhile, I don't have to do things like /make sure the ETL process is running/ or /clear out a bunch of logs when a disk inadvertently fills up/ or any of those other stupid last-century compute problems. It's just a far, far easier way of thinking about application development.

Does it make sense for FAANG to run their own datacenters? Yes of course. Does it make sense for you? No. This is what I don't get about arguments for running a bunch of VPSs-- for literally any environment that isn't thousands of engineers, it is more cost effective to let someone manage your underlying infrastructure for you, and any workload at that scale, you aren't contracting with some random bare metal hosting shop.

Let's say that Hetzner server goes completely toast at 2am and you get a pingdom message. You log in, realize you have to restore from backup. You fire up a new instance, and go through your restore procedure, and everything works great. You're lucky to be offline for an hour.

I cannot even tell you what would happen if an underlying instance running a Lambda goes offline, because it never happens. But let's say that an underlying machine dies in us-east-1. Lambda just starts running more instances of your code on another underlying group of cpus, and you aren't offline.

I cannot tell you the number of times I have implemented "upload your photo and it'll get resized to (profile avatar size from design specs)". It's ridiculous, and it's one of those things that everyone burns time implementing their fun hook into Imagemagick. Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done.

I cannot tell you the number of times I have implemented "when this user signs up, send them a welcome email." It's one of those things where you construct your email, point it at your MTA, do a ton of configuration, then it may work. Now I have one lambda that gets pointed at a new record stream from Dynamo, which calls SES, and I'm done.

I cannot tell you the number of times I have implemented "clear the Redis cache if a user changes their preferences". You write a clearUserCache hook into your DAO, or you paste it manually into your crud functions, and you always forget something, and six months down the line you start getting bug reports of people's zip code not updating, or something. Now I have one lambda that takes record streams from Dynamo, removes a key from Elasticache, and I'm done.

It's not that you couldn't do this before serverless, of course you could and you still can. It's that it makes that level of code reuse that much simpler. You have all of these helper infrastructure functions that you implement for every single project you work on, and reusing that glue code is so, so much easier in Lambda/GCF/AF/etc.

Here's a popular question these days: "when can I stop supporting IE 11?" With GA, the answer comes in a couple of clicks; revenue generated sliced by browser version. I don't even see the revenue generated section of Plausible, or really any way to associate any metadata with custom events. GA gives you this functionality without any coding.

If you don't want to use GA, try something like Amplitude, which has a lot more data manipulation options than Plausible.

This is really disingenuous-- a DBA should not be a gatekeeper of what gets put into a database. Storing 200 bytes of extra data per row costs you absolutely nothing. Even if you assume 100 million photos, that's 20GB of data. That's a little over $2 of EBS cost per month. Who cares.

"The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts.

"Prefer one page over several" is diametrically opposed to the hypertext model. Please don't do this.

"Stick with the 13 web safe fonts" assumes that operating systems won't change. There used to be 3 web safe fonts. Use whatever typography you want, so long as you self host the woff files.

"Eliminate the broken URL risk" by... signing up for two monitoring services? Why?

I think this list of suggestions does a great disservice to people who just want to be able to post their thoughts somewhere. There's an assumption here that you'll need to be technically capable in order to create a page "designed to last" and frankly that is not what the internet is about. Yes, Geocities went away. Yes, Twitter and Facebook and even HN will go away. But the answer sure as hell isn't "I teach my students to push websites to Heroku, and publish portfolios on Wix" because that is setting up technical gatekeeping that is completely unnecessary.