The Problem with Scheduled Downtime
June 16,2010 by jkay • Leave a Comment
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.
The buck stops here
April 26,2010 by jkay • Leave a Comment
As with IT generally, there are a lot of facets to "cloud computing". Some companies deliver cloud services for end-users (facebook or Microsoft's hotmail for example). Some, like Workbooks, deliver services for other companies. And some companies deliver services to support other companies' delivery of cloud services.
Amazon Web Services is perhaps the leading provider to such services - it is a division of Amazon which many organisations use to power their IT services by providing them with computer and storage capacity "on demand". If you take Amazon's Web Services' main offering - EC2 - then you are renting "virtual machine instances". These are systems on which you can run your own operating system and they share a portion of the underlying hardware's resources. You are of course sharing hardware with other EC2 customers and it's down to chance whether your fellow virtual machine users are resource hogs or not. So there are now cloud services which help you manage your Amazon Web Services and it's perhaps unsurprising that some of them report variations in EC2's performance.
This last category poses an interesting question if you believe in the power of the cloud computing model: if you are going to deliver cloud services yourself, should you rely on other cloud services to deliver some of your underlying components? Certainly a model where Workbooks was built upon cloud services from other providers would have its advantages: we'd only pay for exactly what we used, and it would be very easy and very fast to add capacity: simply order some more and turn it on, on demand.
When things go according to plan, everyone's happy. But if things become unreliable it's Workbooks which our customers would see failing - and those customers would be right to expect Workbooks to stand behind the service and remedy it. Excuses such as "it's our supplier's fault" just wouldn't cut it. When you have very large third-parties delivering components of the service it's unlikely that Workbooks' top priority would be their top priority.
Basically, we think that the cloud model is something which works - brilliantly - where there's a simple customer/supplier relationship but that it can break down when there are hierarchies of services unless you think very carefully about how you will deal with the contingencies. It's a little different from traditional business relationships where you have the luxury of at least a little time to sort out most issues: we need our infrastructure to be always available and reliable. We don't want to be involved in trying to diagnose a third-party infrastructure (like EC2) and having the responsibility to sort out issues within it without having the ability to do so.
So we took a different route. We built our own infrastructure and we are responsible for its management - right down to the hardware. Although we do use third parties for some of the components, there is always redundancy: multiple networks, multiple locations. If a provider fails to deliver a service we can call on an alternative so we can be certain we can deliver the service levels we commit to in our SLA. Maybe we will use some Amazon services in the future but if we do they'll be non-core and we'll be sure to have a backup plan.
The reinvigorated web browser
April 08,2010 by jkay • Leave a Comment
At Workbooks we are very interested in the evolution of the web browser - it has only recently become possible to deliver a compelling rich User Interface like the Workbooks Desktop without requiring all manner of plugins. The good news is that the evolution is accelerating and with it the browser's speed and capability.
Eighteen months ago Google launched Chrome which was dramatically faster than any other browser available at the time. A browser performance and functionality war has been underway since then. In those eighteen months, and despite some hiccups, Chrome has become the world's third most popular browser - after Microsoft's Internet Explorer and Mozilla's Firefox and ahead of Apple's Safari and Opera's eponymous browser. It's well documented that Internet Explorer's market share has been declining at an increasing pace since its peak in 2004 - that decline accelerating further since Google's entrance into the market and likely further still with the advent of the European Union's "browser ballot" screen. Google have also announced Google Chrome Frame, a plugin to Internet Explorer, which brings Chrome's features and performance to Microsoft's browsers for websites that are modified to use it. Finally there is now a proliferation of new ways of accessing the Internet using things other than PCs where there is nothing Microsoft in sight: from PS3s, iPhones and iPads for example.
Internet Explorer was first released nearly fifteen years ago; the other week Microsoft unveiled a "Platform Preview" of the next version, dubbed Internet Explorer 9. It's not even "alpha" software - we have no idea when it will be ready - and yet it has excited a lot of commentary. My view is that it signals a radical departure for Microsoft and they should be applauded for it.
As is Microsoft's way they are still a little picky about which open standards they embrace but IE9 includes much that other browsers are also adopting so eventually if you choose a modern browser from any mainstream vendor it will be capable of rendering video, storing data to work with while offline, and showing beautiful charts which scale smoothly as you zoom your browser - all without requiring any external software ("plugins"). As an added benefit it will get easier for developers to write web sites which work consistently across all major browsers without major compromise through a "lowest common denominator" approach: the lowest common denominator is now getting a lot higher.
IE9 is notable also for the speed it promises. It has become very fashionable - and easy - to criticise the performance of Microsoft's browsers. It's refreshing that with IE9 Microsoft has ditched its denial of there being a performance issue with IE and decided to address the issue: now it's going to be "crazy fast".
Depending on the benchmark IE9 shows upwards of a sixfold improvement over IE8 which itself is twice as fast as IE7. Although it's unlikely IE9 will take the speed crown for most tasks from current leaders Opera and Chrome or overtake Safari it does at least mean we will be able to stop focusing quite so much on IE performance as an issue.
Prior to IE9's announcement it was looking increasingly likely that Microsoft's market share decline would only increase however now it's clear that Microsoft have decided not to abdicate from the browser market; Chrome Frame will likely be marginalised to be a tool for those IE users who are unable or unwilling to migrate to the latest version of IE.
But more significant than any of the above is that I think IE9 is going to be fundamentally different from previous versions of IE: it delivers most of what it does using open standards. It's well documented that many organisations are still stuck on IE6 - even though IE6 has had its funeral - because that browser included a raft of proprietary extensions that did not make it into IE7 or any subsequent browser. Open standards are easier for developers and allow users to avoid lockin.
This is all great news for the user: whichever browser you use it is getting faster, more stable and more functional.