Podcast: Why DBaaS and what problems does it solve?

Antony Adshead: What is database as a service (DBaaS) and what challenges does it aim to solve?

Tobias Ternström: DBaaS is really about automating lifecycle management of databases. Things like provisioning a new database server, patching a fleet of database servers, making sure they’re backed up, making sure they’re highly available, making sure they’re protected from various types of disaster, be it operator fat-fingering or a meteorite hitting the datacentre.

And doing this typically in not just one location but in your datacentre, on the edge or in one of multiple public clouds.

Adshead: What would you say are the key benefits of DBaaS?

Ternström: I think database management has become more difficult over time, because it used to be that an organisation would have one database engine. You know, it’s an Oracle shop, or it’s a SQL Server shop, Informix shop, or DB2, or whatnot.

But, you go back 10 or so years and this started changing, and instead of a corporate standard it’s much more developers and application frameworks that bring in the database. Now, instead of just running one, or one or two on the side, if you will, they run multiple.

So, for example, the top five database engines in the world are SQL Server, Oracle, MySQL, Postgres and MongoDB. And all of those are run in … pick any big organisation. So, having people who can manage all of these databases, especially when you’re talking not tens or hundreds, but maybe tens of thousands of them, is very difficult. Making sure they’re secure and taking care of them.

That is the core challenge. DBAs [database administrators] are getting overloaded. DBAs want to focus on the top five really critical databases in an organisation, but instead they end up spread super-thin across thousands of databases, different database engines, different versions, different operating systems; it becomes really difficult.

That, I would say, is the number one problem: DBAs are getting overloaded in this new world.

The second problem we see a lot with our customers is that developers are slowed down. So, pick any large organisation, they typically have a lot of software developers employed, and every developer will use databases for testing, for evaluation purposes, and so on. When they do that they want to just self-service, to call an API [application programming interface] or click a button and *** happens, as I like to say. The database shows up with whatever data they need and they can do their development. Today, what is very common is that they have to file a ticket or call a person, and they have to wait for the database to show up.

The final thing is that there is a lot of movement away from proprietary databases, from expensive database licences, towards open source. And this means that if you ran 10,000 proprietary databases during a long period in years you probably run 10,000 open sources databases also. So, now you have to manage 20,000 databases, and to do that you need some sort of automation, otherwise you need to double your DBA population, and DBAs are hard to find to hire.

So, these are the three main challenges that we see: DBAs are overloaded, developers are slowed down, and there’s a move away from proprietary databases to open source.

Adshead: Is there a sweet spot in terms of use case and workload for DBaaS?

Ternström: I would say it’s not that it doesn’t work, but not every DBaaS is created equal. But it’s very good. It can handle large workloads. It’s more about how much help the DBaaS provides because the fundamental thing the DBaaS does is automation round all these areas we talked about.

And where it comes to these most critical databases, this is where you will have a DBA team that’s focused on making sure that everything is where it needs to be.

Although, I will say that it depends on organisations. If you look at the more experienced organisation, the better the chance a DBA team will take care of things and focus on those most critical workloads.

But the more it’s a new company, that may have been small and now is large, that’s grown very fast, it’s very often not the case. They don’t have this tradition of a DBA team, so they will rely on the DBaaS to take care of the more critical databases.

But it tends to be that the newer the app, the more databases it uses. So, an older critical app might have one gargantuan monolith database, whereas a new critical app might have 1,000 smaller databases for that one app.