Considering a database migration to cloud? Here is what you should know

Moving database workloads to the cloud is a worthwhile effort as part of modernizing your architecture and being better prepared for your future. 

But before you embark on this journey, there are some crucial questions you need to answer:

• Why are we doing this?
• What do we want to get from migrating the database to the cloud?
• Is the primary reason economic? Or, something else like the flexibility to run on a cloud platform?

This, too, is an opportunity to re-evaluate the database choice for your application since technologies in the cloud do not operate in exactly the same way as on-premises.

Let’s have a look at some of the options.

Choices, choices, choices

Oracle’s database technology was built to run best on bare metal and to take advantage of proprietary hardware. It is very well tuned for scale-up scenarios, especially on large servers. In addition, Oracle’s RAC architecture is geared toward optimizing the use of shared disk storage. While these factors are favorable for data center deployments, they generally make Oracle databases ill-fitted for the cloud. The Oracle Cloud has introduced a number of proprietary features to deal with this inherent mismatch but these are only available on the Oracle cloud.

There has been a rapid growth of interest in the PostgreSQL database management system as a popular alternative for cloud workloads. For the second consecutive year, PostgreSQL has been named ‘Database of the Year’ by DB-Engines gaining more popularity than any of the other 343 systems monitored.

When approaching a database migration, think about the support you’ll need for different data types like JSONB, SQL, PostGIS – not just today but for your future needs. Everyone always thinks about data and data structures, but those are the easy part of migration – even with large datasets.

By comparison, code in the form of queries and stored procedures might look like the easy part of a migration but they are not! Then, consider database driver interfaces like OCI, JDBC, ODBC, .NET, which are hard because they touch the application that talks to the database and call stored procedures for return parameters. If this isn’t handled properly in the database migration, then the ripple effect is that the application will need to be transformed which will dramatically increase the cost and risk associated with the migration to cloud.

Consider, too, management and compliance requirements for the database like backup/recovery, security, integration with other IT systems. It’s possible in the migration for the data and code to work just fine, but operational requirements procedures must be met, too.

SEE ALSO: A tour of cloud computing: “Cloud-neutral adds a large amount of complexity and risk to a migration, without really solving the issue”

What makes a good or bad candidate for migration to the cloud?

At this point, the biggest gating factor is performance. While on-premises applications can often leverage a massive, fiber channel-connected server with 100,000+ input/output operations per second (IOPS), you won’t see that kind of high-end performance in the public cloud. In some cases, the IOPs in the cloud might be only half of your organization’s required capability, even in a perfect scenario with no overhead. This type of high-performance workload should remain in your data center.

Here are some other tips:

1. Begin by identifying a small portion of databases that aren’t linked to mission-critical tasks and can be easily moved.
2. Look at the availability of application developers who wrote the source code and are using the database. It’s a good sign if they’re around and can help with verification in the migration to cloud.
3. On the other hand, red flags are proprietary extensions, like Oracle extensions of .NET and ODBC or Java proprietary extensions, for example.
4. Another example of a red flag is the ProC interface used in an older version of Oracle 8, which indicates it’s supporting an old application and typically that means the migration is more difficult.

When you evaluate automated database migration tools, consider the building blocks that you’ll need to migrate – those are your schema, data, stored procedure code, and interface. Some automation tools – like those from cloud providers – only go part of the way migrating schema and data, for example, leaving it up to you to complete the last mile and convert everything else over. And, that may leave you feeling it seems nearly impossible to complete the database migration.

It’s a good idea to use the automated migration tool for verification as the first step in the actual migration process.

Once the schema, data, and application are migrated, you’ll want to run a thorough set of tests to ensure that the application behaves in the same way it did before the move. To meet users’ expectations, test the performance, availability, scalability, network speed, along with security.

I recommend identifying the database candidates that look easiest – your low-hanging fruit – so that you’re able to gain success and experience and progress from there. After you’ve had some successes migrating those in the low-hanging fruit category, you’ll be able to use the knowledge gained from those to progress further in tackling more complicated candidates in your transition to cloud computing.

The post Considering a database migration to cloud? Here is what you should know appeared first on JAXenter.