svorobyov

Thanks a lot, that’s all I wanted to know.

In the era of AWS & Co no one needs managed WP hosting any longer – anyone with a little knowledge (like me) can roll their own best fit for the purpose, fully automated and without any support teams. I just wanted to know the state of the art (which appears quite poor to me) before starting to roll my own…

0. Speaking of good infrastructures – the AWS-authored “reference” WP architecture I mentioned seems completely unsatisfactory to me.

1. Mounting a filesystem between servers has high latency (and AWS EFS is a relic; AWS EBS can be mounted on a single instance at a time).

2. Thanks for the HyperDB pointer, I’ll consider that. But notice that with my solution scaling DB is a no-brainer – stock MySQL replicated on every instance will do the job of (infinite horizontal) scalability.

Forgot to add an LB is needed not only for load-balancing, but also for offloading HTTPS and keeping auto-renewable AWS certs

Yes, I do have many infrastructures of the kind: 1*(LB) + 1*(WP+DB) instance, which I always wanted to (but cannot with the existing tools/plugins) make auto-scalable to 1*(LB) + N*(WP+DB), where N autoscales.

BTW, M*(LB) would not work as you suggested because the WP’s DB keeps (in wp_options) the LB’s hard-wired URL, like site_url=https://foo.com.

Apparently, the best thing I will need to implement is my “every WP instance listens to emerging of the latest-update.wpress and then wp ai1wm restore this latest-update.wpress on itself.”

I simply wanted to know if there were any existing standard solutions, but apparently there aren’t. I am surprised, despite WP powers 27% of the web, people keep their WP web sites so rudimentary simple/unsophisticated: no autoscaling + frequent continuous updates.

Thanks, Yani!

1) I disagree: if you have many php processing servers behind an LB, your ain1wm import/restore request will be load-balanced to just ONE of them, will execute and update styles etc. only on this server/instance, and the others will remain unupdated. Right?

2) So, like I said, EVERY PHP server/instance should listen when a new update shows up and install it. This is especially important if we have AUTOSCALING, when instances get born and die depending on the load; hence every newborn (from an already outdated AMI image should notice that it is outdated and ain1wm the newest .wpress).

3) I am more in favor of having a DB instance on EVERY PHP instance (your last option) because: a) this is “real scaling up”, without a single bottleneck DB; b) Amazon RDS instances are unreasonably expensive (besides creating a bottleneck).

Do you agree?

I found a “reference” AWS WordPress farm architecture:

https://github.com/aws-samples/aws-refarch-wordpress

but it is unsatisfactory since it lacks the update functionality like the one provided by your All-in-One WP Migration.

In a single server setup, we currently develop on a Dev server and when satisfied push changes to the Prod server in one click using wp cli and ai1wm.

Best regards,
Sergei