At RelativityFest this week, kCura showed more details about how their upcoming software-as-a-service hosted in Microsoft Azure works. I really like where they’re going with it.
- It hosts legal data (think lawsuits, cases, investigations)
- Every case is its own database
- New databases are created all the time by end users
- Lawyers work in these databases, putting in their work product
- Losing data would be extremely expensive
This makes database administration a real pain. A lot of HA/DR technologies require you to do manual work as new databases are added, or else you have to build your own custom apps to protect newly added databases automatically. Databases appear out of nowhere, and suddenly get terabytes of data loaded into them over the span of a week, and can then go idle for weeks, then suddenly get a new load of user activity. It’s really hard to predict and protect this stuff, which also makes budgeting for hardware extremely tough. By the time a case comes in and explodes, you don’t have the money for it, and when you get the hardware in, it’s too late.
It’s absolutely perfect for the cloud.
Today, the first private beta iteration of RelativityOne uses SQL Server 2016 hosted in Azure VMs, protected with Always On Availability Groups. (While that option doesn’t really make sense for on-premises HA failover protection, it works for a hosted version for reasons that are kinda unrelated here.) kCura’s own teams are doing uptime and performance support in real time – just like you’ve been doing for years.
I get excited about this because:
kCura’s DevOps teams are learning the challenges of AGs firsthand. I like to say that Always On Availability Groups are the opposite of the easy button – they’re awesome, but they require a ton of work. kCura’s feeling those pains, and as a result, they’re examining their own software to figure out how to improve the HA/DR situation.
kCura can react faster to performance issues. Before RelativityOne, if a new version of Relativity shipped with some less-than-fast queries, you (the DBA) were the first to know. You’d open a support ticket to alert kCura, and they’d work with you on a fix – but that fix may require a patch, and you might need an outage to apply it, and the business might not give it to you. With RelativityOne, kCura will catch the problem first.
Furthermore, it’s in kCura’s best interest to fix performance issues. When a query burns up a ton of server horsepower, it hits kCura directly in the wallet. They can’t pass on increased Azure resource costs to you if they put out a bad query – they have to temporarily absorb it, and then fix it so they can save money. As they do performance tuning, those same fixes will be in the on-premises version too, since it has the same code base.
- If you use the Azure-based RelativityOne, you can avoid the crappy parts of database administration: backups, CHECKDB, server patching, and outage troubleshooting.
- If you use the conventional on-premises version, you get the benefit of better application code because the software vendor is now doing the same work you’ve had to do.
And when I eventually do use RelativityOne – because I think all e-discovery software will end up in the cloud sooner or later – I really love RelativityOne because we still get query access to the databases. I’m amazed they’re giving customers that power – and responsibility.