> Has anybody working towards serverless version of wp?
I'm curious on what a "serverless version of wordpress" consists of, please enlighten us on the technical details of a serverless wordpress, sincerely. And how would you have a "serverless shopping card" too ? I'm really curious about the how it. If you're talking about a static blog generator then it already exists (Hugo,...) is this what you call serverless ?
I read "serverless" in this context to mean a statically generated site, yes. I also infer that dynamic content like authentication, shopping carts, forms, etc would be third party solutions via Ajax and CORS.
I built a service [1] for this latter part (authentication, CORS sql database, and static file hosting). The pieces one could use to build anything for a statically generated site. Adoption has been... non existent up to now.
Most blog content is static, why would you need to use lambda for anything ? you already get automatic scaling by putting static files on S3. What Wordpress functionality would need to be implemented with Lambda ?
I run a static blog on S3 using Lambda. I upload a markdown post to an S3 bucket, Lambda runs Hugo (could be Jekyll, or whatever) to regenerate the appropriate files, then uploads it to an output buckets, invalidates the files it needs to in Cloudfront, etc.
Not infeasible to think you could use Lambda to generate a static cache of a WP site onto S3 and update files on demand.
This is clearly for sites that require more than a fraction of a droplet to run. Just because WordPress can be run on a tiny instance doesn't mean that every WordPress user does -- some sites are actually popular.
You could host several WordPress sites on a free tier AWS EC2, too. Where things get a little more complicated is when you're getting real traffic and want to be fault tolerant and redundant.
RDS is here because keeping your database on the same server as your web server is not ideal at scale.
EFS is here because at some point you want to scale horizontally and it's one method to share underlying code (and perhaps cache).
ELB is here because if you have more than one web server, you need a load balancer
And as you scale, you could add services. This guide isn't for anyone who can host a tiny site on a tiny instance. You'd do that in AWS the same way you would with Digital Ocean.
There should be easier way, e.g. in Azure you can start WordPress (includes MySQL, limited to one app service instance) with one click, not sure what are the costs of maintaining that, but at least starting one in that case is pain free.
Infrastructure as code offers a lower maintenance cost over time in many scenarios.
Sure you can click to set up WordPress on other hosts.
But how do you scale capacity of the servers or the database? How do you peer the network to your other cloud resources? How do you mirror the stack in another region?
With CloudFormation resource management is a few API calls away.
You can also use CloudFormation in point and click mode to create a stack and update its resources.
It may be overkill for some cases but for serious systems it's the best practice.
I gotta shout out wpengine which has been hosting sites for me for years. Scales up with demand and managed so I don't have to play devop. I don't consider myself a WordPress guy but it does fit a number or use cases.
> Before you hop on board with this "pain free" solution, you should accept the fact that you may end up maintaining this [...]
True, although ongoing maintenance of a CloudFormation template isn't significant. It's essentially a specification of the state of the infrastructure, which AWS is then responsible for making come true. It's also their stuff from CloudFormation back, so they're on the hook for making sure nothing changes that would break it (relative to Terraform or other alternatives).
Also keep in mind that AWS services are usually encapsulated from each other, which is a good thing. The result, though, is that defining something like this involves a lot of parts. You need to define its private network, its subnet masks, its EC2 instance types, its database type and configuration, etc. The author also took it a step further to define CloudWatch alarms and scaling policies, which is great.
It is something that requires understanding if changes are necessary, but it's not something that you would expect to need tweaks over time.
> There should be easier way
There is--he could have started Wordpress by just launching an instance with userdata that installs it and sets it up. This isn't really comparable to that because it involves multiple servers behind a load balancer, a CDN, a hosted DNS zone, a separate relational database service instance, and autoscaling.
In my humble opinion, WordPress is something to be surpassed, that is why it fails on being cloud-friendly. If someone makes a system as customizable and flexible as WordPress it would be a huge success.
I've been waiting on this for awhile, currently I run most sites through jekyll and for clients that need CMS options I hook them up with http://cloudcannon.com/
I've gone the WP a number of times and it's been more headaches then it's worth. Everything seems like a hack on a hack. There are things like sage/roots that make it a "little" better.
My experience with WP has been the same. Seems like you get a basic theme installed, and then whatever functionality you need you just download, install and configure a dozen or so plugins. Can't find a plugin that you need? Oh, then you can just write a plugin that you download, install and configure on your own.
I hope your right, but part of the problem is the traction WordPress has. We tried to go with something other than WordPress, but ranbinto all sorts of issues mostly because everything the marketing people wanted to use was already built for WordPress. We also had a hard time finding contractors to make themes and stuff because they all knew WordPress but didn't want to commit to something else.
Do you have anything to say about EFS and WordPress (or other PHP CMS that are basically designed for a single instance?)
Latency on stat() - PHP is often a oop-monster these days with thousands of fs reads as it loads the code? (there are certainly ways to dodge that overhead though).
Have you seen the filesystem stall for any reason? Any caveats with concurrent writers (such as cache/ directories or generated images with deterministic paths etc).
You say without frustrating patches - are there any general limitations with using EFS?
Have you used self-managed NFS for the same purpose before? Any comparison with EFS?
IMO the better way to run is with _no_ shared file system at all. Use CodeDeploy to ship the deploy files to all ec2 servers, and then use S3 to store all uploaded files. WordPress doesn't need to do any file writing outside of the `uploads` directory.
This allows you to sidestep a large amount of pain points with shared filesystems, and every ec2 server has local disk performance.
I tried EFS and it seemed very slow for the wordpress site I tried to host. I didn't think EFS was meant for hosting a webserver but mainly for large files?
Why is anyone running WordPress anymore.? So many better options.100s if not 1,000s. The fact that you need elaborate guides to host it one of the most common hosting providers is yet another example. It's junk. Time to move on.
Edit: and the down votes are why this piece of garbage lives on. Please stop trying to hide how awful WordPress is. We all know it's terrible. Just because you work on it for a living doesn't make it right for you to publicly lie about it and down vote.
What your requirements? With Google rendering JavaScript any static site generator is probably going to be better. If you need crud functionality any number of hosted and open source crud providers are available. Or just use a hosted site builder. They are all better at this point.
Static site generators are just fine for personal blogs. They don't fit the bill at all when you have a group of people all writing on one blog and you need things like access controls and media file management.
Also, not sure why google rendering JavaScript would have any effect on static site generators.
That's why I said it depends on the needs. Read. Stop blindly defending garbage. You can use version control with a static site generator. Otherwise there are hundreds of crud interfaces to edit content with a group that a far superior to WordPress.
JavaScript rendering is if your use case requires dynamically generated content. Again, read. It's based on your needs. Whereas you are defending WordPress because your(not your client's) bank account depends on it. Which I consider very unethical.
Not really defending word press, just pointing out that it has its use cases and the solutions you responded with don't cover them. Have you used Wordpress? It's interface is far from garbage and it's plugin ecosystem is plentiful.
You seem pretty upset about someone choosing wordpress but you haven't done a very good job of articulating why it's bad and what other competitors are out there that are better (no, saying "any other crud editor" does not qualify and only seems to prove how much you don't understand about the use cases of word press)
Edit: for what it's worth, I don't have "clients" and my bank account isn't at all tied to using word press. No idea where you got that from.
You can use SSGs with GitHub for multi-author blogs. Prose.io makes a nice writing interface for GitHub content. If you hook it up to something like Travis CI, the site can be regenerated automatically on GitHub commits.
It's a bit complicated compared to just running a WordPress instance, but it works pretty well.
Because moving an existing site to another platform is non-trivial. Sure I could figure out how to move over my theme, hundreds of posts, my menus, sidebars, hundreds of images, and all of my registered users.
Or I could just stick with the existing good enough system and go do something else.
Sure, you need to support legacy software that is so junky you have no way to migrate off the platform. You're trapped in the dump. Even more reason to avoid WordPress and not get trapped in your situation.
That is one disadvantage. If you bothered to read the rest of my comments you would see that I said it depends on your use case. If you just need a basic website you are much better off using a site builder than wasting quite possibly 1000s of dollars on support when something breaks. Be honest. So many non profits with limited budgets have wasted so much money that should have been spent on the actual purpose. All because of the lies they have been told by shady agencies who want the sweet sweet support contracts that junk like WordPress requires.
>Because moving an existing site to another platform is non-trivial.
It's not just that it's non-trivial, it's that when it comes down to a real analysis, these "clearly better" alternatives aren't clearly better at all. They generally much, much worse.
There is a hipsterism in technology just like every other field where people identify themselves by the things they reject. The GP post is such a claim, with over the top bombast making everyone know how much they dislike Wordpress, acting as if there is some unnatural force (e.g. user delusion) keeping it popular. It's popular because it may just be the best option for the purpose it serves.
And I don't develop Wordpress themes or plugins, and of course curse it occasionally. I leverage it as a tool.
I manage a wordpress installation for a school community site - wordpress's greatest strength (and biggest source of frustration) is it's flexible and popular plugin ecosystem that gives me useful plugins, including a shopping cart system for fundraising, an events calendar and photo galleries, all managed from the same WYSIWYG interface as a blogging engine and a decent CMS.
I could re-write all those plugins in another CMS, but the fact that wordpress is so popular and so flexible is the reason I don't see myself replacing it any time soon.
I'm not sure I would trust sensitive credit card information to any WP plugin, especially plugins with single maintainers that could abandon the plugin at any time. [1]
You don't need an elaborate guide or aws. Plenty of people use it happily on shared hosting or specialized hosting for wp. Or just click to run droplet with everything installed on DO. Plenty of easy ways.
Face it: The war's over and WordPress won. I made an election site for a friend who's running for a city council position. Even though I only program in Erlang, we did the site in WordPress.
Please don't comment like this on Hacker News. The quality of WordPress is not relevant to this article, and even if it were we would ask you to say something substantive rather than simply calling it junk. The guidelines also ask you not to complain about downvotes, so please review them here: https://news.ycombinator.com/newsguidelines.html.
Please do not use "please" in a passive aggressive manner when you are giving an authoritative command. Use please when you are genuinely requesting someone does something as a favor to you. When you are giving an order, be and adult and just give the order.
Someone can request and command something at the same time. Presumably, the administrators don't want to have to take down posts and police the site, and appreciate it when users don't make their lives more difficult. This makes the "please" seem legitimate to me.
I also disagree on characterizing the usage as "passive-aggressive." I would just call it polite. Underscoring your authority with a peremptory tone seems worse to me.
We do exactly this, but we keep our site code including plugins in github and the images in EFS. I would really like to see some recommendations on dealing with the Linux stat issue over NFS.
I do performance WP hosting and would like to try out EFS but it is not available locally yet.
What I do is use redundant RDS, ELB etc but on all the WP installs have an inhouse plugin that with any change it ioniced rsyncs that vhosts tree to all webservers and ssh's a command to them all to dump their WP cache.
It may seem hackish but the sites absolutely fly, have tried several clustered file systems but all that complexity hits reliability and speed.
I've run a sporadically popular (100s of thousands of uniques on some days) blog on Wordpress for years. All running on a single spot instance (if it was killed I have a script to roll over in minutes).
The database, Wordpress, the file storage. Entirely self contained.
I occasionally persist the AMI so I can spin up a new updated system base, and have regular backups of the files and database. My monthly cost is ~$9 on AWS. I've had literally minutes of downtime over the past several years.
Obviously this guide is geared to a more serious installation, but there is the danger that the more reliable a system becomes, often the less reliable it becomes. EFS and NLB configuration changes or problems taking the system offline, for instance.
It's always validating to see someone else write a blog post of the same decisions you made. This guide is good. For doing the uploads folder onto s3, I couldn't recommend S3-Uploads more it has served me well https://github.com/humanmade/S3-Uploads
I work at Human Made (owner of the above repo, and an enterprise WordPress agency), and we run all our sites on an all-AWS stack. We have a few other plugins for related AWS pieces, including email via SES [1] and a dynamic image thumbnail generator that runs on Lambda [2] that might also be relevant.
Using S3 for the uploads solves our problems without needing EFS, as we disable file system changes through other methods. Plugin installs or upgrades are great, but aren't tracked in the git repo, so we do those via local upgrades and deploy out to AWS instead.
The article also mentions installing WordPress as being a pain, but you can easily automate this using wp-cli [3] if you want to. Your RDS containing the WP data is going to be shared though, so there's no real need to install more than once.
Hey thanks for your work, I wanted to mention wp-cli, too, which is especially excellent. Especially with one of my applications where the content portion of the site is wordpress, and the "app" portion is other tech, I needed a way to integrate with the wordpress site, and found wp-cli made some tasks incredibly easily.
Great information, thanks - and I have a question: have you had issues with S3 being only eventually consistent for some usage modes [0]? If so how do you work around them? My first intuition is that this property of S3 could cause occasional problems with plugin upgrades, file changes, etc.
Great short/quick piece. I also do multi-EC2 instances in AWS, but do NFS instead of EFS, and another CDN. WordPress still has its many challenges, but it definitely scales for many different web publishing businesses.
Can someone chime in why hosting this behind Cloudflare is a bad idea?
For something which is a blog/CMS (put another way the # of readers >> # of creators), I'm envisioning using a single instance behind Cloudflare with heavy caching turned on? Cloudflare caches and serves everything. For free (you can pay them if you want). Host your assets in S3 or GCS, also put them behind Cloudflare. If your instance goes down, you have a rough chunk of your caching window to bring your instance back online (which if it's well encapsulated should be a few scripts to spawn a new instance and re-point the cloud provider internal DNS which will update ~1s)
I use Cloudflare for mine (https://www.garysieling.com/blog) - they catch 75% of the requests. For sections that are rarely hit, you'd still get 404's from downtime, and there are more valid URLs to pages on a Wordpress site than you'd think.
Unless you pay for a larger instance where the cost turns out to more like 50 bucks a month you get very limited bandwidth out of AWS, which is why I stopped using it. I suppose if you are running a corporate blog and cost isn't an issue then AWS probably works fine but for smaller sites and individual users there are vastly cheaper very good hosting options out there. I don't want to seem like a shill so I won't mention them by name. It was the super crappy bandwidth on AWS where basically my site would die regularly with just one or two visitors that made me abandon the platform.
> I’m not a fan of Wordpress, as it is neither cloud-ready nor serverless.
Well that's a funny opener.
TL;DR: rather than configure your uploads to go to S3, one of AWS's most battle hardened and time tested offerings, use a service that was launched 10 months ago and can definitely scale perfectly and will never have any issues. Then you can even keep on managing your htaccess files using a WordPress plugin and skip that pesky version control!
Yes, you can do this. But, what about a staging environment? How do you keep data and code in sync between environments? My company runs a lot of wordpress instances, and we've wound up shipping most of them to Pantheon. (pantheon.io) Not only does it take care of environment issues, but it gives you redis and implements caching as a service. As the post says, wordpress fights AWS a bit. We leave it to the people who are experts at winning that fight.
(I know this reads like an ad. I'm not affiliated with pantheon except as a user. Pantheon comes close to making wordpress not suck.)
Requiring the $100/mo plan and charging an additional $30/mo for HTTPS seems.. dated. It makes me wonder if they're behind the times with other things too.
He's partially correct about S3 for media and uploads, but you want to take it one step further and use Imgix for actual image (jpeg/png) delivery because it'll do all of the transformations, cropping, etc. for you without WordPress mucking it up. At that point you have a fairly stateless WordPress installation and can spin up any number of instances of it. Here's my plugin for handling both S3 and Imgix: https://github.com/jawngee/ilab-media-tools/
CloudFlare is really the best thing to happen to WordPress since Imgix. Using CloudFlare's ability to cache at the root and sending correct caching headers from WordPress to CloudFlare, you are virtually indestructible.
We run a news site that gets about 500K uniques a month off a $20 instance on Digital Ocean this way. Granted, it's static, eg no user directed dynamic content like comments, votes, etc.
If you're going to add (full-page) caching, Batcache [0] is the best solution. Combined with a Memcache plugin [1], you can use this to store your page caches in AWS Elasticache.
The root post of this thread is pointing out that you should always run WP behind a CDN like CloudFlare. That will handle all of the caching that you need. If you're running a truly static site, then you're going to have very few actual hits to your server.
$20 a month for the DO droplet, but out of curiosity what's the monthly bandwidth bill from AWS? That's always the kicker - bandwidth from AWS is not cheap.
123 comments
[ 3.1 ms ] story [ 230 ms ] threadHas anybody working towards serverless version of wp?
You can easily manage to get this setup at 30$/mo with Scaleway for example.
So you're looking at ~ $50/mo.
For a setup that can now scale to any volume independently on the HTTP, compute and database tiers.
Overkill for a personal WordPress. Just right for a serious business.
I'm curious on what a "serverless version of wordpress" consists of, please enlighten us on the technical details of a serverless wordpress, sincerely. And how would you have a "serverless shopping card" too ? I'm really curious about the how it. If you're talking about a static blog generator then it already exists (Hugo,...) is this what you call serverless ?
I built a service [1] for this latter part (authentication, CORS sql database, and static file hosting). The pieces one could use to build anything for a statically generated site. Adoption has been... non existent up to now.
[1] https://www.lite-engine.com
It would provide unlimited and automatic scaling, simplified setup/architecture and we would pay only for what we use.
Not infeasible to think you could use Lambda to generate a static cache of a WP site onto S3 and update files on demand.
https://codex.wordpress.org/Function_Reference/capital_P_dan...
The first page of HN can send 10k users to a blog in about one hour. (don't know the peak rate per second).
RDS is here because keeping your database on the same server as your web server is not ideal at scale.
EFS is here because at some point you want to scale horizontally and it's one method to share underlying code (and perhaps cache).
ELB is here because if you have more than one web server, you need a load balancer
And as you scale, you could add services. This guide isn't for anyone who can host a tiny site on a tiny instance. You'd do that in AWS the same way you would with Digital Ocean.
There should be easier way, e.g. in Azure you can start WordPress (includes MySQL, limited to one app service instance) with one click, not sure what are the costs of maintaining that, but at least starting one in that case is pain free.
Sure you can click to set up WordPress on other hosts.
But how do you scale capacity of the servers or the database? How do you peer the network to your other cloud resources? How do you mirror the stack in another region?
With CloudFormation resource management is a few API calls away.
You can also use CloudFormation in point and click mode to create a stack and update its resources.
It may be overkill for some cases but for serious systems it's the best practice.
https://apps.sandstorm.io/
Maybe that is from having been through the ad-hoc or "well, its easy to spin up, but this only works for a single node" setup roundabout a few times.
True, although ongoing maintenance of a CloudFormation template isn't significant. It's essentially a specification of the state of the infrastructure, which AWS is then responsible for making come true. It's also their stuff from CloudFormation back, so they're on the hook for making sure nothing changes that would break it (relative to Terraform or other alternatives).
Also keep in mind that AWS services are usually encapsulated from each other, which is a good thing. The result, though, is that defining something like this involves a lot of parts. You need to define its private network, its subnet masks, its EC2 instance types, its database type and configuration, etc. The author also took it a step further to define CloudWatch alarms and scaling policies, which is great.
It is something that requires understanding if changes are necessary, but it's not something that you would expect to need tweaks over time.
> There should be easier way
There is--he could have started Wordpress by just launching an instance with userdata that installs it and sets it up. This isn't really comparable to that because it involves multiple servers behind a load balancer, a CDN, a hosted DNS zone, a separate relational database service instance, and autoscaling.
I've gone the WP a number of times and it's been more headaches then it's worth. Everything seems like a hack on a hack. There are things like sage/roots that make it a "little" better.
My experience with WP has been the same. Seems like you get a basic theme installed, and then whatever functionality you need you just download, install and configure a dozen or so plugins. Can't find a plugin that you need? Oh, then you can just write a plugin that you download, install and configure on your own.
The bloat from that approach just drives me nuts.
The persistent and shared EFS volume was the missing piece for running WordPress without frustrating patches.
And CloudFormation is the AWS best practice.
Convox has a few serious WordPress installs. The only difference is that it uses ECS so those EC2 instances can be utilized for more apps.
Also you can hack on the WordPress site locally with Docker via 'convox start'
https://convox.com/docs/wordpress/
Disclaimer: I work on Convox.
Latency on stat() - PHP is often a oop-monster these days with thousands of fs reads as it loads the code? (there are certainly ways to dodge that overhead though).
Have you seen the filesystem stall for any reason? Any caveats with concurrent writers (such as cache/ directories or generated images with deterministic paths etc).
You say without frustrating patches - are there any general limitations with using EFS?
Have you used self-managed NFS for the same purpose before? Any comparison with EFS?
This was on a workload much tougher than WordPress.
I haven't run my own NFS for comparison.
I recommend reading the NFS v4 spec. AWS has all the pieces to implement the protocol as well as anyone can.
This allows you to sidestep a large amount of pain points with shared filesystems, and every ec2 server has local disk performance.
Edit: and the down votes are why this piece of garbage lives on. Please stop trying to hide how awful WordPress is. We all know it's terrible. Just because you work on it for a living doesn't make it right for you to publicly lie about it and down vote.
Also, not sure why google rendering JavaScript would have any effect on static site generators.
JavaScript rendering is if your use case requires dynamically generated content. Again, read. It's based on your needs. Whereas you are defending WordPress because your(not your client's) bank account depends on it. Which I consider very unethical.
You seem pretty upset about someone choosing wordpress but you haven't done a very good job of articulating why it's bad and what other competitors are out there that are better (no, saying "any other crud editor" does not qualify and only seems to prove how much you don't understand about the use cases of word press)
Edit: for what it's worth, I don't have "clients" and my bank account isn't at all tied to using word press. No idea where you got that from.
It's a bit complicated compared to just running a WordPress instance, but it works pretty well.
Or I could just stick with the existing good enough system and go do something else.
It's not just that it's non-trivial, it's that when it comes down to a real analysis, these "clearly better" alternatives aren't clearly better at all. They generally much, much worse.
There is a hipsterism in technology just like every other field where people identify themselves by the things they reject. The GP post is such a claim, with over the top bombast making everyone know how much they dislike Wordpress, acting as if there is some unnatural force (e.g. user delusion) keeping it popular. It's popular because it may just be the best option for the purpose it serves.
And I don't develop Wordpress themes or plugins, and of course curse it occasionally. I leverage it as a tool.
I could re-write all those plugins in another CMS, but the fact that wordpress is so popular and so flexible is the reason I don't see myself replacing it any time soon.
I'm not sure I would trust sensitive credit card information to any WP plugin, especially plugins with single maintainers that could abandon the plugin at any time. [1]
[1] http://labs.sucuri.net/?note=2016-10-17
I would like to migrate a couple of sites to something else (likely just static-file sites), but that's just a personal preference.
It works and I don't really have to mess with it.
I also disagree on characterizing the usage as "passive-aggressive." I would just call it polite. Underscoring your authority with a peremptory tone seems worse to me.
What I do is use redundant RDS, ELB etc but on all the WP installs have an inhouse plugin that with any change it ioniced rsyncs that vhosts tree to all webservers and ssh's a command to them all to dump their WP cache.
It may seem hackish but the sites absolutely fly, have tried several clustered file systems but all that complexity hits reliability and speed.
And if your cache is all on disk, a very quick win would involve moving that to memcache, no? That also makes forced expiration very easy.
Of course there are managed services for all of these things anyway.
The database, Wordpress, the file storage. Entirely self contained.
I occasionally persist the AMI so I can spin up a new updated system base, and have regular backups of the files and database. My monthly cost is ~$9 on AWS. I've had literally minutes of downtime over the past several years.
Obviously this guide is geared to a more serious installation, but there is the danger that the more reliable a system becomes, often the less reliable it becomes. EFS and NLB configuration changes or problems taking the system offline, for instance.
Using S3 for the uploads solves our problems without needing EFS, as we disable file system changes through other methods. Plugin installs or upgrades are great, but aren't tracked in the git repo, so we do those via local upgrades and deploy out to AWS instead.
The article also mentions installing WordPress as being a pain, but you can easily automate this using wp-cli [3] if you want to. Your RDS containing the WP data is going to be shared though, so there's no real need to install more than once.
[1]: https://github.com/humanmade/aws-ses-wp-mail [2]: https://github.com/humanmade/node-tachyon [3]: http://wp-cli.org/
[0] See "Amazon S3 Data Consistency Model" on this page: http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction....
It's not a bad idea. Who said that?
Put your blog behind cloudflare. It will cache most of the requests and save a lot of load and bandwidth on your instances.
[1] https://roots.io
Well that's a funny opener.
TL;DR: rather than configure your uploads to go to S3, one of AWS's most battle hardened and time tested offerings, use a service that was launched 10 months ago and can definitely scale perfectly and will never have any issues. Then you can even keep on managing your htaccess files using a WordPress plugin and skip that pesky version control!
(I know this reads like an ad. I'm not affiliated with pantheon except as a user. Pantheon comes close to making wordpress not suck.)
The first step is building your WordPress site correctly, and for me, that starts with using trellis (https://roots.io/trellis) and bedrock (https://roots.io/bedrock).
He's partially correct about S3 for media and uploads, but you want to take it one step further and use Imgix for actual image (jpeg/png) delivery because it'll do all of the transformations, cropping, etc. for you without WordPress mucking it up. At that point you have a fairly stateless WordPress installation and can spin up any number of instances of it. Here's my plugin for handling both S3 and Imgix: https://github.com/jawngee/ilab-media-tools/
CloudFlare is really the best thing to happen to WordPress since Imgix. Using CloudFlare's ability to cache at the root and sending correct caching headers from WordPress to CloudFlare, you are virtually indestructible.
We run a news site that gets about 500K uniques a month off a $20 instance on Digital Ocean this way. Granted, it's static, eg no user directed dynamic content like comments, votes, etc.
We build a lot of WordPress sites this way.
[0]: https://github.com/automattic/batcache [1]: https://github.com/tollmanz/wordpress-pecl-memcached-object-...
I do wonder how much energy is wasted from poorly optimised websites & systems?
http://www.slashgeek.net/cloudflare-making-internet-little-b...