 Hello everyone. Can everybody hear me okay? Excellent. Well, I must say this is a little different. I'm so used to seeing everybody's heads behind a Zoom screen. So yeah, it's weird being back out on stage. The last time I was at an OpenStack summit doing an OpenStack presentation, I actually surprised the audience with an impromptu karaoke session. Now, Mark Tin decided that wasn't a good idea for this one, so I apologize. There's no karaoke today, which is a shame because they could have called it carry low key. Pause for laughter. I'm meant to read that out. Okay. So instead, we're here to talk about backup, which I appreciate isn't the most sexiest of topics. Or is it lower the lights, cue the barry white music? Actually, no. Mark Tin actually decided that was a bad idea as well, which is a shame because I could have called the talk bringing sexy back up. Pause for laughter. There you go. Just warming you up. Okay. So I'm here to hopefully change your mind or certainly bring you into the world of cloud native backup protection. I'm Kevin Jackson. I'm a principal solutions architect Trilio. I'm going to introduce you to the wonderful world of backup and recovery and how current or old practices of backup or recovery doesn't really lend itself well into the world of cloud native data protection. So let me begin. If it will move on. So let's start with the traditional common view of data backup and recovery. So the whole idea of backup is the fact that you take essentially a copy of your data. And in the event of anything going wrong, obviously there's a lot of sad puppy eyes when things go wrong. But the idea is if anything goes wrong, you should be able to take that data and then do a recovery. And then data recovery is essentially, I guess, a paste operation. You've got the copy of your data and now we're putting the data back into production, back into development. Wherever that data is needed, it's important for people. And look how happy those people are. They've just done a recovery of the data. So all is well in the world. They're absolutely elated. But in the world of cloud and cloud native, this is unrealistic and ineffective. And in fact, if I go back, you actually see that those guys aren't actually elated. They're actually just laughing at you. That's the storage team saying, haha, I know we've just backed up your sender data, but it's now up to you to then paste this data back into production and stitch this data back together again. They're laughing at you. But the problem is backups are a requirement. There's regulatory backup requirements. There is just process requirements. There's a lot of requirements required around data protection. So we can't avoid the topic, regardless we're talking cloud, cloud native. And honestly, when we start talking about, hey, I don't need backup, I can sure as hell guarantee that you will need backup and recovery at some point, even if it is A plan Z. Because there's consequences. So this was from a recent survey. And, you know, top line item there is, you know, people do go out of business because of data loss. And that's either because of reputation reasons. It could be a security breach. You're getting fined. There could be just extortion attempts based on the data that somebody's managed to get out of your organization through whatever has occurred that has caused the downtime of your environment. So I'm going to teach you a few things today. I work at Trilio. Trilio exists in the world of cloud and cloud native because there is a different mindset that's needed and a different approach to cloud and cloud native data protection. So first and foremost, data protection obviously is important. You're all in this room today because you agree that data protection is important. Or it's either because this talk was just the best of a, I guess, maybe a bad bunch, or the fact that you want to win that 200 euro Amazon gift card. Either way, I'm going to take the approach that you all agree that data protection is important in your particular world. But cloud native architecture, the way you deal with cloud, the way you use cloud, that requires a completely different approach to your, the idea of data protection. It has to include the application as well. Legacy backup architecture is just not aligned to how you would use cloud. You chose cloud for a particular reason. You chose it for the speed. You chose it for the agility. You chose it for a lot of reasons. And the last thing you want is to deal with a service which is at the side of your cloud environment. You need to have it part of your particular platform. So I'm here today to tell you that putting data protection services directly into the architecture itself will start to open your mind as to how you can consume a service like Trilio and the fact that it's native to the actual platform itself when it comes to data protection. And get to a world where you will start to see that backup recovery is just a feature of tools that are native to these platforms that are able to take data and applications and move them around to wherever you want to. If you think of backup recovery, all we're doing there is essentially moving data. And it sits, I guess, half stale on some storage somewhere. I'd rather put that data to some use. So let's start with the view or the problems with the existing landscape of backup and recovery. Typically, and I'm not saying it's all, but typically, they are agent-based. Now, if you think about your cloud world, I don't know what to begin. This is like a big topic of like managing agent-based solutions in a scale-out cloud and a very dynamic architecture. Because there's a dependency on, I guess, that guest with the agent talking back to a service that's not under your control. Again, the whole idea of cloud is the fact that you are consuming a platform which somebody has decided to give you some control over your applications, your infrastructure, and suddenly you lose that control when it comes to backups. Very specifically, if we think of the world of OpenStack, so hopefully there's a handful of people at least in this room, I'll appreciate OpenStack, that if you think about an agent-based solution, so anything that runs inside a VM, the traffic would traverse through neutron services, so your network service. And that doesn't exclude your data management service, your agents. So that traffic has to flow through your neutron-based networking. And so if you take that a little bit further, start to envisage that networking in your head, you'll realize that that network really was predominantly designed for your front-facing traffic. I appreciate you can put a number of networks in place, but even in that kind of conversation, you start to think of now I have to treat backup as separately, I now need to think of this extra thing just because I need to support this legacy backup solution. Typically, it requires a mothership, something to talk to, this service that sits outside of the environment. From a cloud architect point of view, that's a separate service, that doesn't scale with your OpenStack, it doesn't scale with your Kubernetes platform, it's something that another team has to manage. Requires somebody to manage this. I don't know how skilled up that backup administrator is, and I appreciate there's people in the room which are very, very highly skilled, but you're asking a lot from their skill set. They manage backups, they know how to do backups, they now have to understand Kubernetes, they now have to understand OpenStack, they now have to understand your application, they now need to understand what recovery looks like when it comes to recovering that particular application. And if they don't, they're just going to give you the data, it's up to you to figure the rest out. Yes, media service has a limit on the control of the agents, that's a scale problem. And ultimately, yes, there are a few small exceptions to this, but yes, we will be, I guess, just only backing up that data. Honestly, when it comes to cloud and cloud native, it's much more than just backing up those volumes when it comes to recovering your environment. So, I'm going to introduce you to TrilioVolt. So, a lot of you I know have recognized the faces you've all come to our booth today, so thank you very much. We've had some fantastic conversations. We've only had some short conversations. We're going to introduce you to the six core tenets of TrilioVolt data protection platforms. We have basically three products, but two applicable to this particular event today. And they all share the same design principles. Number one, we are agentless. So, the service that you would get from Trilio, it's a service, it's better software, you'd install into your open stack environment, you'd install into your Kubernetes environment as an operator and manage through CRDs. But ultimately, this is a service which is designed for that platform and solely for that particular platform. So, even if you take nothing away from this particular talk, we've got a service which is essentially a missing service from those particular platforms. If it was there from day one, you'd be consuming it from day one. But we are agentless. We don't ask you to make changes to your applications just because somebody needs to fulfill some GDPR requirements. You can perform a backup immediately after an installation. It's non-disruptive as well because we're part of the infrastructure, we're able to get access to the relevant components and all the things we need to support and the most important aspect of a backup, which is the recovery. So, we're able to get all this without impacting traffic. Now, of course, there are various scenarios where you'd want to interrupt that traffic. We support that as well, but out of the box by default, we are non-disruptive because we're able to get access to, say for example, an open stack. We're an open stack service, but of course, we know how to talk to Cinder. We know how to talk to Nova. We know how to talk to get access to your disks without interrupting that service. We're not doing that pause just because you're very aware of when I do a snapshot in basic Nova, it pauses the VM. We don't do that. We exist because of your shortcomings like this. Of course, we're multi-cluster, multi-tenant because we're designed for those particular platforms. It would actually be quite a product mistake if we have a platform designed for open stack and it's a single user platform. Of course, we're multi-tenant. So, it's backup as a service. It's a self-service backup recovery fully integrated into the UI of open stack that you love and that you always use every day. When we talk of UI as well, it could even be the command line or the restful APIs. Again, always think of us as genuinely part of the actual platform itself. Scalable and obviously infinite scale. Infinite is obviously a very big, big, big number. But scalable, let's just take that word. So, of course, we're scalable. I just told you we are designed to be deployed literally as part of that particular platform. You are managing your Kubernetes. You are cloud administrators. The last thing you want is to go, okay, how come I can't take backups? Oh, it's because my media server needs to scale. That's a different team. With Trilio, we're deployed as part of open stack. We're deployed as part of Kubernetes. So, you naturally don't even have to think of us as we start to scale. I appreciate it. I'm an architect. You obviously have to think of something. Maybe it's the storage. But ultimately, we scale in line with how you would expect to manage that platform. You don't have to think of us and pass that thought over to another team. Lastly, this is a very important piece. We write out to open source format data. Now, it might not be that apparent to everybody in room why I'm calling that out immediately. But there are a number of properties to use in that particular backup schema. The data we write out is QCOW2 for those that want to go down to the lower level detail. That supports a number of great properties. So, if you're very familiar with the low level, you know, it allows us to support things like incremental backups. It allows us to support things like encryption. And it does it in a very efficient way because it's part of the platform, certainly in the world of open stack. And we've adopted that for our Kubernetes platform as well. But it is all open. You get access to that data. And I don't mean that in a world of, oh, my God, that's a security breach. At the end of the day, we can have the same conversation around how you presented Cinder volumes to the environment. So, obviously, only trusted users have access to the back ends of your systems. But this format that we write out to allows special use cases of that particular data. And arguably, that's really the one of the crunch points of this particular talk is the format of the data and gives you the flexibility of where you need to recover your data. We support this across a wide variety of platforms. Obviously, specifically, we're talking open stack today. We're talking Kubernetes, support Kubevert. And for those a little bit, I guess, more old school or bleeding into the Kubevert world, which is Red Hat virtualization. We have products for all three. And that is why we are successful. And when we say it is integrated and it is a service designed for those particular platforms, I'm definitely not lying. So, when it comes to open stack, we're just another one of those services. So, again, if I've bored you today and I have a little bit of a massive soft spot for open stack, obviously, I'll talk for hours. And I appreciate I'm probably between you and some beers right now. So, I appreciate I won't go on for hours about how much I love open stack. But ultimately, Trilio is just another one of those open stack services. Genuinely just another one of those open stack services. So, just like you've got a Nova, just like you've got the Neutrons, just like you've got the Glancers, the whatever services you add into your cloud to make it successful, you can now add Trilio as one of those services. It's literally just another one of those particular services for open stack. We're showing up in the catalogue. We're a part of the when you do your endpoint list and we'll be integrated into Horizon. Switch over to the other world. So, if you've got the world of open stack, you've got Kubernetes maybe running on top of open stack or even at the side, completely agnostic to Kubernetes. We're an operator and you manage us through CRDs. So, for those that are familiar, what that actually implies is the fact that we're a pure software installation, in fact, for both solutions. And in the Kubernetes world, you can orchestrate the installation. Everybody knows you can orchestrate the installation Kubernetes as well. So, now you've got a world where you can just completely have a enterprise protected Kubernetes platform just from the word go. And we're able to protect the workloads without any changes into the environment, and people can continue to use their favorite tools to manage Kubernetes. But we also have a multi-cloud UI as well, which I'll show you shortly. But let's bring it back home in terms of the reason why I have an excuse to use the word Loki in my talk. So, we start off in the world of open stack. So, obviously, open stack, again, I've been an open stack architect for years and you'll appreciate, honestly, it's a nice feeling that I can break down or can compress open stack into one single box. But anyway, so, we've got open stack and we've got some storage. And obviously, in open stack, so, we're deploying some virtual machines into there. I mean, that could be bare metal servers. It could be whatever. But in this case, it's virtual machines. And then on top of the virtual machines, you can deploy whatever you like, of course. It's the reason why you chose cloud. In this case, we've got Kubernetes running on top of the environment. So, at this point, you've got a whole array of services that your users can consume on this particular platform. You've got the ability to scale out your Kubernetes platform because you've got open stack under the hood. That's the reason why you chose running open stack on top of Kubernetes. Kubernetes is on top of open stack. And, well, if we're talking Rantis, you've also got Kubernetes on top of open stack. And maybe you're crazy to put Kubernetes on top of that. I don't know. Morantis, I do love you, I promise. But ultimately, we have open stack. We've got Kubernetes and we've got Kubevert as well. So, you've got the whole world at your feet. Now, of course, we're here because Trilio protects all these environments. And like I said before, again, I can go into a lot of detail and I promise you I will not. But there are services that are, this is not a SaaS service. I don't want anybody to walk away thinking, how do I sign up for the SaaS service called Trilio? It's not. It gets deployed as part of your architecture because that's how you can take advantage of what I'm going to show you next. So, we're able to back up your Kubernetes workloads. So, this is a given, right? So, we're in the world now where Kubernetes is mature enough where storage is a little bit more sane than it used to. And so, we're able to bring in workloads that you wouldn't ordinarily expect to run into Kubernetes. We saw it in open stack and obviously we're sure as hell seeing that now in the Kubernetes world. So, we're now able to back up those workloads. But the key thing is, remember I said about that open universal schema? Well, we're able to then recover, restore those VMs, those containers, the persistent volumes, all that metadata to a completely different Kubernetes cluster. It doesn't even have to be the same distribution. So, our software solution manages that because I guess the secret source behind the scenes on how we do the recovery is orchestration. And I want you to take that away. That's one of the key principles of why we need to see backup as more than just backup and recovery. Same with open stack. We're able to take backups of those virtual machines, the virtual networks, all the stuff that your tenant owns. We're able to take them and store them safely outside of the open stack environment. And then when it comes to recovery, yes, you can do the one-click restore. Like, you've totally trashed your tenant network space and we're able to recover those volumes. We're able to cover that network. Yes, we capture the network information as well. We capture a whole range of information such that you can just do a single-click restore and then do a recovery of that complete environment. But it doesn't have to even be the same open stack distribution. It doesn't have to be the same open stack cloud. Again, I want you to get into the idea of what we do when it comes to recovery is orchestration because that then just opens the doors. I've taken advantage of, you see us, more than a backup service. We're now an engine that can do portability and migration of your applications. Backup is just literally migrating and then just goes to some storage to ultimately maybe die. So, how full integration? So, of course, obviously just a snapshot of a random horizon interface there. But you can see that on our booth. You can see a demonstration of that. But also, we have our own user interface as well for Kubernetes. And again, I don't want you to take away from this. This is something that runs at the side. This isn't a SaaS service. This is a service that gets exposed just as a normal web service from your Kubernetes platform. It gets deployed into your Kubernetes world. It could be behind, completely behind any mean lines deep in a gap environment. There's no callbacks to home. So, it's all self-contained as part of your world. Now, given the fact that, yes, I talk about the user interface side of things, that's really nice. So, again, for familiarity and consistency, it's very nice for users to be able to log into Horizon and suddenly see the fact that they can back up their workloads without having to pick up the phone or raise a ticket to do so. But ultimately, I think arguably that, you know, the way to take greater advantage of a service, which ultimately, from the outset, is backup or recovery. But to see it as more than backup or recovery, it's all about automation and orchestration. So, like anything in OpenStack, yes, you can orchestrate this from start to finish. Why would Trello be any different? We're just an OpenStack service. So, we're not. Pick your favorite tool to say, OK, go and perform a backup because I've just checked in some code. Same with Kubernetes. Just carry on using what you're used to. You can now just protect using simple YAML or however you want to define your backups and just say we're now protecting these particular environments through orchestration and automation. But that orchestration and automation essentially leads to a greater appreciation of Trello and the why I arguably would say that we are more than backup or recovery service. So, let's look at the, I guess, the evolution of the use cases around backup. So, it started from, you know, that very first slide. You know, the typical view of the world is a, we'll provide a backup and recovery service, which is fine. But ultimately, at that point, we're already in like day two operations. You've got things deployed. You've got your engineering team is set up. Everything is running. We've now just got to tick that box to say, hey, I just need to backup and recover these workloads if the proverbial hits the fan. So, that's fine. We support this and we support this in a fantastic way because we're natively part of that particular platform. However, you're missing a huge chunk of why you would choose something like Trello. So, we've looked at like day zero kind of operations. So, you develop a kind of like world. I said to before the fact that we've got this engine, which allows you to take your applications and your data and ultimately, again, from the outside, you'd be saying, okay, I want to store these external to my environment. Just in case anything goes wrong, I can recover these particular applications. But if you have a requirement, again, slightly removed of, you know, just even if you took Trello out of the equation, there are times where you need to be able to test your application on various platforms. There's a requirement to test your applications and your data running on a public cloud. Maybe you're changing some kind of storage. Well, it wouldn't be best if you didn't have to re-engineer every time. I appreciate engineers and developers. Honestly, they are very, very smart, capable people. You don't have to reinvent the wheel if something already exists, especially if the fact that you've already decided to use us for day two operations. We are just an engine. You can orchestrate us. So, in this case, you can deploy your application. You can deploy this internally. You can deploy this to Amazon. You can deploy it as your GKE wherever and do all your testing. And we'll be able to recover those into the appropriate environment, all through orchestration or through the user interface as well. Take this a little step further. Just as part of the ongoing operations of your environment, this is a world where you can start to think of essentially pulling triggers to do something with the data before I don't know, code gets released. So, let's have a look at that kind of example. So, this is a world, of course, you know, the typical I have to deploy. So, if I have to make a change to an environment, I've got down here production. Honestly, whatever production means to you, it could be your development environment. And I appreciate that's not production care, but it's whatever is live and is important to you. You need it to run your job. This is a world where, for example, we're going to check in some particular code. It goes through all the normal process of your CICD pipelines. And what does the CICD pipeline do? Of course, it calls multiple services. Trilio is just literally one of those other services. Again, if you treat us as just a backup tool, you're going to miss these opportunities. So, this is a world where I'm about to make a change to the environment. And again, I appreciate this is obviously a basic example. But before we make a change, orchestrate a backup, an incremental backup, a small change backup of this particular environment, and we can store that safely external to the environment. So, normal CICD, you know, normal stuff just gets deployed. And that point and everything is all good until it isn't. So, at this point, there's a decision that has to be made. Again, there's various ways to get out of this particular problem, but we've got Trilio installed. So, at this point, again, there could be red-green testing, whatever it is, or sorry, some kind of like automated test to say, okay, there's a failure. You can orchestrate the recovery. Arguably, it would probably be somebody pressing a button on this. And then you can just recover that particular application using Trilio. And you're back to square one. It's back to your developers. And then they will fix that bug. And then the cycle begins again. Again, we're just an engine. We just so happen to be able to provide and started off life as backup and recovery. CIS is more than just backup and recovery. But we can take this a step further as well. So, at the CubeCon a couple of weeks ago, we've got a new feature called Continuous Restore. So, away from the developer kind of like world, yes, we're in firmly into day two territory. We're talking worlds of disaster recovery kind of worlds. So, this is a world where you can, you know, there's challenges of running, in this case, say Kubernetes across multiple environments. So, some people have in multi-cloud Kubernetes strategies. Some people don't like it. Some people love it. Honestly, I know there is a complete split on hybrid cloud and multi-cloud as a way to go. However, when you do decide that, there's a tool that will fulfill your, you know, the ability to do this. But in terms of disaster recovery, everything in cloud, everything these days is instant. Everything that you do on your phone is instant. People get really, you know, I think what, shopping carts get abandoned if you're waiting more than like a few seconds, four or five seconds before, you know, something gets returned. It's ridiculous the lack of patients that we have. But it's the same with disaster recovery as well. And of course, in that case, it's not just a case of somebody getting frustrated. Yes, ultimately it is. But ultimately, your business is losing money. So, what we've done is been able to reduce the time for, well, certainly the recovery time objective. And I'll show you how we do this, where we were able to pre-stage the data so recovery is almost instantaneous. So, of course, that brings, you know, our tool allows you to vastly reduce this recovery time objective because the data is already there waiting to be consumed when you flip over as part of disaster recovery. And there's various ways you can consume a tool like this. I'm just using the DR kind of world as an example. So, this is a world where I've got my private cloud. I'm backing this on a schedule. And we can deploy this to multiple clouds. So, again, here, again, this isn't anything which is strange. We're able to pre-stage this on whichever cloud you're able to deploy. So, you might be, this might be part of not even disaster recovery. This could be a test. You might be moving to EKS, AKS, wherever it is. So, we can send data there. And we can add basically as part of the ongoing continual restore process, we're essentially patching the data on that target cloud. So, every time an incremental gets changed, that small incremental gets sent over to that cloud and it's ready to be invoked as part of whatever that changeover is. It could be part of testing. It could be part of disaster recovery. And you can pick and choose your applications. We can send multiple applications over at once. Other types of use cases involve things like bringing data from the edge. You might have multiple small clusters and you're trying to consolidate this. And you can send that incremental data centrally. So, we can do this in reverse as well. So, we're coming up to the end of my talk. And I started with the notion of the fact that, yes, everybody talks of back of recovery and it's always that category of almost as an afterthought. It's that requirement that, you know, it's a checkbox exercise and people come to us saying, okay, we've now done all this work. Do you have a solution for all this magical stuff that we've done? And honestly, when people bring us much earlier into the conversation, we start to have very, enjoyable conversations around disaster recovery. In other words, application owners and platform owners don't have to over engineer the solution. We've already solved part of those solutions for you. We give the ability to do application mobility, that format, the ability for us to take workloads out of OpenStack, out of Kubernetes, have it in a format which allows the recovery to wherever you need it to be. You know, whether it's an on-prem OpenShift or it could be a particular flavor of OpenStack and you're fed up with paying the support contracts, so you're going to go over to some other competitor. Hey, it does exist. And you can use a tool like us to actually move those particular workloads. And I've not even touched on things like ransomware protection. So, obviously, that's for another topic. But ultimately, we obviously play a part in the world of ransomware protection and recoverability, more so in the protection and the recoverability aspect, in the fact that you need to trust your backups to recover from things like malware events and from ransomware events. And so, by using, again, just very quickly, just using things like immutability and encryption, you know, we are now certainly not a weak link when it comes to attackers getting access to that data. Again, that's the last thing. And people do that. That's your backup tool is a target for those ransomware and those malware attacks. So, that brings me to the end. So, looking at the time, oh, I proposed this is okay. I usually talk too much, by the way. So, that's just a small admission. But it looks like we got to the end and this is good. If you want to know more, there's a lot of intelligent people on that booth. I'm just there to look pretty. And we are, you know, people who come to the booth and they get scanned, they get entered into an iPhone 13. If you don't like the iPhone 13, you can still win it. Just sell it on eBay and buy your Android. So, and finally, so maybe some people in the audience are just here for the Amazon gift card. So, that's fine. I'm okay with that. It's not my money. So, we've collected a number of names throughout the day. If you hadn't, I apologize. It was part of the, if you scan the QR code. And so, I've got in front of me a list of users. A list of users, sorry, you're real people. A list of people that, sorry, you're just resources to me. No, you're not. And I'm going to read out the winner. So, for the winner, and hopefully they're in the room today, so fingers crossed, the winner of the 200 Euro Amazon gift card is Pravar Gorba. Hey! Yay, worked. Excellent. So, it's going to be any gift card. So, obviously, we'll email you. But if you come by the booth, we'll just make sure that we've got everything, you know, all the details and stuff. So, thank you. Thank you. Thank you very much, everybody. Hope you enjoy that. I get your tattoos as well. Do you get your tattoos at our booth as well?