5 Reasons Not to Put Your Oracle Databases in the Cloud

5 Reasons Not to Put Your Oracle Databases in the Cloud

As I blogged about recently, Database-as-a-Service (DBaaS) is an important option for many Oracle database customers. But “data in the cloud” is not right for every business, and there are important issues to be aware of as you consider how or if to leverage DBaaS.

Following are five concerns that might limit your use of DBaaS. This is not an exhaustive list, but it covers the most critical areas:

One: Security constraints

Your data is your company’s most valuable asset. But in the wrong hands, it can also be a major threat to your reputation and even your operations. Likewise, many organizations in healthcare, financial services and other verticals face strict compliance requirements that encompass both data security and third-party relationships involving hosting or even transmitting data. When your data is in the cloud, security is largely outside your control. When (let’s be realistic: it’s not a question of “if”) the DBaaS provider’s comparatively large attack surface is breached, will your data be safe? How can you know for certain whether it was or wasn’t compromised? What, if any, additional precautions can you take when data is at rest or in transit to and from the cloud?

Two: Data governance/access

When your data is in the cloud and a third-party is managing it, who has access to it? And what levels of access do they have? With DBaaS, you don’t have direct control over that. People outside your organization, very possibly on another continent, could have access for a wide range of reasons; e.g., database administration or IT infrastructure monitoring. Privilege escalation vulnerabilities can be greater in DBaaS scenarios. Some classes of data (test/development data, non-sensitive data, etc.) are better suited to this scenario than others. What is your level of comfort with how your data is stored and accessed in the cloud?

Three: Database availability, performance and uptime

When you move a database from on-premise into the cloud, you increase the distance between your application and your data. You also introduce factors outside your control that could make your data unavailable or impact database uptime. WAN link failures and service provider outages are probably the two main concerns. What are the service provider’s availability and uptime guarantees? Do you know that your data is being properly and securely backed up? If problems occur, what is your recourse? What is your recovery plan?

Four: Database performance and user experience

When a database resides in a public cloud environment, there are multiple shared infrastructure components supporting it, including the Internet itself, which you can’t control and in many cases would be challenged to monitor. As a result, users’ experience with accessing the data can be very inconsistent. This issue can be made worse when the volumes of data involved are large.  You or your users might also experience poor performance as a result of any number of issues with the service provider’s infrastructure. Will the data service provider do a good job with data management? If they don’t, how much time, energy and money will it take to rectify the situation?

Five: Vendor lock-in and interoperability concerns

DBaaS customers naturally want to be able to shift from one provider to another without a lot of trouble and expense. But cloud vendor lock-in can be burdensome and costly. It may not even be a matter of dissatisfaction with the provider; you may simply want to use different providers that are closer to your diverse customers, in order to minimize latency issues. Or your provider could go out of business. If you write/optimize application components for one DBaaS environment, will they run on another DBaaS provider’s infrastructure? Or are you stuck with that provider’s APIs?

Still thinking about using DBaaS? To get some expert advice on whether DBaaS is right for your Oracle databases, contact Buda Consulting. Concerned about data security? Sign up for a database security audit.