Colleagues at one of the world's largest SIs have been testing the Amazon Oracle Relational Database Service - aka RDS (and not to be confused with SAP Rapid Deployment Solutions also aka RDS.) The early verdict is not promising.
This is what they are finding:
- AWS/Oracle RDS includes a Bring Your Own License (BYOL) model, which is fine as Oracle offers Personal, Standard and Enterprise licensing. AWS does not have a traditional CPU model because of its virtualisation approach. Instead, it uses Compute Units (like SAPS.) This could represent a licensing pitfall. It is not insurmountable and must have been clarified as part of the Oracle and AWS deal. However, there is no detail in the FAQs explaining what, if any differences might exist between licenses already held and those operating on the BYOL RDS model. Given Oracle's close attention to account management, anyone considering AWS/Oracle RDS MUST check with account managers about the status of licensing virtualised instances on AWS.
- Oracle and AWS have hobbled the security permissions on the platform. They say this is for security and stability reasons. If you believe that then one has to question why you'd be considering this deployment method in the first place. For example, the character set of the database for an SAP install needs to be UTF8. If it is ATF something, you do not necessarily have the permissions to change the character set for the database instance. This will be limiting to people on special codepages who want to migrate onto this platform.
- Administrator documentation is very poor. It looks like Oracle has concentrated on allowing people to get data into the database using it's own export/import data pump and nothing else - very poor form. There is little documentation on how to perform administration tasks like changing parameters. It seems that is largely because the security objects have been heavily locked down. It looks like AWS have tried to write some of the sysadmin documentation but have not had a lot of help from Oracle. A first pass suggests Amazon has done an 'OK' job on the API side (which you would expect) but it is very poor on the CLI/SQLPlus commands. The documentation seems to rely on "We've shown you a principle, now go and find the rest yourself." For example, there are stored procedures which can perform admin tasks that require access to the locked security objects. But there are only example commands for four of the 45 rdsadmin stored procedures. There is no AWS documentation on the configurable parameters.
- Given the above, why would you waste any license on this platform and especially an Enterprise license? Until there is better documentation on platform versus edition features, SIs caution on using this service under the BYOL arrangements.
What can we make of this?
Other colleagues have been waiting to hear 'in the field' assessments of RDS in order to better advise clients. This first cut does not look promising. It is no surprise that AWS went with Oracle first. No other Enterprise database vendor wanted AWS RDS. IBM and Microsoft have their own cloud and PaaS offerings; they do not have to play nicely with AWS. That leaves Oracle looking as though it is playing nicely in the low cost AWS world when in reality licensing doubts loom large.
Oracle wants to supplant MySQL as the database of choice in the flexible AWS world, by putting all it's RDBMS real estate on RDS. Oracle can now prioritise feature releases across the RDS with a view to better license revenues.
Let's be clear. We're not seeing a specific cloud edition for RDS, which suggests three things:
- Oracle deployed editions with which experienced DBAs will be familiar but without explaining the feature differences. The less wary may find themselves in licensing hell.
- The RDS platform does not suit the Oracle RDBMS so AWS/Oracle were forced to pare back on features.
- This was a hastily cobbled solution that attempts to give AWS genuine enterprise credibility but fails to deliver on a first pass.
Regardless, customers are advised to think very carefully before deploying anything other than backup storage instances.