(upbeat music) >> Hello, and welcome to Supercloud2. I'm John Furrier, host of theCUBE here. We're exploring all the new Supercloud trends around multiple clouds, hyper scale gaps in their systems, new innovations, new applications, new companies, new products, new brands emerging from this big inflection point. Got a great guest who's going to unpack it with me today, Ramesh Prabagaran, who's the co-founder and CEO of Prosimo, CUBE alumni. Ramesh, legend in the industry, you've been around. You've seen many cycles. Welcome to Supercloud2. >> Thank you. You're being too kind. >> Well, you know, you guys have been a technical, great technical founding team, multiple ventures, multiple times around the track as they say, but now we're seeing something completely different. This is our second event, kind of we're doing to start the the ball rolling around unpacking this idea of Supercloud which evolved from a riff with me and Dave to now a working group paper, multiple definitions. People are saying they're Supercloud. CloudFlare says this is their version. Someone says there over there. Fitzi over there in the blog is always, you know, challenging us on our definitions, but it's, the consensus is though something's happening. >> Ramesh: Absolutely. >> And what's your take on this kind of big inflection point? >> Absolutely, so if you just look at kind of this in layers right, so you have hyper scalers that are innovating really quickly on underlying capabilities, and then you have enterprises adopting these technologies, right, there is a layer in the middle that I would say is largely missing, right? And one that addresses the gaps introduced by these new capabilities, by the hyper scalers. At the same time, one that actually spans, let's say multiple regions, multiple clouds and so forth. So that to me is kind of the Supercloud layer of sorts. One that helps enterprises adopt the underlying hyper scaler capabilities a lot faster, and at the same time brings a certain level of consistency and homogeneity also. >> What do you think the big driver of Supercloud is? Is it the industry growing up or is it the demand for new kinds of capabilities or both? Or just evolution? What's your take? >> I would say largely it depends on kind of who the entity is that you're talking about, right? And so I would say both. So if you look at one cohort here, it's adoption, right? If I have a externally facing digital presence, for example, then I'm going to scale that up and get to as many subscribers and users no matter what, right? And at that time it's a different set of problems. If you're looking at kind of traditional enterprise inward that are bringing apps into the cloud and so forth, it's a different set of care abouts, right? So both are, I would say, equally important problems to solve for. >> Well, one reality that we're definitely tracking, and it's not really a debate anymore, is hybrid. >> Ramesh: Yep >> Hybrid happened. It happened faster than most people thought. But, you know, we were talking about this in 2015 when it first got kicked around, but now you see hybrid in the cloud, on premises and the edge. This kind of forms that distributed computing paradigm that we've always been predicting. And so if that continues to play out the way it is, you're now going to have a completely distributed, connected internet and sets of systems, intra and external within companies. So again, the world is connected 100%. Everything's changing, right? >> And that introduces. >> It wasn't your grandfather's networking anymore or storage. The game is still the same, but the play, the components are acting differently. What's your take on this? >> Absolutely. No, absolutely. That's a very key important point, and it's one that we always ask our customers right at the front end, right? Because your starting assumptions matter. If you have workloads of workloads in the cloud and data center is something that you want to connect into, then you'll make decisions kind of keeping cloud in the center and then kind of bolt on technologies for what that means to extend it to the data center. If your center of gravity is in the data center, and then cloud is let's say 10% right now, but you see that growing, then what choices do you have? Right, do you want to bring your data center technologies into the cloud because you want that consistency in operations? Or do you want to start off fresh, right? So this is a really key, important question, and one that many of our customers are actually are grappling with, right? They have this notion that going cloud native is the right approach, but at the same time that means I have a bifurcation in kind of how do I operate my data center versus my cloud, right? Two different operating models, and slowly it'll shift over to one. But you're going to have to deal with dual reality for a while. >> I was talking to an old friend of mine, CIO, very experienced CIO. Big time company, large deployment, a lot of IT. I said, so what's the big trend everyone's telling me about IT's going. He goes no, not really. IT's not going away for me. It's going everywhere in the company. >> Ramesh: Exactly. >> So I need to scale my IT-like capabilities everywhere and then make it invisible. >> Ramesh: Correct. >> Which is essentially code words for saying it's going to be completely cloud native everywhere. This is what is happening. Do you agree? >> Absolutely right, and so if you look at what do enterprises care about it? The reason to go to the cloud is to get speed of operations, and it's apps, apps, apps, right? Do you ever have a conversation on networking and infrastructure first? No, that kind of gets brought into the conversation because you want to deal with users, applications and services, right? And so the end goal is essentially how do users communicate with apps and get the right experience, security and whatnot, and how do apps talk to each other and make sure that you get all of the connectivity and security requirements? Underneath the covers, what does this mean for infrastructure, networking, security and whatnot? It's actually going to be someone else's job, right? And you shouldn't have to think too much about it. So this whole notion of kind of making that transparent is real actually, right? But at the same time, us and all the guys that we talk to on the customer side, that's their job, right? Like we have to work towards making that transparent. Some are going to be in the form of capability, some are going to be driven by data, but that's really where the two worlds are going to come together. >> Lots of debates going on. We just heard from Bob Muglia here on Supercloud2. He said Supercloud's a platform that provides programmatically consistent services hosted on heterogeneous cloud providers. So the question that's being debated is is Supercloud a platform or an architecture in your view? >> Okay, that's a tough one actually. I'm going to side on the side on kind of the platform side right, and the reason for that is architectural choices are things that you make ahead of time. And you, once you're in, there really isn't a fork in the road, right? Platforms continue to evolve. You can iterate, innovate and so on and so forth. And so I'm thinking Supercloud is more of a platform because you do have a choice. Hey, am I going AWS, Azure, GCP. You make that choice. What is my center of gravity? You make that choice. That's kind of an architectural decision, right? Once you make that, then how do I make things work consistently across like two or three clouds? That's a platform choice. >> So who's responsible for the architecture as the platform, the vendor serving the platform or is the platform vendor agnostic? >> You know, this is where you have to kind of peel the onion in layers, right? If you talk about applications, you can't go to a developer team or an app team and say I want you to operate on Google or AWS. They're like I'll pick the cloud that I want, right? Now who are we talking to? The infrastructure guys and the networking guys, right? They want to make sure that it's not bifurcated. It's like, hey, I want to make sure whatever I build for AWS I can equally use that on Azure. I can equally use that on GCP. So if you're talking to more of the application centric teams who really want infrastructure to be transparent, they'll say, okay, I want to make this choice of whether this is AWS, Azure, GCP, and stick to that. And if you come kind of down the layers of the stack into infrastructure, they are thinking a little more holistically, a little more Supercloud, a little more multicloud, and that. >> That's a good point. So that brings up the deployment question. >> Ramesh: Exactly! >> I want to ask you the next question, okay, what is the preferred deployment in your opinion for a Supercloud narrative? Is it single instance, spread it around everywhere? What's the, do you have a single global instance or do you have everything synchronized? >> So I would say first layer of that Supercloud really kind of fix the holes that have been introduced as a result of kind of adopting the hyper scaler technologies, right? So each, the hyper scalers have been really good at innovating and providing really massive scale elastic capabilities, right? But once you start to build capabilities on top of that to help serve the application, there's a few holes start to show up. So first job of Supercloud really is to plug those holes, right? Second is can I get to an operating model, so that I can replicate this not just in a single region, but across multiple regions, same cloud, and then across multiple clouds, right? And so both of those need to be solved for in order to be (cross talking). >> So is that multiple instantiations of the stack or? >> Yeah, so this again depends on kind of the capability, right? So if you take a more solution view, and so I can speak for kind of networking security combined right? There you always take a solution view. You don't ever look at, you know, what does this mean for a single instance in a single region. You take a macro view, and then you then break it down into what does this mean for region, what does it mean for instance, what does this mean for AZs? And so on and so forth. So you kind of have to go top to bottom. >> Okay, welcome you down into the trap now. Okay, synchronizing the data, latency, these are all questions. So what does the network Supercloud look like to you? Because networking is big here. >> Ramesh: Yes, absolutely. >> This is what you guys do. >> Exactly, yeah. So the different set of problems as you go up the stack, right? So if you have hundreds of workloads in a single region, the set of problems you're dealing with there are kind of app native connectivity, how do I go from kind of east/west, all of those fun things, right? Which are usually bound in terms of latency. You don't have those challenges as much, but can you build your entire enterprise application architecture in one region? No, you're going to have to create multiple instances, right? So my data lake is invariably going to be in one place. My business logic is going to be spread across a few places. What does that bring in? I need to go across regions. Am I going to put those two regions right next to each other? No, I'm not going to, right? I'm going to have places in Europe. I'm going to have APAC, and I'm going to have a North American presence, and I need to bring all these things together. So this is where, back to your point, latency really matters, right? Because I need to be able to find out not just best path but also how do I reduce the millisecond, microseconds that my application cares about, which brings in a layer of optimization and then so on and so on and so forth. So this is what we call kind of to borrow the Prosimo language full stack networking, right? Because I'm not just dealing with how do I go from one region to another because that's laws of physics. I can only control so much. But there are a few elements up the application stack in software that you can tweak to actually bring these things closer and closer. >> And on that point, you're seeing security being talked a lot more at the network layer. So how do you secure the Supercloud at the network layer? What's that look like? >> Yeah, we've been grappling with essentially is security kind of foundational, and then is the network on top. And then we had an alternative viewpoint which is kind of network and then security on top. And the answer is actually it's neither, right? It's almost like a meshed up sandwich of sorts. So you need to have networking security work really well together, right? Case in point, I mean we were talking to a customer yesterday. He said, hey, I have my data lake in one region that needs to talk to an analytics service in a completely different region of a different cloud. These two things just need to be able to talk to each other, which means I need to bring elements of networking. I need to bring elements of security, secure access, app segmentation, all of those things. Very simple, I have an analytics service that needs to contact a data lake. That's what he starts with, but then before you know it, it actually brings up a whole stack underneath, so that's. >> VMware calls that cloud chaos. >> Ramesh: Yes, exactly. >> And then that's the halfway point between cloud smart. Cloud first, cloud chaos, cloud smart, and the next thing, you can skip that whole step. But again, again, it's pick your strategy right? Again, this comes back down to your earlier point. I want to ask you from a customer standpoint, you got the hyper scalers doing very, very well. >> Ramesh: Yep, absolutely. >> And I love what their Amazon's doing. I think Microsoft again though they had a little bit of downgrade are catching up fast, and they have their installed base. So you got the land of the installed bases. >> Correct. >> First and greater, better cloud. Install base getting better, almost as good, almost as good is a gift, but close. Now you have them specializing. Silicon, special silicon. So there's gaps for other services. >> Ramesh: Correct. >> And Amazon Web Services, Adam Selipsky's a open book saying, hey, we want our ecosystem to pick up these gaps and build on them. Go ahead, go to town. >> So this is where I think choices are tough, right? Because if you had one choice, you would work with it, and you would work around it, right? Now I have five different choices. Now what do I do? Our viewpoint is there are a bunch of things that say AWS does really, really well. Use that as a foundational layer, right? Like don't reinvent the wheel on those things. Transit gateways, global accelerators and whatnot, they exist for a reason. Billions of dollars have gone into building those things. Use that foundational layer, right? But what you want to build on top of that is actually driven by the application. The requirements of a lambda application that's serverless, it's very different than a packaged application that's responding for transactions, right? Like it's just completely very, very different. And so bring in the right set of capabilities required for those set of applications, and then you go based on that. This is also where I think whether something is a regional construct versus an overall global construct really, really matters, right? Because if you start with the assumption that everything is going to be built regionally, then it's someone else's job to make sure that all of these things are connected. But if you start with kind of the global purview, then the rest of them start to (cross talking). >> What are some of the things that the enterprises might want that are gaps that are going to be filled by the, by startups like you guys and the ecosystem because we're seeing the ecosystem form into two big camps. >> Ramesh: Yep. >> ISVs, which is an old school definition of independent software vendor, aka someone who writes software. >> Ramesh: Exactly. >> SaaS app. >> Ramesh: Correct. >> And then ecosystem software players that were once ISVs now have people building on top of them. >> Ramesh: Correct. >> They're building on top of the cloud. So you have that new hyper scale effect going on. >> Ramesh: Exactly. >> You got ISVs, which is software developers, software vendors. >> Ramesh: Correct. >> And ecosystems. >> Yep. >> What's that impact of that? Cause it's a new dynamic. >> Exactly, so if you take kind of enterprises, want to make sure that that their apps and the data center migrate to the cloud, new apps are developed the right way in the cloud, right? So that's kind of table stakes. So now what choices do they have? They listen to AWS and say, okay, I have all these cloud native services. I want to be able to instantiate all that. Now comes the interesting choice that they have to make. Do I go hire a whole bunch of people and do it myself or do I go there on the platform route, right? Because I made an architectural choice. Now I have to decide whether I want to do this myself or the platform choice. DIY works great for some, but you don't know what you're getting into, and it's people involved, right? People, process, all those fun things involved, right? So we show up there and say, you don't know what you don't know, right? Like because that's the nature of it. Why don't you invest in a platform like what what we provide, and then you actually build on top of it. We will, it's our job to make sure that we keep up with the innovation happening underneath the covers. And at the same time, this is not a closed ended system. You can actually build on top of our platform, right? And so that actually gives you a good mix. Now the care abouts are interesting. Some apps care about experience. Some apps care about latency. Some apps are extremely charty and extremely data intensive, but nobody wants to pay for it, right? And so it's a interesting Jenga that you have to play between experience versus security versus cost, right? And that makes kind of head of infrastructure and cloud platform teams' life really, really, really interesting. >> And this is why I love your background, and Stu Miniman, when he was with theCUBE, and now he's at Red Hat, we used to riff about the network and how network folks are now, those concepts are now up the top of the stack because the cloud is one big network effect. >> Ramesh: Exactly, correct. >> It's a computer. >> Yep, absolutely. No, and case in point, right, like say we're in let's say in San Jose here or or Palo Alto here, and let's say my application is sitting in London, right? The cloud gives you different express lanes. I can go down to my closest pop location provided by AWS and then I can go ride that all the way up to up to London. It's going to give me better performance, low latency, but I'm going to have to incur some costs associated with it. Or I can go all the wild internet all the way from Palo Alta up to kind of the ingress point into London and then go access, but I'm spending time on the wild internet, which means all kinds of fun things happen, right? But I'm not paying much, but my experience is not going to be so great. So, and there are various degrees of shade in them, of gray in the middle, right? So how do you pick what? It all kind of is driven by the applications. >> Well, we certainly want you back for Supercloud3, our next version of this virtual/live event here in our Palo Alto studios. Really appreciate you coming on. >> Absolutely. >> While you're here, give a quick plug for the company. Next minute, we can take a minute to talk about the success of the company. >> Ramesh: Absolutely. >> I know you got a fresh financing this past year. Plenty of money in the bank, going to ride this new wave, Supercloud wave. Give us a quick plug. >> Absolutely, yeah. So three years going on to four this calendar year. So it's an interesting time for the company. We have proven that our technology, product and our initial customers are quite happy with it. Now comes essentially more of those and scale and so forth. That's kind of the interesting phase that we are in. Also heartened to see quite a few of kind of really large and dominant players in the market, partners, channels and so forth, invest in us to take this to the next set of customers. I would say there's been a dramatic shift in the conversation with our customers. The first couple of years or so of the company, we are about three years old right now, was really about us educating them. This is what you need. This is what you need. Now actually it's a lot of just pull, right? We've seen a good indication, as much as a hate RFIs, a good indication is the number of RFIs that show up at our door saying we want you to participate in this because we want to understand more, right? And so as a, I think we are at an interesting point of the, of that shift. >> RFIs always like do all this work and hope for the best. Pray for a deal. You know, you guys on the right side of history. If a customer asks with respect to Supercloud, multicloud, is that your focus? Is that the direction you guys are going into? >> Yeah, so I would say we are kind of both, right? Supercloud and multicloud because we, our customers are hybrid, multiple clouds, all of the above, right? Our main pitch and kind of value back to the customers is go embrace cloud native because that's the right approach, right? It doesn't make sense to go reinvent the wheel on that one, but then make a really good choice about whether you want to do this yourself or invest in a platform to make your life easy. Because we have seen this story play out with many many enterprises, right? They pick the right technologies. They do a simple POC overnight, and they say, yeah, I can make this work for two apps, right? And then they say, yes, I can make this work for 100. You go down a certain path. You hit a wall. You hit a wall, and it's a hard wall. It's like, no, there isn't a thing that you can go around it. >> A lot of dead bodies laying around. >> Ramesh: Exactly. >> Dead wall. >> And then they have to unravel around that, and then they come talk to us, and they say, okay, now what? Like help me, help me through this journey. So I would say to the extent that you can do this diligence ahead of time, do that, and then, and then pick the right platform. >> You've got to have the talent. And you got to be geared up. You got to know what you're getting into. >> Ramesh: Exactly. >> You got to have the staff to do this. >> And cloud talent and skillset in particular, I mean there's lots available but it's in pockets right? And if you look at kind of web three companies, they've gone and kind of amassed all those guys, right? So enterprises are not left with the cream of the crop. >> John: They might be coming back. >> Exactly, exactly, so. >> With this downturn. Ramesh, great to see you and thanks for contributing to Supercloud2, and again, love your team. Very technical team, and you're in the right side of history in this one. Congratulations. >> Ramesh: No, and thank you, thank you very much. >> Okay, this is Supercloud2. I'm John Furrier with Dave Vellante. We'll be back right after this short break. (upbeat music)

(upbeat jazz music) >> From our studios, in the heart of Silicon Valley, Palo Alta, California. This is a Cube Conversation. >> Hi, welcome to the Cube Studio for another Cube Conversation where we go in-depth with thought leaders driving business outcomes with technology. I'm your host Peter Buriss. As enterprise is look to take advantage of new classes of applications like AI and others that make possible this notion of a data first or data driven enterprise in a digital business world. They absolutely have to consider what they need to do with their stored resources to modernize them to make possible new types of performance today, but also sustain and keep open options for how they use data in the future. To have that conversation we're here with David Floyer, CTO and co-founder of Wikibon. David welcome to the conversation. >> Thank you. >> So David you've been looking at this notion of modern storage architectures for 10 years now. >> Yeah. >> And you've been relatively prescient in understanding what's gonna happen. You were one of the first guys to predict well in advance of everybody else that the crossover between flash and HDD was gonna happen sooner rather than later. So I'm not going to spend a lot of time quizzing you. What do you see as a modern storage architecture? Let's, just let it rip. >> Okay well let's start with one simple observation. The days of standalone systems for data have gone we're in a software defined world and you wanna be able to run those data architectures anywhere where the data is. And that means in your data center where it was created or in the cloud or in a public cloud or at the edge. You want to be able to be flexible enough to be able to do all of the data services where the best place is and that means everything has to be software driven. >> Software defined is the first proposition of modern data storage facility? >> Absolutely. >> Second. >> So the second thing is that there are different types of technology. You have the very fastest storage which is in the in the DIRUM itself. You have NVDIMM which is the next one down from that expensive but a lot cheaper than the DIMM. And then you have different sorts of flash. You have the high performance flash and you have the 3D flash, you know as many layers as you can which is much cheaper flash and then at the bottom you have HDD and even tape as storage devices. So how. The key question is how do you manage that sort of environment. >> Where do we start because it still sounds like we still have a storage hierarchy. >> Absolutely. >> And it still sounds like that hierarchy is defined largely in terms of access speeds >> Yeap. >> And price points. >> Price points. Yes. >> Those are the two Mason and bandwidth and latency as well are within that. >> which are tied into that? >> which are tied into those. Yes. So what you, if you're gonna have this everywhere and you need services everywhere what you have to have is an architecture which takes away all of that complexity, so that you, all you see from an application point of view is data and how it gets there and how is put away and how it's stored and how it's protected that's under the covers. So the first thing is you need a virtualization of that data layer. >> The physical layer? >> The virtualization of that physical layer. >> Right right. >> Yes. And secondly you need that physical layer to extend to all the places that may be using this data. You don't wanna be constrained to this data set lives here. You want to be able to say Okay, I wanna move this piece of programming to the data as quickly as I can, that's much much faster than moving the data to the processing. So I want to be able to know where all the data is for this particular dataset or file or whatever it is, where they all are, how they connect together, what the latency is between everything. I wanna understand that architecture and I want to virtualize view of that across that whole the nodes that make up my hybrid cloud. >> So let me be clear here so, so we are going to use a software defined infrastructure >> Yeah. that allows us to place the physical devices that have the right cost performance characteristics where they need to be based on the physical realities of latency power availability, hardening, et cetera. >> And the network >> And the network. But we wanna mask that complexity from the application, application developer and application administrator. >> Yes. >> And software defined helps do that, but doesn't completely do it. >> No. Well you want services which say >> Exactly, so their services on top of all that. >> On top of all that. >> Absolutely. >> That are recognizable by the developer, by the business person, by the administrator, as they think about how they use data towards those outcomes not use storage or user device but use the data. >> Data to reach application outcomes. That's absolutely right. And that's what I call the data plane which is a series of services which enable that to happen and driven by the application requirements themselves. >> So we've looked at this and some of the services include end end compression, duplication, >> Duplication. backup restore, security, data protection. >> Protection. Yeah. So that's kind of, that's kind of the services that now the enterprise buyer needs to think about. >> Yes. >> So that those services can be applied by policy. >> Yes. >> Wherever they're required based on the utilization of the data >> Correct. >> Where the event takes place. >> And then you still have at the bottom of that you have the different types of devices. You still have you still won't >> A lot of hamsters making stuff work. >> You still want hard disk for example they're not disappearing, but if you're gonna use hard disks then you want to use it in the right way for using a hard disk. You wanna give it large box. You want to have it going sequentially in and out all the time. >> So the storage administration and the physical schema and everything else is still important in all these? >> Absolutely. But it's less important, less a centerpiece of the buying decision. >> Correct. >> Increasingly it's how well does this stuff prove support the services that the business is using to achieve your outcomes. >> And you want to use costs the lowest cost that you can and they'll be many different options open, more more options open. But the automation of that is absolutely key and that automation from a vendor point of view one of the key things they have to do is to be able to learn from the usage by their customers, across as broad a number of customers as they can. Learn what works or doesn't work, learn so that they can put automation into their own software their own software service. >> So it sounds like we talking four things. We got software defined, still have a storage hierarchy defined by cost and performance, but with mainly semiconductor stuff. We've got great data services that are relevant to the business and automation that mask the complexity from everything. >> And a lot of the artificial AI there is, automated >> Running things. Fantastic. David Floyer, talking about modern storage architectures. Once again thanks for joining us on the Cube Conversation. And I'm your host Peter Burris. See you next time. (jazz music)

>> from our studios in the heart of Silicon Valley, Palo Alto, California It is a cute conversation >> universe. And welcome to another cube conversation from our wonderful Palo Alta Studios in beautiful Palo Alto, California. As we do with every cute conversation, we're gonna talk about an important topic with smart people that can provide some good clues and guidance as to how the industry's gonna be forward. We're gonna do that today, too. Specifically, what we're gonna talk about is that there has been an enormous amount of interest in kubernetes is a technology for making possible the whole micro service's approached application development. But one of the challenges that kubernetes has been specifically built to be stateless, which means that it's not necessarily aware of its underlying data. Now that is okay for certain classes of application. But the typical enterprise does want to ensure that its data can remain state full. That does have a level of protection required, et cetera, which creates a new need within the industry for how do we marry state full capabilities, staple storage capabilities with kubernetes and have that conversation? We've got great guests here. Part of Ayatollah is a co founder and C t o of robin dot io and radish men on is the CMO Robin. I owe partner Radish. Welcome to the Cube. >> Great to be here. >> All right, so, reddish one, we start with you. Why don't you give us a quick update on Robin Donna? >> Sure. Robin. Daughter, You, as you were alluding to, is addressing super important problem that is in front of us, which is that you've got cloud. Native technologies, especially containers. And community is becoming the default way in which enterprises are choosing to innovate. But at the same time, there's a >> whole swath >> of applications which were architected just five years ago, which all need to get the same benefits off agility, portability and efficiency of cloud native technologies. Robin helps bridge that, and I hope to talk more about that. >> Excellent. So part of let's start with you and talk about this problem this impedance mismatch between applications that require some state full assurance about the data and kubernetes, which tends to be stateless. How does that How does that impact the way applications get built and deployed? >> Sure. So if you look at me as you mentioned that communities is a platform that has started our originated for stateless workloads, and people have adopted the fastest growing open source project. We know about that, but when you look at a stateless work lord, it actually depends on state from somewhere. It's basically computing something right. It's computing state that's coming either, for the network ordered. Is computing on state that store brother inside, big data data, data leak or inside a database? Now, if you look at the problem itself, developers have gotten used to the agility benefits that communities has to offer the mostly infrastructure as a court kind of construct centered offers, however, the agility is not complete if you do not bring the state full workload workloads also into the communities for so as an example, think about somebody who's trying to build on entire pipeline right across the in. Just process so visualized by plane. If you're saying that you know what, in order to put this entire stock together, our entire pipeline together are to still do something that is non agile by going out sorry communities and then marry that with something inside communities. That's not true, actually. So more and more we're seeing developers and the develops teams basically saying that. Okay, I want to have the entire stock developed on deployed on a child platform, like open these. And of course, that comes with a bunch of challenges that need to be addressed and hoping you talk about that today. >> Well, if we have a zoo said the state has to be maintained somewhere, state may be maintained somewhere up in the cloud, But there are gonna be circumstances where because of data locality issues on, you know you want local control. You have ah, Leighton. See, considerations a number of other issues that you want to be ableto locate state in the closer close to the kubernetes. Is that really what we're talking about here? >> That's one aspect of it which is essentially around the performance and maybe you in governance reasons why you want to call a Kate State and stateless, Right? But the other reason I was saying is, if you want to deploy a stack, stack is comprised of many too many competent, stateless as well estate full. And you're talking about the birth of an entire application that the developer is gonna push under this platform right, so there. It's not about just the data locality and all that. It's also that just enabling the entire stock to be deployed in one shot. >> So you just you just you want a simpler, more manageable stats at all, right? So what's the solution? What people, what people have to do to get access to both those performance more more performance state Full application. Cubans clusters that record, have some degree of day locality concerns or to sustain that dream of increasingly simple stacks. What has to happen differently? >> Sure, and there are two aspects to this. The 1st 1 I would say, is that a the platform that is going to offer this on top of communities has to guarantee the persistency needs, whether it is in terms of reliability, dumps of performances. Selous, it has to guarantee does so you have to get those onto the platform first. But beyond that, if you look at other issues talking about many, there are many, many data platforms or data applications of workloads that predict board docker and communities. Now, if you don't really bring them into the Ford, you really are not solving the real business challenges that people have today, right? So beyond just providing persistency layer to communities pods, you need to have a way in which you can take complex platforms such as Mongol, Cassandra Elastic, such article rack. Cloudera these kind of workload and bring them onto a platform that has architected for Microsoft. Just communities, right? Because these platforms are not. These workers are not designed for micro service's workloads. So how do you marry them onto a platform such as communities that is designed as a micro service's platform? So you go to solve that, and that is exactly what Robin has done. So we have taken this approach where you can take complex workloads, rear platforms and then make them run on on a Microsoft this platform like abilities, starting with the storage subsystem, which is where one of our course fences. >> So I could conceivably imagine an Oracle database being rendered as a container with inside a cougar and he's cluster and position as a service have been orchestrated by by that kubernetes instance. What >> if I could jump in? You don't have to imagine we have customers in production there. They have Oracle Rack as a service offered on robin right now. One thing I want to contextualize is that our roots are in problem solving this hard problem off applications that I haven't been designed for containers contain arising them and being able to manage that gracefully in carbonated right. It just gave the example off Oracle Rack as a service. Or we also have customers with, let's say, multiple petabytes of data with her new bastard service, um, covering big large enterprises as well. Now from that lineage. Now, what've you also offering is that there is a set of customers who, already picked, Committed is already right might be open shift. It might be P K, as it might be g k to do its customers. We also have an offering called Robbins Storage, which brings powerful data management capabilities right. So to offering the platform offering, which is communities plus storage plus networking. Bless application bundles for some of the demanding workloads. But we just talked about, and then Robin Storage is a new offering which can add the magic of data management and advanced data management capabilities to any community. Is that you? >> Well, let's talk about that just for one second the uh, when I think of data management capabilities, I'm thinking not just a Iot being written back and forth between some media and some application. I'm thinking in terms of, oh, data protection and security. So are there Give us a sense of the scope of the service? Is that our part off this solution that you're talking? >> Yeah, I'll start in part like and chime in as well. So the first context you need to have is that all these data management capabilities are in the context of a hybrid being the normed implementation, right? Nine or 10 customers are looking at implementing on Prem with Public Cloud, right? So in that context, any of the cable release that we're talking about being being able to take snapshots or being able to take, you know, move that snap short to be offer as a back up in the cloud or ability, the clone and rehydrate applications, these air own capabilities that need to operate in a hybrid cloud context, that's number one. The second thing is, rather than just solve the storage level problem off taking snapshots, being able to bring application and data together is a big game changer in partner. Can you add a little bit more on the apple is data? >> Absolutely. Because, I mean, if you look at the the dinner service is the radish doctor board snapshots and clones and things living backups. Those constructs have existed in the storage industries for almost three decades. So there's nothing new about dark, right? But if you look at applying them for work Lord that are running in communities, you gotta uplevel that, because when you look at a story little snapshot, it is still a volume orelon level snapshot. But what a developer develops team needs is the ability to take an entire workload. That's a Mongo TB cluster and the only snap, short and dark cluster. I want to keep different states, even if the topology of the application is changing. Correct. And that is something that Robin has innovated on because we recognized. And I come from a storage bag when I was a distinguishing. Jenna very does have Bean fortunate to be building many data platforms there on be recognized that just leaving that storage does not deliver the promise of agility that communities offers. They were uplevel it into applications and for the very first time. In fact, we're introducing concepts such as you go to a Mongo classroom. You say I want to go snapshot this cluster. We understand the apology that this cluster has. How many shards depositor for offering these things. The service is under Langston the volumes and we dark forms a snapshot. That's an application. Little snapshot of the benefit of application will snap Shirt is that if another developer wants to go clone and run queries on that, you don't have to go Dr Storage Admin inside. Just give me clones of these large volumes. They'll say, Just clone this Mongol Devi cluster on. Then within minutes, you have an up and running long body be cluster fully functional. You can start readies life. Exactly. Other thing would be draw the stock double portability. So you have this snapshot taken periodic snapshots. So let's say that you run out of capacity nor deer center, and you would like to go bust into a different cloud. That's your on premises, and you want to go and run a clone in geeky because that's where the capacities, our snapshots and the baby, a implemented and architect of this allow you to port an entire application along with topology? Medea on data so that he can go and stand up Fully functional, ready to use. That's among Would he be cluster and geeky in the club? >> Now you talk about UK a Google kubernetes engine on G C P Google Cloud Platform. Obviously, that's when you think about kubernetes. That's kind of the mother ship. When you come right down to it. How does your platform and G K E G. C P work together? >> So the first thing is >> that we have, ah, partnership, which is led by engineering to engineering engagement, that >> part eyes front, ending around a standard set of AP eyes whereby the advanced data management capabilities that we're talking about can be brought into communities world itself and, of course, geeky as the implementation footprint. Right? So that's one area that we've been collaborating on. The second is from, ah, Google perspective. The preferred storage for running enterprise workloads or state full workloads or the data intensive work clothes that be talking about is Robin Storage and that's ah that we definitely are pretty excited by the fact that through rigorous technical evaluation, after rigorous technical evaluation, Google is chosen Robyn stories as the preferred storage for these demanding workloads. So from both these standpoints off moving the state of the art of what does it mean to provide data management capabilities to communities, to providing a solution that works today for customers who are embracing G K both on Prem in in the cloud to be able to bring state full workloads? We're working with Google and pretty excited about that part. Anyone add further color on the engineering partnership? >> He absolutely, I think, as a radish mentioned. So Google perform. We are the purport storage solution for that. Now can we just rewind back a little bit there? About 25 30 different stories? When does providing stories for communities? Right. So what is this? I think that this move is something special that let us tow this thing at this point, right. We took a very fundamentally different approach when we when we saw this problem for G k r for communities you could have started with several open source story solutions, are there and build on top of that. When their companies that take barter effects, for example, pity orifice and build on that. The companies that takes seven belong there, right? Be formally said that. Listen, if you want to elevate the experience from storage onto applications, that the example that I took earlier off taking a snatcher, a mongo migrating and if your story, it's stackers underwear off the application, which means that the stories track is unaware of the topology of the application. Can you really do application consistent snapshots? You can't. All he can do is begin to snapshot individual Williams. Correct. Now, if the stories stock is not a rare off the application to polish, can you actually the application level quality? Also, this. If you can't do that, can you really guarantee noisy neighbor elimination? You had to >> do all >> those things right? If you really wanna run data platforms, those are the core things that you need to do right and Soviet took an approach is that it doesn't know it will not cut it if you build a story. Stack on top of border defense, for example, are on set, so we do a ground up approach and he said, Look, if you wanna build a story, started this cloud native communities native. How would that look like? And how would the perimeters exposed so that it can deliver the entire experienced applications? So architectural leave yard very superior compared to the other players out there, it's proof is that we've got picked. Now that's one aspect. The other aspect is the approach that were taken to expose these primitives, their own snapshots and backup on a portability and all that was very clean. Right on. Very pragmatic how it works with both the born in the cloud as well as the the prior boatloads right on. Because of that, we're also collaborating with the Google engineers is to come up with a set off a P eyes that were planning to standardize right around community so that you could have a very standard set off a p I through which you can trigger these data management calls. Right? So that's that's other like no other stock Borden engineering to engineering collaboration. So that's the other thing that we're collaborating on to create the stana riser of FBI's based on the knowledge that we have had, because we have have we have feel deployments off like rubbish. Talked about right article rack. We have field the Prime Minster. People are deploying multiple petabytes off starting in the single communities. Robin, cluster. Right? So all that learning all the experience that we have had its contributed towards this joint Engineering to engineering. Afford that you're going to create the standardized data management. >> So we've got Robin. I owe has delivered a piece of technology for handling state full kubernetes clusters that has been validated by Google I o. Today or you know, so that can be used now. And is the basis for further engineering work to move this Maur into the mainstream for the future? That's good. Very exciting stuff, Partha. Right, Dash. Thanks very much for being here in the Cube. Thank you. Thank you. And once again, I want to thank part uh Chautala, Who is the co founder and CEO of Robin I owe and radish men on Who's the CMO Robin don I owe once again. I'm Peter Bursts. Thanks very much for watching this cube conversation until next time