The transition to the cloud is in vogue. According to research by IDC Spotlight, Experience in migrating databases to the cloud63% of companies 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 users 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 such as Apache Cassandra, MariaDB, MySQL, Postgres or Redis. . At EDB, we classify these risks into five categories: support, service, technological stagnation, costs and locking. Switching to the cloud without sufficient attention and risk mitigation can lead to significant cost overruns and project delays, and more importantly, can mean that companies do not reap the expected business benefits of cloud migration.
Since EDB focuses on the Postgres database, I will draw specifics from our experience with Postgres services, but the conclusions apply to other open source database services as well.
Support risk. Customers who use software for production applications need support, whether they work in the cloud or locally. Enterprise-level software support must cover two aspects: expert advice on how to use the product properly, especially in challenging circumstances, and quickly resolving errors and deficiencies that affect production or transition to production.
For commercial software, the minimum level of support comes bundled with the license. Open source databases do not come with a license. This opens the door to the cloud database provider to create and manage a database service without investing enough in the open source community to address bugs and provide support.
Users can assess the ability of a cloud database provider to support their cloud migration by checking open source software release notes and identifying team members who are actively involved in the project. For example, for Postgres, release notes are available for free and they name each individual who has contributed to new features or bug fixes. Other open source communities follow a similar practice.
Open source cloud providers who are not actively involved in the development and debugging process cannot provide both aspects of support – advice and quick response to problems – which poses 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 switching from known local implementations to the cloud. Cloud database providers that do not offer consulting and expert professional services put risk into the process to facilitate this move. Such providers require users to assume the responsibilities of the general contractor and to coordinate between DBaaS providers and potential professional service providers. Instead of one entity that they can consult to help them achieve a flawless implementation with the required performance and availability levels, they are caught in the middle, they have to coordinate and mitigate problems between suppliers.
Beneficiaries can reduce this risk by making sure that they clearly understand who is responsible for the overall success of their implementation and that this entity is indeed in a position to successfully carry out the whole project.
Risk of technology stagnation. The shared responsibility model is a key component of DBaaS. While the user manages the schema definition and query setup, the cloud database vendor applies smaller version updates and larger version upgrades. Not all providers are committed to timely upgrades – and some may lag significantly behind. At the time of writing, one of the major Postgres DBaaS providers is lagging behind the open source community by almost three years in implementing Postgres versions. While DBaaS providers can selectively backport security fixes, delayed implementation of new releases can put customers in a situation where they miss out on new database features, sometimes for years. Users should review the provider’s historical record of upgrade applications 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 resolve license restrictions. Forked versions can deviate 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 need to be careful when adopting cloud-specific versions of open source software. Capabilities may deviate over time, and the cloud database provider may or may not adopt new open source versions.
Cost risk. Leading cloud database services have not experienced 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 resilience combined with a non-transparent cost model. In local environments, database administrators (DBAs) and developers must optimize code to achieve performance with available hardware. In the cloud, it may be much more appropriate to ask your cloud vendor to increase I / O enabled per second (IOPS), computing, or memory to optimize performance. As each case of increase increases costs, such a short-term repair is likely to have long-term negative consequences on costs.
Users reduce cost risk in two ways: (1) closely monitor IOPS, CPU, and memory increases to ensure they are in balance with application optimization costs; (2) testing DBaaS provider cost models to identify and avoid suppliers with complex and unpredictable cost models.
Risk of locking. Cloud database services can create a “Hotel California” effect, where data cannot easily leave the cloud again, in several ways. Although the cost of data output is often mentioned, general data gravity and integration with other cloud-specific tools for data management and analysis have a greater impact. Data gravity is a complex concept that, at a high level, implies that when a set of business data is available on a cloud platform, more applications are likely to be deployed using data on that platform, which in turn makes it less likely that data can be moved without significant business impact.
Cloud-specific tools are also a significant driver for locking. All cloud platforms provide handy and proprietary tools for data management and analysis. While they help to quickly extract business value, they also create a lock.
Users can mitigate the effect of cloud locking by carefully avoiding the use of proprietary tools in the cloud and ensuring that they use only DBaaS solutions that support efficient replication of data to other clouds.
Risk planning. Moving databases to the cloud is undoubtedly a goal of many organizations, but it is not without risk. Businesses need to fully explore and understand the potential weaknesses of cloud database vendors in the areas of support, services, technology stagnation, cost, and locking. While these risks are not a reason to avoid the cloud, it is important to address them in advance, and to 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 board of the MIT Technology Review.