Hybrid Cloud Open Source DBaaS with Kubernetes
Zaitsev, Peter
DBaaS is the fastest growing way to deploy databases. It is fast and convenient and it helps to reduce toil a lot, yet it is typically done using proprietary software and tightly coupled to the cloud vendor. We believe Kubernetes finally allows us to build fully OpenSource DBaaS Solution capable to be deployed anywhere Kubernetes runs - on the Public Cloud or in your private data center. In this presentation, we will describe the most important user requirements and typical problems you would encounter building DBaaS Solution and explain how you can solve them using Kubernetes Operator framework.
 Hello everyone. Today we'll talk about database as a service with Kubernetes. So let me start by taking you back to the early days of a modern open source software. I got involved with open source myself in late 90s. And I remember at that time that was quite complicated. You would often have to download their source code and then some patches to make it work for your particular operating system, your compiler, your compiler, you know, compile it all and hope it works. Since that time, we had started this never ending journey towards simplicity. We got binaries, then packages, repositories, containers, which make it easier and easier to deploy the software we use, which is wonderful. And if you look at the database, the database as a service is state of art, how you can get simple access to the database. Now, database as a service is often termed, which is used in conjunction with public cloud providers. So what do I mean when I am talking about the open source database as a service? I think database as a service is generally two things. From one standpoint, that is an interface. Instead of conventional or old-fashioned database delivery approach, we have to install a bunch of packages, configure servers separately, backups, monitoring, maybe some HA solution. We can just have an API call where we deploy a full database cluster, which includes backup, maybe self-healing, self-patch, self-tuning, and so on and so forth. And that is actually something which is very well suited for open source database software. Now there is another part of that, which is also there, backend management, then software fails, and there are some always edge cases when database doesn't happen, then humans can get involved and fix it so you, as a service consumer, is not impacted. That happens in all public cloud providers out there, often though it is invisible to you. And that is something which cannot be completely open source, right, because that is human doing stuff, but that is something that you can control here by yourself or can choose from other partner to help you. Now let's talk a bit about the cloud or the promise of the cloud. If you remember, a few years back, then cloud was not so common as those days. The cloud was explained by analogy of thinking to electric services and say, hey, folks, instead of producing your own electricity by running generator at home, it's a common sense what you just should have somebody doing that efficiently at scale and providing reliable electricity for you. And that is all good and that is a very appealing explanation which makes sense to me. The thing to note and to remember is electricity, though, you often can choose among different providers, which give you pretty much the same usable electricity and some of them may be more reliable, other more green and others cheaper, but you can still run your TV wherever provider you use. And that is not quite reality where cloud vendors are taking us. If you look at the cloud architect courses and in general reference architectures, you would see what the same cloud vendors who sold the clouds as equivalent to the commodity electricity, they want to lock you in by advising most proprietary solutions where platform has to offer. For example, in a database space, you're not said ever to, hey, just deploy the database on Kubernetes, or even on the EC2, you are told to use solutions like the NamaDB or Amazon Aurora when it comes to Amazon solution. Well, obviously solutions which provides the lock in and stickiness in their platform. And there is a lot of push and marketing for that. So it is rather hard to resist. In the end, though, the choice is yours. You can choose your cloud or rather how you use the cloud, right? You can choose the way of serve them where you are at the mercy of the cloud and completely locked into the solution of one way of freedom. When you think about the freedom as it applies to the cloud infrastructure, that is where I think the Kubernetes comes in play as pretty much ubiquitous API, which provides you substantial compatibility between different cloud vendors. If you do not know what Kubernetes is, right here is a very simple introduction. You can think about that as an operating system, right, like similar to Linux, but for the cluster or data center rather than individual hosts. And that is something which has a lot of momentum. And that is universally supported in public, private, hybrid clouds, right? So if you can deploy your software on the Kubernetes back end, you can pretty much deploy it anywhere and everywhere. Traditionally, though, Kubernetes was not great for running stateful applications. Well, in fact, it was designed for running stateless applications. And the databases are, you know, as far opposite of stateless application as you probably can go. And there are still a lot of people who question to what extent stateful workloads are suitable for Kubernetes. There are a lot of improvements over the last few years which make it feasible, possible, and even recommended. So for example, we got the stateless, stateful sets to manage the, you know, complicated stateful environments like databases. We got the persistent volumes to hold that state even if particular Kubernetes forwards die. And we also got the operator framework to manage all that complexity which databases require. Now, in additional to this kind of fact that that's possibly, is possible to do, there are actually quite a few of the public clouds database as a service which are powered by Kubernetes. Co-crowd cloud and FluxDB, PlanetScale, we all talk publicly about where infrastructure builds fully on Kubernetes. So if you are looking to run database on Kubernetes, you will not be alone. There are probably hundreds of thousands of nodes which are running in production among the clouds, among those and others. Now, if you look at at our work, and I would say they are not the largest contribution, contributor to Kubernetes and databases, but we are working to do our part. We have developed the Kubernetes operators for essentially MySQL and MongoDB to run the databases in the cloud. And our thinking really is what we are looking at the two types of users for this software. One is the direct users of our Kubernetes operators, which will just take them and run them. And then the users which want something as a database as a service, similar to what Amazon provides, when you can have a simple API call or couple of clicks through the web interface, and you get your database which essentially manages itself as much as possible. And the fact that it is using Kubernetes in the back end in this case is not so relevant. So operators that are available for folks who are familiar with Kubernetes and want to work with Kubernetes in a well, in Kubernetes way. If you are not one of those, we also provide the corner database of the service experimental CLI, which essentially allows you to create clusters, rather simply by running some commands, right? After you set up connection to your Kubernetes cluster somewhere in the cloud, you can run the single command to create MySQL cluster. And when you have done that, then you can use QPCL for the port mapping and then use your favorite client like MySQL and credentials provided to connect to that. Now, if you would rather want to expose their IP and have a database accessible outside of Kubernetes, we also have that option, right? We provide a functionality where you can specify your own password rather than using automatically created password. Or as well, while our default deployment is a cluster of the three nodes, right? Because especially with Kubernetes, we do not want to rely on reliability of a single port. If you just need the database for, I don't know, experiment for development, maybe you may not want to have the three nodes deployed, which are, for this use case. In this case, you can also use this advanced deployment and deploy the node with, deploy only one database node without high availability. Because this is not safe configuration, we kind of require you to jump from extra hoops to specify what you do really understand what you are doing because, well, losing your data is quite unpleasant. Now, the next step, what we are taking in this case is making their database as a server functionality included with Percona Monitoring Management, where we actually just recently released the preview functionality of this release. In this case, that gets pretty close to what you get with Amazon RDS. After you've connected PMM to Kubernetes cluster, you are able to deploy the database clusters in just a few clicks and get fully operational monitor database cluster. We're not quite doing their backups yet, right? And some other things still need to be improved, but that is why it's called preview. So if you are interested in this direction of our work, let us know, check it out, maybe you can submit a full request, which is a fully open source project. So to finish it up, you can see what if Percona Database is a server CLI, you can get something similar to Database as a service experience with Kubernetes already. And PMM is taking that either fuller. And in the corner, we are continuing to work to bring more features and extent usability of Database as a service available in open source software. If you're interested in that too, then check out our software or contribute, participate in development. We would really appreciate that. To finish my, let me finish it with this thought, is I believe what the Database as a service has won as a way to consume Database because of really unparalleled convenience it offers. At the same time, vendor locking sucks. And especially if you're coming to force them, I think you probably believe that. And as usually, as with many other problems before, the open source is coming to the rescue. Thank you. With that, I'm ready to answer some of your questions if you have any. Okay, looks like they are done, right? Okay, I just wait a couple of seconds. Yeah, and I guess we're live. Okay. Thanks, Peter, for your talk. We have some questions. The first one is, is this available as CRDs too? I don't know exactly what this refers to, but you will know. Yeah, I mean, so if you look at the concept for the right, in this case, so our, the operator is how we integrate that with their Kubernetes in a pretty standard way, right? And then they speak about the standard of CLI and other graphical user interface, that is for people who are not familiar with Kubernetes. That's a sort of path that shows for integration. Okay, then another question is, how good of a feeling do we have running such DB classes on a production Kubernetes? Well, so I think their data on Kubernetes, right, is I think is always this kind of contentious topic, right? And I have both customers, right, and even huge kind of fortune-tastic operations, which run a lot of the databases on Kubernetes and very successful. And there are folks who say, oh my gosh, you cannot do it ever. And as I mentioned, you also see the increase in number of the even of the public clouds, right, solutions are being built on the Kubernetes, right? So it is pretty robust at this point, if you can figure that out properly, right? There are some limitations, of course, like, for example, if you look at the pod sizes, right, if you look at bare metal, then maybe Iranian databases, which has, you know, hundreds of CPU cores, maybe terabyte plus of memory and so on and so forth, right? You probably don't want to do that with Kubernetes, right? As a practical standpoint, what we suggest to everybody is, if you're not comfortable, do not jump and put your most critical database in this environment first. Start, test, and dev, maybe kind of get you some second tier database on Kubernetes first, right? And as, and if you develop your trust, you can move on to have more production critical databases. Okay. Another question we have is, do you have any code links to database as a service CLI? And does it use the Kubernetes API in the background with some wrappers? Oh, yes. Yes. So if you look at the Kubernetes CLI, no, of course, there is a pretty much CLI which works at Kube CTL, like actually in this case, and that's it. Yeah. So, and let me get the link for folks. So I obviously have it here. Okay. And then we have one last question. Can operators perform backup and restore? And if so, where can it store backups? Yes. So if you do have an operator support for backups, right, we even have a release just a few days ago, their point in time recovery support for operators, which is kind of pretty unique as the database operator goes, right? There is essentially can, you know, every minute, right, or every two seconds to get the database changes and upload it right into some cloud storage. The most common way to use the Kubernetes for us for backups is S3, compatible storage, right? So if you use S3 itself or your admin or write or something like that, the support right, you can also take backup locally, but the usability of that is limited, right in the Kubernetes environment. Okay. So are there any other questions? We still have a few minutes left. And folks, this is obviously open source project. So we would very much welcome your feedback, bugs, even some code contribution, right? So. Okay, we do have some more questions. What happens with events such as node failures and how quickly can the workload be migrated? Well, that is a great question, right? And that is one of the beautiful things with Kubernetes where it provides that kind of back playing for handling node failures. So if you have a node which is, which is, which has failed, then operator will provision another node for performance to the cluster, right, which will rejoin the cluster. How much time it will take depends on, on, on a data size and as well what kind of failure that is, because if you have just computer source failed, then it's very quick to reprovision that. Now, if you also have a storage which was attached to that node has failed, then it will need to essentially re-sync the storage from a database and that will depend on your database size and your network speed. Okay. Another question is, are you already developing help charts for the Persona X-Straight with Stradib cluster operator? Well, it's, it was a, yes, so there is a help chart available, right? Let me send you another doc, doc in the chart, in the chart. So
 Hello everyone. Today we'll talk about database as a service with Kubernetes. So let me start  by taking you back to the early days of a modern open source software. I got involved  with open source myself in late 90s. And I remember at that time that was quite complicated.  You would often have to download their source code and then some patches to make it work  for your particular operating system, your compiler, your compiler, you know, compile  it all and hope it works. Since that time, we had started this never ending journey  towards simplicity. We got binaries, then packages, repositories, containers, which make  it easier and easier to deploy the software we use, which is wonderful. And if you look  at the database, the database as a service is state of art, how you can get simple access  to the database. Now, database as a service is often termed, which is used in conjunction  with public cloud providers. So what do I mean when I am talking about the open source database  as a service? I think database as a service is generally two things. From one standpoint,  that is an interface. Instead of conventional or old-fashioned database delivery approach,  we have to install a bunch of packages, configure servers separately, backups, monitoring, maybe  some HA solution. We can just have an API call where we deploy a full database cluster,  which includes backup, maybe self-healing, self-patch, self-tuning, and so on and so  forth. And that is actually something which is very well suited for open source database  software. Now there is another part of that, which is also there, backend management, then  software fails, and there are some always edge cases when database doesn't happen, then  humans can get involved and fix it so you, as a service consumer, is not impacted. That  happens in all public cloud providers out there, often though it is invisible to you.  And that is something which cannot be completely open source, right, because that is human  doing stuff, but that is something that you can control here by yourself or can choose  from other partner to help you. Now let's talk a bit about the cloud or the promise of  the cloud. If you remember, a few years back, then cloud was not so common as those days.  The cloud was explained by analogy of thinking to electric services and say, hey, folks,  instead of producing your own electricity by running generator at home, it's a common  sense what you just should have somebody doing that efficiently at scale and providing reliable  electricity for you. And that is all good and that is a very appealing explanation which  makes sense to me. The thing to note and to remember is electricity, though, you often  can choose among different providers, which give you pretty much the same usable electricity  and some of them may be more reliable, other more green and others cheaper, but you can  still run your TV wherever provider you use. And that is not quite reality where cloud  vendors are taking us. If you look at the cloud architect courses and in general reference  architectures, you would see what the same cloud vendors who sold the clouds as equivalent  to the commodity electricity, they want to lock you in by advising most proprietary solutions  where platform has to offer. For example, in a database space, you're not said ever  to, hey, just deploy the database on Kubernetes, or even on the EC2, you are told to use solutions  like the NamaDB or Amazon Aurora when it comes to Amazon solution. Well, obviously solutions  which provides the lock in and stickiness in their platform. And there is a lot of push  and marketing for that. So it is rather hard to resist. In the end, though, the choice is yours.  You can choose your cloud or rather how you use the cloud, right? You can choose the way of  serve them where you are at the mercy of the cloud and completely locked into the solution  of one way of freedom. When you think about the freedom as it applies to the cloud infrastructure,  that is where I think the Kubernetes comes in play as pretty much ubiquitous API, which provides you  substantial compatibility between different cloud vendors. If you do not know what Kubernetes is,  right here is a very simple introduction. You can think about that as an operating system,  right, like similar to Linux, but for the cluster or data center rather than individual hosts. And  that is something which has a lot of momentum. And that is universally supported in public,  private, hybrid clouds, right? So if you can deploy your software on the Kubernetes back end,  you can pretty much deploy it anywhere and everywhere. Traditionally, though, Kubernetes  was not great for running stateful applications. Well, in fact, it was designed for running  stateless applications. And the databases are, you know, as far opposite of stateless application  as you probably can go. And there are still a lot of people who question to what extent  stateful workloads are suitable for Kubernetes. There are a lot of improvements over the last  few years which make it feasible, possible, and even recommended. So for example, we got the  stateless, stateful sets to manage the, you know, complicated stateful environments like databases.  We got the persistent volumes to hold that state even if particular Kubernetes forwards die.  And we also got the operator framework to manage all that complexity which databases  require. Now, in additional to this kind of fact that that's possibly, is possible to do,  there are actually quite a few of the public clouds database as a service which are powered  by Kubernetes. Co-crowd cloud and FluxDB, PlanetScale, we all talk publicly about  where infrastructure builds fully on Kubernetes. So if you are looking to run database on  Kubernetes, you will not be alone. There are probably hundreds of thousands of nodes which  are running in production among the clouds, among those and others. Now, if you look at  at our work, and I would say they are not the largest contribution, contributor to  Kubernetes and databases, but we are working to do our part. We have developed the Kubernetes  operators for essentially MySQL and MongoDB to run the databases in the cloud. And our thinking  really is what we are looking at the two types of users for this software. One is the direct users  of our Kubernetes operators, which will just take them and run them. And then the users which  want something as a database as a service, similar to what Amazon provides, when you can have a  simple API call or couple of clicks through the web interface, and you get your database which  essentially manages itself as much as possible. And the fact that it is using Kubernetes in the  back end in this case is not so relevant. So operators that are available for folks who are  familiar with Kubernetes and want to work with Kubernetes in a well, in Kubernetes way. If you  are not one of those, we also provide the corner database of the service experimental CLI,  which essentially allows you to create clusters, rather simply by running some commands, right?  After you set up connection to your Kubernetes cluster somewhere in the cloud,  you can run the single command to create MySQL cluster. And when you have done that, then you can  use QPCL for the port mapping and then use your favorite client like MySQL and credentials provided  to connect to that. Now, if you would rather want to expose their IP and have a database  accessible outside of Kubernetes, we also have that option, right? We provide a functionality  where you can specify your own password rather than using automatically created password. Or as  well, while our default deployment is a cluster of the three nodes, right? Because especially with  Kubernetes, we do not want to rely on reliability of a single port. If you just need the database  for, I don't know, experiment for development, maybe you may not want to have the three nodes  deployed, which are, for this use case. In this case, you can also use this  advanced deployment and deploy the node with, deploy only one database node without high  availability. Because this is not safe configuration, we kind of require you to jump from extra hoops  to specify what you do really understand what you are doing because, well, losing your data  is quite unpleasant. Now, the next step, what we are taking in this case is making their database  as a server functionality included with Percona Monitoring Management, where we actually just  recently released the preview functionality of this release. In this case, that gets pretty close  to what you get with Amazon RDS. After you've connected PMM to Kubernetes cluster, you are  able to deploy the database clusters in just a few clicks and get fully operational monitor  database cluster. We're not quite doing their backups yet, right? And some other things still  need to be improved, but that is why it's called preview. So if you are interested in this direction  of our work, let us know, check it out, maybe you can submit a full request, which is a fully  open source project. So to finish it up, you can see what if Percona Database is a server CLI,  you can get something similar to Database as a service experience with Kubernetes already.  And PMM is taking that either fuller. And in the corner, we are continuing to work to bring more  features and extent usability of Database as a service available in open source software.  If you're interested in that too, then check out our software or contribute, participate in  development. We would really appreciate that. To finish my, let me finish it with this thought,  is I believe what the Database as a service has won as a way to consume Database because of really  unparalleled convenience it offers. At the same time, vendor locking sucks. And especially if  you're coming to force them, I think you probably believe that. And as usually, as with many other  problems before, the open source is coming to the rescue. Thank you. With that, I'm ready to  answer some of your questions if you have any. Okay, looks like they are done, right?  Okay, I just wait a couple of seconds.  Yeah, and I guess we're live. Okay. Thanks, Peter, for your talk. We have some questions.  The first one is, is this available as CRDs too? I don't know exactly what this refers to, but you  will know. Yeah, I mean, so if you look at the concept for the right, in this case, so our,  the operator is how we integrate that with their Kubernetes in a pretty standard way,  right? And then they speak about the standard of CLI and other graphical user interface,  that is for people who are not familiar with Kubernetes. That's a sort of path that  shows for integration. Okay, then another question is,  how good of a feeling do we have running such DB classes on a production Kubernetes?  Well, so I think their data on Kubernetes, right, is I think is always this kind of  contentious topic, right? And I have both customers, right, and even huge kind of  fortune-tastic operations, which run a lot of the databases on Kubernetes and very successful.  And there are folks who say, oh my gosh, you cannot do it ever. And as I mentioned, you also see the  increase in number of the even of the public clouds, right, solutions are being built on the  Kubernetes, right? So it is pretty robust at this point, if you can figure that out properly, right?  There are some limitations, of course, like, for example, if you look at the pod sizes, right,  if you look at bare metal, then maybe Iranian databases, which has, you know, hundreds of  CPU cores, maybe terabyte plus of memory and so on and so forth, right? You probably don't want to  do that with Kubernetes, right? As a practical standpoint, what we suggest to everybody is,  if you're not comfortable, do not jump and put your most critical database in this environment  first. Start, test, and dev, maybe kind of get you some second tier database on Kubernetes  first, right? And as, and if you develop your trust, you can move on to have more production  critical databases. Okay. Another question we have is, do you have any code links to  database as a service CLI? And does it use the Kubernetes API in the background with some wrappers?  Oh, yes. Yes. So if you look at the Kubernetes CLI, no, of course, there is a pretty much CLI  which works at Kube CTL, like actually in this case, and that's it. Yeah. So, and let me get the link  for folks. So I obviously have it here. Okay. And then we have one last question.  Can operators perform backup and restore? And if so, where can it store backups?  Yes. So if you do have an operator support for backups, right, we even have a release just a few  days ago, their point in time recovery support for operators, which is kind of pretty unique  as the database operator goes, right? There is essentially can, you know, every minute,  right, or every two seconds to get the database changes and upload it right into some cloud storage.  The most common way to use the Kubernetes for us for backups is S3, compatible storage, right? So  if you use S3 itself or your admin or write or something like that, the support right,  you can also take backup locally, but the usability of that is limited,  right in the Kubernetes environment. Okay.  So are there any other questions? We still have a few minutes left.  And folks, this is obviously open source project. So we would very much welcome your feedback,  bugs, even some code contribution, right? So.  Okay, we do have some more questions. What happens with events such as node failures  and how quickly can the workload be migrated?  Well, that is a great question, right? And that is one of the beautiful things with Kubernetes  where it provides that kind of back playing for handling node failures. So if you have a node  which is, which is, which has failed, then operator will provision another node for  performance to the cluster, right, which will rejoin the cluster. How much time it will take  depends on, on, on a data size and as well what kind of failure that is, because if you have  just computer source failed, then it's very quick to reprovision that. Now, if you also have a  storage which was attached to that node has failed, then it will need to essentially re-sync  the storage from a database and that will depend on your database size and your network speed.  Okay. Another question is, are you already developing help charts for the Persona X-Straight  with Stradib cluster operator? Well, it's, it was a, yes, so there is a help chart available,  right? Let me send you another doc, doc in the chart, in the chart. So
containers_k8s_dbaas_0_6911.png containers_k8s_dbaas_6912_8555.png containers_k8s_dbaas_8556_10415.png containers_k8s_dbaas_10416_10595.png containers_k8s_dbaas_10596_13703.png containers_k8s_dbaas_13704_14351.png containers_k8s_dbaas_14352_16571.png containers_k8s_dbaas_16572_16835.png containers_k8s_dbaas_16836_16967.png containers_k8s_dbaas_16968_21083.png containers_k8s_dbaas_21084_22331.png containers_k8s_dbaas_22332_22655.png containers_k8s_dbaas_22656_22979.png containers_k8s_dbaas_22980_23891.png containers_k8s_dbaas_23892_24263.png containers_k8s_dbaas_24264_24335.png containers_k8s_dbaas_24336_24755.png containers_k8s_dbaas_24756_26027.png containers_k8s_dbaas_26028_26207.png containers_k8s_dbaas_26208_28751.png containers_k8s_dbaas_28752_30227.png containers_k8s_dbaas_30228_30503.png containers_k8s_dbaas_30504_31103.png containers_k8s_dbaas_31104_31547.png containers_k8s_dbaas_31548_32111.png containers_k8s_dbaas_32112_32879.png containers_k8s_dbaas_32880_33107.png containers_k8s_dbaas_33108_35315.png containers_k8s_dbaas_35316_35629.png
Hello everyone. Today we'll talk about database as a service with Kubernetes. So let me start by taking you back to the early days of a modern open source software. I got involved with open source myself in late 90s. And I remember at that time that was quite complicated. You would often have to download their source code and then some patches to make it work for your particular operating system, your compiler, your compiler, you know, compile it all and hope it works. Since that time, we had started this never ending journey towards simplicity. We got binaries, then packages, repositories, containers, which make it easier and easier to deploy the software we use, which is wonderful. And if you look at the database, the database as a service is state of art, how you can get simple access to the database. Now, database as a service is often termed, which is used in conjunction with public cloud providers. So what do I mean when I am talking about the open source database as a service? I think database as a service is generally two things. From one standpoint, that is an interface. Instead of conventional or old-fashioned database delivery approach, we have to install a bunch of packages, configure servers separately, backups, monitoring, maybe some HA solution. We can just have an API call where we deploy a full database cluster, which includes backup, maybe self-healing, self-patch, self-tuning, and so on and so forth. And that is actually something which is very well suited for open source database software. Now there is another part of that, which is also there, backend management, then software fails, and there are some always edge cases when database doesn't happen, then humans can get involved and fix it so you, as a service consumer, is not impacted. That happens in all public cloud providers out there, often though it is invisible to you. And that is something which cannot be completely open source, right, because that is human doing stuff, but that is something that you can control here by yourself or can choose from other partner to help you. Now let's talk a bit about the cloud or the promise of the cloud. If you remember, a few years back, then cloud was not so common as those days. The cloud was explained by analogy of thinking to electric services and say, hey, folks, instead of producing your own electricity by running generator at home, it's a common sense what you just should have somebody doing that efficiently at scale and providing reliable electricity for you. And that is all good and that is a very appealing explanation which makes sense to me. The thing to note and to remember is electricity, though, you often can choose among different providers, which give you pretty much the same usable electricity and some of them may be more reliable, other more green and others cheaper, but you can still run your TV wherever provider you use. And that is not quite reality where cloud vendors are taking us. If you look at the cloud architect courses and in general reference architectures, you would see what the same cloud vendors who sold the clouds as equivalent to the commodity electricity, they want to lock you in by advising most proprietary solutions where platform has to offer. For example, in a database space, you're not said ever to, hey, just deploy the database on Kubernetes, or even on the EC2, you are told to use solutions like the NamaDB or Amazon Aurora when it comes to Amazon solution. Well, obviously solutions which provides the lock in and stickiness in their platform. And there is a lot of push and marketing for that. So it is rather hard to resist. In the end, though, the choice is yours. You can choose your cloud or rather how you use the cloud, right? You can choose the way of serve them where you are at the mercy of the cloud and completely locked into the solution of one way of freedom. When you think about the freedom as it applies to the cloud infrastructure, that is where I think the Kubernetes comes in play as pretty much ubiquitous API, which provides you substantial compatibility between different cloud vendors. If you do not know what Kubernetes is, right here is a very simple introduction. You can think about that as an operating system, right, like similar to Linux, but for the cluster or data center rather than individual hosts. And that is something which has a lot of momentum. And that is universally supported in public, private, hybrid clouds, right? So if you can deploy your software on the Kubernetes back end, you can pretty much deploy it anywhere and everywhere. Traditionally, though, Kubernetes was not great for running stateful applications. Well, in fact, it was designed for running stateless applications. And the databases are, you know, as far opposite of stateless application as you probably can go. And there are still a lot of people who question to what extent stateful workloads are suitable for Kubernetes. There are a lot of improvements over the last few years which make it feasible, possible, and even recommended. So for example, we got the stateless, stateful sets to manage the, you know, complicated stateful environments like databases. We got the persistent volumes to hold that state even if particular Kubernetes forwards die. And we also got the operator framework to manage all that complexity which databases require. Now, in additional to this kind of fact that that's possibly, is possible to do, there are actually quite a few of the public clouds database as a service which are powered by Kubernetes. Co-crowd cloud and FluxDB, PlanetScale, we all talk publicly about where infrastructure builds fully on Kubernetes. So if you are looking to run database on Kubernetes, you will not be alone. There are probably hundreds of thousands of nodes which are running in production among the clouds, among those and others. Now, if you look at at our work, and I would say they are not the largest contribution, contributor to Kubernetes and databases, but we are working to do our part. We have developed the Kubernetes operators for essentially MySQL and MongoDB to run the databases in the cloud. And our thinking really is what we are looking at the two types of users for this software. One is the direct users of our Kubernetes operators, which will just take them and run them. And then the users which want something as a database as a service, similar to what Amazon provides, when you can have a simple API call or couple of clicks through the web interface, and you get your database which essentially manages itself as much as possible. And the fact that it is using Kubernetes in the back end in this case is not so relevant. So operators that are available for folks who are familiar with Kubernetes and want to work with Kubernetes in a well, in Kubernetes way. If you are not one of those, we also provide the corner database of the service experimental CLI, which essentially allows you to create clusters, rather simply by running some commands, right? After you set up connection to your Kubernetes cluster somewhere in the cloud, you can run the single command to create MySQL cluster. And when you have done that, then you can use QPCL for the port mapping and then use your favorite client like MySQL and credentials provided to connect to that. Now, if you would rather want to expose their IP and have a database accessible outside of Kubernetes, we also have that option, right? We provide a functionality where you can specify your own password rather than using automatically created password. Or as well, while our default deployment is a cluster of the three nodes, right? Because especially with Kubernetes, we do not want to rely on reliability of a single port. If you just need the database for, I don't know, experiment for development, maybe you may not want to have the three nodes deployed, which are, for this use case. In this case, you can also use this advanced deployment and deploy the node with, deploy only one database node without high availability. Because this is not safe configuration, we kind of require you to jump from extra hoops to specify what you do really understand what you are doing because, well, losing your data is quite unpleasant. Now, the next step, what we are taking in this case is making their database as a server functionality included with Percona Monitoring Management, where we actually just recently released the preview functionality of this release. In this case, that gets pretty close to what you get with Amazon RDS. After you've connected PMM to Kubernetes cluster, you are able to deploy the database clusters in just a few clicks and get fully operational monitor database cluster. We're not quite doing their backups yet, right? And some other things still need to be improved, but that is why it's called preview. So if you are interested in this direction of our work, let us know, check it out, maybe you can submit a full request, which is a fully open source project. So to finish it up, you can see what if Percona Database is a server CLI, you can get something similar to Database as a service experience with Kubernetes already. And PMM is taking that either fuller. And in the corner, we are continuing to work to bring more features and extent usability of Database as a service available in open source software. If you're interested in that too, then check out our software or contribute, participate in development. We would really appreciate that. To finish my, let me finish it with this thought, is I believe what the Database as a service has won as a way to consume Database because of really unparalleled convenience it offers. At the same time, vendor locking sucks. And especially if you're coming to force them, I think you probably believe that. And as usually, as with many other problems before, the open source is coming to the rescue. Thank you. With that, I'm ready to answer some of your questions if you have any. Okay, looks like they are done, right? Okay, I just wait a couple of seconds. Yeah, and I guess we're live. Okay. Thanks, Peter, for your talk. We have some questions. The first one is, is this available as CRDs too? I don't know exactly what this refers to, but you will know. Yeah, I mean, so if you look at the concept for the right, in this case, so our, the operator is how we integrate that with their Kubernetes in a pretty standard way, right? And then they speak about the standard of CLI and other graphical user interface, that is for people who are not familiar with Kubernetes. That's a sort of path that shows for integration. Okay, then another question is, how good of a feeling do we have running such DB classes on a production Kubernetes? Well, so I think their data on Kubernetes, right, is I think is always this kind of contentious topic, right? And I have both customers, right, and even huge kind of fortune-tastic operations, which run a lot of the databases on Kubernetes and very successful. And there are folks who say, oh my gosh, you cannot do it ever. And as I mentioned, you also see the increase in number of the even of the public clouds, right, solutions are being built on the Kubernetes, right? So it is pretty robust at this point, if you can figure that out properly, right? There are some limitations, of course, like, for example, if you look at the pod sizes, right, if you look at bare metal, then maybe Iranian databases, which has, you know, hundreds of CPU cores, maybe terabyte plus of memory and so on and so forth, right? You probably don't want to do that with Kubernetes, right? As a practical standpoint, what we suggest to everybody is, if you're not comfortable, do not jump and put your most critical database in this environment first. Start, test, and dev, maybe kind of get you some second tier database on Kubernetes first, right? And as, and if you develop your trust, you can move on to have more production critical databases. Okay. Another question we have is, do you have any code links to database as a service CLI? And does it use the Kubernetes API in the background with some wrappers? Oh, yes. Yes. So if you look at the Kubernetes CLI, no, of course, there is a pretty much CLI which works at Kube CTL, like actually in this case, and that's it. Yeah. So, and let me get the link for folks. So I obviously have it here. Okay. And then we have one last question. Can operators perform backup and restore? And if so, where can it store backups? Yes. So if you do have an operator support for backups, right, we even have a release just a few days ago, their point in time recovery support for operators, which is kind of pretty unique as the database operator goes, right? There is essentially can, you know, every minute, right, or every two seconds to get the database changes and upload it right into some cloud storage. The most common way to use the Kubernetes for us for backups is S3, compatible storage, right? So if you use S3 itself or your admin or write or something like that, the support right, you can also take backup locally, but the usability of that is limited, right in the Kubernetes environment. Okay. So are there any other questions? We still have a few minutes left. And folks, this is obviously open source project. So we would very much welcome your feedback, bugs, even some code contribution, right? So. Okay, we do have some more questions. What happens with events such as node failures and how quickly can the workload be migrated? Well, that is a great question, right? And that is one of the beautiful things with Kubernetes where it provides that kind of back playing for handling node failures. So if you have a node which is, which is, which has failed, then operator will provision another node for performance to the cluster, right, which will rejoin the cluster. How much time it will take depends on, on, on a data size and as well what kind of failure that is, because if you have just computer source failed, then it's very quick to reprovision that. Now, if you also have a storage which was attached to that node has failed, then it will need to essentially re-sync the storage from a database and that will depend on your database size and your network speed. Okay. Another question is, are you already developing help charts for the Persona X-Straight with Stradib cluster operator? Well, it's, it was a, yes, so there is a help chart available, right? Let me send you another doc, doc in the chart, in the chart. So
easier and easier to deploy the software we use, art, how you can get simple access to the to you. And that is something which cannot be by advising most proprietary solutions where to Linux, but for the cluster or data center something which has a lot of momentum. And that software on the Kubernetes back end, you can databases in the cloud. And our thinking really And the fact that it is using Kubernetes in the for this use case. In this case, you can also use in development. We would really appreciate that. way to use the Kubernetes for us for backups is from a database and that will depend on your