 Hi, this is Yoosafin Bhatia and welcome to another episode of TFR. Let's talk and today we have with us Chris Maldsted, Customer Success Architect at Ondat. Chris, it's great to have you on the show. Thank you very much for having me. Lovely to be here. Yeah, it's my pleasure to host you today. Let's talk a bit about we have covered Ondat so many times, but it's always good to refresh memories of reviewers, what is Ondat all about. So talk about it. So Onda is a container native storage solution. So we work with Kubernetes. So Kubernetes back in the olden days, didn't really have any kind of storage solutions and it's been through a few iterations, but now has a kind of a CSI. So a container storage interface plug-in where you can plug your own storage solutions into there. And Ondat is a software-only solution. So you install it into your Kubernetes cluster. So it's a Kubernetes native solution. And we can make use of any persistent storage that we have in the cluster. So you can take, you know, your hyperconverged kind of on-premise bare metal machines and turn them into a storage array that scales with your Kubernetes cluster. Is there any difference when you say container native storage versus cloud native storage? And if not, why? I guess I would define the three words and kind of a continuum. So traditional storage, I think everyone, or at least in my mind, they think of it as kind of like a storage array. So it's something external to whatever you're powering. Container native storage in my definition is something that runs anywhere Kubernetes runs. So you can take the solution, you can run it on EKS, GKE, AKS, OpenShift, Rancher, whatever your Kubernetes distribution of choice. And I think the cloud native storage, I think that's a solution that's native to the specific cloud that you're running in. So I would have to, I mean, I think today we're going to talk a bit about a report we've done as well about EBS storage. So that would be the elastic block storage. And that storage is native only to Amazon web services. So you can only find it on the Amazon cloud, for example. You don't get the equivalent solutions and specifications and performance and stuff on any of the other clouds. That would be my definition, because I think it's very fungible, depending on who you speak to out there at the moment in those terms. When developers are looking at container native storage solutions, what are some core or primary requirements that are there, which you can also compare to the traditional or legacy storage solutions as well? I think when you look at Kubernetes, the reason people like Kubernetes is they like the abstractions and the developers like the abstractions. So this kind of idea of a pod and this idea of scaling. But they also like the way that everything is very declarative. So I can define this application. I can define this software, this end-to-end business kind of goal I'm trying to achieve, and then pods and load balancers and all these other components will spin up on demand and then disappear on demand. So for me, if you're going to talk about container native storage, the primary requirement you should be looking for as any development team is this dynamic provisioning. So if I have a pod and that pod wants to request a persistent volume claim. So I'd like to lay claim to 10 gigabytes of storage and that storage should be read right once and it should be based on a storage class that's backed by fast NVMe or slower spinning traditional, you know, spinning disks, then as an application development team, I want to be able to kind of, you know, knit the right thing to the right application for the right requirement with just by, you know, in my application workflow, my development workflow, just saying, hey, I'm just going to define it into my application spec. And then I can throw that at my Kubernetes cluster and my storage will respond in exactly the same way to all the other components that I need to actually provide a business solution. I also want to talk a bit about, because no technical or technological solution is kind of, you know, sufficient enough, you know, is there's no business value there. Talk a bit about what are the, not only benefits for technical benefits, but all the business benefit when we look at container native storage solutions versus, you know, other solutions. Yeah, in addition to the kind of developer workflow, I think when you look at the traditional storage, there's a few things that traditional storage solutions have provided. And by being software defined, it's very easy to kind of add more features and turn those features on and off with just very simple kind of labels or feature flags in a Kubernetes kind of terminology. So you can define a storage class in your Kubernetes cluster and say, actually, my developers, this application that they're writing, it's really important and business critical. So I'd like them to replicate that data between multiple nodes. And oh, by the way, those nodes should be in a different availability zone. So if we lose power or we lose a machine hall or we lose, you know, one of the availability zones in the cloud terms, we can survive an outage of that component and, you know, traditional things which we then move into things like, you know, sensitive and personal information and regulations. You know, we must encrypt that data at rest. So we must be able to turn on a per volume way different levels of encryption and different encryption keys. So I think the key benefits, not just for the application development team, but also for, you know, the people running the platform, is that ability to be able to turn on all these different features and functions just by the simple labels and saying to the developers, hey, if you want to replicate this data and encrypt it, you know, encryption, everything encrypted needs, you know, more processing power to encrypt and decrypt data. There's always a trade-off that you have to make there. And replication, there's always more kind of storage you need at the back end to store more copies of the data. But you can just turn up those features and turn down those features very, very simply and say to the developers, hey, here's a very cheap, very, you know, low resilience, low scalability, low robustness kind of storage for development use. And here's a really high quality, or not quality is probably the right word, here's a really high feature, rich piece of storage which has got inter-availability zone replication. It's got encryption with it and it's backed off to a key management system. So it's going to pass, you know, regulations like a PCI and those kind of regulations. And it's also got, you know, availability zone protection so we make sure the replicas are in different availability zones so we know that everything's in the right place. So it's very easy with their software-defined components to just mix and match and give different people different capabilities all backed by, you know, the single storage solution that you're using in your Kubernetes cluster. Can you talk about how mature is this market now? Because on that, you folks yourself, you know, rebranded, you know, the company name changed because the market is evolving, market is changing. So where do you see VR when it comes to container, you know, native storage, Kubernetes storage? Is the market still mature? Are we still, you know, in the process of, you know, maturation? I think the solutions out there in the market now are actually very mature. I mean, on that has been around for about seven years now as a startup. And you look at, you know, the recent benchmarking report there's about four or five options out there some of which have been around even longer. I think what's changing in my view is that the industry maturity is changing. So I did a recent talk at KubeCon with some of the enterprise DB team and we were talking about how to run Postgres on Kubernetes. And the really interesting thing there is seeing companies who are data-first and data-orientated then now pushing their cloud native Postgres solution as, you know, the primary mechanism for running Postgres at scale. And in a previous employer, I was working on a, with one of the large retail banks in the United Kingdom and I saw a core banking application which was being delivered as a Kubernetes native application. So core banking, you know, in my mind 20 years ago would have been a mainframe only approach and mainframe only system. And for me, the big change in maturity is about actually applications and it's actually the business and the independent software vendors. Those are the people who are changing actually saying, hey, we've seen the benefits of delivering everything in a Kubernetes way. We want to deliver the data component of our application and our solution in that way as well. We have been mentioning that report that you folks did with Architecting IT. Talk a bit about the goal idea of the report and if you can share some of the key findings which help not only you to improve the project but also to get a better understanding of the ecosystem. There's actually a couple of reports that we've done recently. The first one was there was a report about a year ago that was done and this was a report where we actually looked at or was looked at real-world benchmarking applications. So rather than doing a synthetic FIO, so FIO is a standard Linux tool which is written by the gentleman who maintains the storage subsystem in Linux. So rather than using this synthetic workload, it was actually taking real-life workloads to taking Postgres, Redis, Mongo and actually running those workloads and running the actual benchmarking tools for the applications. So actually saying, you know, how much transactional volume can I actually get through this storage subsystem and that benchmark was done using the same pieces of hardware, the same pieces of equipment every time. So it was normalized to a set of infrastructure so everything had the same resources. So it's how much workload, so how much money do I have to spend and bearing in mind, if you think about this, this is a hyperconverged solution so you're kind of running your Kubernetes cluster which is running your application. It's also running your storage subsystem so it's a really good measure of how efficient, you know, these storage solutions are and that was the first one and the second one which we've done recently was all about looking at different storage solutions in the AWS specifically in the cloud and how do we run different storage solutions at scale and that was fascinating to me because I think a lot of people over the last five, six years, the biggest conclusion I took from this was I think people have been accustomed to taking the core cloud services off the shelf so they'll pick up AWS and they'll say, for storage, it must be EBS, it must be the Elastic Block Service or it must be EFS, it must be the Elastic File Service. Those are the two solutions for storing ReadWriteOnce or ReadWriteMany kind of components of data. What we found out was if you kind of take those building blocks, there are some features that are available in one so EBS, for example, you can't do replication between availability zones so you need to do that at a different level in your stack whereas we found with using these software-defined storage container-native storage solutions specifically, you know, on that as we were using on that in the benchmarking report to provide that testing we saw that we could survive, you know, availability zone outages so you could take applications which maybe weren't cloud-native applications which weren't availability zone which didn't have replication built into them and you could take those more vintage-style workloads and you could actually build them into a Kubernetes cluster and survive availability zone failures. And I think the other thing as well which was really fascinating and I'm intrigued to see where we go in this space because I do see a lot of interest in this and did see a lot of interest in this from KubeCon as well is by taking the core components so taking machine types like the I3ENs or the I4Is so these are machine types which have got NVMEs, local NVMEs in them and these NVMEs are rated at tens of thousands or hundreds of thousands of IO operations per second and what was really fascinating was looking at workloads so, you know, we started to see a lot of blockchain workloads with massive amounts of storage and data bandwidth and data IOPS you can actually build solutions on Kubernetes clusters using those building blocks which give very attractive price per operation or price per gigabyte or price, you know basically if you're speed constrained there's some interesting bits and you can start to see where I think there's a lot of more agile start-ups and a lot of more agile companies who are looking at the kind of the established as a service offerings and the cloud providers and saying actually, you know, we can build really innovative solutions just by taking the, you know, the composite bit to these cloud providers and actually we'll do it in Kubernetes because we understand Kubernetes we know how to deploy applications in that we need a persistent storage layer and actually, you know, solutions like on that we can install that into our Kubernetes cluster and bam, we've got inter-AZ replication, we've got ability to recover if we have an outage, we can turn on encryption of data at rest so we can provide solutions which meet regulations like PCI DSS and suddenly we can build a solution which we can have up and running in a few days, a few weeks and you compare that to, you know I mean there's a different level of maturity in resilience and scalability compared to the as a service offerings as they are but you can start to see people building niche applications left, right and center using these building blocks that's the real interesting thing I took from this Chris, thank you so much for taking time out today and talk about container data storage, the whole evolution of market and I really appreciate you sharing those insights and I would love to have you on the show again, thank you absolute pleasure, love to be back thank you very much