The beginner’s guide to HASH (highly available scalable hosting).
16th June 2020 • 8 min read
16th June 2020 • 8 min read
The French have a saying, “All cognac is brandy but not all brandy is cognac,” and a similar thing applies when it comes to hosting.
The advent of cloud computing means that ‘highly available scalable hosting’ (HASH) is now available to anyone – not just big multinationals with budgets to match.
Highly available hosting and scalable hosting may sound like the same thing, and they do use some of the same methods to achieve their goals. But there’s a difference between the two, much like brandy and cognac.
Scalable hosting means that the hosting solution is able to grow and shrink to meet the demand being placed on it.
Highly available hosting, on the other hand, means that if any component fails – from a web server going down to a load balancer dying – the solution will be able to carry on working.
To demonstrate this concept in true Torpedo fashion, we did a practical demonstration during one of my infamous internal Knowledge Shares.
Hopefully that’s given you a high-level overview of how it works – but how do we achieve this at Torpedo?
The goal of highly available hosting is to be able to recover from any component failure within a system. A basic solution might look like the following diagram:
This solution starts with the premise that you can have no single point of failure. The way we achieve this is by ensuring every part of the infrastructure has at least one failover:
The entire solution is also spread across at least two separate data centres. This means that even if a data centre goes dark, the machines in another data centre will still be running. It’s also possible to have the system bring up resources in a third data centre, but this is straying into the realms of scalable hosting.
“ Everything fails, all the time. ”
The goal of scalable hosting is to allow the solution to grow and shrink to meet demand, a basic solution looks much like the highly available one, but with a few tweaks;
While a number of the elements in this solution are the same, we’re relying on different characteristics of these components:
The magic that makes the solution a cognac and not just a rather fine brandy is the auto-scaling group. This, once configured, sets up monitoring on the servers (database or web) and fires up an additional server when the monitored metric goes over a certain threshold.
For example, if the Central Processing Unit (CPU) usage across both web servers is over 60% then the system will add an additional server into the mix, increasing the number of servers until the CPU usage drops back down below 60%, or the number of servers hits an upper limit. On the other hand, if the CPU usage drops below 30% then the system will kill off additional servers until the CPU usage goes back above 30%, or the number of servers hits a lower limit.
These upper and lower limits are defined in the configuration. If you set the lower limit to two then you automatically have a ‘highly available’ solution because there will always be at least two web servers. In fact, because of the auto-scaling group lower limit, if there are only two servers and one of them fails, which as Mr Vogels says will happen, then the system will recognise that there’s only one server and increase the number of servers back to two – in another data centre if necessary.
Scalable hosting is automatically highly available as the solution will spin up a replacement if part of the solution fails. But a highly available solution is not automatically scalable as the system is only designed to ‘keep running’ which requires intervention when things go wrong, rather than ‘self-repairing’.
I mentioned that with the advent of cloud computing, the cost of these solutions is now within reach for most businesses, however it’s still expensive. You’d be looking at more than five times the cost of standard hosting and there’s more maintenance involved, so this solution should only be considered if uptime is critical. For example, if you have an ecommerce site and downtime stops you from taking orders, you should definitely consider this. You might also consider this type of hosting if there’s a possibility of reputational damage if the site goes down.
When we built an ecommerce site for CRM Students, we used highly available scalable hosting. We worked with CRM Students, a leading provider of student accommodation, to build them a new website in WordPress that was highly flexible and included ecommerce functionality. The site also needed to integrate with TCAS the third-party student accommodation booking system.
We also incorporated HASH into the corporate websites we created for Lucy Group and each of its 7 different business units. The company was established in Oxford over 200 years ago and has continued to expand and diversify into new markets and regions, now employing over 1,400 people and trading in over 60 countries.
Another project we worked on that includes HASH is the award-winning BIM 360 website we built for leading software company Autodesk. The website brings together all content relating to BIM 360 software and transforms the user experience, helping every member of Autodesk’s audience quickly and easily find the content they need.
