Five risks of migrating databases to the cloud

Migration to the cloud is all the rage. According to an IDC survey focus, Experience migrating databases to the cloud63% of enterprises are actively migrating their databases to the cloud, and another 29% are considering doing so within the next three years.

This article discusses some of the risks that customers may inadvertently encounter when migrating databases to Database as a Service (DBaaS) in the cloud, especially when DBaaS leverages open source database software such as Apache Cassandra, MariaDB, MySQL, Postgres or Redis . At EDB, we categorize these risks into five categories: support, service, technology stagnation, cost, and lock-in. Migrating to the cloud without adequate diligence and risk mitigation can result in significant cost overruns and project delays, and more importantly, can mean that the business is not able to reap the expected business benefits from cloud migration.

Because EDB focuses on Postgres databases, I’ll draw specifics from our experience with Postgres services, but the conclusions are equally valid for other open source database services.

Support risk. Customers running software for production applications need support, whether they are running in the cloud or on-premises. Support for enterprise-grade software must cover two areas: expert advice on how to use the product properly, especially in challenging environments, and the rapid resolution of bugs and defects that impact or move to production.

For commercial software, the license is bundled with a minimum level of support. Open source databases do not come with a license. This opens the door for cloud database providers to create and operate database services without having to invest enough in the open source community to fix bugs and provide support.

Customers can evaluate a cloud database provider’s ability to support their cloud migration by reviewing open source software release notes and identifying team members who are actively involved in the project.For example, for Postgres, the release notes are free, and they named everyone who contributed new features or bug fixes. Other open source communities follow a similar approach.

Open source cloud database providers that are not actively involved in the development and bug-fixing process are unable to provide both support—advice and rapid response to issues—which creates significant risks for cloud migrations.

Service Risk. Databases are complex software products. Many users require expert advice and practical help to properly configure their databases for optimal performance and high availability, especially when migrating from the familiar on-premises deployments to the cloud. Cloud database providers that do not offer consulting and expert professional services to facilitate this initiative introduce risk into the process. Such providers hold customers to assume general contractor responsibilities and coordinate between DBaaS providers and potential professional service providers. Rather than being able to consult a single entity to help them achieve a seamless deployment with the desired level of performance and availability, they are caught in the middle and have to coordinate and mitigate issues between vendors.

Clients can mitigate this risk by ensuring they have a clear understanding of who is responsible for the overall success of their deployment and that this entity is indeed able to successfully execute the entire project.

Risk of technological stagnation. A shared responsibility model is a key component of DBaaS. While the user handles schema definition and query tuning, the cloud database provider applies minor version updates and major version upgrades. Not all vendors are committed to timely upgrades – some may lag significantly. As of this writing, one of the major Postgres DBaaS providers is nearly three years behind the open source community in deploying Postgres releases. While DBaaS providers can selectively backport security fixes, delays in applying new versions can put customers in the position of missing out on new database capabilities, sometimes for years. Customers need to review the vendor’s application upgrade history to assess this risk.

Similar risks are introduced when proprietary cloud database providers try to create their own forks or versions of well-known open source software. Sometimes this is done to optimize software for cloud environments or to work around license constraints. Forked versions may deviate significantly from the more well-known parent version, or lag behind the open source version. Notable examples of such forked or proprietary versions are Aurora Postgres (a Postgres derivative), Amazon DocumentDB (compatible with MongoDB), and Amazon OpenSearch Service (originally derived from Elasticsearch).

Users need to be careful when adopting cloud-specific versions or forks of open source software. Features may deviate over time, and cloud database providers may or may not adopt new features from open source versions.

cost risk. The leading cloud database services have not experienced meaningful direct price increases. However, there is a growing recognition that the nature of cloud services presents significant cost risks, especially when self-service and rapid elasticity are combined with opaque cost models. In a local environment, database administrators (DBAs) and developers must optimize code to take advantage of the available hardware for performance. In the cloud, it may be more convenient to ask the cloud provider to increase the provisioned input/output operations per second (IOPS), compute or memory to optimize performance. Such short-term fixes can have long-term negative cost implications as each instance increases drive up costs.

Users mitigate cost risk in two ways: (1) closely monitor increases in IOPS, CPU, and memory to ensure they are balanced against application-optimized costs; (2) review DBaaS provider cost models to identify and avoid costs Suppliers with complex and unpredictable models.

lock-in risk. Cloud database services can create a “Hotel California” effect in a number of ways, where data cannot easily leave the cloud again.although Data export costs are often mentionedUniversal Data Gravity, and integration with other cloud-specific data management and analysis tools are more impactful. data gravity is a complex concept, at a high level it claims that once a business data set on a cloud platform is available, more applications may be deployed using the data on that platform, which in turn reduces data being moved elsewhere , but had no significant business impact.

Cloud-specific tools are also a meaningful driver of lock-in. All cloud platforms offer convenient proprietary data management and analysis tools. While they help capture business value quickly, they also create lock-in.

Users can mitigate cloud lock-in by carefully avoiding proprietary cloud tools and ensuring they only use DBaaS solutions that support efficient data replication to other clouds.

Risk planning. Migrating databases to the cloud is certainly a goal for many organizations, but doing so is not without risk. Enterprises need to fully investigate and understand the potential weaknesses of cloud database providers in terms of support, service, technology stagnation, cost and lock-in. While these risks are not reasons to avoid the cloud, it is important to address them up front and understand and mitigate them as part of a carefully considered cloud migration strategy.

This content is produced by the Education Bureau. It was not written by the editorial staff of MIT Technology Review.