The comment on "complexity-as-a-service" resonates. IMHO, it's primarily because they want to make a product out of everything, including stuff companies build to manage their own AWS implementations. Instead of a simple list of products, its a complex list, with lots of nuances per each service offering. The other day, I was giving a high level summary of cloud technology to an intern; there was a point where I couldn't even find the AWS service I was telling her about from the product list, which annoyed me. Maybe that's more a comment about the marketing site though, but still, when your product catalog gets that big, its hard to avoid ridiculous levels of complexity.

From that Let's Encrypt article: "We have a number of replicas of the database active at any given time, and we direct some read operations to replica database servers to reduce load on the primary."

Maybe they run reporting on the read replicas because those can take a long time.

I tend to agree with this. AWS etc is nice if your scale is big enough that you need to run a big cloud of dozens of servers with complex interconnections for security etc. If a single plain old server with database etc on it will do the job fine, much better to stick with that.

No?

A bare metal Postgres install needs optimization, and a working backup and restore plan (you did test your backups, right?).

That's half a day of work lost to get your system set up.

Now your app keeps serious data and you want a read replica. How long does that take?

Now you need a separate development environment. Here you go again, adding a few hours of work.

Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window.

You just racked up several day's worth of work, and for a DB instance with a similar amount of infra work done, the RDS solution is way cheaper and easier to provision.

If your time is worth money, there's no reason to go bare metal.

I still disagree and say yes.

Why does my bare metal Postgres install need optimization? My sites mostly doesn't get much traffic, and it runs fine as-is. It'd be silly to try and optimize it without being able to measure what's actually slow.

Backup systems should also be set up according to desired reliability. I have a 10-line bash script that pulls a DB dump, zips it, and sends it to S3. Under 5 minutes to install, including setting up a new AWS role and keypair for it, just have to add in some Ansible commands I already have set up, and set a cron job to run once a day.

Read replicas are nice for some applications, but not needed for any of my current ones. I probably wouldn't want to set one up on bare-metal admittedly, but I'm not worrying about it until I need it.

I don't see a need for a separate cloud deployment for a development environment for my current application either. Would be nice if I had multiple developers and testers working on it, but I don't now.

Never needed to update the DB version, and the traffic is low enough that I don't need to really care about keeping reasonable change windows if I did.

So nope, 10 minutes of work for a low-traffic application. Meanwhile, a AWS RDS setup is easy to start, but then you have to muck with security groups, VPCs, permissions, etc to get it working right. That's not necessarily easy if you don't already make use of that stuff.

Probably you should try sqlite. And maintenance will be even easier.

There's gonna be a lot of judgement calls here, but I think a local Postgres install is the happy medium. A basic local install is super quick and easy to do, and it also has a lot of good scalability options. SQLite is okay as long as you stay small, but it doesn't scale up very well.

If I suddenly get big and my database is Postgres, then I can spin up my own dedicated server, or switch over to RDS after all, optimize concurrent queries, hire a DBA with scaling expertise, etc. Most of that isn't an option with SQLite. I'd have to switch to a completely different database engine. Despite the promises from ORM writers, I've never seen this go smoothly, and it would have to be done at the worst possible time for it.

> Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window.

What, as opposed to needing to read the RDS patch notes, and schedule the maintenance widow?

You might need to read the Postgres version changes for your internal databse code, but you're not gonna need to devise and execute a procedure for upgrading your database, which is essentially done with a single click in an unsupervised manner.

+1 also it's easy to use Docker containers and Traeffik as reverse proxy to manage many services.

Which scripting or which infra do you use for automatic installation/configuration of your server?

Not OP, but I did the same and I use

- Ansible for the low-level stuff (like network, mounts, iSCSI, configuration files) - Terraform for high-level stuff (like DB users)

In my case, as I have several services that use a lot of RAM running, I couldn‘t afford The Cloud but can easily afford a colocation. I don‘t mind the maintenance (it‘s a couple hours each month) and I don‘t care much if services are down a few hours.

If you need something running 24/7 with 99.9%, colocation will be more expensive just because of the human you need.

Why wouldn't you use Ansible for the high level stuff? It can easily manage DBs and you wouldn't need another tool.

Not sure about op but you have to put forth quite a bit of effort to get declarative infra with Ansible. Some of it is declarative out of the box but a lot is imperative.

The main difference, if I revoke a DB privilege, I have to add a line to Ansible with a REVOKE in most cases versus Terraform you just delete the config line and the tool realizes during its diff stage and performs the removal change (it's stateful and declarative)

Does terraform has any drifts for example if I remove a db from terraform is it going to.remove the db from prod? Can I trust it's always the same or do I have to do cleanups?

Terraform is declarative, meaning: The stuff you write into the terraform files (TF) is exactly the stuff you get configured.

Example: you add a new database and a database user to the TF files, run terraform plan & apply, you do have the database and user configured. You remove the user and run plan & apply, terraform does remove the user.

It goes the other way too: if you add additional port rules to a network security group (e.g. in AWS) by hand, terraform will remove them when plan & apply because they are not defined in the TF files.

So in conclusion: for your declared state, there will be no drift.

As nijave said, the declarative style is the difference. I can read a terraform file and already know the exact state my system will have.

Laravel Forge

What's your exact stack.. just ssh and bash script?

On bare metal as well. Not a trace of doubt.

It also seems more feasible with concurrency focused languages such as Go which have become more popular in recent years

I do not see anything less feasible doing it with threads / forks.

Asynchronous IO like in Go I think is useful in a sense that if some of the networked responders are temporarily slow then they will not hold fast ones and would not accumulate threads. If however it is disk / database, then by immediately switching to a next method this strategy will let internal async tasks piling up indefinitely and saturating resource pools of OS just as well. So those "concurrency focused" languages are not a silver bullet and one has to understand internal mechanics to properly manage requests lifecycle.

What is blocking you from using just EC2?

A year of free startup credits, I'd guess.

Their config costs around 230,000$, which i think is impressive for a single server