Five risks of moving your database to the cloud

Moving to the cloud is in fashion. According to a leading IDC survey, Experience in Database Migration to the Cloud, 63% of companies 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 moving their database to a cloud database as a service (DBaaS), especially when DBaaS leverages open source database software like Apache Cassandra, MariaDB, MySQL, Postgres or Redis. . At EDB, we classify these risks into five categories: support, service, technology stagnation, cost, and dependency. Migrating to the cloud without sufficient due diligence and risk mitigation can lead to significant cost overruns and project delays and, more importantly, can mean that companies do not realize the expected business benefits of migrating to the cloud.

Because EDB focuses on the Postgres database, I’ll distill the details of our experiences 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 run in the cloud or on premises. Support for enterprise-grade software must cover two aspects: expert advice on how to use the product correctly, especially in difficult circumstances, and quickly addressing bugs and defects that affect production or the move to production.

For commercial software, a minimum level of support is included with the license. Open source databases do not come with a license. This opens the door for a cloud database provider to build and operate a database service without investing enough in the open source community to fix bugs and provide support.

Customers can assess a cloud database vendor’s ability to support their cloud migration by reviewing open source software release notes and identifying team members actively involved in the project. For example, for Postgres, the release notes are available for free, and name each person who has contributed new features or bug fixes. Other open source communities follow similar practices.

Open source cloud database vendors that are not actively involved in the development and bug-fixing process are unable to provide both aspects of support (advice and rapid response to issues), which presents a significant risk to the cloud migration.

Service risk. Databases are complex software products. Many users need expert advice and hands-on assistance to properly configure databases for optimal performance and high availability, especially when moving from familiar on-premises deployments to the cloud. Cloud database providers that do not offer professional consulting and expert services to facilitate this move introduce risk into the process. Such providers ask the customer to assume the responsibilities of a general contractor and to coordinate between the DBaaS provider and potential professional service providers. Instead of a single entity they can turn to to help them achieve a seamless implementation with the required levels of performance and availability, they get caught in the middle, having to coordinate and mitigate issues across vendors.

Clients can reduce this risk by ensuring that they clearly understand who is responsible for the overall success of their implementation and that this entity is in a position to execute the entire project successfully.

Risk of technological stagnation. The shared responsibility model is a key component of a DBaaS. While the user handles the schema definition and query tuning, the cloud database provider applies minor version updates and major version updates. Not all providers are committed to updating in a timely manner, and some may be significantly delayed. At the time of this writing, one of the major Postgres DBaaS vendors lags behind the open source community by almost three years in its implementation of Postgres versions. While DBaaS vendors may selectively support security fixes, a delayed implementation of new releases can put customers in a situation where new database capabilities are lost, sometimes for years. Customers should inspect a vendor’s update application tracking history to assess this exposure.

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

Users should be careful when adopting cloud-specific versions or forks of open source software. Capabilities may vary over time, and the cloud database provider may or may not adopt the new capabilities of the open source version.

cost risk. Major cloud database services have not seen significant direct price increases. However, there is a growing understanding that the nature of cloud services can lead to significant cost risk, especially in the case of self-service and rapid elasticity combined with a non-transparent cost model. In on-premises environments, database administrators (DBAs) and developers must optimize code for performance on available hardware. In the cloud, it may be much more convenient to ask the cloud provider to increase provisioned input/output operations per second (IOPS), compute, or memory to optimize performance. As each instance of escalation increases cost, a short-term fix is ‚Äč‚Äčlikely to have negative long-term cost impacts.

Users mitigate cost risk in two ways: (1) closely monitor IOPS, CPU, and memory increases to ensure they are balanced against the cost of application optimization; (2) scrutiny of DBaaS vendor cost models to identify and avoid vendors with complex and unpredictable cost models.

Blocking risk. Cloud database services can create a “Hotel California” effect, where data cannot easily move back out of the cloud, in a number of ways. While data output cost is often mentioned, the overall gravity of the data and the integration with other cloud-specific tools for data management and analysis are more impactful. data severity is a complex concept that, at a high level, implies that once a set of business data is available on a cloud platform, more applications are likely to be implemented using the data on that platform, which in turn makes make it less likely that data can be moved elsewhere without significant business impact.

Cloud-specific tools are also a significant factor for blocking. All cloud platforms provide convenient and proprietary data management and analysis tools. While they help quickly gain business value, they also create a block.

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

Planning for risk. Moving databases to the cloud is certainly a goal for many organizations, but doing so is not without risk. Companies should fully investigate and understand the potential weaknesses of cloud database providers in the areas of support, services, technology stagnation, cost, and lock-in. While these risks are not a reason to move away from 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 was produced by EDB. It was not written by the MIT Technology Review editorial team.

Leave a Reply

Your email address will not be published.