 All right, happy Friday afternoon to everybody and thank you so much for showing up for my talk. I really appreciate it I hope I will do it justice. I inherited this talk a little bit late in the process and so this is kind of Going to be I think an evolving talk for me. So So my name is Joe Brockmeyer. I work at Percona. We do open-source databases. I'm not going to Make this one big commercial or anything, but that's why I'm talking about databases. So I think that's at least relevant. I'm head of community at Percona So I've been in open-source for more than 20 years and Part of my career I worked at Red Hat and worked on a project that unfortunately no longer exists called project atomic I worked on portfolio marketing around the rail container story for a while And now I work at Percona with databases, which is why I'm discussing this topic, but I'm not a Hardcore Kubernetes expert or anything like that. So how many folks in the audience are working with Kubernetes like every day? All right, y'all know way more than I do No shame admitting that. How many folks work with Kubernetes at all? How many folks are working with databases? All right, okay How many folks have no idea why they're in this room and thought I was gonna be talking about something else nobody okay great. All right, all right Okay, so what we're gonna be talking about here I'm gonna talk a little bit about why we're talking about this why it's a topic why it got accepted I think why it got accepted to the conference. I'm gonna talk a very brief history of Linux containers I'm gonna talk about containers as they exist today As a mainstream technology Then we'll talk about are they ready for production databases Then I'm gonna talk about Kubernetes and things at scale because a lot of times now when people say containers what they really mean is Kubernetes Right, they really mean can I put this into Kubernetes or not? Then I'll talk a little bit about the challenges that are specific to Databases for Kubernetes and I'll talk a little bit about how you might handle those and then also close it off with I'm not a believer in No matter what technology you may be evangelizing or Working with it's not always the right technology for everything So there are some times when maybe Kubernetes in your database or not the right match, right? So why are we still talking about this containers have been mainstreamed for a while? But Organizations are still adopting containers and Kubernetes, right like is the future is here, but it is not widely distributed, right? So we've crossed the chasm from interests people thinking about maybe we want to play with Kubernetes Maybe maybe to we actually do want to use this, but this is a lot like Linux adoption in the early 2000s, okay So if you were around in the early 2000s as Linux was becoming mainstream Kind of crept in from the edges, right? Everybody didn't put all of their workloads on Linux right away You had your file and print servers and your web servers, and then it crept in closer and closer and soon You knew that they what they're running Oracle databases on Linux Wall Street's using Linux everybody's using Linux now What happened? How did that happen? That's the same thing with Kubernetes Why databases why is that this a specific thing that we want to talk about because databases are at the heart of most of Our businesses, right? That's where your data lives These are really important applications for you and so that's a very important topic and The other reason is because containers are great for stateless applications and databases are the original stateful application like you did just these are two very different things. These are you know either like milk and Nachos or it's like, you know Reese's peanut butter cups like which one is it like is this gonna measure is this not So lots of legacy applications people are thinking about lifting and shifting and getting it wrong is extremely costly This is the important thing. So at Precona we work with people's databases and people are like holy crap This is really important and if we get it wrong Bad things happen to our business the database goes down. We can't operate in some fashion or we lose data, which is even worse, right? Oh, and I do want to you know a little ask Reese there when I'm talking about containers We're talking about Docker style containers. There are more than one way to contain things So a brief history of Linux containers. How many folks have been in the industry for more than 10 years? A lot of y'all some old folks in the room. Okay, great more than 15 More than 20 All right, the AARP is signing up right outside that no I Started getting those when I was like 40. I'm like seriously seriously. Okay All right. So anyway, Linux has had containers for a long time. It's had charoot for a long time You could contain a process using charoot Which was a very primitive but a form of container and then Way back in the early 2000s for a while I work for a hosting company in Denver called data 393 and we adopted this thing called virtuoso anybody ever use virtuoso All right Virtuoso was a original form of Linux containers that was a lightweight virtualization basically it was a whole system container and the idea was for hosting companies let you carve up your servers into Multiple servers and offer Private virtual servers for people because a lot of people didn't like the shared hosting model They wanted what felt like their own server and we used virtuoso for that later. They open source that is open vz There are a lot of hosting companies that still use open vz but the CTO CIO at data 393 were pretty smart fellas and they Used it in a non-prescribed way Which is relates to the topic of databases production databases what they would do because we had customers who would get a dedicated server Outgrow it because this was before scalable applications They would outgrow it and we would have to migrate them to a new server, which was painful So what we would do is provision the whole thing with virtuoso and give them one big container on the system and Provision all of the resources when they outgrew the server We would migrate that container to another server, which was a pretty clever way of Migrating people and handling customer problems similar to what you might think about doing with a production database Then LXC came around Similar to Docker how many folks have played with LXC a little bit Does similar things to Docker but without the neat developer tooling Docker came along and Put all this wonderful tooling around working with containers that nobody else had done and revolutionized the way that we think about working with So here we are 2023 I'm gonna take a quick drink because I'm starting to dry out here. I rarely talk this much in one time So basically Docker style containers. They're the tooling to manage the containers and that's not just Docker. How many folks use podman I Knew Adam's hand was gonna go up you better Yeah, I knew your hand was gonna go up you a couple folks over there So there's pod man also works with OCI Docker type containers Yeah, Dan is gonna be reviewing the tape to make sure that Adam raised his hand here So it's the format for the container images People who work with containers a lot are very picky when you talk about containers a container is a running Process the running container the image is the thing that you're swapping around Docker pull and things like that, but it's basically a bunch of processes and everything wrapped in namespaces and C groups and everything So Dan Walsh likes to say everything on your system is in a container. Some of it's just in the system container. Okay, I Bring all that up because It's pertinent to the question of can you run databases in a container you kind of already do even if you don't use containers So there is no reason you can't run a pet database in a container With a couple of extra steps. So and it might even be handy for you in some instances. Let's say You've got an application. You got a beefy server and you've got one application that needs my sequel five seven You've got another one needs my sequel eight and you've got another application that needs a version of postgres Real beefy server carve it up into three with containers And you're gonna have three different containers running on the system that won't conflict too much with one another, right? So you can use this for production databases, okay? It's slightly more overhead. It's slightly more complicated, but a pet container might be doable All right, but really what a lot of folks are thinking about is can I use? Databases with Kubernetes because I'm starting to write applications for Kubernetes. I'm starting to do cloud native apps Can I use them with can I use my database with these things right because I've got my data in this? I've got my apps over here So just a little illustration CNCF report recently 96% of organizations are using or evaluating Kubernetes, right? So We know everybody's going in this direction the same way everybody was going in the direction of Lennox, okay? It's just a matter of how fast and how completely they get there, okay? and Then there how many folks have heard on the about the data on Kubernetes folks Just one okay, so I'm here to evangelize for data on Kubernetes Which is a group that is trying to solve problems not just around databases, but data in general stateful applications and large data sets on top of Kubernetes and So they did a survey last year. I think it was a report with 500 respondents and 90% say they think that Kubernetes is ready for stateful workloads. Okay, 71% say they're already doing that in production Okay, now these are the people who responded to that survey. So there's probably a little bit of self-selection going on But almost all of the people surveyed said that they're more productive Using Kubernetes than not okay, so when they move things into Kubernetes it makes them more productive 76% of the 500 say that they're using databases in Kubernetes. So obviously For some value of ready Kubernetes is ready for production databases But they also say that day two operations are a significant challenge This is not a shock day two operations are always a challenge for every technology It's usually easy to spin things up. It's mark much harder to keep them spinning, right? But only 9% of those respondents say that they're getting more than 20% of their revenue related to this So in other words, it's widely used, but it's this deep right now, but it's getting deeper And by the way, I will put these slides up on my blog. My blog is disassociated press net You just Google for Joe Brockmeyer. You'll probably find that eventually. I'll put these up on my blog No later than I'm gonna say Monday Sunday is Mother's Day, and I feel like I need to attend to that But I will make sure that by Monday these slides for this talk and my previous talk are up on my blog So you'll be able to download the PDF and you can get all the URLs and things that are in here So anyway, good report recommend reading through the whole thing So what is good about databases on Kubernetes? Pretty much the same thing that's good about other things on top of Kubernetes, it's where your other workloads are at If that's where they are you can move more quickly to deploy things into Kubernetes Then you can to a bare metal server or virtualization or yada yada yada You have automation on Kubernetes. You can do self-healing Things are portable if you're running Kubernetes in your data center and you want to move something out to EKS or Amazon Or you want to move something to OpenShift? It should work from you know, assuming these are fairly similar versions of Kubernetes Should work across those things Now with databases, there's the extra consideration of how much data am I trying to chuck from one data center to another? But at least in theory your applications and everything should be portable between them And there's also the potential for self-service, right? You get more potential to allow people to provision their own databases and things on top of these Which makes it much easier for your DBAs who don't want to spend their time provisioning databases They want to spend their time tuning databases and doing all those wonderful things but there are challenges and Some good things so good if you're writing new green field applications in cloud native apps, this is good It's great for development and testing because you're usually not hammering huge databases, but you can prototype things quickly If you're already a Kubernetes organization, this is a much better You know, it's it's better for you if things are in Kubernetes than not If you have lots of small databases, I think I haven't been able to determine if this is actually true But I think like wordpress.com would be an ideal scenario for lots of small databases in top on Kubernetes, right? I'm a wordpress.com customer. I have a business plan I'm pretty sure that my database does not cause their infrastructure a great deal of stress But it's easy for them to isolate my database from all the other customers on wordpress.com, right? It's repeatable. So like if you have an application, it's easy to you know, just Step and repeat that application across a bunch of different users and so forth. It's scalable It's easy to scale applications on Kubernetes if you have the infrastructure And good thing is Kubernetes and the ecosystem are still evolving So the folks who are beavering away at all the different projects around Kubernetes and Kubernetes keep doing new and wonderful things And so they keep adding new and wonderful features that solve old and painful problems, right? The bad if you do this thinking everybody else is doing it But you don't know what you're doing that can be bad It has a very steep learning curve for DBAs and people who have traditionally of I'm an old Linux guy Kubernetes is is different and it's you know, like it's a learning curve for me It'd be like me trying to learn Emacs after using Vim for 24 years a little bit But not that bad and Kubernetes is less resource intensive, but you know, you get the point So Okay, so day two operations This is where it's easy to stand things up when I used to work at red hat and people would talk to me like Why do I want to use rel or open shift instead of like just vanilla upstream? Because it's like a puppy Okay Free isn't puppy. You can get the vanilla upstream Free you can go and outside Walmart and take home a puppy or a kitten But then you got to train it so like if you want a full-fledged service dog You don't want to try to train that puppy. You want to get the service dog that you need to get on with your life, right? So the day two operations you may be good at standing things up But keeping them running and figuring out the problems is a little bit harder And also the ugly truth is that not every kubernetes Environment is exactly the same Okay, so you may run into problems And then the ugly if you have a large pet databases are cto said if you have a large pet database named zoos On its own server. That's probably not a great candidate to put into kubernetes right away Okay, if you have like a four terabyte data set, it's probably not a great candidate for that Database sprawl so every time I've been in the industry for a while and then VMs and then things like open shift and then You know, whatever every time you make it easy for users to self-service and spin things up They do the problem is they don't spin them back down again So you can very easily get into database sprawl and some things where You have a lot of stuff going on in your environment that you may not be aware of Okay, there are also memory limits and getting resourcing right. So, you know making sure that you have your resource tuning and everything can be very difficult Performance may suffer For things like network latency and resource isolation You may have some performance issues that you weren't anticipating or used to On you know, if you're moving from VMs or bare metal database You may run into some things that you weren't expecting. So there are some gotchas. Okay So the real question isn't are the containers ready for a production database? It's Is your production database ready for kubernetes? Have you architected things correctly to run in kubernetes or does it match? So there is a partial solution to a lot of these problems and that's kubernetes operators So how many folks are familiar with operators? All right fewer than I expected but i'm glad for that. So, um So kubernetes operators are basically base basic they're basically extensions to kubernetes that let you Utilize custom resources Manage applications complexity. Basically. It's like mega scripting for kubernetes, right? It's basically you can hide a lot of complexity in The operator and make it easy for people to deploy things and operate things Um with operators. So you can do things like deploying a service performing backups and restores Which is real important when you're talking about databases You can do upgrades and provision storage and scale applications and all sorts of wonderful Things when you're working with kubernetes operators Um, and this is basically just some of the things that you can deal with with operators and so forth. So, you know monitoring backups updates encryption all these things are available to you much more easily So basically it hides the complexity. It lets you simplify the deployment and it simplifies day two operations Percona offers several operators for things like mysql clustering and so forth So we've got some experience with doing these things and are still learning Again, i'll go and promote data on kubernetes Community they're working on an operator matrix to talk about the maturity of different operators for working with data On kubernetes. So if your company your organization You personally are working with kubernetes and operators and are interested in data on kubernetes I'd really recommend checking out that community. It is a vendor neutral Pooling of people coming together to solve these stateful application problems. Okay So and this is kind of the capability levels. So, you know, this is how you would look at your operators Like can I just do an install? Can I just throw something out? to to kubernetes Level two. Can I do upgrades? Can I deploy something and keep it running and keep it updated? Full life cycle level three basically like if I look at an operator and it can do all of these things um backup recovery Failover i'm at level three if I can get deep insights into my application which you want if you're running serious databases on there Then you want a level four or better operator and Basically level five is going to give you the auto scaling. It's going to give you all of the goodness tuning Detect abnormalities all of that goodness. Okay All of that said kubernetes isn't always the answer as I said some databases just should not be migrated To kubernetes if you have a really big hefty legacy database Keep it outside kubernetes figure out how you're going to get your applications to talk to it Size guidelines. So this is a fun story again. I'm not as hands-on as a lot of the folks Maybe in this room and certainly not as the dba's and folks that I work with at prokona and I tossed out the question It's always fun when you ask a bunch of technical people a question like Tell me like I have a concrete question. Give me a concrete answer. You know what you know what the next two words you're going to get are It depends. Thank you. Yes. It depends which is everyone's least favorite Answer to a question. I was like now. I know how my teenager feels when they asked me a question like can I do this? Well, it depends So same thing asking everybody like, all right I'm going to go do this talk. I'm going to talk to customers. I'm going to be booth, you know And I know people are going to ask me what's the size limit for databases on kubernetes Exactly So I did manage to extract kind of a consensus around like if your database is a terabyte or larger Maybe think about no, okay, if it's four terabytes or larger Definitely you probably do not want to be doing that with traditional databases now. There may be some things I'm not an expert on every single database. I'm not an expert on most databases But like if you look at something like maybe cockroach db Which is a cloud native database that may be suited for larger datasets because it's architected for kubernetes But if you're looking at my sequel or a postgres or something like that Probably not a good candidate if you have individual databases of that size okay, so basically If you have kubernetes expertise in your organization, if you have smaller databases You need the automation and scaling And you're comfortable with and going to use operators to deploy these things It's doable might even be a good idea. Okay If you are new to kubernetes if you have huge databases if you are performance sensitive if you're doing manual deploys Is not a good idea for you to try to use databases in kubernetes in production. Okay And that's it. That is my whole talk that I managed to get through in 23 minutes, which uh Kind of a personal best time wise. So, um, are there any questions? Um, or comments or anything Yes, sir Oh, I'm sorry. Yes. Thank you. Um, yes, please use the microphone. I appreciate that Anna. Thank you So do you foresee any progress in the future for that? Yeah. Oh, absolutely um, I I think that these things will evolve in both directions. I think that, um Companies like, you know, ours will keep working on databases to make them better suited for for kubernetes And I think the kubernetes community Here's companies saying we want to run all of our stuff in kubernetes Not just some of it and they're going to keep working towards that. So yes, absolutely We've made a lot of progress. I mean this would have um, when I was I mean only when open shift was first Ported over to kubernetes and everything that would have been completely bonkers to want to try to do that But yeah, we made a lot of progress and I think we'll keep doing that. That's what open source does, right? so Any other questions or anything? It was that bad No, all right. Well, uh, thank you everybody again for turning up on a friday afternoon. I appreciate your time and attention I hope you have a good rest of the conference and thanks for being here. Thanks the organizers and uh, have a good rest of your weekend