The Problem with Scheduled Downtime
June 16,2010 by jkay • Leave a Comment
Filed under:
One of the things which surprises me about IT systems, whether SaaS or not, is the amount of time that upgrades take as systems grow, their often inconvenient timing, and the impact the resulting downtime can have.
Whilst not as damaging as the unscheduled variety, scheduled downtime still has an impact: with international travel it's not uncommon for your colleagues in distant timezones to need to access and update your data, at what are otherwise unsocial hours. Or, if your system is based in another continent an "out of hours" upgrade can happen at the most inconvenient time (for our UK users, the good news is that we are UK-based so the timing of our scheduled outages is less likely to be a problem). But, regardless of where our users are, we want to reduce the duration and minimise the impact of our scheduled outages.
So we do all we can to reduce scheduled downtime. We have always kept the frequency of system updates to a minimum and considered their timing carefully - for example by adopting a quarterly cycle for major releases - but now we're taking advantage of Workbooks' architecture to do things a little differently.
One reason why upgrades are time-consuming is because they involve changes to how data is stored and organised, and the more data that you have to modify at the same time the slower things will get. At Workbooks we've taken a different approach from our competitors as to how we store customer data: for security and scalability that data is completely segmented into separate databases for each customer. Amongst other advantages this means we can process upgrades one customer at a time and prioritise the processing of updates for customers who attempt to access the system in the minutes just after the upgrade has been initiated. Because many customers don't actually access their data at night over the weekend this means that we can reduce scheduled downtime for those that do. We can also run more of the upgrade in parallel further reducing its duration.
I'm pleased that we'll be using this new scheme for all future upgrades, starting with our next major release.