Moving to the cloud is all the rage. According to an IDC Survey Spotlight, Experience with migrating databases to the cloud, 63% of enterprises are actively migrating their databases to the cloud, with an additional 29% 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 database as a service (DBaaS) in the cloud, especially when the DBaaS uses open source database software such as Apache Cassandra, MariaDB, MySQL, Postgres or redis . At EDB, we classify these risks into five categories: support, service, technology stagnation, cost and lock-in. Moving to the cloud without due diligence and risk mitigation can lead to significant cost overruns and project delays, and more importantly, could mean that enterprises do not reap the expected business benefits from cloud migration.
Since EDB focuses on the Postgres database, I’ll draw the details from our experiences with Postgres services, but the conclusions are equally valid for other open source database services.
Support risk. Customers using software for production applications need support whether they are running in the cloud or on premise. Enterprise-level software support should include two aspects: expert advice on how to properly use the product, especially in challenging conditions, and the rapid resolution of bugs and defects that affect production or transition 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 create and operate a database service without investing enough in the open source community to address 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 participating in the project. For example, for Postgres, the release notes are available for free, and they name every person who contributed new features or bug fixes. Other open source communities follow similar practices.
Open source cloud database providers who aren’t actively involved in the development and bug-fixing process are unable to provide both aspects of support — advice and rapid response to issues — posing a significant risk to cloud migration.
Service risk. Databases are complex software products. Many users need expert advice and practical help to properly configure databases to achieve optimal performance and high availability, especially when moving from trusted on-premises deployments to the cloud. Cloud database providers who fail to offer consulting and expert professional services to facilitate this step bring risks into the process. Such providers ask the client to assume the responsibilities of a general contractor and coordinate between the DBaaS provider and potential professional services 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 and need to coordinate and resolve issues between suppliers.
Customers can mitigate this risk by ensuring they clearly understand who is responsible for the overall success of their implementation, and that this entity is indeed capable of successfully completing the entire project.
Risk of technological stagnation. The shared responsibility model is an important part of a DBaaS. While the user handles schema definition and query tuning, the cloud database provider applies minor version updates and major version upgrades. Not all carriers are committed to upgrading in a timely manner — and some may lag significantly. At the time of writing, one of the major Postgres DBaaS providers is nearly three years behind the open source community in deploying Postgres versions. While DBaaS providers can selectively backport security solutions, delayed adoption of new releases can put customers in a situation of missing out on new database capabilities, sometimes for years. Customers should inspect a provider’s historical track record of applying upgrades to assess this exposure.
A similar risk is introduced 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 to address licensing restrictions. Forked versions may differ significantly from the better known parent or lag 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. Leading cloud database services have not experienced significant direct price increases. However, there is a growing awareness that the nature of cloud services can create significant cost risk, especially in the case of self-service and rapid elasticity coupled with an opaque cost model. In on-premises environments, database administrators (DBAs) and developers must optimize code to achieve performance with the 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 power, or memory to optimize performance. Since any increase in costs drives up costs, such a solution is likely to have long-term negative cost implications in the short term.
Users mitigate cost risk in two ways: (1) closely monitor the increase in IOPS, CPU, and memory to ensure they are balanced against the cost of application optimization; (2) examining the cost models of DBaaS providers to identify and avoid vendors with complex and unpredictable cost models.
Lock-in risk. Cloud database services can create a “Hotel California” effect in several ways, where data cannot easily leave the cloud again. While the cost of outbound data traffic is often mentioned, the overall data gravity and integration with other cloud-specific data management and analysis tools are more impactful. Data gravity is a complex concept that claims, at a high level, that once a business dataset is available on a cloud platform, more applications are likely to be deployed using the data on that platform, which in turn makes it less likely that the data can be moved without significant business impact.
Cloud-specific tools are also a useful driver for lock-in. All cloud platforms provide convenient and proprietary tools for data management and analysis. While they help to quickly create business value, they also create a lock-in.
Users can reduce 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.
Plan for risk. Moving databases to the cloud is undoubtedly a target for many organizations, but it is not without risk. Businesses should fully investigate and understand potential cloud database provider weaknesses in support, services, technology stagnation, cost, and lock-in. While these risks are not a reason to avoid the cloud, it is important to address them in advance, understand and mitigate them as part of an informed cloud migration strategy.
This content is produced by EDB. It was not written by the editors of MIT Technology Review.