Moving to the cloud is all the rage. According to an IDC Spotlight survey, Experience in migrating databases to the cloud63% of companies are actively migrating their databases to the cloud, and 29% plan to do so within the next three years.
This article discusses some of the risks that customers may unintentionally encounter when moving their database to a database as a service (DBaaS) in the cloud, particularly when the DBaaS leverages open source database software. source such as Apache Cassandra, MariaDB, MySQL, Postgres or Redis. . At EDB, we categorize these risks into five categories: support, service, technology stagnation, cost, and blockage. Moving to the cloud without sufficient due diligence and risk mitigation can lead to significant cost overruns and project delays and, more importantly, can mean companies are not realizing the expected business benefits of migrating to the cloud.
Since EDB is focused on the Postgres database, I’ll draw the details from our experiences with Postgres services, but the conclusions are valid for other open source database services as well.
Risk assumption. Customers running software for production applications need support whether they’re running in the cloud or on-premises. Enterprise software support should cover two aspects: expert advice on how to use the product correctly, especially in difficult circumstances, and prompt resolution of bugs and defects that impact production or transition to production.
For commercial software, a minimum level of 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 operate a database service without investing enough in the open source community to fix bugs and provide support.
Customers can gauge a cloud database vendor’s ability to support their cloud migration by reviewing the open source software release notes and identifying team members who are actively involved in the project. For example, for Postgres the release notes are available for free, and they name everyone who 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 cannot provide both aspects of support (advice and rapid issue response), which poses a risk important for cloud migration.
Service Risk. Databases are complex software products. Many users need expert guidance 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 vendors that do not offer professional advisory and expert services to facilitate this transition introduce risk into the process. These providers require the customer to assume the responsibilities of a general contractor and coordinate between the DBaaS provider and potential professional service providers. Instead of a single entity that they can consult to help them achieve a seamless deployment with the required levels of performance and availability, they find themselves caught in the middle, having to coordinate and mitigate issues between vendors.
Customers can reduce this risk by ensuring that they clearly understand who is responsible for the overall success of their deployment, and that this entity is in fact able to execute the entire project successfully.
Risk of technological stagnation. The shared responsibility model is a key element of a DBaaS. While the user manages schema definition and query tuning, the cloud database provider applies minor version updates and major version upgrades. Not all vendors are committed to performing the upgrade in a timely manner, and some may experience significant delays. As of this writing, one of the major Postgres DBaaS vendors is almost three years behind the open source community in its deployment of Postgres releases. While DBaaS vendors can selectively backport security patches, delayed application of new releases can put customers in a situation where they miss new database features, sometimes for years. Customers should inspect a vendor’s track record of applying upgrades to assess this exposure.
A similar risk is introduced when a proprietary cloud database vendor 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 to meet licensing restrictions. Forked versions may deviate significantly from the better known parent version 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 to achieve performance with available hardware. In the cloud, it can be much faster to ask the cloud provider to increase provisioned input/output operations per second (IOPS), compute, or memory to optimize performance. Since each instance of increase increases costs, such a short-term solution is likely to have long-term negative impacts on costs.
Users mitigate cost risk in two ways: (1) closely monitoring increases in IOPS, CPU, and memory to ensure they are balanced against the cost of optimizing applications; (2) careful review of DBaaS vendor cost models to identify and avoid vendors with complex and unpredictable cost models.
Risk of blockage. Cloud database services can create a “Hotel California” effect, where data can no longer easily leave the cloud, in several ways. While the cost of data output is often mentionedgeneral data gravity and integration with other cloud-specific tools for data management and analysis have more impact. Data Gravity is a complex concept that, at a high level, claims that once a set of enterprise data is available on a cloud platform, more applications will likely be deployed using the data on that platform -shape, making it less likely that data could be moved elsewhere without significant business impact.
Cloud-specific tools are also a significant lock-in factor. All cloud platforms provide convenient and exclusive data management and analysis tools. While they help generate business value quickly, they also create lock-in.
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 others clouds.
Risk planning. Moving databases to the cloud is undoubtedly a target for many organizations, but it is not without risk. Companies should investigate and fully understand the potential weaknesses of cloud database vendors in the areas of support, services, technology stagnation, cost, and lock-in. While these risks aren’t a reason to avoid the cloud, it’s important to address them up front, understand them, and mitigate them as part of a carefully thought-out cloud migration strategy.
This content was produced by EDB. It was not authored by the editorial staff of MIT Technology Review.