- How AWS’s new heterogeneous migration targets Oracle.
- Understanding how AWS’s Managed Services reduces a company’s reliance on Oracle support.
Oracle has based its database business around lock-in. As I have covered in previous articles, there is an immense opportunity to reduce costs by migrating away from Oracle databases to databases like PostgreSQL or MariaDB or others. However, something that is required is a managed DB. There is no point in migrating away from Oracle DBAs if something else cannot take its place.
Well, something did.
AWS’s Managed Services
AWS came up with the managed DB through its managed services, which manages overall infrastructure, databases being one component of this. This AWS has had for a while. However, migration has been performed by consulting firms with expertise in AWS. But recently AWS has “greased the skids” for companies with the desire to migrate databases to AWS, and also to migrate away from the database to different databases. Let us see the following quotation from the AWS website.
“The service supports homogenous migrations such as Oracle to Oracle, and also heterogeneous migrations between different database platforms, such as Oracle to Amazon Aurora or Microsoft SQL Server to MySQL. You can also use AWS DMS to stream data to Amazon Redshift, Amazon DynamoDB, and Amazon S3 from any of the supported sources, including Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE, SQL Server, and MongoDB. In addition, you can use AWS DMS for continuous data replication with high availability.” – AWS Website
“Options” But a Target on Oracle’s Back
AWS presents this as a bunch of “options” but there is one database vendor that is burning a hole in company’s pockets with its expense and overhead and this database is Oracle.
In this quotation, it explains the details of how this is accomplished.
“With this launch, AWS DMS enables customers to use the same mechanic that the database uses for commit sequencing, which is the log sequence number (LSN). The launch also opens more integration use cases. For example, now you can use Oracle Data Pump or SQL Server BCP to do the initial data load into a target database and then use the DMS log sequence numbers to start change data capture (CDC). With the checkpoint feature.. you can replicate changes once a day from the last checkpoint.” – AWS Website
This conversion setup can be seen in the following screenshot from AWS.
Notice the options under the migration type.
Companies can avail themselves of this new capability to migrate away from Oracle. Of course, many companies have customizations in Oracle, stored procedure, etc, that reduce the ability to migrate. However, for those databases that can, (other databases can be migrated by moving the stored procedures out of the database and into the application layer) it enables one to migrate to an open source database, which in the vast majority of cases can handle the workload just fine, and with AWS’s Managed Services, it means that Oracle support can be dropped. This can be a boon to companies. It takes what amounts to what is widely considered to be close to no value, and puts back in the company’s pocket to spend on things that do add value.
Search Our Other HANA Content
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model