(gentle bright music) >> Okay, welcome back to our "Supercloud 2" event live coverage here at stage performance in Palo Alto syndicating around the world. I'm John Furrier with Dave Vellante. We've got exclusive news and a scoop here for SiliconANGLE and theCUBE. Zhamak Dehghani, creator of data mesh has formed a new company called NextData.com NextData, she's a cube alumni and contributor to our Supercloud initiative, as well as our coverage and breaking analysis with Dave Vellante on data, the killer app for Supercloud. Zhamak, great to see you. Thank you for coming into the studio and congratulations on your newly formed venture and continued success on the data mesh. >> Thank you so much. It's great to be here. Great to see you in person. >> Dave: Yeah, finally. >> John: Wonderful. Your contributions to the data conversation has been well-documented certainly by us and others in the industry. Data mesh taking the world by storm. Some people are debating it, throwing, you know, cold water on it. Some are, I think, it's the next big thing. Tell us about the data mesh super data apps that are emerging out of cloud. >> I mean, data mesh, as you said, it's, you know, the pain point that it surfaced were universal. Everybody said, "Oh, why didn't I think of that?" You know, it was just an obvious next step and people are approaching it, implementing it. I guess the last few years, I've been involved in many of those implementations, and I guess Supercloud is somewhat a prerequisite for it because it's data mesh and building applications using data mesh is about sharing data responsibly across boundaries. And those boundaries include boundaries, organizational boundaries cloud technology boundaries and trust boundaries. >> I want to bring that up because your venture, NextData which is new, just formed. Tell us about that. What wave is that riding? What specifically are you targeting? What's the pain point? >> Zhamak: Absolutely, yes. So next data is the result of, I suppose, the pains that I suffered from implementing a database for many of the organizations. Basically, a lot of organizations that I've worked with, they want decentralized data. So they really embrace this idea of decentralized ownership of the data, but yet they want interconnectivity through standard APIs, yet they want discoverability and governance. So they want to have policies implemented, they want to govern that data, they want to be able to discover that data and yet they want to decentralize it. And we do that with a developer experience that is easy and native to a generalist developer. So we try to find, I guess, the common denominator that solves those problems and enables that developer experience for data sharing. >> John: Since you just announced the news, what's been the reaction? >> Zhamak: I just announced the news right now, so what's the reaction? >> John: But people in the industry that know you, you did a lot of work in the area. What have been some of the feedback on the new venture in terms of the approach, the customers, problem? >> Yeah, so we've been in stealth modes, so we haven't publicly talked about it, but folks that have been close to us in fact have reached out. We already have implementations of our pilot platform with early customers, which is super exciting. And we're going to have multiple of those. Of course, we're a tiny, tiny company. We can have many of those where we are going to have multiple pilots, implementations of our platform in real world. We're real global large scale organizations that have real world problems. So we're not going to build our platform in vacuum. And that's what's happening right now. >> Zhamak: When I think about your role at ThoughtWorks, you had a very wide observation space with a number of clients helping them implement data mesh and other things as well prior to your data mesh initiative. But when I look at data mesh, at least the ones that I've seen, they're very narrow. I think of JPMC, I think of HelloFresh. They're generally obviously not surprising. They don't include the big vision of inclusivity across clouds across different data stores. But it seems like people are having to go through some gymnastics to get to, you know, the organizational reality of decentralizing data, and at least pushing data ownership to the line of business. How are you approaching or are you approaching, solving that problem? Are you taking a narrow slice? What can you tell us about Next Data? >> Zhamak: Sure, yeah, absolutely. Gymnastics, the cute word to describe what the organizations have to go through. And one of those problems is that, you know, the data, as you know, resides on different platforms. It's owned by different people, it's processed by pipelines that who owns them. So there's this very disparate and disconnected set of technologies that were very useful for when we thought about data and processing as a centralized problem. But when you think about data as a decentralized problem, the cost of integration of these technologies in a cohesive developer experience is what's missing. And we want to focus on that cohesive end-to-end developer experience to share data responsibly in this autonomous units, we call them data products, I guess in data mesh, right? That constitutes computation, that governs that data policies, discoverability. So I guess, I heard this expression in the last talks that you can have your cake and eat it too. So we want people have their cakes, which is, you know, data in different places, decentralization and eat it too, which is interconnected access to it. So we start with standardizing and codifying this idea of a data product container that encapsulates data computation, APIs to get to it in a technology agnostic way, in an open way. And then, sit on top and use existing existing tech, you know, Snowflake, Databricks, whatever exists, you know, the millions of dollars of investments that companies have made, sit on top of those but create this cohesive, integrated experience where data product is a first class primitive. And that's really key here, that the language, and the modeling that we use is really native to data mesh is that I will make a data product, I'm sharing a data product, and that encapsulates on providing metadata about this. I'm providing computation that's constantly changing the data. I'm providing the API for that. So we're trying to kind of codify and create a new developer experience based on that. And developer, both from provider side and user side connected to peer-to-peer data sharing with data product as a primitive first class concept. >> Okay, so the idea would be developers would build applications leveraging those data products which are discoverable and governed. Now, today you see some companies, you know, take a snowflake for example. >> Zhamak: Yeah. >> Attempting to do that within their own little walled garden. They even, at one point, used the term, "Mesh." I dunno if they pull back on that. And then they sort of became aware of some of your work. But a lot of the things that they're doing within their little insulated environment, you know, support that, that, you know, governance, they're building out an ecosystem. What's different in your vision? >> Exactly. So we realize that, you know, and this is a reality, like you go to organizations, they have a snowflake and half of the organization happily operates on Snowflake. And on the other half, oh, we are on, you know, bare infrastructure on AWS, or we are on Databricks. This is the realities, you know, this Supercloud that's written up here. It's about working across boundaries of technology. So we try to embrace that. And even for our own technology with the way we're building it, we say, "Okay, nobody's going to use next data mesh operating system. People will have different platforms." So you have to build with openness in mind, and in case of Snowflake, I think, you know, they have I'm sure very happy customers as long as customers can be on Snowflake. But once you cross that boundary of platforms then that becomes a problem. And we try to keep that in mind in our solution. >> So, it's worth reviewing that basically, the concept of data mesh is that, whether you're a data lake or a data warehouse, an S3 bucket, an Oracle database as well, they should be inclusive inside of the data. >> We did a session with AWS on the startup showcase, data as code. And remember, I wrote a blog post in 2007 called, "Data's the new developer kit." Back then, they used to call 'em developer kits, if you remember. And that we said at that time, whoever can code data >> Zhamak: Yes. >> Will have a competitive advantage. >> Aren't there machines going to be doing that? Didn't we just hear that? >> Well we have, and you know, Hey Siri, hey Cube. Find me that best video for data mesh. There it is. I mean, this is the point, like what's happening is that, now, data has to be addressable >> Zhamak: Yes. >> For machines and for coding. >> Zhamak: Yes. >> Because as you need to call the data. So the question is, how do you manage the complexity of big things as promiscuous as possible, making it available as well as then governing it because it's a trade off. The more you make open >> Zhamak: Definitely. >> The better the machine learning. >> Zhamak: Yes. >> But yet, the governance issue, so this is the, you need an OS to handle this maybe. >> Yes, well, we call our mental model for our platform is an OS operating system. Operating systems, you know, have shown us how you can kind of abstract what's complex and take care of, you know, a lot of complexities, but yet provide an open and, you know, dynamic enough interface. So we think about it that way. We try to solve the problem of policies live with the data. An enforcement of the policies happens at the most granular level which is, in this concept, the data product. And that would happen whether you read, write, or access a data product. But we can never imagine what are these policies could be. So our thinking is, okay, we should have a open policy framework that can allow organizations write their own policy drivers, and policy definitions, and encode it and encapsulated in this data product container. But I'm not going to fool myself to say that, you know, that's going to solve the problem that you just described. I think we are in this, I don't know, if I look into my crystal ball, what I think might happen is that right now, the primitives that we work with to train machine-learning model are still bits and bites in data. They're fields, rows, columns, right? And that creates quite a large surface area, an attack area for, you know, for privacy of the data. So perhaps, one of the trends that we might see is this evolution of data APIs to become more and more computational aware to bring the compute to the data to reduce that surface area so you can really leave the control of the data to the sovereign owners of that data, right? So that data product. So I think the evolution of our data APIs perhaps will become more and more computational. So you describe what you want, and the data owner decides, you know, how to manage the- >> John: That's interesting, Dave, 'cause it's almost like we just talked about ChatGPT in the last segment with you, who's a machine learning, could really been around the industry. It's almost as if you're starting to see reason come into the data, reasoning. It's like you starting to see not just metadata, using the data to reason so that you don't have to expose the raw data. It's almost like a, I won't say curation layer, but an intelligence layer. >> Zhamak: Exactly. >> Can you share your vision on that 'cause that seems to be where the dots are connecting. >> Zhamak: Yes, this is perhaps further into the future because just from where we stand, we have to create still that bridge of familiarity between that future and present. So we are still in that bridge-making mode, however, by just the basic notion of saying, "I'm going to put an API in front of my data, and that API today might be as primitive as a level of indirection as in you tell me what you want, tell me who you are, let me go process that, all the policies and lineage, and insert all of this intelligence that need to happen. And then I will, today, I will still give you a file. But by just defining that API and standardizing it, now we have this amazing extension point that we can say, "Well, the next revision of this API, you not just tell me who you are, but you actually tell me what intelligence you're after. What's a logic that I need to go and now compute on your API?" And you can kind of evolve that, right? Now you have a point of evolution to this very futuristic, I guess, future where you just describe the question that you're asking from the chat. >> Well, this is the Supercloud, Dave. >> I have a question from a fan, I got to get it in. It's George Gilbert. And so, his question is, you're blowing away the way we synchronize data from operational systems to the data stack to applications. So the concern that he has, and he wants your feedback on this, "Is the data product app devs get exposed to more complexity with respect to moving data between data products or maybe it's attributes between data products, how do you respond to that? How do you see, is that a problem or is that something that is overstated, or do you have an answer for that?" >> Zhamak: Absolutely. So I think there's a sweet spot in getting data developers, data product developers closer to the app, but yet not burdening them with the complexity of the application and application logic, and yet reducing their cognitive load by localizing what they need to know about which is that domain where they're operating within. Because what's happening right now? what's happening right now is that data engineers, a ton of empathy for them for their high threshold of pain that they can, you know, deal with, they have been centralized, they've put into the data team, and they have been given this unbelievable task of make meaning out of data, put semantic over it, curates it, cleans it, and so on. So what we are saying is that get those folks embedded into the domain closer to the application developers, these are still separately moving units. Your app and your data products are independent but yet tightly closed with each other, tightly coupled with each other based on the context of the domain, so reduce cognitive load by localizing what they need to know about to the domain, get them closer to the application but yet have them them separate from app because app provides a very different service. Transactional data for my e-commerce transaction, data product provides a very different service, longitudinal data for the, you know, variety of this intelligent analysis that I can do on the data. But yet, it's all within the domain of e-commerce or sales or whatnot. >> So a lot of decoupling and coupling create that cohesiveness. >> Zhamak: Absolutely. >> Architecture. So I have to ask you, this is an interesting question 'cause it came up on theCUBE all last year. Back on the old server, data center days and cloud, SRE, Google coined the term, "Site Reliability Engineer" for someone to look over the hundreds of thousands of servers. We asked a question to data engineering community who have been suffering, by the way, agree. Is there an SRE-like role for data? Because in a way, data engineering, that platform engineer, they are like the SRE for data. In other words, managing the large scale to enable automation and cell service. What's your thoughts and reaction to that? >> Zhamak: Yes, exactly. So, maybe we go through that history of how SRE came to be. So we had the first DevOps movement which was, remove the wall between dev and ops and bring them together. So you have one cross-functional units of the organization that's responsible for, you build it you run it, right? So then there is no, I'm going to just shoot my application over the wall for somebody else to manage it. So we did that, and then we said, "Okay, as we decentralized and had this many microservices running around, we had to create a layer that abstracted a lot of the complexity around running now a lot or monitoring, observing and running a lot while giving autonomy to this cross-functional team." And that's where the SRE, a new generation of engineers came to exist. So I think if I just look- >> Hence Borg, hence Kubernetes. >> Hence, hence, exactly. Hence chaos engineering, hence embracing the complexity and messiness, right? And putting engineering discipline to embrace that and yet give a cohesive and high integrity experience of those systems. So I think, if we look at that evolution, perhaps something like that is happening by bringing data and apps closer and make them these domain-oriented data product teams or domain oriented cross-functional teams, full stop, and still have a very advanced maybe at the platform infrastructure level kind of operational team that they're not busy doing two jobs which is taking care of domains and the infrastructure, but they're building infrastructure that is embracing that complexity, interconnectivity of this data process. >> John: So you see similarities. >> Absolutely, but I feel like we're probably in a more early days of that movement. >> So it's a data DevOps kind of thing happening where scales happening. It's good things are happening yet. Eh, a little bit fast and loose with some complexities to clean up. >> Yes, yes. This is a different restructure. As you said we, you know, the job of this industry as a whole on architects is decompose, recompose, decompose, recomposing a new way, and now we're like decomposing centralized team, recomposing them as domains and- >> John: So is data mesh the killer app for Supercloud? >> You had to do this for me. >> Dave: Sorry, I couldn't- (John and Dave laughing) >> Zhamak: What do you want me to say, Dave? >> John: Yes. >> Zhamak: Yes of course. >> I mean Supercloud, I think it's, really the terminology's Supercloud, Opencloud. But I think, in spirits of it, this embracing of diversity and giving autonomy for people to make decisions for what's right for them and not yet lock them in. I think just embracing that is baked into how data mesh assume the world would work. >> John: Well thank you so much for coming on Supercloud too, really appreciate it. Data has driven this conversation. Your success of data mesh has really opened up the conversation and exposed the slow moving data industry. >> Dave: Been a great catalyst. (John laughs) >> John: That's now going well. We can move faster, so thanks for coming on. >> Thank you for hosting me. It was wonderful. >> Okay, Supercloud 2 live here in Palo Alto. Our stage performance, I'm John Furrier with Dave Vellante. We're back with more after this short break, Stay with us all day for Supercloud 2. (gentle bright music)

>> Announcer: From the SiliconANGLE Media Office in Boston, Massachusetts it's theCUBE. Now, here's your host, Stu Miniman. >> Hi, I'm Stu Miniman and after many travels around the globe with theCUBE, really happy to be back in the Boston area studio, and happy to welcome to the program first time guest and first time we've had OpenLink on the program, Rich Grossi who's the CEO. Coming up from Long Island, appreciate you joining me up here and looking forward to discussing with you. >> Understood. >> So, first OpenLink, as I said, company, first time we've had on theCUBE. Why don't you give the audience a little bit of background, how long the company's been existing and what the focus is. >> Well, we're celebrating this year our 25th anniversary. So we serve the energy, financial, trading and treasury markets. We're based in Long Island with offices around the world serving about 500 clients or so in those different markets. I'm happy to be here today to talk about some of the innovation that we have going on. >> Great. Before we get into the OpenLink, Rich, give us a little bit about your background. You've been with OpenLink for a good part of the journey. >> I have. I've been with the company for 21 years in a variety of different roles. I've spent some time in operations, in development. Prior to the CEO position I spent some time in operations and prior to this role I was the CTO of the company. >> Okay, well congrats on the new role, Rich. So tell me, what is OpenLink today? You talked about kind of the industries you focus on. How do you fit in the markets today? >> So we are the market leader for the categories I mentioned. So we'll play in the energy and the commodity space. I will plan the financial services, banking, treasury space. We're well-known for our risk management capabilities and we serve top-tier clients in all those markets around the globe. >> Yeah, Rich, it's interesting. I think there's not a single segment in the market that's not going through some significant change. Disruption is on everyone's mind. What's changing for your customers and how is OpenLink really kind of adjusting to meet those needs? >> Yeah, it's always been a high degree of sensitivity towards risk. That's been our strong point as a company for a long time, and we serve the clients through kind of advanced analytics that provide them with that capability. But more frequently, we're seeing total cost of ownership driving a lot of the decisions made by our clients, right. So in markets that have some head wounds coming in and just kind of steady-state markets, looking for how to use technology to benefit them but also reduce the total cost of ownership. >> Okay, and so explain what that means. You say things like risk, things like analytics, you know, data, super important to all customers. How do we make sure they have the right data, how do they make sure that they're not getting a tax on what they have. Where does OpenLink help their-- what do the products look like? >> Yes, I mean, so we have a pretty advanced trading and risk-management platform. We also provide treasury and cash management solutions. And in those spaces what we're doing is we're providing our clients with the ability to manage their risk, manage their positions, take a peek ahead to see what's coming in the markets. Do sensitivity analysis to ensure that as they trade and as they train dex, and to your point, as they manage to the logistics. It's all done with a system capture from front to back, and it's all done with a view towards the risk of the application and a risk of the markets that they're in. >> Okay, you had a recent launch that was OpenCloud. Maybe explain what that is, how that fits with the broader discussion of Cloud. >> Sure, OpenLink's been in the private Cloudspace now for about 11 years. So this was our hosting application. And through those years, we built up the technology to support more of the, kind of, online, so predominantly we're a perpetual-based company, on-prem. And now our clients are looking for a little bit more ownership. A little bit more security. And they're looking for that single vendor to manage their applications within the could. So there's a big transformation in our markets where many of our large tier one energy financial services clients are looking for that reduction of total cost, and they're looking for OpenLink to be the provider that can offer them that service within the could environments. >> Okay, so is this a SAS offering? Is it living on some of the public Clouds? Help us, kind of, get our weeds a little bit. You're a former CTO. >> Sure, so, I mean, it's a similar technology to what we've built over the years. So, we're still managing scaleability and performance. We still have created security in the application. Still managing a lot of the monitoring and logging in application security within that. But it is in the Microsoft Azure environment, so we're working with Microsoft, partnered with them to build up a Cloud environment for our customers, such as they can manage this remotely as you would in any Cloud environment, and then provide all the advantages of Microsoft Azure on top of the technology that OpenLinks built over time. >> Okay, so it sounds, you know, similar to what you were doing before, but a lot of changes. How organizationally do you have to change for this, and maybe walk us through a customer, why would they choose one versus the other? What are the big advantages of the new way? >> Sure, so organizationally, we do have Cloud-dedicated teams now, right? So a lot of knowledge required to take your product, not only Cloud-enable it, but make it feature functionality-rich for the clients within the could. So we've built Cloud operations teams, we built SOx and NOx. We leverage our employee base around the world. We put a lot of technology advantages into the new software that is Cloud enabled. So, things like performance is just a big topic for us. So, allowing our clients to drive greater performance through scaleability and dynamic scaleability within the could. That's a big advantage to our clients. >> Yeah, you think back a couple of years ago if you talked about Microsoft and Google, and the Amazons of the world, it's like, 'Well, I'm worried about the security, the government is challenging.' I was just at one of the bigger Cloud shows and they said security is actually opportunity. You get to kind of get a re-do on security. Government seems to be something that we're sort of doing-- what's your customer's experiences? Is there still hesitancy, or are people, you know, kind of jumping in the waters nice? >> Well, I think there's still the question, and I think it's changing very rapidly for our client base. So, a couple years ago our clients were interested in the could but not necessarily moving to the could. And I think you're absolutely right in the sense that some of them were concerned about the security of their trading data being out in something like Microsoft Azure. Many of them recognize today that the security benefits of a Microsoft Azure, as an example, could be far greater than what they're doing in-house today. And as you look at the technology of OpenLink we've built layers of security on top of everything we used to have within the core application, encryption and the like. And now using some of the key vault technologies and some of the scaleability technologies of Microsoft Azure, we feel like we're able to provide a higher level of security than they even have on-prem using the could up close. >> Yeah, one of the other big advantages if you plug into, kind of, that ecosystem and platform of the public Cloud, what opportunities there-- Microsoft, you think of, like, you know, active directory, all of the business functionality. What do you gain today and maybe give us a little roadmap as to what this looks like down the road? >> Yeah, so our clients are looking for a handful of things. So they're looking for that reductioning of ownership. We've been able to save them on average about 30 per cent, just coming from them their on-prem or their data centers today. They're also looking for that single source of support. So today, we're working with their network engineers and they're DBAs. In the could version we're able to provide them with those same services, coupled with our support applications so that we're providing single line of visibility into their overall trading and risk-management application. And they're also looking for performances, I mentioned before, and security. So with the could application, we're not only able to provide them with the feature functionality of our application, but also the could technology that sits around it. >> One of the other things if you look at, kind of managing the environment versus going to the public Cloud, usually the public Cloud, you know the joke I have is: What version of Azure are you running on? Well, Microsoft takes care of it. A similar thing in your environment? >> Very similar. So, the ability to upgrade, the ability to leverage the scaleability of Microsoft Azure, the new technology coming out in Microsoft Azure. All the could feature functionality, that all comes with it for free. And to your point, providing our clients with a manage service so that we can manage not only their day-to-day environment, but we can also manage the infrastructure and the business needs that they have in using our application. So, all that combined has provided our clients with a great leg up in terms of how they use our software and how they manage it moving forward. >> Yeah, I'm curious: do the customers have to choose one over the other? The on-prem or the could? Do you have some customers that may be migrating, being to the Hybrid Multi-Cloud is kind of a big issue for a lot of customers these days. >> Yeah. So we have a large number of clients today that are still on-prem, and they're probably staying on-prem for awhile. But the evolution of the could as it relates to our client-base is quite rapid. So, a couple years ago we would talk to our clients and they were interested. Last year we announced our proof of concept coming and what we were building. We launched our public Cloud just in quarter three of this year. And the feedback from our client-base was dramatic. So now they're all looking to migrate over. We respond to ROPs quite often and I would estimate maybe about nine per cent of those coming have some interest in the public cloud moving forward. >> Okay, Rich, what do you want your clients to really know about OpenLink? And, the two pieces, just kind of today, and if they knew OpenLink, say, five years ago. You know, what's the big change? >> Yeah, well I think, well we have a tagline that says we like to solve the complex, right? And make it simple. You'll see many of our clients, the bigger names, avengers that are out there using our software to solve really complicated problems, right? So our software is pretty configurable and also addresses some of the larger challenges that we have within the spaces that OpenLink sits in. So, our clients are well-known in that area, and OpenLink is well-known in there, and our ability to solve those problems. When you take that, and you take the total cost of ownership, and you take the public Cloud capabilities and you build all that technology that we've advanced over the past, you know, 25 years, it's a pretty compelling application and company that we work for. >> Alright, well, Rich, appreciate the updates on everything happening at OpenLink. Wish you the best of luck with the could offering. We'll be back with more coverage here. Always check out thecube.net for all the coverage, and thanks for watching this, theCUBE. (upbeat techno music)