The popularity of public cloud is on exceptional growth; more and more organizations are moving their Infrastructure, databases, and applications to the Cloud. Oracle Database migration to Google Cloud is one of the prominent use cases that many organizations are adopting and focusing to start their journey.
This is because of the flexibility, scalability, reliability, and security that Google Cloud offers. And as we evolve, we expect to see more enterprises consider leveraging these capabilities.
Database Migration is one of the most critical components of any workload migration and yes, it could be a challenging task due to several reasons:
- A lot of proprietary technology and functionality that's built into the legacy database technologies and functionalities like stored procedure, custom functions, Oracle RAC etc.
- Historical on-prem databases are all monolithic and humongous servers.
- Incompatibility issues: Both internal- and external-facing applications, that are all relying on the database and might not be compatible with different database platforms.
There are 4 ways to run Oracle in Google Cloud
- Bare metal within Region Extensions:
- Oracle certified compute and storage within region extensions
- Low latency connectivity to GCP (<1ms)
- Same license cost as on-prem (no 2x cloud penalty)
- BYOL model, sole tenant bare metal servers ensure low bar for entry from on-prem, all existing processes, scripts work seamlessly
- Manage Oracle database yourself or bring in a partner, Google manages infrastructure, SLA 99.9%
- Google Cloud VMWare Engine:
- Fully managed VMWare infrastructure from Google Cloud
- Management, networking services, operating platform, and backend infrastructure run at-scale by Google Cloud
- Provision your VMware environment in Google Cloud in minutes
- API-driven management of VMware SDDC
- Automated remediation of failed components
- Free customers from infrastructure operation toil
- El Carro – Oracle on Anthos:
- Run Oracle containerized with the power of Bare Metal
- Modernize Oracle landscape by adopting DevOps practices from the container world
- Containers provide higher density per core (approximately 2x) than VM with bare metal performance, reducing license cost
- Lifecycle tasks of provisioning, backup and restore, etc. automated by Kubernetes operator with full administrative access
- Database Anywhere:
- Run database anywhere, on-prem, or partner co-lo and connect to GCP via high-speed interconnect service from Equinix
- Giving latency-sensitive on-prem applications and databases direct and secure access to Google Cloud’s extensive capabilities
- Leveraging BQ, including streaming data in real-time and predictive analytics with built-in ML
- Enabling SaaS customers to archive Oracle databases on Google Cloud using direct and secure, private interconnection
It's important to consider the risks that are associated with migrating the on-prem Oracle database to Cloud. Depending on the current infrastructure, migration timeline and triggers and the aspirations of a customer, different targets and strategies could be considered.
In general, there are two types of database migrations:
- Homogeneous Migration (Lift & Shift/ Re-host, Re-platform)
- Heterogeneous Migration
Everything starts with an assessment; this is the most critical stage of the engagement. It is important to spend time during assessment analyzing the source databases in-order to establish suitable candidates for different type of migrations and approaches
Homogeneous migration
Lift and shift, Re-hosting: Where you're retaining the same database engine, but you're just moving over from on-premises to the cloud. Lift and shift, Re-hosting the database on cloud without changing the underline platform (OS) or changes to the app. There are multiple ways to achieve this on Google Cloud:
- Re-hosting the virtualized VM-ware workload on Google Cloud by extending to GCVE (Google Compute VM-Ware Engine).
- Making use of Bare Metal Solution for specialized workloads
- Re-hosting database on GCE (Google Compute Engine)
Each of the above has its own considerations. For example, license considerations on GCE:
- If the existing database vendor allows for license mobility
- Does the vendor certify a particular platform? This may have support implications.
- Right sizing, in case of non-virtualized workloads on Bare Metal
- Performance implications
This approach is very common and brings a lot of benefits, like:
- You already have trained staff that understands the technology and is familiar with the current solution. So, migrating it on cloud would not impact resources – as there's not as much of a learning curve associated with it and at the same time it accelerates the migration timelines.
- The database engine is still the same - you have fewer application rewrites or for that matter no application changes, which means lower risk and reduced migration timelines.
Figure 2 : Benchmarking and right sizing
Re-platform: Keeping the application unchanged while adopting platforms which are either cloud compatible or help drive additional value while migrating workload to cloud. For instance,, re-platforming databases running on AIX to Linux
Some other examples include On-prem MS SQL Server / MySQL / PostgreSQL migrations to Cloud SQL
This approach again would to consider:
- Project timelines
- Feature compatibility
- Downtime
- Tools
- Cost
Heterogeneous migration
The other type of migration is called heterogeneous migration, where you want to port the legacy database engine. Organizations commonly use this in the same vein as Modernization or Digital Transformation.
Reasons to trigger Heterogenous Migrations
- Cost of License and renewal
- With business growth- organizations tend to develop more and more new applications. Therefore, to avail the benefits of cloud like cost savings, lowering TCO (Total Cost of Ownership)
- Reducing your reliance on a particular vendor lock in proprietary technology.
- Adoption of open-source technologies
Although, from a high-level it appears to be a lucrative proposition to migrate off the enterprise database like Oracle to an Open-source database such as PostgreSQL, one could immediately visualize positive impacts such as no periodic renewal cost, freedom to choose an open-source database. However, the following factors must be reviewed while choosing the path forward.
- No two bespoke applications would have the same schema. It is important to understand that unlike lift and shift and re-platform, the issues with heterogeneous conversion are deeper. The database objects and code cannot be migrated as-is. It is important to do a deep schema level analysis before committing.
- Whether there is embedded code or ORM (Object Relational Mapper)
- The knowledge of the business logic is essential in case of application refactoring or Database code re-write.
- Feature mismatch between the source and target database. For example, native packages which are available on source may not have an equivalent on target. This entails finding workarounds for specific problems which are time consuming.
- Downtime availability, while it is not a factor during the code conversion. It may become a critical dependency during the cutover. The choice of tools hence becomes critical.
- The complexity of code and database size are factors that determine the effort required.
- If the application has been developed over a period of time, there is a good possibility that the original application developer is not part of the team anymore and there is legacy code which may have to be rewritten.
- The functional testing although is the primary responsibility of the application team it would require engagement of the database resources. Expect the total time to be spent on the functional and performance testing to be around 50%. These numbers are indicative and may vary greatly depending on the schema and application complexity/requirement.
The idea of migrating the overall database landscape from database “A” to database “B” is a very critical business decision. Realistic assessment would result in fruitful attempts rather than overambitious failure. The assessment for heterogeneous migration would form the basis successful migration
- The platform IaaS (Open Source or a supported Enterprise version) or PaaS (Cloud SQL PostgreSQL)
- Effort required for conversion both at application and database layer.
- Tools to be used
- Feasibility
The choice of platform is critical for the success of migration as different platforms provide different capabilities. The choice of platform would impact the effort where code compatibility is a major issue. The choice of tools depends on the choice of platform and the downtime availability (specifically for a production environment)
The choice of tool for migration is another important factor. There are several tools available both open source and licensed. Both have their own set of advantages, challenges and costs. Knowing when to use which tool is based on the experience of the team. For example, there are situations where you may prefer using an open-source tool like Ora2PG for conversion over a licensed one like Ispirer and vice-versa.
The size of data and the rate of change of data are factors to be considered for critical applications /databases which cannot afford downtime during cutover or require parallel run. Then a CDC (Change Data Capture) based synchronization tool must be considered to facilitate near zero downtime, continuous synchronization, and a possible rollback. There are choices which are cloud native and third-party tools.
The below picture provides a high-level view of steps for Heterogeneous Migration, For e.g. Oracle to Cloud SQL
Figure 3: Oracle to Cloud SQL Migration steps
Migration Complexity:
Complexity of a migration is derived out of various factors. The most significant factors are illustrated below.
Figure 4: Complexity Matrix
Conclusion
Database Migration is a complex process and organizations should decide their roadmap on cloud with full proof planning through in-depth assessment. Both homogeneous and heterogeneous migrations have their own benefits and challenges which must be factored in during the discovery and assessment phase. The migration effort must be justified by the gains. A big bang migration without considering the challenges may result in undesired outcome. Source databases must be picked based on the real-world effort estimates rather than guess work. With careful planning, right strategies, tools, and resources successful migration can be achieved and organizations can gain the real benefit of Google Cloud.
