5 ms·
There is a lot of scoffing in this thread and I agree AWS does make some things overly complicated but I think the scoffing here is unfair because the architect
by laumars 7y ago
There is a lot of scoffing in this thread and I agree AWS does make some things overly complicated but I think the scoffing here is unfair because the architecture looks far more complicated than it actually is.
First of all, lets bare in mind this is talking about larger, enterprisey installs. So what would you need if you hosted on-prem:
- a DB with a read replica in case your main DB died (RDS can actually build read replicas for you pretty easily so this part of the deployment would be much easier than doing the same MySQL replication config on-prem)
- Redis for caching (my experience with WP is a couple of years out of date now but when I last managed an highly popular WP install (several in fact) Redis or Memcached caching was a necessity to get the kind of page load times our visitors expected)
- Shared storage (bare in mind you're running more than one WP web server - if this was on prem you'd be hosting those files off a SAN)
- A load balancer (I don't think I need to explain a justification for that one)
- And probably a CDN too (reduce the stress on your web-servers and internet gateway)
That's literally the bare minimum any large Wordpress application would need and that's all that AWS architecture is outlying. Sure there's a few more items on there like NAT gateways but those are just network stacks that are deployed as part of your VPC (or in on-prem terms, that's just the VLAN and/or subnet management that you'd assign to your load balancer).
If you don't need multiple web-servers nor high availability then your architecture becomes drastically simpler (no load balancer, no shared storage, no replica DB, etc) but also you would run the risk of downtime and even data loss. Which might not be an issue for some people but it's also not one of the selling points of AWS. So you'd be better off with shared hosting or a managed WP service -- or to put it another way, AWS was never going to be a good fit.
edit: Personally I think the issue here is more WP -- or rather the classical CMS design -- than it is AWS. A static site generator style of CMS would be a lot simpler cloud design and run a lot cheaper too. WP is designed from an era when web shops had this infrastructure set up by default.
- snowwrestler 7y agoFor me the scoffing is because Wordpress is such a well-known and popular CMS that there are hosts that specialize in it and have all this architecture pre-baked. Of all the CMS's in the world I can think of, Wordpress seems like the least likely one to require a bespoke from-scratch hosting strategy. I self-hosted Wordpress for years and yes this architecture is not unreasonable for a high volume site. Now I pay WP Engine a fixed annual fee and all this comes out of the box with a few clicks.
- cat199 7y ago> Wordpress seems like the least likely one to require a bespoke from-scratch hosting strategy. wordpress may not, the org deploying it might.
- brodouevencode 7y agoAgreed. The example included was to show HA for any CMS/dynamic application. You could easily sub in Wordpress for just about anything. It accounts as an example and not a complete recommended solution, though it could be one depending on your needs. But because it comes from QuinnyPig it gets more Internet points.
- momokoko 7y agoBut all what you described will port, with some adjustments, to a different provider for another decade. This is all to host on one specific host. The money spent on planning and architecture is a one time cost and it is very high. Not to mention the much higher cost of ownership over time for hosting on AWS. AWS feels like hosting on IIS back in the day. It was extremely expensive and pointless for more than 50% of their customers, but people kept saying “but we’re enterprise!” and throwing money away until the world finally woke up.
- Spooky23 7y agoAWS is just not a toolset optimized for Wordpress in a SMB/Startup/Hobbyist org. And organizations who do enterprisy stuff on AWS aren't optimized for IT practices that look sane to others. You need this complexity in an enterprise environment because the web teams don't have access to databases, and the DBAs aren't allowed to manage databases outside of the data network, etc. That's why enterprise content management exists. Big companies and public sector value repeatability and seperation of duties over cash and time.
- closeparen 7y agoSeparation of duties is the root of so much evil. I'm very glad to work in an environment where anyone can submit a change to anything - it just has to go through code review. Same security property: malice requires conspiracy. But also safety against mistakes.
- brodouevencode 7y agoI think you're right on the first half. For monolithic apps, it's expensive to run on AWS. Expensive vs. the DC depends on a lot of other factors so YMMV. 12F apps, microservices, etc. are much _cheaper_ to run on AWS because you don't have to worry about scaling/provisioning/and HA/DR capabilities are basically baked in. A lambda that processes 100,000 requests/day is, on average from the teams I've worked with, significantly cheaper to run than a machine in a DC that is always up.
- Hikikomori 7y ago
- snuxoll 7y agoThis is more just basic requirements of ANY application requiring HA. A MediaWiki install I manage has a more complicated deployment, files reside on DigitalOcean spaces so there’s no NFS bullshit but there’s still multiple instances each of nginx-ingress, trafficserver, memcached, mysql, nginx/php-fpm, keycloak, cronjobs to run background tasks and a managed load balancer in front of it all. Still, then bill in comparison to AWS is cheap - base costs are $125USD/mo for the 6 droplets and spaces storage. We just enabled auto scaling for the MediaWiki instances so it can vary a bit now, but traffic is bursty so it won’t go up by much.
- stevekemp 7y agoBear in mind a lot of startups get a ton of free AWS credits, which means the sticker-price is almost irrelevant.
- deleted 7y ago[deleted]
- steelaz 7y agoWe run very similar scaffolding to host different workloads, except we run it on ECS, so you could complicate reference diagram even further. In reality, when we had to add Wordpress to our workloads, there was nothing special we had to do except for introducing EFS. All our workloads before that didn't require keeping state on a file level. And just like that we had a scalable/HA Wordpress setup with pretty decent performance.
- silviogutierrez 7y agoSide note, as in your place, I'd like to know: "bear" in mind. "Bear with me". Think of the animal. Rawr. Otherwise agree with your post. All depends on the business needs.
- laumars 7y agoHaha good spot. Thank you
- kichik 7y agoAnd you can set it all up with CloudFormation templates provided along with the posted image. https://github.com/aws-samples/aws-refarch-wordpress https://github.com/aws-samples/aws-refarch-wordpress Good luck automating it that much on-premise.