 Live from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019. brought to you by Red Hat, the CloudNative Computing Foundation and ecosystem partners. Welcome back to theCUBE. I'm Stu Miniman, my co-host Corey Quinn, 7,700 here in Barcelona, Spain for KubeCon CloudNativeCon. Happy to welcome to the program a first-time guest, Aaron Boyd, who's a senior principal software engineer in the office of the CTO of Red Hat. Aaron, thanks so much for joining us. Yeah, thanks for having me. All right, so just a couple of weeks ago, I know I was in Boston, you probably were too, for Red Hat Summit, taking into a lot of the pieces. You focus on multi-cloud and storage, just to tell us a little bit about your role and what you're doing here at theCUBE. Sure, I'd be happy to. So for over a year now, Red Hat's really been kind of leading the pack on hybrid cloud, allowing customers to have more choice with both public and private cloud offerings. And of course, OpenShift being our platform built on Kubernetes, we believe that should be the consistent API in which we have federation. Yeah, so Aaron, I got to talk to quite a few OpenShift customers at Red Hat Summit, was really how they're using that as a lever to help them really gain agility in their application deployment. But let's start for a second, without getting too pedantic, you say hybrid cloud. What does that mean to your customers? Red Hat has a long legacy of, you know, RHEL lives everywhere. So public cloud, private cloud, hosted provider, all of the environments, you know, Red Hat Enterprise Linux can live there. So in your space, what does hybrid cloud mean? So hybrid cloud I think follows a model of RHEL. It's everywhere. So it's, you know, having OpenShift run on top of that and being able to have the application portability that you would expect. Along with the application portability, which is my focus, is having the data agility within those applications. All right, how do you wind up approaching a situation where an app is now agile enough to move between providers almost seamlessly without having it, I guess, descend down to the lowest common denominator that all providers that it's on are going to provide? I mean, at some point, doesn't that turn into treating the cloud as a place to just run your either instances or containers and not taking advantage of, I guess, the platform level services? Sure, so I think that the API should expose those choices. I don't think it's a one-size-fits-all when we talk about, you know, if you move your application, maybe your data doesn't necessarily have to move. So part of the core functionality that Federation is meant to provide, which has been renamed CubeFed since Summit, is that you have the choice within that and defining policies around the way we do this. So perhaps your application is agile enough to span three different clouds, but due to data privacy, you want to keep your data on-prem. So CubeFed should enable you to have that choice. You know, so, you know, help us dig down a little bit in the storage, you know, environment here. You know, I go back, you know, I worked for a very large storage company that was independent before it got bought for a very large sum of money. But we had block and file storage and mostly that, you know, lived in a box or in a certain application. And, you know, the future, we always talk that there's going to be this wonderful object storage and actually it's designed to be, you know, we'll shard it, we'll spread it around and it can live in lots of places. Cloud, a lot of times, has that underneath it. So, you know, have we started to, you know, cross that gap of, you know, that mythical nirvana of where, you know, storage should actually live up to that distributed architecture that we're all looking for. Right, so with Kubernetes, the history is we started off with only file systems. Block is something very new within the past couple of releases that I actually personally worked on. The next piece that we're doing at Red Hat is leading the charge to create CRDs for object storage. So it's defining those APIs so customers can dynamically provision and manage their object storage with that. In addition, we recently acquired a company called Nuba that does exactly that. They're able to have that data mobility through object buckets across many clouds, doing the sharding and replication with the ability to de-dupe. And that's super important because it opens up for our customers to have image streams, photos, things like that that they typically use within an enterprise and quickly move the data and copy it as they need to. Yeah, so I'd actually talk to the Nuba team. I would joke with them that didn't they de-duplicate their name because it's like N-O-O-B-A-A. So, you know, have plenty of vowels there. But right, storage built for the cloud world is what we're talking about there. How's that different from, you know, some of the previous storage solutions that we've been dealing with? So I think before we were trying to maybe make fit what didn't work, that's not to say that file and block aren't important. I mean, having local storage for a high performance application is absolutely critical. So I think we're meeting the market where it is. You know, it's dependent on the behavior of the application and we should be able to provide that. And applications that primarily run in the cloud and need that flexibility, we should be offering object as a first class citizen and that's why our work with those CRDs is really critical. What is the customer need that drives this? Historically, with my own work with object stores, I tend to view that as almost exclusively accessed via HTTP endpoints. And at that point, it almost doesn't matter where that lives as long as the networking and security and latency requirements are being met. What is it that's driving this as making it a first class citizen built into Kubernetes itself through Rook? So it allows us to create the personas that we need. So it allows an administrator to administrate storage just like they would normally with your persistent volume, persistent volume claims and quotas. And then it abstracts the details of, for instance, including that URL in your application. We use a config map within the app so the user doesn't have access necessarily to your keys in the cloud. It also creates a user. So you're able to manage users like you would with normal object, which is a little bit different than the PVPVC. And that's why we feel like, you know, it's important to have a CRD that defines object in that sense because it is a little bit different. All right, so Aaron, is this Rook we're talking about then? Is, you know, and Rook, did I understand? I think got to 1.0, just got released. Yeah. You know, give us the update on kind of what Rook is, you know, how that fits with this conversation we've been having and, you know, where we are with the maturity of it. And Rook, as was on the keynote this morning, you know, is a great CNCF project with a really healthy community behind it. One of the provisioners we've created as part of those objects CRDs is a Rook provisioner for SEF object. We also have an S3 provisioner. So, you know, we hope to have, just like we had external provisioners in Kubernetes, use, you know, allow for the same contribution from the community for those. Okay. Yeah, I remember a couple of years ago at the show, just fixing storage for containers in Kubernetes was something that was a little bit contention in there and there are a few different projects out there for that, you know, where are we with that? You know, we understand that it's never, you know, one solution for every single use case. You know, you already talked about, you know, block file and object and how there's going to be, you know, a spectrum of options. Sure. And so I think there's lots of things to fix when you talk about that. One of the key things that Rook offered was the ability to ease the deployment of the storage and administration of it. And as you know, Rook, you know, has a plethora of different storage systems that it provides. And you know, what we're really pushing at Red Hat, which I think is important is having, you know, operators, like the operator hub that was released with OpenShift 4.0, Rook will be an operator in there. So what that allows is for more automation and true scaling, because that's where we want to get to with Hybrid Cloud. If you're managing 10,000 clusters, you cannot do that manually. So having Rook, having operators and automating the storage piece underneath is really critical to making that scale happen. Forgive my ignorance. When you say that Rook winds up exposing, for example, now an object store underneath, is that its own managed, a pile of disks on a system somewhere that it's running? Is it wrapping around object store provided by other cloud providers? Is it something else entirely? What is the, where do the actual drives that hold my data when I'm using Rook's object store live? So with Rook today, the object storage that it uses is Seth object. So it exposes the ability to create the Seth components underneath, which Rook can lay down and then expose the object piece of that. So that's the first provisioner in there. Yep. Wonderful. All right. So I guess when I think about object storage for years, it's been, well, I've got S3 compatibility and that's kind of the big thing. Is Rook S3 compatible then? Is it giving more flexibility to users to make this the standard in a cloud native environment help us put a fine point as to what this isn't, isn't? Yeah, that's a great question actually. And we get asked it often. So one of the first provisioners we did is just a proof of concept was an S3, generic S3 provisioner. And of course, Seth is S3 compliant. So it also does that, but you know, there isn't a standard for object. So most providers of object are S3 compatible. So we found it very easy to take off the S3 provisioner we created to create the Seth one. There wasn't much differentiation, which means it's a great pattern for anyone to want to onboard. Yeah. Do you find that as S3 itself, and of course it's competitors and other cloud providers become more capable, you're starting to see differentiation. Easy example would be with some of the object storage tiers where there's increased latency on retrievals. In some cases as little as five minutes or as much as 12 hours. Other providers like Google Cloud, for example, or Azure have consistent retrieval times on their archive storage. As an easy example, is that something that you're going to start seeing divergence on as object storage becomes smarter by I guess all of the providers as they race each other to improve their products? Absolutely. I think tiering is one of the facets of object that's really critical. And you know, of course, as we spoke earlier, it's physics. You know, and having data consistency at that very low threshold is important. So you know, using the storage for what it's worth, using the best tool. And pulling object into the ecosystem is part of that. Yeah. Aaron, is there anything that differentiates kind of Kubernetes storage from what people are familiar with in the past? I think Kubernetes storage continues to evolve. The more we learn about how people use Kubernetes and their needs, I think we listen closely to the community and we develop against that. Okay. I guess the other thing is, you know, what kind of feedback are you getting from customers? Where are we along this maturation journey? You know, my history is, you know, I worked when we had to fix networking and storage in virtualized environment and it took about a decade. We're five years into Kubernetes. It feels like we've, you know, accelerated that based on what we've done in the past, but you know, definitely, you know, when it first started it was, you know, let's put stateless stuff in containers and you know, storage will be an afterthought or something that was kind of a sidecar over here where you had your repository. Right. Yeah. And that's the beauty of CubeFed is that in order to have true hybrid cloud and have federation, we have to come together in consensus with both network compute and storage. So it really brings the story full circle. Perfect. What do you think right now customers are having their biggest challenges with as they start wrapping their minds around this new way of thinking as I mean, again, it's easy for a tiny startup that's Twitter for pets or something like that to spin up in a pure cloud native way, but larger companies with this legacy concept known as a business model that might involve turning a profit generally predate cloud and have done an awful lot of stuff on the data center. What are they seeing as currently being limiting factors on their digital transformation? So with Kubernetes just being five years old as we celebrate the birthday today, I think customers are also maturing. You know, they're entering the landscape, learning about Kubernetes, learning how to containerize, you know, lift and ship their applications and then they're running up it to costs, right? And lock in and things they want to avoid. And that's really where we in the community want to provide a platform and a runway for them to have that choice. All right, Erin, any customer successes that you can share with us, either about the operator or about work specifically? Certainly not with Federation. We haven't released it. It will come out in OpenShift 4.2. So we don't have any customer success stories yet, but I would say definitely it's a request and we're asking customers about it and if they're interested and you will find many times maybe they're not familiar with the word Federation, but they're definitely interested in that use case. Okay, how's the general feel? You know, what kind of feedback are you getting from customers so far? Things that you're excited about that are happening here at the show? I'm just excited that Kubernetes is kind of growing up and it's becoming a true enterprise level project that customers rely on and build their business on. Well, Erin Boyd, really appreciate you joining us, sharing all of the updates. Look forward to the upcoming release and definitely get to follow up with you soon to hear about those customers that they start rolling it out. All right, great, thank you. All right, for Corey Quinn, I'm Stu Miniman here at KubeCon, CloudNativeCon 2019, Barcelona, Spain. Thanks for watching the Kube.