At DediPower we support a massively diverse corner of the internet with hosting platforms ranging from single server sites to large, multi-server, load balanced content delivery systems. As businesses change, requirements inevitably follow and as such my job as a solution architect sometimes becomes much more of an advisory role.
A particular scenario that I can personally relate strongly to coming from a development background is where clients are happily running nice, simple traditional 2 tier web and database applications but growing to a point where they are starting to take more traffic than was ever envisioned and are straining the hardware originally deployed to support it.
More commonly than not we see clients using software, be it custom software or one of the thousands of software platforms available, that hasn’t been designed with true scalability in mind.
Scaling a platform vertically is always a quick win when hardware starts to struggle however there is only so far you can scale up and typically we advise, for those clients rapidly growing, that this should be considered as simply buying some time to test options for greater performance potential.
We see a lot of web applications which are extremely heavy on the underlying database and unfortunately it is typically scaling the database which is the difficult task during these projects. Deploying multiple web servers behind a load balancer is a relatively simple and risk free procedure for most applications, however, to do the same with the database layer requires a certain degree of support by the web application itself and that a few specific database design issues are considered.
There is no one way of designing or modifying a database so that it can be horizontally scaled as this depends hugely on the form and purpose of the service and is certainly way beyond the scope of this post.
The general principle however is to make the web app capable of utilising multiple instances or partitions of the same database so that you have the computing resources of multiple servers available to you for handling queries. The replication mechanisms at work behind the scenes, that ensure data written to one instance is also copied to all other instances, work in near real-time, however, “near” real-time is not fast enough for this process to be transparent to the web application.
Often, a large proportion of the cost of building in true scalability to web services is the relatively high expense of the potentially significant development and testing time required to make software and databases compatible. We are often asked what we can do with the platform itself to minimise this impact, and the truth is, there are quite a few tricks that can be employed to enhance performance without touching the software. However, between us we have a huge wealth of software development knowledge so we are well equipped to give really good guidance, not just on potential hardware and configuration but also on quick wins that can be found within the application and databases themselves.
Working through these kind of problems with our clients and helping them though these difficult upgrades is one particularly interesting and rewarding part of my job!