Taking enterprise databases to your cloud


Databases are like cars. You have the vintage cars that everyone looks back on fondly, and now they cost 20 times what they did back in the 1970s. Also, you have the new cars that don’t have the same sex appeal but work much better than cars built 30 years ago; they are faster, get better mileage, and have the latest technology.

Many data sets are being relocated to the cloud, and now those charged with moving the workloads and data must consider their options.

The first option is to just move your enterprise database license to the public cloud provider. It’s called “bring your own license” (BYOL). This is the path of least resistance, considering that all you’re doing is moving data native to database A to database A on another host platform, this time hosted in the public cloud.

However, it’s not the cheapest way to go. You’re likely paying out the nose annually for your enterprise database, and it probably does not have the features, functions, and performance of some cloud-native database options, which have on-demand (usage-based) pricing.

Although your specific requirements may vary, generally speaking, cloud-native databases are a better way to relocate data to the cloud. The downside is that you’ll need to load and recast the data for a new native storage model. Moreover, you’ll have to change the applications that access the database.

My take on this is that you’d likely need to refactor the applications anyway to leverage cloud-native services, so you might as well refactor for a new cloud-native database as well. This may increase the frustration for some, but the end results are applications and databases that perform better, provide more features and functions, cost less to use, and are purpose-built for your specific use case.

READ  Your 3-minute guide to serverless success



READ SOURCE

LEAVE A REPLY

Please enter your comment!
Please enter your name here