 All right. So let's go through this fire announcement thing real quick. So please note the locations of surrounding emergency exits and located nearest lit exit signs. In the event of a fire alarm or other emergency, please calmly exit to the public concourse area. Exit, emergency exit serials leading to the outside of this facility are located along the public concourse. For your safety and emergency, please follow the directions of public safety. All right. Now that that's done, my name is Mike Rhodes. I am a architect in Dell EMC's data protection division, specializing in cloud native technologies. And I'm here to talk about Kubernetes and everything involved in protecting Kubernetes, running staple workloads in Kubernetes, disaster recovery, all those type of things. So when we first started looking at this, the first thing we asked ourselves is, where is the data, right? So I think the best way to look at it is from classic cloud foundry Pivotal application sense, we took a look and said, okay, well, in the Pivotal application service, you're usually running 12 factor apps. You're using a service broker to attach to external services. And those services sit somewhere else, right? They're outside of the container run time, outside of Diego, they're somewhere else, typically on one or more virtual machine, maybe they're in the cloud somewhere. And they likely are run by somebody else, right? The app team writes the code, the service team, the database team, the infrastructure team might run the database, control the database, et cetera. And this is good, right? So they have SLAs, they offer you protection. But this could also be a little bit scary, right? Because you don't own that infrastructure. So your data is somewhere where you're not 100% in control of it, right? So you really, really have to trust those SLAs. But now Kubernetes and specifically PKS is becoming a thing that we can utilize, right? Not every database has to run on a VM anymore. Not every database has to be set up in the, let's say the older sense as opposed to these modern technologies that we have. So maybe this is something that we could just play around with and see if there's anything else there, right? So perhaps we could apply PKS to running a database, right? And then the next question is why? So why would you run a database or any stateful workload on Kubernetes? This is a question that we talk about a lot. Number one is containerized efficiencies. Maybe that service, right? Actually, Cloud Native is all about running things more efficiently. Maybe that database, that traditional database you have, like MySQL, will run just a little bit faster, maybe a little bit more efficient, use less resources. Maybe it will run really, really good and you could have more instances across your infrastructure. Quicker provisioning, containers load up faster typically than VMs. That's always a good thing. Deployment consistency. So we hear from a number of operators that like running the same platform, right? So deploying all to the same thing all the time. Your apps, data services, all to one plane is nice to work with. It works everywhere, right? Kubernetes runs everywhere. Any public cloud works on prem because it's, you know, just came out, but it works on a number of different clouds. And most importantly in my mind is you get to take advantage of the Kubernetes ecosystem. So inside Kubernetes itself, you could plug your application and your data services into it and take advantage of that. That's what we're going to see today in my next couple of slides. But also all of these, you know, booming ecosystem applications that are out there that attach onto Kubernetes, logging, monitoring, all these things, they're just like one download and one deploy away. And that's a, there's a really cool use case that you could do for on top of these data services you're running. And I guess also importantly, it Kubernetes is all the rage, right? All the cool kids are doing it nowadays. So why don't we take a look and see if there's something there? Typically, if you're new to Kubernetes, the way you would run a stateful workload or let's say a database in this example, MySQL, is you take advantage of a first-class resource called a stateful set. A stateful set will control one or more pods. Each pod is one or more container. And you run your stateless workload in there, like a MySQL server. And then the stateful set attaches that to a persistent volume. So whatever storage under the covers you're using, maybe you're on AWS and you want to provision an EBS volume, the Kubernetes will do that for you via persistent volume claims. And this will lead up to a service. Service is sort of like your load balancer. And it will push traffic to a container or dependent on demand. So should we run databases? Now you know why, should we? If you look at it historically, back a couple years ago, Kubernetes released in June of 2014, then between now, between then and around the end of 2016, even thinking about running a database and Kubernetes was going to get you fired. It wasn't originally built for that. It was built for stateless workloads, very similar to Cloud Foundry. But then at the end of 2016, there was a beta feature introduced called PetSets. And that's when we started to see people pop up MySQL databases in test and dev. You might see a risky person every once in a while run something in production, but PetSets were very new. And during this time, the ecosystem for Kubernetes kind of just went insane. And we started to see more and more projects pop up on top of Kubernetes, plug into Kubernetes from the bottom, and more just in general workloads being run in production. So this past December, PetSets was renamed StatefulSets and it became GA, so it's production quality, so to speak. And now we start to see people talking about, okay, well, maybe I should take my classic, let's say my SQL database running on VMs, hard to provision. Maybe I should move that into Kubernetes and take advantage of its orchestration and all its ideal first-class citizen resources. And as the future moves on, as Kubernetes starts to get more and more adoption, which obviously it is, we'll start to see the storage integration. Right now, there's 60 to 100 different storage integrations into Kubernetes. We'll start to see that level out. And we'll start to see a lot more DevOps tools. So once you get your database running, then it's all about protecting it, monitoring it, et cetera, et cetera. And we're going to see a ton more databases and other stateful workloads in production on top of Kubernetes. So like I said, if you choose to run your stateful workload on PKS or Kubernetes, get in a running stateful set. The next thing after that is in our opinion, in my opinion is how do I protect it, make sure that data never goes away. One of the things we have here at Dell EMC is a product called Data Domain. So Data Domain is one of our most important products. It's all about backup management and protection storage. So not necessarily how you take the backup, but what you do with the backup after you've taken it. So you have a lot of efficiencies. You have storage efficiencies, network efficiencies. Data Domain's probably biggest feature is deduplication. So if you think about taking the thousand snapshots a day, and they're all one or more gigabyte, Data Domain helps you cut that by 70 percent on the storage end. It helps with network efficiency in that when you take a snapshot, it won't even send bits that it already has back on Data Domain. So if you think about taking a backup of my SQL database every, let's say, 10 minutes, 99 percent of that data is going to be the same every backup you take. So why do we send that across the network? Why do we store that on our servers on the back end? Also protection. So it's highly encrypted. I don't know if you know this, but a lot of the hacking that will go on in the world isn't going after production workloads. They're going after your backups. So they'll steal a copy of something that you had from a month ago and get critical information. Data Domain helps with that. Another cool feature of Data Domain, if you have multiple of them in different sites, in different clouds, it quickly and easily moves backups and workloads over to other data domains. So let's say you wanted to do some disaster recovery from on-premises to AWS. Your backups are already there and you could get them up and running in AWS very easily. Data Domain can be deployed as an appliance on-premises or as a virtual instance in a public cloud. We support all the public clouds. And it plugs into Kubernetes as a persistent volume. So this would be a secondary storage use case inside of Kubernetes. You do your primary storage on an EBS volume if you're running AWS. And you'll do your secondary storage, your backup storage on top of Data Domain. So switching it up a little bit, so we have this Data Domain product and it plugs into Kubernetes. We said, well, how is the user going to invoke it? And that's where the Open Service Procreate API comes in. So we've been working with the Open Service Procreate API group on the specification for a while. And we are in the process almost done with adding a feature called extensions, formerly known as actions. It could be actions again. An example of an action would be backup and restore. There are day two operations. There could be other things like ping and start, stop, pause a service. But obviously, backup and restore are the ones that we are most interested in. And the goal is to enable new endpoints to the API in a generic way. And this allows current things out there to be reused. So Azure's MySQL Database API has a backup and restore option. We didn't want to tell them, you have to switch to this backup and restore API to be able to integrate with the Open Service Procreate API. So that was a big feature in this. And it removes this sort of burden of managing API definitions, especially backup and restore, which can be very complicated, from the OSB API specification. So the way this works at an extremely high level is that the service broker, when you get a list of the actions, returns an Open API document. Open API 3.0 before 3.0 is called swagger, if you're familiar with swagger. And platforms or users, whoever is using the service broker, can take a look at the Open API document and understand which are the new endpoints that they can run and what are the payloads that are needed to run them. So this is currently in the validated stage. We do have a PR here, and we're looking for collaborators. This is very close to going into the specification, which means this will be, you know, there to take advantage of for all service providers. And just at a very quick, lower level, the way it works is when you provision a service instance, so you do a put on service instances, you get a result back. Originally, you would only get a dashboard URL, which is sort of your management UI and the last operation. Now, in blue, what you get back is an extensions API, and this tells you what those new actions are that you want to run, any credentials you need to run them. And this returns a swagger doc, and it just explains new endpoints, right? So in this example, on the same service broker, you could run a backup and restore and all those type of things. So what does that look like when we put all these things together? Database running on Kubernetes, OSB API, and data domain. Well, what we decided to do was we took the pivotal application service, so classic cloud foundry. We set up a PKS next to it. We put our own custom open service broker API running inside of Kubernetes. This one has a focus on my SQL databases. And then down at the bottom, we have our data domain appliance. This one's running in AWS. Actually, all of this is. And on that is a DDBoost volume. So this is a volume you provision. This is your secondary volume store, right? So all of your backups are going to go to this particular volume. And then we have our user. We have me sitting over there on the left. And he would do his typical things that he would do with CF, right? So he would do a CF marketplace, a CF create service. And this would all go back through the cloud controller through the open service broker API and spin up my stateful set for my SQL. Very quickly, just pushes out a new container image, sets up a service, sets up the stateful set, attaches my EBS volumes in this case, and I have my SQL service ready to go, right? And, you know, that's great. I now have a really fast on-demand my SQL service running. But what about backup and restore? So we created a CF plugin, a number of CF plugins to do just that. So in orange now, because it's new, I could take a CF backup, pass in my service instance name, name it something, and through obviously the same path, it's going to go into Kubernetes and in this case run a job. So a job in Kubernetes is also a first class citizen. It's just a task that runs the completion. It runs, does something, and then it stops. In our case, this job mounts our DD Booze volume for backup storage, goes into the MySQL service instance of your choice, and pushes MySQL DOM to your backup storage. After that, you could go in and do a CF list backups of your particular service instance and get a whole list of all the different backups you've taken in the past. You could do a CF restore, which just does the inverse. A different job pulls from this DD Booze volume and data domain and restores your service instance. And then from there, we thought about a whole other, you know, tons and tons of use cases that we could do from this Open Service Broker API. You could migrate services. You could clone services at, you know, the touch of a button, all those type of things. So I do have a quick demo that I'd like to see if it's working that I could show you. Let's see here. Let me come out of... Okay. How's the text, Louie? Oh, it's the light? Horribly light? All right. Let's see if we could beef it up real quick. And if we run out of time, we'll have to skip it. Is it... If I increase it, does that help? A little better? Okay. We'll go with it. So on the top, I have my CF command line, the usual stuff. So I'm going to check the marketplace. In my marketplace, this is my service, MySQL running on Kubernetes. I'm just going to quickly go and create one. Protected is the plan. And I'm going to do CF sum 2. So on the bottom left here, I'll increase this as well. So I'm going to do a kube control, and I'm going to do a get pod, and I'm going to watch the pods. So right now, the pods I have running here, my OSB server, and I have a baked MySQL up already, so I don't have to copy data into it and waste your precious time. So if we watch this, we hit this provision command. And there we go. See, we're starting to watch this pod pop up, right? It's running. It's pending. It's working eventually. So I'm going to exit out of this and clear. So if we take a look at services, we'll see we have a new load balancer, MySQL, and this is using the elastic load balancer in AWS. This is the access point, remember, into MyService. And we'll take a quick look at the stateful set. So I have two MySQL stateful sets running, one from 23 hours ago and one from 12 seconds ago. So now I could fully access this MySQL service. It's there. It's good to go. So if we take a look again, so now I have two services running in my environment. So now I'm just going to quickly show you one of these databases. Show databases. So let's use world. And I think I have a table called city with, like, 5,000 rows, right? 4,000 rows. So here's my database. I'm going to quit this guy and clear this guy. So now I'm going to, on kube control, I'm going to do a get for jobs. So there should be, oh, I'm going to watch this. So there's no jobs found. But if we keep watching, I'm going to do a CFS, so I don't remember, so I don't forget the name of my services. I'm going to do a CF back up, CF sum 1, and I'm going to name it backup 1. So what we should see is under the jobs, new container pops up. The age for whatever reason is invalid, so that's just a demo. And I'm going to go take a few more. So backup 2, you see a new pod pop up. This is doing these tasks 4 and then number 5. And then the last thing, in the bottom right corner, if this didn't time out, I'm going to, let's see, re-log into my kube node. And I'm just going to quickly show you. Again, I've got to zoom in a little bit. I'm going to show you this mount. So here, this is my DD boost mount going back to data domain. So if you see here, the name of the pod, the name of the service, comes up in a new folder on my DD mount. And if I just take a look at that, I see my five backups there. And the important thing to note, whatever size these are, I could probably do it in human readable, but this says, you know, whatever it is, 30,000 bytes, it's only one of those that are actually being stored. So the deduplication is happening right here. Maybe one of those plus a little bit more of metadata, right? These are all stubs pointing back. We're not wasting this much in storage space. Also, you could turn on encryption and all these things that make it much more secure. So I have my backups. I'm just going to go back in to my database again. Let's see, show databases. Because I keep forgetting. I'm going to drop database world. Okay, show again. World is gone. And then I'm going to do a CF restore, actually a CF list backups on CF sum one, I think it was called. So there's my five backups. There's the date when they were taking. There's the size. Okay, so 3.6 megs. Only one of those 3.6 megs is being stored on the data domain. And then I'll just do a CF restore. CF restore, CF sum one, back up, I don't know, four. Let's pick that one. So if you see bottom left-hand corner, here's another job running, another container popping up. It runs to completion, and then it's done. So the last little bit of this demo, we'll go back to my SQL server. We'll take a look at the databases. And then, obviously, world is back here. And we'll just double-check, like, star from city. And then those are my, you know, 4,000 or so rows. Like I said, all those CF plugins, we have clone. If you have an active service instance, you could just clone it on this puncher button, all of this stuff possible via the open service broker API. So let's see how we're doing on time. I think we have six minutes. So that's one way to do things, right? That's one of our products. And I want to show you really, really, really quickly two other ones on two separate slides. So data domain is one product. Another product we have, it's one product in one pattern. So that's like a storage drive for your Kubernetes cluster. Another pattern we have is to use Avamar. So Avamar is another one of our classic on-premises solution. It runs specific agents and it can do the backups for you. It does consistent state backups for your databases and other workloads. We can integrate Avamar clients inside of Kubernetes as a sidecar. So instead of having this one drive and a job that you mount and it runs a particular workload, Avamar client will attach to your running application and keep it in a backup state. So whatever that backup state may be, a full backup, a logical, physical, incremental, Avamar will take care of that for you. It offers you a web-based file level restore so you don't have to restore from a command line or from inside of Kubernetes itself. You do it from a centralized UI. You can also set policies and schedules from that same UI. And it managed workloads across all clusters. So if you have 50 Kubernetes clusters deployed, you could have Avamar running centrally, push out clients inside of your Kubernetes clusters to your MySQL servers to whatever else you're running, and manage data production from a centralized point. And very simply, it just runs inside of that state of set. So we push the client in there and it's running all the time. And then lastly, another product, this is an open source product of ours called Ocopy, pronounced Ocopy, regardless of how you see the spelling. So this is an open source product. It focuses on test dev for both PCF and Kubernetes. And it gives you a UI, a CLI, and an API-driven way to take what we refer to as cloud-native application copies. And that's sort of everything, right? So we're used to traditionally taking a copy of the database and you say, oh, the container and the container image, I'm backing that up separately. Ocopy tries to merge all these things together. So the container code, whether it exists in Artifactory or some container registry, the container metadata, so all the environment variables and bindings, any attached storage, and then any data stores. It kind of clumps all these things together and takes a snapshot of it. And this is important in a lot of ways. You could think of some production use cases. But one of the ones that we were focused on is if you want to take a snapshot of something in production, let's say you have an app running in production, it's attached to a MySQL database, you have some bug on it. Well, why not take a, you know, when you fix that bug, why not take a snapshot from production and test that out in tests or dev or staging before you push the change to production? That's one of the main use cases for it. But there are a bunch of other use cases that you could do. Again, third pattern that we have for integration in Kubernetes. And this is on GitHub, so feel free to take a look and contribute and open PRs, open issues, et cetera. So I'm going to leave this shout-out slide up and ask for questions. I know I spoke a ton. So any questions? Let's see if this guy works. Louie? I don't know how to work it, so you got to figure that. I have a very similar, so what's the data to me? Yes. Defoe? So you have a bunch of different options. So in the data protection division, we have a ton of products and they all integrate with each other. So in data domain, there is a data domain centralized UI that you could use. And exactly what you said, I think the gentleman that was speaking before me was talking about they have seven-year retention policies. They have to keep the data for long. In cases like that, you would handle inside of the data domain UI and pushing copies back and forth between sites and clouds. That would all be done there. Yep. You could do it, you could do it, whatever you want. Yep. Any other questions? We got two. Okay. Well, thank you very much for joining.