With so many workloads being migrated to the cloud, this is a question we get all the time. For anyone making this move there are many choices to make and options to consider. In this post, I will step through those to help you decide on a path forward.
First, recognize that not every workload is equally suited for cloud deployment. To properly prioritize workloads, it is recommended that applications are segmented into different tiers based on their business importance and fitness for 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.
The other big concern about moving workloads to the cloud – and databases in particular – relates to security. Today, however, by implementing best practices for data governance and security, databases can be just as secure in the cloud as they are in the data center. For instance, it’s possible to take advantage of strong encryption algorithms like Advanced Encryption Standard (AES).
Once you’ve segmented and prioritized your workloads, you’ll need to consider the best cloud computing option for your database. Here is a quick overview of four popular choices.
Amazon Web Services (AWS) offers almost anything you might want to use on a cloud and databases are no exception. Using APIs, you can create scripts to help with orchestration and connect other services. However, this kind of customization ties you closer to AWS and can mean less flexibility.
Microsoft Azure is a strong alternative cloud platform that is a particularly good fit for organizations already built on a .NET ecosystem.
Then, there is Google Cloud Platform (GCP) which offers massive scale and responsiveness along with a long history of contributing to open source. Because of this, many of the services can be replicated elsewhere using open source technologies, such as Kubernetes for container management. This reduces the risk of cloud lock-in.
If you are running Oracle database, it is natural to consider the Oracle Cloud as an option. Of course, the database is only one piece of the overall application environment to be moved to the cloud and typically not the piece that is leading the decision for that move. You’ll need to also evaluate the availability of application development tools, regions in which the cloud operates, along with pricing. In addition, if you are interested in reducing your dependence on Oracle as a vendor in your migration to the cloud, moving from on-premises Oracle to Oracle Cloud will only increase your commitment.
Next, for those workloads that are candidates to run in the cloud, you’ll need to determine how to get them there. Migrating a database application takes careful preparation to ensure it runs as expected. This, too, is an opportunity to re-evaluate the database choice for your application because technologies in the cloud do not operate in exactly the same way as on-premises.
For example, Oracle’s database technology was built to run best on bare metal. It is very well tuned for scale-up scenarios, especially on large servers. In addition, Oracle’s RAC architecture is geared toward optimizing 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. Yet, many organizations are reluctant to become further entangled with Oracle in their move to the cloud. In fact, cloud migration projects are a great opportunity to explore alternative database approaches, like Postgres.
There has been rapid growth of interest in the PostgreSQL database management system as a popular alternative for cloud workloads. It has gained more popularity in the DB-Engines.com ranking within the last year than any of the other 341 systems it monitors. This led DB-Engines to name Postgres the DBMS of the Year for 2017.
One reason Postgres is so popular is that there is more than one way to deploy Postgres in the cloud. With the EDB Managed DBaaS Service, you can extend Postgres in the public cloud with Oracle-compatible functionality with the same ease of deployment and elasticity as with AWS, but without the possible trade-offs in performance tuning, configurability, customization, and control. If you’d like to learn more, take a look at our paper on Moving Oracle Workloads to the Cloud.
Our next post will continue this discussion with a review of tools to help with database migrations to the cloud.
Ken Rugg is EDB's Chief Product and Strategy Officer and is charged with leading the company's product and strategic vision. Prior to joining EDB, Ken was the founder and CEO of Tesora. The Tesora DBaaS Platform, based on OpenStack Trove, let enterprises provide self-service database provisioning and full lifecycle management to their developers across 16 different databases, including Postgres, MySQL, Oracle, MongoDB, Cassandra and others.
Before founding Tesora, Ken served as Senior Vice President and General Manager for Enterprise Business Solutions (EBS) of Progress Software which was comprised of a number of enterprise infrastructure product lines. The EBS business unit included the Actional, Apama, FUSE, Savvion, and Sonic products. Ken joined Progress Software when it acquired Object Design/eXcelon Inc. where he served as Vice President, Product Development and Chief Technology Officer.