Interview: Chris Buckel is the VP for biz dev at Silk, a data storage startup based in Massachusetts that used to be called Kaminario. In a recent article, The Battle For Your Databases”, he wrote about the efforts of public cloud titans to win over relational databases, which are the last hold-out of mission-critical on-premises applications. We asked him to expand his thoughts via this email interview.
Blocks & Files: In your blog post you say, “Pretty much every company with an on-prem presence will have one or more relational databases underpinning their critical applications… These workloads are the last bastion of on-prem, the final stand of the privately-managed data centre. And just like mainframes, on-prem may never completely die, but we should expect to see it fade away this decade.” The reason is the hyperscalers (AWS, Azure and GCP) want them. Why?
Chris Buckel: For the public cloud vendors, this is the biggest game still left on the on-prem hunting ground. These business-critical databases are not only important workloads themselves – belonging to enterprise customers who are used to paying heavy costs to run them – but they also support a rich ecosystem of applications around which the hyperscalers can build their high-value offerings like AI and analytics. The phrase being used is “anchor workloads” because these are the anchors which hold back entire, revenue-rich environments from reaching the cloud, keeping them stuck in on-prem purgatory.
Blocks & Files: Aren’t these mission-critical RDMS apps and their data too big to move? Even for AWS Snowball? How will the hyperscalers try to persuade businesses to move their RDBMS app crown jewels to the public cloud?
Buckel: It feels like it, right? But then you have to ask yourself what you mean by “too big to move”. Big as in capacity? Many of the world’s most important transactional databases are less than a few terabytes in size – the rate of change is high, but the actual footprint is surprisingly small. Or maybe “too big” means too critical, too complex, too risky? Before the cloud, database upgrade or migration projects would take months or years.
But this is a different ball game: CIOs and executive boards are embracing the cloud for financial reasons, like exiting the boom and bust cycle of 5 year IT hardware refreshes; outsourcing operational IT to specialist, hyperscalers who can deliver economies of scale; moving to a flexible Opex-based cost model. Whether this dream is a reality or not is still to be decided, but very few companies want to own their own infrastructure anymore, so this journey really does feel inevitable.
Blocks & Files: Do you know of any public cloud efforts to attract mission-critical RDBMS-type applications?
Buckel: All of the major cloud vendors are fighting for these workloads right now. It’s no secret that AWS has been hiring enterprise salespeople for years, building its impressive range of RDS (managed) database services: Oracle, SQL Server, Postgres, MySQL etc. Microsoft – who arguably has the best enterprise credentials of the Big Three – is actively targeting its MS SQL customer base and searching out Oracle customers to bring into Azure.
Google, disadvantaged by Oracle’s refusal to support its eponymous database on GCP, is heavily pushing its Cloud SQL managed service for everyone. Finally, Oracle is obsessed with getting as many of its on-prem customers into the Oracle Cloud as possible, before time runs out. This includes some interesting policy decisions about which products are supported in which clouds, plus the commercial carrot and stick of licensing discounts and – allegedly – audits.
Blocks & Files: Will it be possible to repatriate a migrated RDBMS app suite back to on-premises? Will the egress charges kill that option? (Note Dropbox’s repatriation move saved the company $75 million over two years. )
Buckel: It’s always possible – and some outliers will crop up to make headlines. But in most cases, moving these platforms to the cloud represents a wholesale shift in mindset, in company focus, in roles and responsibilities… If you want to go back, it means undoing a lot of work – you would have to really want it.
On the subject of egress charges, again most databases aren’t actually that big – especially if you can extract or export the raw data. Dropbox is an unusual example because they were a file storage company using AWS as the underlying storage. Given the relatively low margins in their business model, I suspect it was hard to maintain a solution where both Dropbox and AWS made a profit.
Blocks & Files: Do you think webscale companies will retain their data centres (and mission-critical applications) while sub-webscale data centres will move to the public cloud?
Buckel: I personally do not see on-prem dying out; I envisage a long fade away into obscurity in perhaps the same way as mainframes. But it does seem inevitable that workloads will continue to migrate to the hyperscalers over time, which will cause a slow but inexorable rise in the price of on-prem computing. On the other hand, the stellar growth experienced by the hyperscalers cannot continue forever – and what happens then? Could prices increase? If that happened, a lot of cloud customers could find their options very limited given the small number of serious public cloud players in the market.
Blocks & Files: How will non-cloud-native RDBMS app suites be migrated to the cloud? As virtual machines? Is it a massive migration exercise? Can consultancies help?
Buckel: This is a very interesting question. Oracle Database was first released in 1979, DB/2 in 1983, Microsoft SQL Server in 1989. These amazing database products, which still run so many businesses today, were not designed with highly distributed cloud-scale architectures in mind. And Oracle won’t even support the use of its scale-out clustering software outside of the Oracle Cloud.
But the real issue is the complexity of these environments; many will contain untold lines of business logic, written by long-since-departed developers. Moving this into a new database product like CloudSQL, or a managed DBaaS service like RDS, might be too difficult, so IaaS will be the compromise for many. Also, many business-critical databases require high levels of performance which either aren’t natively available in the cloud or are very expensive.
In fact, at Silk we are seeing that performance in the cloud is the single biggest blocker for RDBMS cloud migrations – it’s the number one reason customers engage with us. Consultancies will therefore be key here, as will in-house migration teams at the hyperscalers. Customers will want to be reassured by people who do this all day long.
Blocks & Files: With the rise of edge computing will it matter if the central data centre is hollowed out and its applications go to the public cloud?
Buckel: The nature of these classical RDBMS systems means they are centralised, so while edge computing might play a role at the application level, the database layer is destined to remain as the big, black hole of data around which everything else gravitates.
At least until these platforms are retired in favour of newly-designed, containerised cloud-native applications written by immaculately bearded, t-shirt wearing developers working in Shoreditch basement offices full of exposed brickwork and table-tennis tables. But hey, as a former Oracle guy I’m still a bit sore about finding my old technical skills on the wrong side of the word “legacy”.
Blocks & Files: Is some kind of hybrid model possible, with the on-prem RDBMS app bursting to the public cloud?
Buckel: Yes – it’s a choice which makes sense for many customers. But, architecturally, it’s challenging to take a classical RDBMS application – for example Electronic Patient Records in healthcare, or Warehouse Management in retail – and distribute it so that some users are accessing one location on-prem while others are accessing a public cloud location (a type of design known as “sharding”).
RDBMS is just a very centralised approach to data, so unless the application was already designed with sharding in mind, this may fall into the “too hard” bucket. A more common approach, which we see with Silk customers, is to move the DR site into the public cloud and keep production on-prem (for now). The benefit here is that the cloud DR site can be kept very small, to control cost, but in the event of a failover it can be scaled up (via APIs) to whatever size is appropriate for the necessary performance.
Blocks & Files: What would Silk advise customers to do?
Buckel: Firstly, we advise anybody who is about to renew on-prem database infrastructure to seriously evaluate the public cloud options. Five years is a long time to commit to another stack of on-prem big iron. No database is too big or too performance-hungry to run in the cloud – for example, we are currently helping a bunch of Oracle Exadata customers get the performance they need to move to one of the hyperscalers – so even if now isn’t the time, it makes sense to have a roadmap.
The other bit of advice I give customers is to take a hard look at the cloud roadmap of their on-prem infrastructure vendors. Every vendor has a “Cloud” page on their website, but scratch beneath the surface and many of them offer no value above what you can get direct from Amazon, Microsoft or Google – while some literally run a virtualised version of their product in a cloud VM and think that’s enough to underpin a hybrid cloud story. It’s never been easier to walk away from these guys, so if you are going to give them your money, make sure they are earning every penny.
