I am a photographer first and a webmaster second – that is the way it is supposed to be.
Every professional photographer knows how important a good website is for getting their images out there. The flip side is that sometimes my ‘computer time’ is spent more on the web-mastery side of things than working on my images. A website should work for me, not me for it!
WordPress is an excellent foundation, and once you have found and customized the right theme for your needs, the challenge becomes the hosting provider.
As my website scales up and down my back end computing needs change. Sometimes if I want to upgrade to a more powerful instance, the hosting provider forces me to migrate my entire WordPress site with all my content, settings, customizations and databases from one instance to another. Even with specialist migration plugins like All-in-One WP Migration, some little things always break.
Many photographers with smaller websites don’t need an expensive, dedicated platform so they opt for shared hosting. My experience with shared hosting is that after the initial migration of the website, performance and site responsiveness are good. Over time though, generally after 6 to 9 months as the server loads up with other customer sites, performance figures decrease, the user experience becomes sluggish, and visitor numbers drop. So you migrate up or migrate away to another provider – it’s a cyclical process.
Looking at the Amazon AWS menu can be quite daunting if you aren’t familiar with cloud computing. Even if you are familiar, trying to figure out which option is best for your performance needs, with the most efficient administration overhead, can make your head spin!
To make it simpler, AWS EC2, or Elastic Compute Cloud, is Amazon’s play for cloud computing; it’s a Swiss Army knife that can do everything. The key thing is I don’t need to do everything, I want a flexible, scalable platform just to run WordPress on. Amazon Lightsail is just what I have been looking for.
As an experiment, using the 1 month free trial for the smallest Virtual Private Server (VPS), I created my Lightsail instance. WordPress comes preinstalled, as does the migration plugin I mentioned earlier. After the migration, I accessed my site and my first thought was “wow, this is fast, my site feels much more responsive.”
This feeling is confirmed by the results from 2 separate Pingdom speed tests run a few seconds apart.
My homepage has a size of 2.8Mb and I knew performance was slow in its old home. However, I was shocked the results were this bad. 3.81s (yes seconds!) versus 616ms from Lightsail. That is a night and day difference in responsiveness!
Both the Pingdom server and my old hosting provider are on the US East Coast so latency due to geographic distance won’t make a big difference. This is purely back end server/infrastructure performance.
So, setup and migration were simple. The speed of page delivery is clearly excellent. Two very compelling reasons to keep my site running on Lightsail.
Now I need to start making some changes, the migration broke some links within one of the Envira galleries, plus I need to remove some plugins I no longer use. This brings me onto the topic of testing, another major advantage of cloud compute.
Previously, when I wanted to do some development (enhancement) to my live site, I would migrate a copy of the live site to a small virtual machine at home. Then I would do my testing and if something broke which I couldn’t fix (remember, I am a photographer, not a web guru!) I would need to migrate (again) a copy from live down to my test environment and try the test again. Not a bad solution but very 20th century (and slow) compared to what I can do now with Lightsail.
Now with AWS, I simply tell Lightsail to create a Snapshot of my live virtual machine. This takes around 15 minutes to complete. I then select that snapshot and spin it up as a new virtual machine with a new Public IP. If my testing breaks WordPress and I need to start over, I kill that test virtual machine and create another in minutes.
Lightsail and S3
By this point, you can tell I have got the ‘Amazon bug’, it is simple and it works. Lets see what else I can do with the next phase of site testing – Amazon S3. Next, for backup purposes, I created another snapshot of my Lightsail instance, as you will read shortly, I am very glad I did!
If you have read my Photographic Data Management article you may remember that I already use the AWS Storage Product – S3 – as my NAS backup. The first step to using it for my website was to create an S3 bucket for my WordPress wp-content directory to reside. With that done, I downloaded the WP Offload Media Lite for Amazon S3 plugin and activated it. Configuring the free plugin was quick and intuitive, just a matter of selecting the S3 bucket name I created earlier.
From now on, any new image files I upload will be stored on S3, not on my local server storage. The problem is that my current media is still on the local server. Paying a subscription to unlock the ‘migrate existing’ feature in this plugin was a possible option. However, after a short Google search I found an alternative (free) solution with a plugin called Regenerate Thumbnails. It appears the main reason for regenerating the thumbnails is because it tricks WP Offload Media into seeing each as a new upload, and therefore storing it on S3 rather than locally.
After selecting the option of regenerate all thumbnails, the process was complete after 20 minutes. The Media page showed all the images and thumbnails with the correct S3 link. However, in EnviraGallery something must have gone wrong. At least 50% of the images had lost their thumbnail and the image links still showed them as being on the local server when they were now stored on S3 – not good! Proof indeed that there is ‘no such thing as a free lunch!’
Removing the images from one of the broken Envira galleries and them re-adding them didn’t fix the problem. For some time I have planned to update the galleries with higher resolution image files. This made the decision to do it now an easy one, plus this is my sandbox environment anyway! After restoring the previous snapshot on a new instance, I removed the Regenerate Thumbnails plugin, removed all the image content. In parallel PS CC ran a action to resize each gallery from the master image folders. After the upload, all the images were correctly stored on S3. Using a text editor I did a search and replace to ensure all the links were pulling from the correct URL.
Lightsail, S3 and CloudFront
Next, CloudFront as a Content Distribution Network (CDN). I am on the US East Coast, so is my AWS region. Therefore my latency to my site is very low and responsiveness is good. If a visitor is accessing that content from the US West Coast or EMEA/APAC all that data, particularly the image data, has to traverse a long distance and the site appears slow. Using a CDN means that my content is stored in all of Amazon’s CloudFront data centers, so if a visitor from Singapore is viewing my site the images aren’t being served from the US, they are delivered from the CDN location in Singapore – in other words – very quickly!
First, a domain name needs to be created within the CloudFront portal. This is normally a ‘longrandomstring.cloudfront.net’. I then linked the S3 bucket where my images are stored to the new CDN domain name. Content deployment to all of Amazon’s global locations then starts automatically.
At this point, the CloudFront CDN is serving the images from the closest location to the viewer. There is one final step to complete. Google Site Search Bots don’t like the long URL string I mentioned above and it can impact the search rating of my site. The easiest solution was to create a DNS CNAME record for cdn1.exposurecompensation.co.uk. After DNS propagation I added the new CNAME record to the WP Offload Media plugin and everything was complete.
This was an interesting (and fun) experience, one that surprised me in terms of how simple everything was. I had no need to tweak or customize the virtual server, it just worked. Also the smallest VPS option appears to be more than adequate for my current needs. It is surprisingly fast – faster than some bigger dedicated platforms I have had from other hosting providers.
After thoroughly testing all content, forms, galleries and internal site links, I decided to make this instance my production one. I updated the DNS A record with the Public IP of the Lightsail instance. After propagation of the DNS record, the site was live!
Lastly, since environment is now Amazon centric, migrating domain ownership to Amazon’s Route 53 (their DNS product) made a lot of sense. The other benefit of doing this is that DNS updates are now almost instant.