Happy Nice Mall

Moving to the cloud is all the rage. According to IDC Survey Spotlight, Experience with Migrating Databases to the Cloud, 63% of businesses are actively migrating their databases to the cloud, and another 29% are considering doing so in the next three years.

This article discusses some of the risks that customers may unwittingly face when migrating their databases to database as a service (DBaaS) in the cloud, particularly when leveraging open source database software such as DBaaS, Apache Cassandra, MariaDB, MySQL, Postgres, or Redis. . At EDB, we categorize these risks into five categories: support, service, technology recession, cost, and deadlock. Migrating to the cloud without adequate care and risk mitigation can result in significant cost overruns and project delays and, more importantly, mean that organizations are not reaping the expected business benefits from cloud migration.

Since EDB focuses on the Postgres database, I’ll extract details from our experience with Postgres services, but the conclusions apply equally to other open source database services.

Support risk. Customers running software for production applications, whether running in the cloud or on-premises, need support. Enterprise-level software support should cover two aspects: expert advice on how to use the product correctly in particularly demanding conditions, and prompt handling of errors and defects that affect production or the transition to production.

For commercial software, minimal support is provided with the license. Open source databases do not come with a license. This opens the door for a cloud database provider to build and run a database service without adequate investment in the open source community to troubleshoot bugs and provide support.

Customers can evaluate a cloud database provider’s ability to support cloud migration by checking open source software release notes and identifying team members actively involved in the project. For example, the release notes for Postgres freely, and give the name of each individual who contributed new features or bug fixes. Other open source communities are following similar practices.

Open source cloud database providers that are not actively involved in development and bug fixes cannot provide both aspects of support (quick response to suggestions and issues), posing a significant risk to cloud migration.

Service Risk. Databases are complex software products. Many users need expert advice and hands-on help to configure their databases correctly to achieve optimum performance and high availability, especially when moving from familiar on-premises deployments to the cloud. Cloud database providers that fail to provide consulting and expert professional services to facilitate this movement introduce risk into the process. Such providers require the client to assume the responsibilities of a general contractor and coordinate between the DBaaS provider and potential professional service providers. They stay in the middle, having to coordinate and mitigate issues between vendors, rather than a single entity they can consult to help them achieve a smooth deployment with the required levels of performance and availability.

Customers can mitigate this risk by making sure they clearly understand who is responsible for the overall success of their deployment and that this entity is indeed in a position to run the entire project successfully.

Risk of technology stagnation. The shared responsibility model is an important component of a DBaaS. The cloud database provider applies minor version updates and major version upgrades while the user performs the schema definition and query setting. Not all providers are committed to timely upgrades, and some may be delayed significantly. At the time of this writing, one of the leading Postgres DBaaS providers has outstripped the open source community by almost three years in distribution of Postgres releases. While DBaaS providers may selectively support security fixes, delayed implementation of new versions can put customers in a situation where they miss out on new database features, sometimes for years. Customers should review a provider’s track record of implementing upgrades to assess this risk.

A similar risk arises when a proprietary cloud database provider tries to create its own fork or well-known open source software version. Sometimes this is done to optimize the software for the cloud environment or to remove license restrictions. Forked versions may deviate significantly from the more well-known major version or lag behind the open source version. Well-known examples of such forks or proprietary versions are Aurora Postgres (a Postgres derivative), Amazon DocumentDB (with MongoDB compatibility), and Amazon OpenSearch Service (originally derived from Elasticsearch).

Users need to be careful when adopting cloud-native versions or open source software forks. Capabilities may change over time and the cloud database provider may or may not adopt the new features of the open source version.

Cost risk. Leading cloud database services did not experience significant direct price increases. However, there is a growing understanding that the nature of cloud services can pose significant cost risks, particularly in the case of self-service and rapid flexibility combined with an opaque cost model. In on-premises environments, database administrators (DBAs) and developers must optimize code to achieve performance with existing hardware. In the cloud, it may be much more convenient to ask the cloud provider to increase the input/output operations per second (IOPS), computation, or memory to optimize performance. Such a short-term adjustment is likely to have long-term adverse cost effects, as each instance of increase increases cost.

Users reduce cost risk in two ways: (1) close monitoring of IOPS, CPU and memory boosts to ensure they are balanced against the cost of application optimization; (2) examining the cost patterns of DBaaS providers to identify and avoid vendors with complex and unpredictable cost patterns.

Risk of deadlock. Cloud database services can create a “Hotel California” effect where data cannot easily exit the cloud again. During data output cost is often mentioned, overall data weighting, and integration with other cloud-specific tools for data management and analysis is more effective. Data weight At a high level, it is a complex concept that claims that when a business dataset is available on a cloud platform, more applications will be deployed using the data from that platform, thus making the data less likely. relocated to another location without significant business impact.

Cloud-specific tools are also a meaningful driver for deadlock. All cloud platforms provide convenient and proprietary data management and analysis tools. While they help to achieve business value quickly, they also create deadlock.

Users can mitigate the cloud lockdown effect by carefully avoiding the use of private cloud tools and making sure to only use DBaaS solutions that support efficient data replication to other clouds.

Planning for risk. Moving databases to the cloud is undoubtedly a goal for many organizations, but doing so is not without risk. Businesses should fully explore and understand the potential weaknesses of cloud database providers in the areas of support, services, technological recession, cost, and deadlock. While these risks are not a reason to move away from the cloud, it is important to address them upfront and understand and mitigate them as part of a carefully considered cloud migration strategy.

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