[yllus]

This is ridiculously over the top.

I run our organization's WordPress sites on Elastic Beanstalk (just do a "eb deploy" from your Git repo of the site and it gets up there), plus RDS (Amazon Aurora) and CloudFront. EB and Aurora auto-scale and CloudFront does its CDN thing.

I highly, highly recommend Elastic Beanstalk ( https://aws.amazon.com/elasticbeanstalk/ ) to anyone who wants their org to concentrate on creating value (new/better code) and being cost-efficient (use the compute power needed that minute instead of overprovisioning) instead of fiddling with custom server configs and wondering if you're fully patched up. It was a game changer for us.

[laumars]

EB is for sites operating at a different, smaller, scale to the kind of sites you'd host with the AWS design being critiqued.

Personally I've found EB to be a great development tool but it's really hard to manage once you step up into the enterprise scale. By that point you'd be writing your CloudFormation scripts by hand (or better yet, using Hashicorp Terraform) and "building stuff to fail" (as the adage goes).

edit: getting downvoted. I'm guessing some people are using EB for sites that generate millions of visitors a day (let alone minute like some services I manage). I'd be interested to hear how you overcame EB's shortcomings with resource failures breaking the entire EB build pipeline in often unrecoverable ways.

[rfks]

I owned a service running on EB that did 100QPS stable, 5K QPS weekly peak (with reasonably linear traffic increases) ~5 years ago. I'd still recommend it, but we hit some arbitrary limits / found leaky abstractions that took a lot of time to work around. Overall, I'd much rather own a EB app (or any other PAAS, or Kubernetes) than a tangled nest of bash scripts, JIRA tickets and tribal knownledge.

[laumars]

Well as I alluded to in my previous comment, there are other IaC options on the table that offer better granularity for deploying cloud infrastructure (and no, I’m not talking about Bash scripts).

In fact theses days there are a lot of Infrastructure as Code solutions out there. If you deal mainly with lambdas then there’s Serverless[1] or CDK[2] (Cloud Developer Kit). EB is itself ostensibly “just” a frontend for CloudFormation[3] (as I hinted at in my earlier post). Personally I use HashiCorp Terraform[4] the most but every single one of the aforementioned bar CDK has been used in production by my team.

However if none of those float your boat then there are a whole plethora of other IaC tools out there I’ve not mentioned.

So if you’re hitting the limitations of EB then your time is well spent learning another tool. In fact I’d go further than that and say I think it is worth your while learning Terraform (or any other IaC tool) even if you aren’t hitting the limitations of EB —- but I’m biased because of having wasted so much time in the past fixing deployments that EB has completely mismanaged.

[1] https://serverless.com/

[2] https://aws.amazon.com/cdk/

[3] https://aws.amazon.com/cloudformation/

[4] https://www.terraform.io/

[mike503]

EB is great, until it gets stuck in a weird status, then it sucks.

Also, WP works "mostly" but if you rely on shared assets (temp files, etc) and log files written to disk like woocommerce, mailchimp, and more do, those are silently inconsistent. most people don't care, but it's not 100% "correct"

So while it appears to work 100%, there are things under the hood that simply are misbehaving and out of sync.

Personally I prefer doing my own ASG or other methods than rely on EB anymore. I've had it break too much, and I can get a lot more scaling out of a completely custom AMI build.

[yllus]

I think there's a balance to be struck here depending on the type of site and what organization you work for.

If you're thinking long term and beyond the time period that you yourself will be employed at your org, you should put serious thought into making as vanilla and out-of-the-box a build as possible. My organization has a simple path to getting new developers up to speed on how to maintain and further update our Elastic Beanstalk-served sites: Learn the basics of how EB works and you're good to go.

On the other hand, if I had put together a superbly optimized AMI and grafted each site onto it, a whole lot of question marks start to appear. What distro is being run? Who/what's keeping it up to date? How do you connect to it? (On EB, you type "eb ssh" and it logs you in.) What's the load balancer setup look like? Where is all of this documented?

I think the trade-off of a few percentage points of optimization versus the fully-documented nature of a packaged service and the simplicity of getting someone new up to speed... I'll drop the few percentage points any day.

In fact, a few weeks ago a media org I frequent often had a site outage - they run WordPress so I offered to help (it was the weekend and I figured their IT guy might not be available) and they took me up on it. It took me five minutes to solve the issue and twenty-five minutes to understand how their custom, minimally documented setup was designed. I don't think that should be the norm.

[headcanon]

Sounds like your setup is only 2 steps away from what OP describes:

1. If you need multiple WP instances, you'll need to duplicate that setup with read replica + load balancer

2. If you want to do things enterprise-proper, you'll want to set up a VPC, which means you need the internet gateway + some routing setup

And voila, thats the above architecture. If you don't need it you don't need it. But none of this is particulary complicated to set up if you know what youre doing, especially if you're using Terraform.

[neurostimulant]

> 1. If you need multiple WP instances, you'll need to duplicate that setup with read replica + load balancer

Don't forget that wordpress is not stateless. It'll need write access to its code directory, which complicates scaling. AWS has EFS which support up to 1000 clients, but at that point you'll probably better off rewriting your website with something else that easier to scale on the cloud.

[yllus]

Elastic Beanstalk comes with the load balancer already in place, I've never had to think about load balancing as a thing-to-figure-out. And Amazon Aurora lets you set up a read replica / autoscaling policy as you're setting it up.

Honestly - it's a pretty painless, AWS-takes-it-from-there setup.

[BrentOzar]

How do you handle file uploads from the front end, like when users upload pictures for their blog posts?

[yllus]

There's a lovely WordPress plug-in called WP Offload Media Lite ( https://en-ca.wordpress.org/plugins/amazon-s3-and-cloudfront... ) that takes the upload locally and re-ups it to an Amazon S3 bucket of your choice. Five minute setup job (put in your keys and the bucket name) tops.

[thomas]

Exactly. Would recommend people investigate this route for most cases.

[Kiro]

That sounds overly complicated as well. I upload my WordPress site with FTP to a web host and it just works.

[yllus]

Everything depends on your organization's scale and complexity! We've got multiple developers and have a workflow built around Git (feature branches, pull requests and all that); in my opinion a professional development outfit that doesn't use version control is failing at one of its basic responsibilities.

[Kiro]

I hear you. I do however use git but it's unrelated to deployment. I just upload master and overwrite everything.

[brodouevencode]

Wordpress + Beanstalk is fine for small deployments. Anything bigger and you'll need a true microservices architecture using cloud native technology.

[inapis]

That statement requires quantitative and qualitative qualification. I know of people who are running sites with multimillion visits and revenue using a basic monolith. One even runs a Wordpress install configured with decent caching to serve millions of visits an hour.

If you are read heavy, offloading static assets to a CDN and having good caching will get you very far. If need be, you can load-balance between databases and you’ll still go very far.

Micro-services is not necessarily synonymous with scale.

[brodouevencode]

And in doing so you're flushing tons of cash down the toilet. There are leaner, more optimal cloud native ways of serving content.