The cloud isn’t for everyone

We often have to research and spec out hosting setups for clients and almost everytime the current hosting buzz word crops up: Cloud. Most of the time clients tell me they want cloud but they don’t know why, or worse – their reasoning is flawed. I don’t want to tell my clients they don’t know what they want, but there’s a huge misconception about cloud in the hosting sphere.

My understanding of a “Cloud Hosting” provider is a company that can deliver most or all of the necessary building blocks to set up an environment that is redundant on all possible levels, including location. Amazon Web Services (AWS) is a good example of this with multiple regions and zones within regions, and they have abstracted many common services like mysql, memcached etc into their own products that can be set up in a way that provides true locational redundancy. However just because the service can be set up this way, doesn’t always mean it is. AWS itself is not a simple beast and often I see clients setting up a standard server in a single zone, without grasping the level of redundancy AWS can provide. Armed with just a single server, these clients are no better off on AWS than a traditional VPS provider or other cloud provider like VPS.NET or Dediserve.

VPS.NET and Dediserve really do simplify the process of Cloud Hosting and deliver it to the client at such a level even a beginner can understand. Their Virtual Private Servers (commonly abbreviated VPS or VDS or VMs) have basic cloud functionality built in with no work required on the user side; all user data is stored on a separate disk-only machine called a Storage Area Network (SAN), so even if the server your VPS is hosted on fails, your VPS will be booted up automatically on a different server. However, if the SAN fails that’s an awful lot of VPS’ offline for a prolonged period of time. Unlike AWS, there’s no protection against a datacentre-wide outage, so you still need to build a geo-redundant configuration if required. The missing component here compared to AWS is that you need extra tools such as DNS failover services to achieve this redundancy.

There are many traditional dedicated server providers, or non-cloud VPS providers like Linode, where all data is stored on-server rather than a SAN. The advantage of not using a SAN is that storage failures only affect single servers rather than hundreds of servers. On the other hand, if the server you’re hosted should fail, your downtime could be prolonged while your data is moved and/or reconstructed on another server.

So back to my title and why the cloud isn’t for everyone. Put simply, many clients I deal with on a daily basis do not need all the bells and whistles of something like AWS, and don’t strictly require their site/server to have 100.000% uptime. With AWS specifically, clients end up paying more for a basic service and use only a fraction of its potential, when they could purchase a more powerful traditional VPS or dedicated server at a lower cost. In my opinion, AWS is great for very large-scale site deploys where traffic may burst to very high volumes and extra horsepower is required to be brought online automatically. However AWS still has its drawbacks; in my experience the alloted CPU time for EC2 VPS’ is small, so for dynamic web sites – i.e. Magento-based online shops – clients are required to purchase much bigger VPS’ than actually required in order to benefit from extra CPU time. This is a costly process to do, and it often works out cheaper to have a large static pool of resources using traditional VPS hosting that can take all the load without issues.

Many providers wrongly sell their products as cloud and/or falsely add cloud to their product names, when the product they’re selling isn’t cloud at all. No namesdropping here (even though I could go on forever!), but I’m specifically targeting such companies that sell cPanel/WHM hosting as “cloud” to their customers, when in actual fact it’s not cloud and isn’t even redundant!

At Somerset Technical Solutions we like to do things differently. We work closely with the client to understand their requirements and business objectives in a detailed manner – before we even quote. We’re then able to tailor the correct solution to the client, which may be cloud-based, or a redundant traditional VPS configuration, or sometimes even shared hosting. Our solutions are based entirely on requirements and proven hosting technology, not buzzwords or over-priced hype products,which in turn brings your expenditure down and your satisfaction up. If you’re looking for hosting or need to review your current configuration then please get in touch.

WordPress, HTTPS, CDN and W3 Total Cache – Take 2

I’ve previously mentioned some of the workarounds of using the excellent W3 Total Cache plugin with a CDN and utilising HTTPS on some pages. The heart of the matter is that some CDN providers do not provide Custom HTTPS support out of the box or do but with a normally large monthly fee attached, some like the excellent MaxCDN will provide free shared SSL support but that is on there own domain, for example for this website, using MaxCDN my HTTPS domain for CDN is

The Problem

By default when you configure W3 Total Cache with a CDN it assumes that your CDN hostname is the same for HTTP or HTTPS. However for providers like MaxCDN and people that don’t want to pay or simply merit the costs of Custom HTTPS support, this means, that as before without disabling CDN on HTTPS pages you would get a mixed content error or worse the CDN elements may fail to load at all, something especially true with Google Chrome.

The Solution

We stumbled upon a solution while chatting with the W3 EDGE team about the issue that there currently exists a way to specify the HTTPS CDN hostname separately from the HTTP hostname. It appears that this feature request was completed some time ago but never made its way into documentation, and the solution is remarkably simple and requires no code changes or additions to get working.

w3tc-cdn-settingsYes it is that simple! in case the image is unclear, in the replace site’s hostname with field, simply supply a comma separated list of hostnames in the format,

and W3 Total Cache will do the rest for you. If you take a look of our Contact page source then you will see that things like CSS files are now loaded from the different HTTPS endpoint compared to the other pages on the site.

If you are a MaxCDN or NetDNA customer you can find your HTTPS domain very easily, login to your MaxCDN/NetDNA portal, go and manage your Pull Zone, there should be a tab called SSL, simply make sure the enable shared SSL option is ticked and save your settings, then the SSL URL should be shown on that same tab if it wasn’t already like in this screenshot:


Now you can enjoy faster more consistent page load times even on HTTPS without causing an extra drain on your server or your wallet.

A new lick of paint

Well as you can see, things look a little different around here! It has taken an exceptionally long time to get this out the door primarily because we prefer to focus on our clients when they need us rather than delay them longer than necessary when support issues come in. I think particularly our redesigned Portfolio page is a testament to how happy our clients are.

We are aware of a few issues with mobile browsers and will be rapidly working at those when we have the moment, but I was keen to get this redesign out the door as it was well overdue. It was Olorin and his team at Level1 Internet that did the design for us with a combination of Explain Extended and the Somerset Technical Solutions team that brought the design to life within WordPress in a totally optimised manner. Just look at the Pingdom Full Page Test results. If you want your website to fly just like that, then you should get in touch.

With the new design we have re-arranged some content. Hopefully nothing is lost and if anything it makes it easier to find out about our services, which we have also just refined and have made clearer so take a look now.