So, you’ve decided to pursue a Database-as-a-Service in the cloud strategy using an open source database—that’s awesome! A DBaaS approach offers enterprises a way to power innovation without having to deal with managing the infrastructure, monitoring, backup/recovery, security, availability and many other technical tasks that can be outsourced to a public cloud service provider like Amazon AWS or Microsoft Azure.
As with any choice, there are upsides and downsides to this decision, which enterprises look at in terms of risk. Every CIO, CTO and CEO wants to be able to manage risk and keep it at an acceptable level for their business—it’s unlikely anything is ever risk-free. And open source DBaaS is no exception.
You can classify risk into these categories:
- Support risk
- Service risk
- Technology stagnation risks
- Cost risk
- Lock-in risk
Moving to the cloud without sufficient diligence, risk awareness and risk mitigation can lead to cost overruns and project delays, and more importantly, may mean that you do not get the expected business benefits from your cloud migration.
The following areas are opportunities to better manage risk during your journey to the cloud.
Support
Enterprises running software for production applications need support, whether they run in the cloud or on-premises. Support for enterprise software must include expert advice on how to use the product correctly and quickly addressing bugs and defects that impact production.
For commercial software, some support is commonly bundled with the license. Due to the permissive nature of many open source licenses, cloud database providers may avoid investing in the open source community to address bugs and provide support for open source databases when creating and operating a DBaaS.
Enterprises can evaluate a cloud database provider’s ability to support their cloud migration by checking the open source software release notes and identifying their team members who actively participate in the project. For example, for PostgreSQL, the release notes are freely available, and they name every individual who has contributed new features or bug fixes. Other open source communities follow similar practices.
Look to select an open source database provider who is intimately familiar with and involved in open source Postgres development and bug fixing processes. Open source cloud database providers that are not actively involved in these areas cannot provide both aspects of support—advice and rapid response to problems—which presents a significant risk to cloud migration.
Service
Because databases are complex software products, customers need expert advice and hands-on assistance to configure databases correctly to achieve optimal performance and high availability, especially when moving from familiar on-premises deployments to the cloud. Cloud database providers that do not offer consultative and expert professional services to facilitate this move introduce risk into the process. Instead, these cloud providers might ask the customer to act like a general contractor and to coordinate between the DBaaS provider and third party professional services teams. Instead of a single vendor who customers can consult to help achieve a seamless deployment with the required performance and availability levels, customers get caught in the middle, having to coordinate and mitigate issues between cloud and consulting vendors.
Customers can reduce this risk by making sure they clearly understand who is responsible for the overall success of their deployment, and that this entity is indeed in a position to execute the entire project successfully. EDB’s DBA Services have been very successful at helping customers with an integrated end-to-end solution with very high availability.
Technology stagnation
The shared responsibility model is a key component of a DBaaS. While the customer handles schema definition and query tuning, the cloud database provider applies minor version updates and major version upgrades. Not all providers are committed to upgrading in a timely manner—and some can lag behind significantly. (As of mid-2022, one of the major Postgres DBaaS providers lagged behind the open source community by almost three years in their deployment of Postgres versions.) While DBaaS providers can selectively backport security fixes, a delayed application of new releases can put customers in a situation where they miss out on new database capabilities, sometimes for years. Customers need to 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 tries 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 license restrictions. Forked versions can deviate significantly from the better-known parent 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).
Enterprises need to be careful when adopting cloud-specific versions or forks of open source software. Capabilities can deviate over time, and the cloud database provider may or may not adopt the new capabilities of the open source version.
Cost
While leading cloud database services have not experienced meaningful direct price increases, 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 elasticity combined with opaque cost models. In on-premises environments, database administrators (DBAs) and developers must optimize code to achieve performance with the available hardware. In the cloud, it can be much more expedient to ask the cloud provider to increase provisioned input/output operations per second (IOPS), compute, or memory to optimize performance. Such a short-term fix is likely to have a long-lasting cost impact as each increase adds cost.
Enterprises mitigate the cost risk in two ways:
- close supervision of the increases of IOPS, CPU and memory to make sure they are balanced against the cost of application optimization
- scrutiny of the cost models of DBaaS providers to identify and avoid vendors with complex and unpredictable cost models.
Lock-in
Cloud database services can create a lock-in effect, where data cannot easily leave the cloud again, in several ways. While data egress cost is often mentioned, general “data gravity” and the integration with other cloud-specific tools for data management and analysis are more impactful. Data gravity is the concept that, at a high level, purports that once a business data set is available on a cloud platform, more applications likely will be deployed using the data on that platform. This in turn makes it less likely that the data can be moved elsewhere 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 derive business value quickly, they also create lock-in.
Enterprises can mitigate the cloud lock-in effect by carefully avoiding the use of proprietary cloud tools and by making sure they only use DBaaS solutions that support efficient data replication to other clouds.
Planning to mitigate risk
Moving databases to the cloud is undoubtedly a target for many organizations, but doing so is not risk-free. Businesses need to fully investigate and understand potential weaknesses of cloud database providers in the areas of support, services, technology stagnation, cost and lock-in. While these risks are not a reason to avoid the cloud, it’s important to address them up front, and to understand and mitigate them as part of a carefully considered cloud migration strategy.
EDB BigAnimal is designed specifically to address these risks. BigAnimal is supported by the leading contributor to the Postgres project. EDB has a strong Postgres services team and is committed to deploying the latest Postgres versions using a highly transparent cost model.