Moving to the cloud is all the rage. According to an IDC study Spotlight, Experience with migrating databases to the cloud63% of companies are actively migrating their databases to the cloud, and a further 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 database as a service (DBaaS) in the cloud, especially when DBaaS utilizes 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, costs and lock-in. Moving to the cloud without adequate care and risk reduction can lead to significant cost overruns and project delays, and more importantly, it can mean that companies do not get the expected business benefits of cloud migration.
Because EDB focuses on the Postgres database, I will draw the details from our experience 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 are running in the cloud or on-site. Support for enterprise-level software should cover two aspects: expert advice on how to use the product properly, especially in challenging circumstances, and prompt handling of errors and defects affecting 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 create and operate a database service without investing enough in the open source community to fix bugs and provide support.
Customers can evaluate a cloud database provider’s ability to support their cloud migration by checking the open source software release notes and identifying team members who are actively participating in the project. For example, for Postgres, the release notes are freely available and they name each individual person who has contributed new features or bug fixes. Other open source communities follow similar practices.
Providers of open source cloud databases that are not actively involved in the development and bug fixing process cannot provide both aspects of support – advice and quick response to problems – which poses a significant risk of cloud migration.
Service risk. Databases are complex software products. Many users need expert advice and practical assistance to configure databases correctly to achieve optimal performance and high availability, especially when moving from well-known on-premises implementations to the cloud. Cloud database providers that do not offer consulting and expert services to facilitate this move introduce risk in the process. Such providers ask the customer to assume the responsibilities of a main contractor and coordinate between the DBaaS provider and potential professional service providers. Instead of a single device they can consult to help them achieve a seamless implementation with the required levels of performance and availability, they are 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 implementation and that this device is actually able to execute the entire project successfully.
Risk of technology stagnation. The shared responsibility model is a key component of a DBaaS. While the user handles schedule definition and query adjustment, the cloud database provider applies minor version updates and major version upgrades. Not all providers are required to upgrade in a timely manner – and some may lag significantly. At the time of writing, one of the major Postgres DBaaS providers is lagging behind the open source community with almost three years in their rollout of Postgres versions. While DBaaS providers can selectively back up security patches, delayed use of new releases can put customers in a situation where they miss out on new database features, sometimes for years. Customers must inspect a provider’s historical track record to apply upgrades to assess this exposure.
A similar risk is introduced when a proprietary cloud database provider attempts to create their 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 may differ significantly from the better known parent or fall behind in 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 should be careful when adopting cloud-specific versions or forks of open source software. The options may differ over time, and the cloud database provider may not use the new options in the open source version.
Cost risk. Leading cloud database services have not experienced meaningful direct price increases. However, there is a growing understanding that the nature of cloud services can drive significant cost risk, especially in the case of self-service and rapid resilience combined with an opaque cost model. In local environments, database administrators (DBAs) and developers need to optimize code to achieve performance with the available hardware. In the cloud, it may be much more appropriate to ask the cloud provider to increase provisioned input / output operations per second (IOPS), computer, or memory to optimize performance. As each case of increase increases the cost, such a short-term solution is likely to have long-term negative costs.
Users reduce cost risk in two ways: (1) close monitoring of the increases in IOPS, CPU, and memory to ensure they are balanced against the cost of application optimization; (2) reviewing 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, where data can not easily leave the cloud again, in several ways. While the cost of data output is often mentioned, overall data gravity and integration with other cloud-specific data management and analysis tools are more effective. Data gravity is a complex concept that claims at a high level that once a business dataset is available on a cloud platform, multiple applications are likely to be implemented using the data on that platform, which in turn makes the data less likely to be moved elsewhere. places without significant business impact.
Cloud-specific tools are also a meaningful driver for lock-in. All cloud platforms provide convenient and proprietary data management and analysis tools. While they help achieve 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 by ensuring that they only use DBaaS solutions that support efficient data replication for other clouds.
Planning for risk. Moving databases to the cloud is undoubtedly a goal for many organizations, but doing so is not risk-free. Businesses need to fully investigate and understand potential vulnerabilities of cloud database providers in the areas of support, services, technology stagnation, costs, and lock-ins. While these risks are not a reason to shy away from 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 is produced by EDB. It is not written by the editorial staff of MIT Technology Reviews.