[00:00.000 --> 00:12.880]  Our next talk is by Peter, and he's going to talk about database in a container to debass
[00:12.880 --> 00:13.880]  on Kubernetes.
[00:13.880 --> 00:16.000]  I hope I pronounced this correctly.
[00:16.000 --> 00:17.000]  Yeah.
[00:17.000 --> 00:18.000]  Okay.
[00:18.000 --> 00:19.000]  Hello, everyone.
[00:19.000 --> 00:20.000]  You hear me well?
[00:20.000 --> 00:21.000]  Okay.
[00:21.000 --> 00:22.000]  Cool.
[00:22.000 --> 00:33.000]  So, let me ask first, how many of you folks have been involved with open source in 90s?
[00:33.000 --> 00:36.000]  Anyone remember those days?
[00:36.000 --> 00:46.000]  So, well, I was, and for me in those times, right, you remember that open source was,
[00:46.000 --> 00:49.000]  well, quite different than today, right?
[00:49.000 --> 00:53.000]  You needed a lot of elbows grease, right?
[00:53.000 --> 00:58.000]  I remember how you have to, you know, download the source packages, maybe patch them some
[00:58.000 --> 01:04.000]  way to make sure it works if your particular compiler, right, and, you know, figure out
[01:04.000 --> 01:11.000]  all the libraries, dependencies, all this kind of stuff to make it work, right?
[01:11.000 --> 01:18.000]  And you could feel that certain pride for just installing some applications.
[01:18.000 --> 01:26.260]  Since that, we had this never-ending move to simplicity, making it possible to run open
[01:26.260 --> 01:31.320]  source software more and more easily, right?
[01:31.320 --> 01:35.200]  So, from that, download sources, patch, and compile.
[01:35.200 --> 01:41.000]  We had a wonderful invention of TarGZ binaries and install script.
[01:41.000 --> 01:43.000]  Anybody remembers those?
[01:43.000 --> 01:44.000]  No?
[01:44.000 --> 01:45.000]  Some do, right?
[01:45.000 --> 01:51.000]  And then they got, like, packages of dependencies, and then those have been in repositories,
[01:51.000 --> 01:52.000]  right?
[01:52.000 --> 01:56.500]  And in the end, they're coming to say, hey, you know what, now we don't really care about
[01:56.500 --> 02:01.000]  the disk space anymore, so we just, you know, jumble it all together as a, you know, docker
[02:01.000 --> 02:06.000]  or snap packages, right, with no dependencies, right?
[02:07.000 --> 02:16.000]  So we got a lot of that move to their simplicity, and obviously that is, you know, fantastic
[02:16.000 --> 02:17.000]  and convenient.
[02:17.000 --> 02:25.000]  One of those ways, which is very popular, is docker.
[02:25.000 --> 02:31.000]  And a question in our talk, as it relates to the database and what is my background,
[02:31.000 --> 02:39.280]  is to what extent you can and should use database with those technologies.
[02:39.280 --> 02:45.800]  And if you look at the docker, we use that actually quite a lot in particular in test
[02:45.800 --> 02:49.000]  and dev environment, right?
[02:49.000 --> 02:55.120]  What is wonderful about docker, if you want several database versions, right, or wherever
[02:55.120 --> 03:01.120]  you can install them very easily on the same node, which don't conflict with each other,
[03:01.120 --> 03:02.120]  right?
[03:02.120 --> 03:08.120]  Where in, you know, your classical Linux operating system, if you want to install, you know,
[03:08.120 --> 03:14.000]  MySQL 5.5, 5.6, 5.7 at the same time, because you maybe want to make sure your application
[03:14.000 --> 03:17.120]  is working well, good luck, right?
[03:17.120 --> 03:22.120]  They all conflict on the shared files and so on and so forth.
[03:22.120 --> 03:24.120]  Dockers enable that, right?
[03:24.120 --> 03:27.120]  That is absolutely fantastic.
[03:27.120 --> 03:32.120]  And also, you can use solutions like a docker compose and bunch of others if you want to,
[03:32.120 --> 03:38.120]  you know, deploy your application and, you know, database that depends on in a docker
[03:38.120 --> 03:44.120]  containers, make it very easily, very nicely.
[03:44.120 --> 03:52.120]  Now, if you look at docker in production, though, it is also possible, though we actually
[03:52.120 --> 03:55.120]  see less than that.
[03:55.120 --> 04:00.120]  Some of the concerns come from overhead, and I would say these are mostly unfounded those
[04:00.120 --> 04:06.120]  days, but if you really, like Google, you can still find some articles saying, like,
[04:06.120 --> 04:14.120]  some scary stories about docker and database being absolutely horrible, right?
[04:14.120 --> 04:21.120]  What also you need to take care of in this case is a little bit of extra complexity, which
[04:21.120 --> 04:25.120]  I know especially a lot of not-docker experts have been beaten by.
[04:25.120 --> 04:32.120]  Like, you have to have your database on a data volume for best results.
[04:32.120 --> 04:38.120]  Otherwise, you can remove your data container, right, and boom, all your data is gone.
[04:38.120 --> 04:44.120]  Well, that is a very different experience compared to, let's say, uninstalling the RPM
[04:44.120 --> 04:50.120]  or depth package on Linux, where you can uninstall the database package your data remains so you
[04:50.120 --> 04:52.120]  can install a different one, right?
[04:52.120 --> 05:00.120]  In docker, unless you have the data stored in a separate volume, you will trash your data,
[05:00.120 --> 05:04.120]  right, to give if you're moving their container.
[05:04.120 --> 05:11.120]  Also, in production, that is somewhere you need a lot of monitoring and observability.
[05:11.120 --> 05:18.120]  Okay.
[05:18.120 --> 05:21.120]  Hopefully, that will settle.
[05:21.120 --> 05:30.120]  So, if you look at the introduction, we often need some observability, right, and monitoring,
[05:30.120 --> 05:39.120]  which initially lacked support for docker, which I think got a lot better in those days.
[05:39.120 --> 05:43.120]  So, what is the state of open-source databases with docker?
[05:43.120 --> 05:50.120]  If you think about that, what most open-source databases out there have official docker images.
[05:50.120 --> 05:57.120]  For those which don't, you will find a variety of unofficial docker images out there, right,
[05:57.120 --> 06:01.120]  so you can pretty much run it everywhere.
[06:01.120 --> 06:05.120]  It is very commonly deployed for test and dev.
[06:05.120 --> 06:10.120]  You will, if you look at the docker stats, you will see, like, hundreds of millions of downloads,
[06:10.120 --> 06:18.120]  like docker pools for many of them, though, I would say, in production, it is limited, right.
[06:18.120 --> 06:23.120]  I know some companies say, hey, we have deployed our production with docker with, let's say,
[06:23.120 --> 06:31.120]  our custom orchestration system, but I would not say that is very common.
[06:31.120 --> 06:38.120]  You know, at your corner, for our software, for database, we support, we essentially do the same thing.
[06:38.120 --> 06:43.120]  We provide the docker packages for everything.
[06:43.120 --> 06:54.120]  So, if you are just sticking to docker, to pure docker, what problems are not solved very well in this environment?
[06:54.120 --> 06:59.120]  The first, and I think the most important one, is, you know, day two operations.
[06:59.120 --> 07:05.120]  The databases are interesting, right, in a way that unlike the application where you often can say,
[07:05.120 --> 07:10.120]  let's just, you know, tear down and redeploy from scratch, right, and that is the approach
[07:10.120 --> 07:21.120]  which is increasingly often taken, right, instead of just, you know, modifying their application, right.
[07:21.120 --> 07:25.120]  You cannot really do that with a database.
[07:25.120 --> 07:31.120]  You know, database is something which has to retain the state, retain the data,
[07:31.120 --> 07:34.120]  not lose any transactions which have been committed and so on and so forth,
[07:34.120 --> 07:42.120]  and that means what majority of the complexity and majority of the life in database happens is what's called day two, right,
[07:42.120 --> 07:47.120]  after you have the deployed, right, and docker-wise simplifies your installation,
[07:47.120 --> 07:53.120]  does not do anything really to solve all that needs to upgrade database.
[07:53.120 --> 07:59.120]  You don't deal with high availability and so on and so forth, right.
[07:59.120 --> 08:08.120]  Also, we can see what a lot of database management problems
[08:08.120 --> 08:14.120]  for real production database have to be done in context of a cluster,
[08:14.120 --> 08:20.120]  because every real production database will require high availability
[08:20.120 --> 08:23.120]  and that is cannot be done by the single instance, right.
[08:23.120 --> 08:30.120]  That has to be some sort of distributed cluster and docker doesn't really help us in this regard.
[08:30.120 --> 08:32.120]  So what does?
[08:32.120 --> 08:38.120]  Well, as you may have guessed, that would be a Kubernetes, right.
[08:38.120 --> 08:43.120]  Really, there have been some other container orchestration system for years,
[08:43.120 --> 08:49.120]  but I think you can say with confidence is what docker has won at this level,
[08:49.120 --> 08:56.120]  and in this regard it has a, you know, largest market share.
[08:56.120 --> 09:03.120]  So where do we see the states of Kubernetes and databases?
[09:03.120 --> 09:11.120]  Well, the relationship has been kind of complicated through years, why?
[09:11.120 --> 09:18.120]  Because Kubernetes initially was designed for a stateless application, right.
[09:18.120 --> 09:22.120]  And if you're saying, well, something is designed for stateless application,
[09:22.120 --> 09:26.120]  you can say, using that for databases, are you freaking crazy?
[09:26.120 --> 09:29.120]  The database are the opposite of stateless, right.
[09:29.120 --> 09:35.120]  The database where we supposed to have our states, right.
[09:35.120 --> 09:39.120]  And I think that is something which has been getting improvement, right,
[09:39.120 --> 09:47.120]  and now the Kubernetes is actually quite capable to run databases as well.
[09:47.120 --> 09:49.120]  But that wasn't always the case, right.
[09:49.120 --> 09:52.120]  I think this is interesting to look at this tweet, which is what,
[09:52.120 --> 09:56.120]  like almost like four years ago, right, at that time,
[09:56.120 --> 10:02.120]  in which case KC Hightower, which is one of very, well,
[10:02.120 --> 10:07.120]  you know, we're experts and third leaders in the Kubernetes space,
[10:07.120 --> 10:13.120]  was not very sure, right, about running databases on Kubernetes, right.
[10:13.120 --> 10:17.120]  Well, let's see what has changed and look at some stats.
[10:17.120 --> 10:21.120]  Now, over the last few years, in the Kubernetes space,
[10:21.120 --> 10:27.120]  we had this doc community, right, which stands for data on Kubernetes community.
[10:27.120 --> 10:32.120]  Very active, right, and really working to enable
[10:32.120 --> 10:36.120]  running data intensive applications on Kubernetes.
[10:36.120 --> 10:41.120]  And I think we've quite good results, right.
[10:41.120 --> 10:44.120]  These are actually like a little bit outdated,
[10:44.120 --> 10:48.120]  like from the last year, pool results, right.
[10:48.120 --> 10:57.120]  But we could see what there is a fair amount of companies running some significant number
[10:57.120 --> 11:03.120]  of data intensive applications on Kubernetes already.
[11:03.120 --> 11:09.120]  Here are some stats which are newer from a cloud native foundation this day, right.
[11:09.120 --> 11:14.120]  And these are comparing 2021 to 2022, right, essentially,
[11:14.120 --> 11:18.120]  just last year starts where we can see what the databases
[11:18.120 --> 11:25.120]  was the second most common workload,
[11:25.120 --> 11:30.120]  well, second most fastest growing kind of workload,
[11:30.120 --> 11:32.120]  which is deploying Kubernetes, right.
[11:32.120 --> 11:36.120]  So we can see what the things are changing, right.
[11:36.120 --> 11:40.120]  Now you can see also some other stuff like messaging and big data.
[11:40.120 --> 11:44.120]  All of those are also actually data intensive applications, right.
[11:44.120 --> 11:50.120]  So we can see Kubernetes have moved in this field, right.
[11:50.120 --> 11:52.120]  Now here is our interesting data point, right.
[11:52.120 --> 11:58.120]  If you look at the database as a service, public database as a service, right,
[11:58.120 --> 12:02.120]  you would see many independent database as a service solutions
[12:02.120 --> 12:06.120]  which have been released over the last, you know, three, four years,
[12:06.120 --> 12:08.120]  actually Kubernetes built, right.
[12:08.120 --> 12:10.120]  They're based on Kubernetes, right.
[12:10.120 --> 12:14.120]  Here are, you know, a number of companies, right,
[12:14.120 --> 12:22.120]  which you may have heard, which are running their public databases
[12:22.120 --> 12:24.120]  as a service on Kubernetes.
[12:24.120 --> 12:29.120]  So I hope by this point I have convinced you
[12:29.120 --> 12:34.120]  what the databases on Kubernetes is, you know, quite possible
[12:34.120 --> 12:38.120]  and can be run quite successful.
[12:38.120 --> 12:44.120]  Now what is wonderful about Kubernetes specifically?
[12:44.120 --> 12:49.120]  Well, I mentioned that as a container orchestration system, right,
[12:49.120 --> 12:55.120]  but I also can think about that as essentially an operating system
[12:55.120 --> 12:59.120]  which is focused on the, you know, data center, right, a set of data centers,
[12:59.120 --> 13:05.120]  environment rather than on a single node.
[13:05.120 --> 13:08.120]  What I think is particularly great when it comes to the databases,
[13:08.120 --> 13:13.120]  it has a very robust mechanics to deal with all kind of failures,
[13:13.120 --> 13:16.120]  node failures and some others, right,
[13:16.120 --> 13:21.120]  because this is actually quite complicated problems, right.
[13:21.120 --> 13:23.120]  If you think about, like, very large systems,
[13:23.120 --> 13:28.120]  you have to be thinking about failures happening all the time,
[13:28.120 --> 13:32.120]  so often maybe multiple failures at the same time, right,
[13:32.120 --> 13:38.120]  and really doing that manually, right, as you would have to do
[13:38.120 --> 13:43.120]  if you want to, let's say, roll out your highly available system
[13:43.120 --> 13:46.120]  on, you know, like a bare metal or a bunch of VMs, right.
[13:46.120 --> 13:49.120]  It is tough, right.
[13:49.120 --> 13:53.120]  It is tough to get that, you know, last one, two, wherever,
[13:53.120 --> 13:57.120]  or maybe kind of zero one percent of edge cases,
[13:57.120 --> 14:04.120]  which is absolutely essential for running applications and scale.
[14:04.120 --> 14:09.120]  Specifically for databases, these typically are being built
[14:09.120 --> 14:11.120]  with the operator framework, right.
[14:11.120 --> 14:15.120]  The operator framework is something which, as the name says,
[14:15.120 --> 14:18.120]  allows you to put a lot of logic in, right,
[14:18.120 --> 14:22.120]  and say, hey, do what a skilled database operator would do.
[14:22.120 --> 14:24.120]  Because being stateful,
[14:24.120 --> 14:27.120]  databases need, like, an extra care, right,
[14:27.120 --> 14:30.120]  how you are going to upgrade the cluster, right.
[14:30.120 --> 14:34.120]  Well, you know what, you don't shut over database nodes down, right,
[14:34.120 --> 14:36.120]  and then change between your version and spin up.
[14:36.120 --> 14:39.120]  Well, no, you don't do it this way in databases.
[14:39.120 --> 14:42.120]  You often need to follow some process, you know,
[14:42.120 --> 14:44.120]  upgrade them one after another,
[14:44.120 --> 14:47.120]  maybe when to ensure your grade was successful,
[14:47.120 --> 14:50.120]  that's how database was warmed up appropriately, right,
[14:50.120 --> 14:56.120]  and all the very nuanced things which databases at scale need.
[14:56.120 --> 15:00.120]  Now, if you look at the databases on Kubernetes,
[15:00.120 --> 15:07.120]  we can see their pickup by vendors is slower, right.
[15:07.120 --> 15:13.120]  If you think about, you know,
[15:13.120 --> 15:17.120]  many of them would have operators that are not quite existing, right,
[15:17.120 --> 15:19.120]  or quite limited.
[15:19.120 --> 15:24.120]  And I would say a lot of reason for that is what,
[15:24.120 --> 15:28.120]  in this age, vendors often would want you to rather
[15:28.120 --> 15:32.120]  to go to the database as a service solution, right.
[15:32.120 --> 15:34.120]  Idea, hey, you know, if you are,
[15:34.120 --> 15:38.120]  how you would like you to develop cloud native applications
[15:38.120 --> 15:41.120]  is go to our solution, right.
[15:41.120 --> 15:44.120]  If you are playing with, you know, MariaDB,
[15:44.120 --> 15:46.120]  go to SkySQL, right.
[15:46.120 --> 15:49.120]  If you are, you know, MongoDB,
[15:49.120 --> 15:52.120]  go to MongoDB Atlas, right, and so on and so forth, right.
[15:52.120 --> 15:57.120]  But in this case, you often steal a lot of third party solutions
[15:57.120 --> 16:00.120]  very developed, and then slowly but surely,
[16:00.120 --> 16:02.120]  many vendors, they start to pick up, right,
[16:02.120 --> 16:05.120]  because hey, you know what, it's better to have a Kubernetes
[16:05.120 --> 16:08.120]  operator and people doing something else entirely, right.
[16:08.120 --> 16:14.120]  So we have, for example, official operators for MySQL
[16:14.120 --> 16:18.120]  or MariaDB or even MongoDB, they are, though,
[16:18.120 --> 16:23.120]  relatively limited at this point.
[16:23.120 --> 16:27.120]  Now, from our side, we've been in this operator game,
[16:27.120 --> 16:31.120]  I think, for a while, and for MySQL, MongoDB Postgres
[16:31.120 --> 16:36.120]  has pretty robust solutions, right,
[16:36.120 --> 16:41.120]  which you can use.
[16:41.120 --> 16:46.120]  What I would say is the problem with Kubernetes in this case.
[16:46.120 --> 16:51.120]  Well, if you look in this case of the Kubernetes,
[16:51.120 --> 16:55.120]  it can be quite complicated, right.
[16:55.120 --> 17:01.120]  And the running database is something you need to really be careful
[17:01.120 --> 17:04.120]  because often you don't get a second chance, right.
[17:04.120 --> 17:07.120]  If you sort of lost your database, well,
[17:07.120 --> 17:15.120]  that can be already very big and serious issue for your business, right.
[17:15.120 --> 17:20.120]  And setting up Kubernetes for a database,
[17:20.120 --> 17:24.120]  for like a storage and backup, right,
[17:24.120 --> 17:31.120]  can be quite advanced skill at this point.
[17:31.120 --> 17:34.120]  Now, if you look at the databases,
[17:34.120 --> 17:38.120]  where we see their state-of-art simplicity, I would say,
[17:38.120 --> 17:47.120]  is in there in a database as a service, right.
[17:47.120 --> 17:52.120]  And databases as a service, as it available in a proprietary cloud,
[17:52.120 --> 17:55.120]  I think brings a lot of great usability,
[17:55.120 --> 17:58.120]  but of course, also at a great cost.
[17:58.120 --> 18:01.120]  And in this case, I mean both as direct cost,
[18:01.120 --> 18:05.120]  as well as a vendor lock-in, which happens.
[18:05.120 --> 18:08.120]  In this case, if you look at the databases and servers,
[18:08.120 --> 18:12.120]  as they exist right now, there are a number of proprietary databases
[18:12.120 --> 18:16.120]  and service offerings, like obviously any launch cloud has them.
[18:16.120 --> 18:21.120]  Then there are some database vendors, right,
[18:21.120 --> 18:24.120]  which have their own, you think about MongoDB,
[18:24.120 --> 18:28.120]  SkySQL from MariaDB, Cockroach, Cloud, right, Timescale,
[18:28.120 --> 18:32.120]  everybody also has their own branded database cloud those days.
[18:32.120 --> 18:35.120]  And there is also a bunch of other vendors, right,
[18:35.120 --> 18:38.120]  which has also their own proprietary database management framework,
[18:38.120 --> 18:44.120]  like Avian Instaclassers gets you there.
[18:44.120 --> 18:48.120]  Now, why database as a service is important from my standpoint,
[18:48.120 --> 18:51.120]  because it really removes a lot of toil, right,
[18:51.120 --> 18:54.120]  the management have ability, like things of, hey, you know,
[18:54.120 --> 18:56.120]  patching, like security updates,
[18:56.120 --> 18:59.120]  it all can be done either automatically or, you know,
[18:59.120 --> 19:02.120]  like a pretty much push-down solution, you know,
[19:02.120 --> 19:05.120]  backups makes things easy to scale, right,
[19:05.120 --> 19:07.120]  hey, you know what I want to scale, right,
[19:07.120 --> 19:10.120]  instead of figuring out how to do that.
[19:10.120 --> 19:15.120]  But the problem with database as a service,
[19:15.120 --> 19:18.120]  as it comes right now,
[19:18.120 --> 19:21.120]  it often would be what I would call
[19:21.120 --> 19:24.120]  like a hotel California compatibility, right,
[19:24.120 --> 19:29.120]  like you can move into something as Amazon Aurora,
[19:29.120 --> 19:35.120]  right, from your, you know, of cloud installation,
[19:35.120 --> 19:38.120]  but then it's maybe very hard to move back.
[19:38.120 --> 19:43.120]  In fact, a lot of work out there is done exactly to make that,
[19:43.120 --> 19:45.120]  hmm, that hard.
[19:45.120 --> 19:48.120]  What also would see with a lot of the cloud vendors
[19:48.120 --> 19:55.120]  is those solutions they are called fully managed, right?
[19:55.120 --> 20:01.120]  Well, and fully managed is kind of over a market in my opinion,
[20:01.120 --> 20:04.120]  right, because when you talk to Amazon, for example,
[20:04.120 --> 20:07.120]  they say, oh, our solution is fully managed.
[20:07.120 --> 20:10.120]  Okay, so who's responsible for database security?
[20:10.120 --> 20:12.120]  Oh, that's shared responsibility.
[20:12.120 --> 20:13.120]  Who's going to tune that?
[20:13.120 --> 20:14.120]  Oh, that's shared responsibility.
[20:14.120 --> 20:16.120]  Well, what if I could not share responsibility, right?
[20:16.120 --> 20:18.120]  Everything is shared responsibility,
[20:18.120 --> 20:22.120]  and that means, well, which you may not find
[20:22.120 --> 20:25.120]  from the marketing pages, you still need people
[20:25.120 --> 20:28.120]  to understand databases on your stuff.
[20:28.120 --> 20:31.120]  Those, if the budgets have been reallocated
[20:31.120 --> 20:34.120]  to the fully managed database service providers,
[20:34.120 --> 20:37.120]  you may not have those people
[20:37.120 --> 20:42.120]  or enough of your people on the team.
[20:42.120 --> 20:45.120]  Now, my concern, of course, with those commercial databases
[20:45.120 --> 20:49.120]  service solution is that it is a vendor login,
[20:49.120 --> 20:51.120]  as I mentioned right now, right?
[20:51.120 --> 20:55.120]  Which may be, you know, painful for some, right?
[20:55.120 --> 20:58.120]  Maybe some of you have heard about 37 signals
[20:58.120 --> 21:02.120]  who recently wrote this article about why they live in the cloud
[21:02.120 --> 21:07.120]  and saying, oh, my gosh, that is like so expensive, right?
[21:07.120 --> 21:09.120]  And they mentioned specifically expense
[21:09.120 --> 21:12.120]  and a lot of, you know, fully managed database solutions
[21:12.120 --> 21:14.120]  they have been doing.
[21:14.120 --> 21:18.120]  But that is also something likely to come,
[21:18.120 --> 21:21.120]  become even more painful, you know, painful.
[21:21.120 --> 21:25.120]  So anybody of you recognize this young, good-looking guy
[21:25.120 --> 21:27.120]  out there?
[21:27.120 --> 21:29.120]  Anyone?
[21:29.120 --> 21:34.120]  Well, this is Mr. Larry Ellison, right?
[21:34.120 --> 21:38.120]  And what Mr. Larry Ellison was doing in 80s,
[21:38.120 --> 21:42.120]  he was really saving people from the nasty big blue
[21:42.120 --> 21:46.120]  and the vendor login which was happening, right,
[21:46.120 --> 21:48.120]  with the mainframe, right?
[21:48.120 --> 21:51.120]  But we go, we understand what happened,
[21:51.120 --> 21:54.120]  you know, a couple of decades after, later,
[21:54.120 --> 21:59.120]  after people were sufficiently saved by the Oracle.
[21:59.120 --> 22:01.120]  Now, what do we say?
[22:01.120 --> 22:05.120]  Well, Oracle doesn't have customers, Oracle has hostages, right?
[22:05.120 --> 22:12.120]  So that is what we should expect
[22:12.120 --> 22:16.120]  with a database vendor login as well, right,
[22:16.120 --> 22:22.120]  as you sufficiently adopt all of those wonderful extra features
[22:22.120 --> 22:27.120]  and you don't have a way back anymore, right?
[22:27.120 --> 22:33.120]  You can expect their cost of escalating as if Oracle.
[22:34.120 --> 22:38.120]  In my opinion, though, there is a good way to use the cloud,
[22:38.120 --> 22:41.120]  I would say, as indicates here,
[22:41.120 --> 22:46.120]  where you can really use the cloud as a commodity
[22:46.120 --> 22:51.120]  and build the value through their open-source solutions
[22:51.120 --> 23:02.120]  as Kubernetes and really look at this side, right?
[23:02.120 --> 23:06.120]  Instead of really building a relationship
[23:06.120 --> 23:08.120]  on the proprietary cloud vendors,
[23:08.120 --> 23:12.120]  you can see how you can embrace their solutions
[23:12.120 --> 23:16.120]  which are coming from an open-source stack
[23:16.120 --> 23:20.120]  like a one-in-a-cloud computing foundation.
[23:20.120 --> 23:23.120]  You can see this as an example, right?
[23:23.120 --> 23:25.120]  There are a lot of icons here.
[23:25.120 --> 23:27.120]  You probably cannot really read all of them,
[23:27.120 --> 23:32.120]  but the point what I want to indicate here
[23:32.120 --> 23:38.120]  is just how big is an open-source ecosystem is,
[23:38.120 --> 23:43.120]  and you probably find some projects for almost any need
[23:43.120 --> 23:47.120]  which you would have in like a proprietary cloud
[23:47.120 --> 23:50.120]  but they're in open-source.
[23:50.120 --> 23:55.120]  In my experience, what I would like to see
[23:55.120 --> 23:59.120]  and what you're working on as per corner
[23:59.120 --> 24:04.120]  in a database space to really provide a fully open-source solution
[24:04.120 --> 24:09.120]  which you can write on a variety of environments, right?
[24:09.120 --> 24:11.120]  Like, hey, you want it on a cloud,
[24:11.120 --> 24:15.120]  you want it in any of the on-prem environments,
[24:15.120 --> 24:17.120]  well, you got it, right?
[24:17.120 --> 24:23.120]  You should be able to do that with no changes.
[24:23.120 --> 24:26.120]  If you are just looking for the basics, actually...
[24:26.120 --> 24:29.120]  Well, I take it back.
[24:29.120 --> 24:32.120]  If you are having a lot of Kubernetes experience
[24:32.120 --> 24:34.120]  in your company already,
[24:34.120 --> 24:40.120]  actually their Kubernetes database operators
[24:40.120 --> 24:42.120]  are already pretty cool, right?
[24:42.120 --> 24:47.120]  They really, you know, eliminate so much of Toil, right?
[24:47.120 --> 24:50.120]  And you can check this, you know, tutorial
[24:50.120 --> 24:53.120]  which shows you how you set up a cluster, scale it,
[24:53.120 --> 24:55.120]  you know, whatever, back it up, right?
[24:55.120 --> 24:59.120]  Really, you know, just a couple of single comments
[24:59.120 --> 25:02.120]  compared to what that would do on Linux.
[25:02.120 --> 25:07.120]  It's like on a bare Linux is a lot more complicated.
[25:07.120 --> 25:11.120]  And for those who like more of, you know,
[25:11.120 --> 25:16.120]  graphical user interface similar to what Amazon RDS
[25:16.120 --> 25:18.120]  or other cloud vendors provide,
[25:18.120 --> 25:21.120]  we're working on that through our solution PMM,
[25:21.120 --> 25:24.120]  which is also 100% open source.
[25:24.120 --> 25:32.120]  Well, like, you can, you know, check it out.
[25:32.120 --> 25:36.120]  So, in the end, we would like to see, right,
[25:36.120 --> 25:39.120]  and hopefully we'll see more similar solution coming up
[25:39.120 --> 25:44.120]  from an industry where we have open source databases
[25:44.120 --> 25:46.120]  as a service experience.
[25:46.120 --> 25:48.120]  Some people wonder in this case, like,
[25:48.120 --> 25:50.120]  what does that really mean?
[25:50.120 --> 25:52.120]  Because the database as a service
[25:52.120 --> 25:54.120]  supposed to be like a fully managed.
[25:54.120 --> 25:57.120]  And what I mean by that is this, right?
[25:57.120 --> 26:00.120]  First part of a database as a service
[26:00.120 --> 26:02.120]  is your interface and experience.
[26:02.120 --> 26:06.120]  Like, hey, I deploy the database in a couple of clicks, right?
[26:06.120 --> 26:08.120]  Or like a single API call.
[26:08.120 --> 26:12.120]  Well, and nothing prevents us having an open source software
[26:12.120 --> 26:14.120]  which has those features.
[26:14.120 --> 26:16.120]  We can do it, right, and we should do it.
[26:16.120 --> 26:19.120]  Now, of course, there is an other piece, right?
[26:19.120 --> 26:26.120]  Well, typically, then things go beyond software ability
[26:26.120 --> 26:27.120]  to deal with that.
[26:27.120 --> 26:30.120]  There are some people, you know, in Amazon, right,
[26:30.120 --> 26:33.120]  or, you know, SkySquad or Avian, right,
[26:33.120 --> 26:35.120]  any of those providers, right?
[26:35.120 --> 26:38.120]  And of course, that is something, well, you don't get
[26:38.120 --> 26:40.120]  if you get a software alone.
[26:40.120 --> 26:43.120]  But that is something I believe you should have a choice
[26:43.120 --> 26:47.120]  where you are building those troubleshooting skills in-house.
[26:47.120 --> 26:49.120]  If that is the choice you take, right,
[26:49.120 --> 26:54.120]  or you should be able to pick from a variety of vendors, right,
[26:54.120 --> 26:58.120]  which can provide that kind of need for you, right,
[26:58.120 --> 27:01.120]  to provide a full database as a service experience
[27:01.120 --> 27:04.120]  comparable to the get-in and commercial cloud those days.
[27:04.120 --> 27:11.120]  So, with that, let me finish up with this, right,
[27:11.120 --> 27:15.120]  is what, if you look at the database as a service,
[27:15.120 --> 27:18.120]  the databases, they have been really going from container
[27:18.120 --> 27:27.120]  to full database experience in the open source side quite well.
[27:27.120 --> 27:32.120]  We can see what the Docker support is very mature.
[27:32.120 --> 27:34.120]  Kubernetes, I think, is getting there, right,
[27:34.120 --> 27:36.120]  if a lot of people are using that already.
[27:36.120 --> 27:39.120]  And the databases experience in the open source space
[27:39.120 --> 27:41.120]  is still work in progress,
[27:41.120 --> 27:44.120]  but I would expect it's coming and maturing
[27:44.120 --> 27:48.120]  both from Percona and other vendors in a few years.
[27:48.120 --> 27:51.120]  And, well, because of the open source,
[27:51.120 --> 27:56.120]  you can be part of solution, in this case,
[27:56.120 --> 28:03.120]  by, you know, by contributing to the ecosystem.
[28:03.120 --> 28:08.120]  So, I think the database as a service has won, right,
[28:08.120 --> 28:10.120]  because of unparalleled convenience,
[28:10.120 --> 28:17.120]  and you know what, deep down, we're all suckers for that.
[28:17.120 --> 28:20.120]  The software vendor lock-in sucks, right,
[28:20.120 --> 28:23.120]  I don't think anybody wants to build the company,
[28:23.120 --> 28:25.120]  and as in many other areas,
[28:25.120 --> 28:30.120]  I believe the open source is coming for rescue as well.
[28:30.120 --> 28:33.120]  With that, that's all ahead.
[28:33.120 --> 28:59.120]  Okay, we have time for about one, maybe two questions.
[28:59.120 --> 29:02.120]  Hi, thank you for your presentation.
[29:02.120 --> 29:06.120]  Quick question about the more operational side
[29:06.120 --> 29:10.120]  of running a database in Docker or Kubernetes.
[29:10.120 --> 29:13.120]  So, the main part people are usually scared about
[29:13.120 --> 29:16.120]  is, of course, the stateful part of it.
[29:16.120 --> 29:18.120]  So, storing the data somewhere
[29:18.120 --> 29:22.120]  should be for, like, file system snapshots
[29:22.120 --> 29:24.120]  or doing backups and so on.
[29:24.120 --> 29:28.120]  So, that's, in a way, stored in a separate place afterwards.
[29:29.120 --> 29:31.120]  For that second building block,
[29:31.120 --> 29:35.120]  what kind of services would you suggest in that case?
[29:35.120 --> 29:39.120]  Yeah, so, well, the question is about some operational aspects
[29:39.120 --> 29:42.120]  about running a database on Kubernetes, right,
[29:42.120 --> 29:46.120]  and specifically as it relates to the storage, right?
[29:46.120 --> 29:47.120]  Well, in our experience,
[29:47.120 --> 29:49.120]  a lot of that depends on what already exists.
[29:49.120 --> 29:54.120]  I think one of the big improvements in Kubernetes recently
[29:54.120 --> 29:59.120]  was having a unified CSI, right,
[29:59.120 --> 30:01.120]  internal storage interface, right,
[30:01.120 --> 30:05.120]  which allows now a lot more flexibility than before, right,
[30:05.120 --> 30:07.120]  and it's ever-improving, right?
[30:07.120 --> 30:10.120]  Like, for example, snapshots, they're building, right?
[30:10.120 --> 30:14.120]  Or you can now, like, scale the volume in many cases, right?
[30:14.120 --> 30:20.120]  So, that is what we rely on.
[30:21.120 --> 30:25.120]  Okay, we're unfortunately out of time.
[30:25.120 --> 30:28.120]  Thank you for the talk. Thank you for being here.
[30:28.120 --> 30:30.120]  Okay, well, and I will be outside
[30:30.120 --> 30:32.120]  so you guys have a few more questions.
[30:32.120 --> 30:33.120]  Happy to answer.