Go back to Blog articles
For many organisations considering a move to Kubernetes, a key driver is to improve the operational story of their containerised workflows. These advantages are well known. However, this still leaves open the question of where business data sits within this new containerised world. For most businesses, the majority of this data is persisted in some form of database. Traditionally, running a database has been seen as a specialist art, requiring skilled persons who have mastered the esoteric configuration options for the database engine at hand and how to get the best performance out of it. This was fine when organisations had one or two central enterprise databases, but in a world of microservices, POC, and MVPs, companies soon found waiting for a database was massively limiting. And so, enter stage left, comes the Database-as-a-Service (DBaaS).
DBaaS has undoubtedly delivered benefits for many users. For developers, it delivers new database instances at the touch of a button. For businesses, it means they no longer need to maintain such an extensive collection of database administrators (DBAs) and other associated data-whisperers. And for Platform Engineers, it removes the need to keep up to date with new automation required by the latest flavor-of-the-month database engine. As a result, DBaaS has almost become the go-to way to create and manage databases within a cloud environment. However, there is a dark side to DBaaS that is starting to emerge. Increasingly companies are beginning to realise that, far from being a magic hammer, cloud DBaaS has some severe downsides.
This blog series will examine the pitfalls of cloud DBaaS in detail and challenge the long-held perception that hosting your databases is risky and complex. Next blog will explore how a combination of SUSE Rancher and Ondat allows organisations to create their own internal DBaaS solution that rivals any cloud equivalent for developer convenience. We will explore how this can be done without the need for any unique expertise over and above the Kubernetes knowledge users already have in-house. And in our final post, we will illustrate the simplicity of the combined SUSE Rancher Ondat solution by showing readers how to create their own PostgreSQL DBaaS running on SUSE Rancher and Ondat.
Why Cloud DBaaS is challenging?
When looking at the downsides to Public Cloud DBaaS, it is best to tackle the elephant in the room head-on - DBaaS is hideously expensive.
This is unsurprising. The cloud has always been touted as a way to reduce compute expenditure by using the ephemeral nature of the cloud; as long as your workload is elastic, you can reap the benefits of cheap, if short-lived, hardware. However, there is no more static, monolithic workload than Relational database management system (RDBMS). The average cloud database instance is in use 24/7, 365 days a year, especially where the instance is in production. And where developers are given the freedom to spin up new DB instances, they will jump at the chance in order to help them push out features faster. These resulting instances are either numerous, long-lived and often both.
This cost can snowball rapidly. It is all too common for CTOs to be confronted by a wild looking CFO, clutching a budget-busting bundle of cloud invoices, due to the rampant growth of DBaaS. Moreover, once companies start using a cloud DBaaS, walking it back can be tricky. Common mitigations options are either to use reserved instances, other up-front payments, or to restrict the creation of a database to DevOps engineers. However, both solutions are a step backward to the dark days of capacity management and sysadmin central control that the cloud claimed to have vanquished decades ago.
Putting the lock-in
In the following article, we will explore how, by running your own internal DBaaS using SUSE Rancher and Ondat, readers can dramatically shrink the cost of running a database platform, whether this is hosted, public cloud, or running on internal servers. But before we get there, it's worth looking beyond immediate financial benefits and locking our gaze on the issue of lock-in and restricted choice.
When public DBaaS were first introduced to the market, there was a far more limited choice of database engines. Alongside the enterprise favorites of Oracle and Microsoft SQL, there were PostgreSQL and MySQL for users looking to run an open source alternative. Since then, there has been a renaissance of database design and innovation that now addresses needs far beyond the simple CRUD. Database engines such as CockroachDB and Vitess offer new ways to interact and scale Relational Data, while Cassandra and MongoDB offer compelling NoSQL experiences. Popular new Search, Graph and Time Series databases have emerged, and the ML revolution is sparking the development of new VectorDB engines such as Milvus. There has never been so much choice for data persistence.
With this explosion of DB choice, cloud DBaaS providers have failed to keep pace with innovation. For cloud vendors, integrating new DB engines, producing automation, and automatically scaling their hosted offerings takes serious investment and development time. More recently, many of the most popular open source vendors have grown resentful of large cloud providers reselling their products as DBaaS offerings without paying anything back to the originators. This has led to companies such as Cockroach, Elastic, MongoDB, and others to introduce new licenses that forbid cloud vendors from offering their open source products as a hosted solution. Some of the cloud vendors have responded by creating their own forks, however, this is already leading to compatibility issues for users.
Even where cloud providers are able to use the open source product, the DBaaS offering is often an altered version of the original project. Even where cloud providers are able to use the open source project, the DBaaS offering is often an altered version of the original project. This presents issues for operators that are working in multi-cloud environments where they now have to operate different implementations of the same database engine, which will have nuances in features available (or missing) from cloud providers DBaaS offerings. This makes it a challenge to have consistent data and a sound disaster recovery and business continuity policy for your applications that follow any hybrid or multi-cloud strategy.
As we have demonstrated, despite surface convenience, cloud DBaaS has some significant financial and strategic downsides, and can impact product velocity. In a nutshell, it is expensive, inflexible, and limited. However, despite these factors, many organisations remain hesitant to create their own, internal DBaaS offering for developers. In our next blog, we will tackle some of the perceived issues of internal DBaaS head on. Finishing up with a short tutorial, we will prove how it is easier than you might think to roll your own with SUSE Rancher and Ondat.
