This article is not a shoot-out or bake-off between technologies, but rather a discussion on items for consideration and review when evaluating a cloud migration and possible conversion to an alternative technology stack.
Lift and Shift Versus App Modernization
As cloud adoption gains traction, one of the obvious questions is whether to simply lift and shift or also modernize an application’s data tier. Modernization can mean many things. In the simplest form, modernization may involve upgrading to newer versions or incorporating a new feature set such as consolidation in Oracle using the multitenant option. At the other end of the spectrum, it might involve a complete re-envisioning, involving a move to a cloud-native data storage service.
When deciding how to migrate and modernize, of course, application functionality and technical facets are of critical importance. But so are many other non-functional requirements (NFRs). These are typically not application-required technical features but may include business workflows and other requirements.
Cloud Services Vary
Cloud offerings vary vastly between cloud vendors and specific services. If using infrastructure as a service and running your database software, then there’s really no change. You’ll have the same features, functions, and capabilities in the cloud as you do locally. Where the servers physically ride (and ownership and pricing models) are the primary differences. Likely, it’s the same when using cloud database as a service offerings.
Considering Amazon’s Relational Database Services (RDS) offerings, things start to differ. For example, with the Oracle RDS service, you no longer have access to the underlying operating system and hence cannot use RDBMS structures such as “external tables” or system database administrator privileges. Still, you get most of the Oracle Database functionality although the ability to change settings and initialization parameters may be limited. With other Amazon RDS platforms there may be more or fewer restrictions.
Things really differ for example when evaluating Google BigQuery, where the features and functionality are greatly changed. You’re essentially getting the ability to store and query large amounts of data with a serverless pricing model. Other offerings such as Google Spanner have limitations on the ability to perform DML through their SQL interface and data type storage restrictions.
Possibly these items can be overcome through application changes, redesign, and recoding to yield significant licensing and resourcing savings and/or performance advantages.
But what’s the bigger picture of things to consider?
Business Workflow Requirements
The first thing to do is park the thoughts about costs and general performance, and instead think about other business requirements.
For example, do you need multiple tiers for your applications? Or, do you need a test environment to test application upgrades or user interactions? Depending on the cloud service, it may or may not be possible to perform backups and refreshes of secondary environments. It may be that the cloud vendor provides a service-level agreement (SLA) only. It may not be possible to physically clone your production environment into a secondary test environment in whole or in part—or logically export schemas or tables, and if so, with inter-object consistency.
If you’re used to allowing business users to do a “test deployment” prior to each month-end using a cloned copy of production, then you’ll need to ensure the cloud service you’re considering will support that.
Security and Audit
Data protection through encryption of data at-rest and maybe data in-flight is pretty typical with cloud data services. But what if you have more advanced security requirements such as the need for row-level security, column-level encryption, or data redaction?
Similarly consider audit requirements: object auditing, privilege usage, fine-grained auditing, and audit data management.
Traditional RDBMS software platforms such as the Oracle Database have extensive and comprehensive security and audit features. Cloud services such as Amazon RDS may have most of the same functionality while more cloud-native services may have considerably less.
Data Corruption Mitigation
Cloud-native services typically provide SLAs. But what if you introduce data corruption due to application bugs, user mistakes, or malicious activities?
Again, the Oracle Database, for example, offers many robust features. It depends on the exact situation, but data corruption can often be mitigated using technologies such as the recycle bin to restore accidentally dropped tables, flashback query to query data from a point in time in the past, or even logminer to see data changes in a forensic type of investigation. In a worst-case scenario, it may be desirable to flashback the entire database to a point in the past, or perform a point-in-time recovery. Cloud-native services quite possibly have no equivalent features.
SQL Compatibility
SQL language support can change from one service to another. For example, SQL constructs (such as UNION or MINUS) may not be available on all products. Or if you’re used to “fixing” application issues via data hammers (changes outside of application interfaces), those may or may not be possible.
Also, consider whether cloud-native data services require more business logic (i.e., constraints and similar constructs) to be moved from the data tier to the application tier, hence making them bypassable when using non-application interfaces and making queries less performant (i.e., the Oracle Database optimizer can evaluate a query predicate against a check constraint—moving the business logic to the application tier would lose that efficiency).
One nice thing about the Oracle Cloud offerings is that they’re all based on the Oracle Database under the covers. So whether you’re using the new autonomous database services or the old schema as a service offering, you get full SQL compatibility and access using traditional tools.
Consistency Versus Performance
Are your business users used to certain performance expectations? Then, case dynamic changes/optimizations that are transparent to users and administrators can cause alarm.
If your line of business is accustomed to a month-end job running for 6 hours, and one month the database tunes itself without notification, and it runs for only 30 minutes, will that cause undue concern, investigation, and validation effort? However, if using a cloud-native service, it may go the other way and run for longer due to underlying contention, caching, product updates, or feature changes without visibility.
So the question is whether your users value knowledge and consistency beyond dynamic and non-transparent changes.
Dollars and Sense
Price comparisons are not as simple as the actual amount of money spent. Consult with your finance and accounting departments, as there are differences between service-based costs and costs associated with acquisitions of depreciating assets.
Also consider the importance of “cost certainty” to organizations. Traditional models (of acquiring hardware, software, and people to run, manage, and upgrade them) have a reasonable degree of cost certainty. Cloud services may have cost variance depending on dynamic scalability and usage (i.e., paying per query executed or per byte read).
Weighing the Pros and Cons
Traditional RDBMSs offer a vast array of proprietary or complex features. A cloud lift-and-shift likely means you can continue to use those features and actually, due to cloud licensing differences, you may end up with access to even more.
But if refactoring an application to use more modern cloud native services, many of those features may be lost. And even if not required from the application feature and functionality perspective, it’s critical to consider the other NFRs and changes to business processes and even potential risks.