>> 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

>> Live from San Jose, in the heart of Silicon Valley, it's theCUBE. Covering DataWorks Summit 2018. Brought to you by Hortonworks. >> Welcome back everyone, you are watching day two of theCUBE's live coverage of DataWorks here in San Jose, California. I'm your host, Rebecca Knight. I'm coming at you with my cohost Jame Kobielus. We're joined by Partha Seetala, he is the Chief Technology Officer at Robin Systems, thanks so much for coming on theCUBE. >> Pleasure to be here. >> You're a first timer, so we promise we don't bite. >> Actually I'm not, I was on theCUBE- >> Oh! >> At DockerCon in 2016. >> Oh well excellent, okay, so now you're a veteran, right. >> Yes, ma'am. >> So Robin Systems, as before the cameras were rolling, we were talking about it, it's about four years old, based here in San Jose, venture backed company. Tell us a little bit more about the company and what you do. >> Absolutely. First of all, thanks for hosting me here. Like you said, Robin is a Silicon Valley based company. Our focus is in allowing applications, such as big data, databases, no sequel and AI ML, to run within the Kubernetes platform. What we have built is a product that converges storage, complex storage, networking, application workflow management, along with Kubernetes to create a one click experience where users can get managed services kind of feel when they're deploying these applications. They can also do one click life cycle management on these apps. Our thesis has initially been to, instead of looking at this problem from an infrastructure up into application, to actually look at it from the applications down and then say, "Let the applications drive the underlying infrastructure to meet the user's requirements." >> Is that your differentiating factor, would you say? >> Yeah, I think it is because most of the folks out there today are looking at is as if it's a competent based play, it's like they want to bring storage to Kubernetes or networking to Kubernetes but the challenges are not really around storage and networking. If you talk to the operations folk they say that, "You know what? Those are underlying problems but my challenge is more along the lines of, okay, my CIO says the initiative is to make my applications mobile. They want go across to different Clouds. That's my challenge." The line of business user says, "I want to get a managed source experience." Yes, storage is the thing that you want to manage underneath, but I want to go and click and create my, let's say, an Oracle database or distributions log. >> In terms of the developer experience here, from the application down, give us a sense for how Robin Systems tooling your product enables that degree of specification of the application logic that will then get containerized within? >> Absolutely, like I said, we want applications to drive the infrastructure. What it means is that we, Robin is a software platform. We later ourselves on top of the machines that we sit on whether it is bare metal machines on premises, our VMs, or even an Azure, Google Cloud as well as AWs. Then we make the underlying compute, storage, network resources almost invisible. We treat it as a pool of resources. Now once you have this pool of resources, they can be attached to the applications that are being deployed as can inside containers. I mean, it's a software place, install on machines. Once it's installed, the experience now moves away from infrastructure into applications. You log in, you can see a portal, you have a lot of applications in that portal. We ship support for about 25 applications of some such. >> So these are templates? >> Yes. >> That the developer can then customize to their specific requirements? Or no? >> Absolutely, we ship reference templates for pretty much a wide variety of the most popular big data, no sequel, database, AI ML applications today. But again, as I said, it's a reference implementation. Typically customers take the reference recommendation and they enhance it or they use that to onboard their custom apps, for example, or the apps that we don't ship out of the box. So it's a very open, extensible platform but the goal being that whatever the application might be, in fact we keep saying that, if it runs somewhere else, it's runs on Robin, right? So the idea here is that you can bring anything, and we just, the flip of switch, you can make it a one click deploy, one click manage, one click mobile across Clouds. >> You keep mentioning this one click and this idea of it being so easy, so convenient, so seamless, is that what you say is the biggest concern of your customers? Is this ease and speed? Or what are some other things that are on their minds that you want to deliver? >> Right, so one click of course is a user experience part but what is the real challenge? The real challenges, there are a wide variety of tools being used by enterprises today. Even the data analytic pipeline, there's a lot across the data store, processor pipeline. Users don't want to deal with setting it up and keeping it up and running. They don't want that, they want to get the job done, right? Now when you only get the job done, you really want to hide the underlying details of those platforms and the best way to convey that, the best way to give that experience is to make it a single click experience from the UI. So I keep calling it all one click because that is the experience that you get to hide the underlying complexity for these apps. >> Does your environment actually compile executable code based on that one click experience? Or where does the compilation and containerization actually happen in your distributed architecture? >> Alright, so, I think the simplest- >> You're a prem based offering, right? You're not in the Cloud yourself? >> No, we are. We work on all the three big public clouds. >> Oh, okay. >> Whether it is Azure, AWS or Google. >> So your entire application is containerized itself for deployment into these Clouds? >> Yes, it is. >> Okay. >> So the idea here is let's simplify it significantly, right? You have Kubernetes today, it can run anywhere, on premises, in the public Cloud and so on. Kubernetes is a great platform for orchestrating containers but it is largely inaccessible to a certain class of data centric applications. >> Yeah. >> We make that possible. But our take is, just onboarding those applications on Kubernetes does not solve your CXO or you line of business user's problems. You ought to make the management, from an application point of view, not from a container management point of view, from an application point of view, a lot easier and that is where we kind of create this experience that I'm talking about, one click experience. >> Give us a sense for how, we're here at DataWorks and it's the Hortonworks show. Discuss with us your partnership with Hortonworks and you know, we've heard the announcement of HDP 3.0 and containerization support, just give us a rough sense for how you align or partner with Hortonworks in this area. >> Absolutely. It's kind of interesting because Hortonworks is a data management platform, if you think about it from that point of view and when we engaged with them first- So some of our customers have been using the product, Hortonworks, on top of Robin, so orchestrating Hortonworks, making it a lot easier to use. >> Right. >> One of the requirements was, "Are you certified with Hortonworks?" And the challenge that Hortonworks also had is they had never certified a container based deployment of Hortonworks before. They actually were very skeptical, you know, "You guys are saying all these things. Can you actually containerize and run Hortonworks?" So we worked with Hortonworks and we are, I mean if you go to the Hortonworks website, you'll see that we are the first in the entire industry who have been certified as a container based play that can actually deploy and manage Hortonworks. They have certified us by running a wide variety of tests, which they call the Q80 Test Suite, and when we got certified the only other players in the market that got that stamp of approval was Microsoft in Azure and EMC with Isilon. >> So you're in good company? >> I think we are in great company. >> You're certified to work with HTP 3.0 or the prior version or both? >> When we got certified we were still in the 2.X version of Hortonworks, HTP 3.0 is a more relatively newer version. But our plan is that we want to continue working with Hortonworks to get certified as they release the program and also help them because HTP 3.0 also has some container based orchestration and deployment so you want to help them provide the underlying infrastructure so that it becomes easier for beyond to spin up more containers. >> The higher level security and governance and all these things you're describing, they have to be over the Kubernetes layer. Hortonworks supports it in their data plane services portfolio. Does Robin Systems solutions portfolio tap in to any of that, or do you provide your own layer of sort of security and metadata management so forth? >> Yeah, so we don't want- >> In context of what you offer? >> Right, so we don't want to take away the security model that the application itself provides because might have step it up so that they are doing governance, it's not just logging in and auto control and things like this. Some governance is built into. We don't want to change that. We want to keep the same experience and the same workflow hat customers have so we just integrate with whatever security that the application has. We, of course, provide security in terms of isolating these different apps that are running on the Robin platform where the security or the access into the application itself is left to the apps themselves. When I say apps, I'm talking about Hortonworks. >> Yeah, sure. >> Or any other databases. >> Moving forward, as you think about ways you're going to augment and enhance and alter the Robin platform, what are some of the biggest trends that are driving your decision making around that in the sense of, as we know that companies are living with this deluge of data, how are you helping them manage it better? >> Sure. I think there are a few trends that we are closely watching. One is around Cloud mobility. CIOs want their applications along with their data to be available where their end users are. It's almost like follow the sun model, where you might have generated the data in one Cloud and at a different time, different time zone, you'll basically want to keep the app as well as data, moving. So we are following that very closely. How we can enable the mobility of data and apps a lot easier in that world. The other one is around the general AI ML workflow. One of the challenges there, of course, you have great apps like TensorFlow or Theano or Caffe, these are very good AI ML toolkits but one of the challenges that people face, is they are buying this very expensive, let's say NVIDIA DGX Box, this box costs about $150,000 each, how do you keep these boxes busy so that you're getting a good return on investment? It will require you to better manage the resources offered with these boxes. We are also monitoring that space and we're seeing that how can we take the Robin platform and how do you enable the better utilization of GPUs or the sharing of GPUs for running your AI ML kind of workload. >> Great. >> Those are, I think, two key trends that we are closely watching. >> We'll be discussing those at the next DataWorks Summit, I'm sure, at some other time in the future. >> Absolutely. >> Thank you so much for coming on theCUBE, Partha. >> Thank you. >> Thank you, my pleasure. Thanks. >> I'm Rebecca Knight for James Kobielus, We will have more from DataWorks coming up in just a little bit. (techno beat music)