Switching to the cloud is very much in vogue. According to an IDC survey Spotlight, Experience in migrating databases to the cloud, 63% of organizations 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 customers may unknowingly face when moving their database to a Database as a Service (DBaaS) in the cloud, especially when DBaaS uses open source database software like Apache Cassandra, MariaDB, MySQL, Postgres or uses Redis . At EDB, we classify these risks into five categories: support, service, technology stagnation, cost, and retention. Moving to the cloud without proper due diligence and risk mitigation can result in significant cost overruns, project delays and, more importantly, organizations not realizing the expected business benefits from cloud migration.
Since EDB focuses on the Postgres database, I’ll draw the specifics 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 need support, whether they’re running in the cloud or on-premises. Enterprise-level support for software must cover two aspects: expert advice on how to use the product correctly, especially in difficult circumstances, and rapid resolution of errors and defects that affect production or the transition to production.
For commercial software, a minimum level of support is bundled 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 investing enough in the open source community to debug and provide support.
Customers can evaluate 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 participating in the project. For Postgres, for example, these are the release notes 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 providers that are not actively involved in the development and troubleshooting process cannot provide both aspects of support—advice and quick response to issues—which poses a significant risk to 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 vendors that do not offer consulting and expert services to facilitate this step introduce risk into the process. Such providers ask 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 achieve a seamless deployment with the performance and availability levels they need, they get caught in the middle and have to coordinate and mitigate issues between vendors.
Customers can mitigate this risk by ensuring they clearly understand who is responsible for the overall success of their deployment and that that entity actually has the ability to successfully complete the entire project.
Risk of technological stagnation. The shared responsibility model is a key component of a DBaaS. As the user performs schema definition and query optimization, the cloud database provider applies minor version updates and major version upgrades. Not all vendors commit to a timely upgrade — and some can delay significantly. At the time of writing, one of the major Postgres DBaaS providers is almost three years behind the open source community in delivering Postgres versions. While DBaaS providers can selectively backport security fixes, delayed application of new releases can put customers in a situation where they miss out on new database features, sometimes for years. Customers must review a vendor’s historical track record of applying upgrades to assess this risk.
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 to fix license restrictions. Fork versions can differ significantly from the more well-known parent version or fall 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 must be careful when adopting cloud-specific versions or forks of open-source software. Features may vary 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 have not seen any significant direct price increases. However, there is a growing realization that the nature of cloud services can pose a significant cost risk, particularly in the case of self-service and rapid elasticity combined with an opaque cost model. In on-premises environments, database administrators (DBAs) and developers must tune code to achieve performance with the available hardware. In the cloud, it can make much more sense to ask the cloud provider to increase provisioned input/output operations per second (IOPS), compute power, or memory to optimize performance. Since each increase drives up costs, such a short-term fix is likely to have long-lasting negative impacts on costs.
Users mitigate cost risk in two ways: (1) closely monitor increases in IOPS, CPU, and memory to ensure they are offset against application optimization costs; (2) Review DBaaS providers’ cost models to identify and avoid providers with complex and unpredictable cost models.
lock-in risk. In a number of ways, cloud database services can create a “hotel California” effect where data can’t just leave the cloud again. While The cost of data egress is often mentioned, general data gravity, and integration with other cloud-specific data management and analysis tools are more powerful. data gravity is a complex concept that generally asserts 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 reduces the likelihood that the data will be available without significant impact on the Business moved to another location.
Cloud-specific tools are also a useful driver for lock-in. All cloud platforms offer convenient and proprietary data management and analysis tools. While they help derive 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 they only use DBaaS solutions that support efficient data replication to other clouds.
plan risks. Moving databases to the cloud is undoubtedly a goal for many companies, but it’s not without risk. Organizations need to fully investigate and understand potential cloud database vendor vulnerabilities in the areas of support, services, technology stagnation, cost, and lock-in. While these risks are not a reason to shy 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 created by EDB. It was not written by the editors of MIT Technology Review.
