Running WordPress in the Cloud – And how to Cause Unnecessary Problems doing so

When it comes to the “Cloud”, people tend to get immediately excited and think that it is the holy grail of modern technology. Especially, not so tech adept people love the sound of infinite scalability and paying only for what you use. Plus the buzz words cloud computing just sound kind of cool.

I just had a customer who insisted on using the cloud in a very illogical way. All of the arguments, such as higher maintenance overhead and initial setup costs, were not enough reason to dissuade the client from wanting to move the software to the cloud. But since the customer is king, I carried it out as they wished. 

I love the possibilities of cloud computing with its simple setup and scalability. With cloud computing, you don’t have to worry too much about how to scale the system once the users start flooding the servers with requests. Setting up load balancers, data replication, backups, scaling horizontally within short periods of time etc., are all awesome advantages for systems that might experience high traffic in the future. But for some usecases, you might be way better off with a traditional system with persistent storage, even if it is a normal virtual machine in the cloud.

Now to the specific project:

The company is running a set of 5 corporate WordPress blogs, one for each language. Each language runs in its own WordPress installation and they are not connected. The cloud computing platform they wanted to use was a service like Heroku, where every application has to run in its own container. You can scale that container horizontally (add more instances) or vertically (use bigger hardware). While this setup is awesome for software that actually needs to scale (which you can do with a simple slider within seconds), it causes all kinds of problems with a software that was designed to run on persistent storage (WordPress for example).

The Problem:

Whenever you scale your container or whenever the container changes because of internal management of the cloud service (which could happen anytime), your whole codebase is reset to the state when you deployed it. So all of your uploaded files and all changes you made to the codebase are irreversibly lost. If the system is designed for a service like that and stores everything in a separate service like Amazon S3, this is perfectly fine. But if you use a software, like WordPress, that changes its files automatically and expects a persistent storage as a data system, you run into a whole list of problems:

  • Uploaded media files will be gone after instance reset with the default configuration, so you need to use a plugin that stores all files on upload in a separate file storage service. I used S3 in this case, which is pretty cheap storage and can speed up the loading process of the page.
  • If you install a plugin through the usual installer in WordPress, it stores all the plugin files in the instance. After instance reset they will be gone. So every time you want to install a new plugin, you need to add it locally to your code and deploy it, before you can use it on your site.
  • You face the same problem with updates of the WordPress core. For each minor version release, you need to install it locally and then deploy it to the cloud.
  • A couple of plugins write files to disk, for example settings etc. All those plugins won’t work properly and can seriously break your WordPress installation in the worst case.
  • The biggest problem I see is that an update or an installer of a plugin or the core can execute its installer and run database updates. After instance reset the software runs on the codebase of the previous version, but uses an incompatible database structure from after the update, which can lead to corrupt data.

To avoid all that, I would definitely prefer to run that blog on a (virtual) server that has a persistent data storage. Especially, if the blog only has a couple hundred visitors and probably never has to be scaled to an extent where you actually have to use a distributed environment. The client would have been way better off with a normal managed webspace, where you can run all blogs on one server and don’t have to share the server resources with too many other clients. That would have also been cheaper because you wouldn’t have had to run 5 containers. The blogs could have shared the server resources and you could enjoy the benefits of WordPress’s easy upgrade mechanisms without hiring a server administrator for each update to deploy the code to the cloud (Once for each blog). The setup costs would have also been lower without the necessary plugins to use persistent storage for media files and migrating existing data to the new storage. But as I mentioned in the beginning, since the customer is king, I gonna make that Ferrari go Off-Road if that is what the customer wants…

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">