>> Welcome back to Supercloud22, #Supercloud22. This is Dave Vellante. In 2019 Oracle and Microsoft announced a collaboration to bring interoperability between OCI, Oracle Cloud Infrastructure and Azure Clouds. It was Oracle's initial foray into so-called multi-cloud and we're joined by Karan Batta, who's the Vice President for Product Management at OCI. And Kris Rice is the Vice President of Software Development at Oracle Database. And we're going to talk about how this technology's evolving and whether it fits our view of what we call supercloud. Welcome gentlemen, thank you. >> Thanks for having us. >> So you recently just last month announced the new service. It extends on the initial partnership with Microsoft Oracle interconnect with Azure, and you refer to this as a secure private link between the two clouds, it cross 11 regions around the world, under two milliseconds data transmission sounds pretty cool. It enables customers to run Microsoft applications against data stored in Oracle databases without any loss in efficiency or presumably performance. So we use this term supercloud to describe a service or sets of services built on hyper scale infrastructure that leverages the core primitives and APIs of an individual cloud platform, but abstracts that underlying complexity to create a continuous experience across more than one cloud. Is that what you've done? >> Absolutely. I think it starts at the top layer in terms of just making things very simple for the customer, right. I think at the end of the day we want to enable true workloads running across two different clouds where you're potentially running maybe the app layer in one and the database layer or the back in another. And the integration I think starts with, you know, making it ease of use. Right. So you can start with things like, okay can you log into your second or your third cloud with the first cloud provider's credentials? Can you make calls against another cloud using another cloud's APIs? Can you peer the networks together? Can you make it seamless? I think those are all the components that are sort of, they're kind of the ingredients to making a multi-cloud or supercloud experience successful. >> Oh, thank you for that, Karan. So I guess there's a question for Chris is I'm trying to understand what you're really solving for? What specific customer problems are you focused on? What's the service optimized for presumably it's database but maybe you could double click on that. >> Sure. So, I mean, of course it's database. So it's a super fast network so that we can split the workload across two different clouds leveraging the best from both, but above the networking, what we had to do do is we had to think about what a true multi-cloud or what you're calling supercloud experience would be it's more than just making the network bites flow. So what we did is we took a look as Karan hinted at right, is where is my identity? Where is my observability? How do I connect these things across how it feels native to that other cloud? >> So what kind of engineering do you have to do to make that work? It's not just plugging stuff together. Maybe you could explain a little bit more detail, the the resources that you had to bring to bear and the technology behind the architecture. >> Sure. I think, it starts with actually, what our goal was, right? Our goal was to actually provide customers with a fully managed experience. What that means is we had to basically create a brand new service. So, we have obviously an Azure like portal and an experience that allows customers to do this but under the covers, we actually have a fully managed service that manages the networking layer, the physical infrastructure, and it actually calls APIs on both sides of the fence. It actually manages your Azure resources, creates them but it also interacts with OCI at the same time. And under the covers this service actually takes Azure primitives as inputs. And then it sort of like essentially translates them to OCI action. So, we actually truly integrated this as a service that's essentially built as a PaaS layer on top of these two clouds. >> So, the customer doesn't really care or know maybe they know cuz they might be coming through, an Azure experience, but you can run work on either Azure and or OCI. And it's a common experience across those clouds. Is that correct? >> That's correct. So like you said, the customer does know that they know there is a relationship with both clouds but thanks to all the things we built there's this thing we invented we created called a multi-cloud control plane. This control plane does operate against both clouds at the same time to make it as seamless as possible so that maybe they don't notice, you know, the power of the interconnect is extremely fast networking, as fast as what we could see inside a single cloud. If you think about how big a data center might be from edge to edge in that cloud, going across the interconnect makes it so that that workload is not important that it's spanning two clouds anymore. >> So you say extremely fast networking. I remember I used to, I wrote a piece a long time ago. Larry Ellison loves InfiniBand. I presume we've moved on from them, but maybe not. What is that interconnect? >> Yeah, so it's funny you mentioned interconnect you know, my previous history comes from Edge PC where we actually inside OCI today, we've moved from Infinite Band as is part of Exadata's core to what we call Rocky V two. So that's just another RDMA network. We actually use it very successfully, not just for Exadata but we use it for our standard computers that we provide to high performance computing customers. >> And the multi-cloud control plane runs. Where does that live? Does it live on OCI? Does it live on Azure? Yes? >> So it does it lives on our side. Our side of the house as part of our Oracle OCI control plane. And it is the veneer that makes these two clouds possible so that we can wire them together. So it knows how to take those Azure primitives and the OCI primitives and wire them at the appropriate levels together. >> Now I want to talk about this PaaS layer. Part of supercloud, we said to actually make it work you're going to have to have a super PaaS. I know we're taking this this term a little far but it's still it's instructive in that, what we surmised was you're probably not going to just use off the shelf, plain old vanilla PaaS, you're actually going to have a purpose built PaaS to solve for the specific problem. So as an example, if you're solving for ultra low latency, which I think you're doing, you're probably no offense to my friends at Red Hat but you're probably not going to develop this on OpenShift, but tell us about that PaaS layer or what we call the super PaaS layer. >> Go ahead, Chris. >> Well, so you're right. We weren't going to build it out on OpenShift. So we have Oracle OCI, you know, the standard is Terraform. So the back end of everything we do is based around Terraform. Today, what we've done is we built that control plane and it will be API drivable, it'll be drivable from the UI and it will let people operate and create primitives across both sides. So you can, you mentioned developers, developers love automation, right, because it makes our lives easy. We will be able to automate a multi-cloud workload from ground up config is code these days. So we can config an entire multi-cloud experience from one place. >> So, double click Chris on that developer experience. What is that like? They're using the same tool set irrespective of, which cloud we're running on is, and it's specific to this service or is it more generic, across other Oracle services? >> There's two parts to that. So one is the, we've only onboarded a portion. So the database portfolio and other services will be coming into this multi-cloud. For the majority of Oracle cloud, the automation, the config layer is based on Terraform. So using Terraform, anyone can configure everything from a mid-tier to an Exadata, all the way soup to nuts from smallest thing possible to the largest. What we've not done yet is integrated truly with the Azure API, from command line drivable. That is coming in the future. It is on the roadmap, it is coming. Then they could get into one tool but right now they would have half their automation for the multi-cloud config on the Azure tool set and half on the OCI tool set. >> But we're not crazy saying from a roadmap standpoint that will provide some benefit to developers and is a reasonable direction for the industry generally but Oracle and Microsoft specifically. >> Absolutely. I'm a developer at heart. And so one of the things we want to make sure is that developers' lives are as easy as possible. >> And is there a metadata management layer or intelligence that you've built in to optimize for performance or low latency or cost across the respective clouds? >> Yeah, definitely. I think, latency's going to be an important factor. The service that we've initially built isn't going to serve, the sort of the tens of microseconds but most applications that are sort of in, running on top of the enterprise applications that are running on top of the database are in the several millisecond range. And we've actually done a lot of work on the networking pairing side to make sure that when we launch these resources across the two clouds we actually picked the right trial site. We picked the right region we pick the right availability zone or domain. So we actually do the due diligence under the cover so the customer doesn't have to do the trial and error and try to find the right latency range. And this is actually one of the big reasons why we only launch the service on the interconnect regions. Even though we have close to, I think close to 40 regions at this point in OCI, this service is only built for the regions that we have an interconnect relationship with Microsoft. >> Okay, so you started with Microsoft in 2019. You're going deeper now in that relationship, is there any reason that you couldn't, I mean technically what would you have to do to go to other clouds? You talked about understanding the primitives and leveraging the primitives of Azure. Presumably if you wanted to do this with AWS or Google or Alibaba, you would have to do similar engineering work, is that correct? Or does what you've developed just kind of poured over to any cloud? >> Yeah, that's absolutely correct Dave. I think Chris talked a lot about the multi-cloud control plane, right? That's essentially the control plane that goes and does stuff on other clouds. We would have to essentially go and build that level of integration into the other clouds. And I think, as we get more popularity and as more products come online through these services I think we'll listen to what customers want. Whether it's, maybe it's the other way around too, Dave maybe it's the fact that they want to use Oracle cloud but they want to use other complimentary services within Oracle cloud. So I think it can go both ways. I think, the market and the customer base will dictate that. >> Yeah. So if I understand that correctly, somebody from another cloud Google cloud could say, Hey we actually want to run this service on OCI cuz we want to expand our market. And if TK gets together with his old friends and figures that out but then we're just, hypothesizing here. But, like you said, it can go both ways. And then, and I have another question related to that. So, multi clouds. Okay, great. Supercloud. How about the Edge? Do you ever see a day where that becomes part of the equation? Certainly the near Edge would, you know, a Home Depot or Lowe's store or a bank, but what about the far Edge, the tiny Edge. Can you talk about the Edge and where that fits in your vision? >> Yeah, absolutely. I think Edge is a interestingly, it's getting fuzzier and fuzzier day by day. I think, the term. Obviously every cloud has their own sort of philosophy in what Edge is, right. We have our own. It starts from, if you do want to do far Edge, we have devices like red devices, which is our ruggedized servers that talk back to our control plane in OCI. You could deploy those things unlike, into war zones and things like that underground. But then we also have things like clouded customer where customers can actually deploy components of our infrastructure like compute or Exadata into a facility where they only need that certain capability. And then a few years ago we launched, what's now called Dedicated Region. And that actually is a different take on Edge in some sense where you get the entire capability of our public commercial region, but within your facility. So imagine if a customer was to essentially point a finger on a commercial map and say, Hey, look, that region is just mine. Essentially that's the capability that we're providing to our customers, where if you have a white space if you have a facility, if you're exiting out of your data center space, you could essentially place an OCI region within your confines behind your firewall. And then you could interconnect that to a cloud provider if you wanted to, and get the same multi-cloud capability that you get in a commercial region. So we have all the spectrums of possibilities here. >> Guys, super interesting discussion. It's very clear to us that the next 10 years of cloud ain't going to be like the last 10. There's a whole new layer. Developing, data is a big key to that. We see industries getting involved. We obviously didn't get into the Oracle Cerner acquisitions. It's a little too early for that but we've actually predicted that companies like Cerner and you're seeing it with Goldman Sachs and Capital One they're actually building services on the cloud. So this is a really exciting new area and really appreciate you guys coming on the Supercloud22 event and sharing your insights. Thanks for your time. >> Thanks for having us. >> Okay. Keep it right there. #Supercloud22. We'll be right back with more great content right after this short break. (lighthearted marimba music)

(cheerful music) >> Hello everyone, welcome to today's session of theCUBE's presentation of AWS Startup Showcase, New Breakthroughs in DevOps, Data Analytics, Cloud Management Tools, featuring Okera from the cloud management migration track. I'm John Furrier, your host. We've got two great special guests today, Nong Li, founder and CTO of Okera, and Sanjeev Mohan, principal @SanjMo, and former research vice president of big data and advanced analytics at Gartner. He's a legend, been around the industry for a long time, seen the big data trends from the past, present, and knows the future. Got a great lineup here. Gentlemen, thank you for this, so, life in the trenches, lessons learned across compliance, cloud migration, analytics, and use cases for Fortune 1000s. Thanks for joining us. >> Thanks for having us. >> So Sanjeev, great to see you, I know you've seen this movie, I was saying that in the open, you've at Gartner seen all the visionaries, the leaders, you know everything about this space. It's changing extremely fast, and one of the big topics right out of the gate is not just innovation, we'll get to that, that's the fun part, but it's the regulatory compliance and audit piece of it. It's keeping people up at night, and frankly if not done right, slows things down. This is a big part of the showcase here, is to solve these problems. Share us your thoughts, what's your take on this wide-ranging issue? >> So, thank you, John, for bringing this up, and I'm so happy you mentioned the fact that, there's this notion that it can slow things down. Well I have to say that the old way of doing governance slowed things down, because it was very much about control and command. But the new approach to data governance is actually in my opinion, it's liberating data. If you want to democratize or monetize, whatever you want to call it, you cannot do it 'til you know you can trust said data and it's governed in some ways, so data governance has actually become very interesting, and today if you want to talk about three different areas within compliance regulatory, for example, we all know about the EU GDPR, we know California has CCPA, and in fact California is now getting even a more stringent version called CPRA in a couple of years, which is more aligned to GDPR. That is a first area we know we need to comply to that, we don't have any way out. But then, there are other areas, there is insider trading, there is how you secure the data that comes from third parties, you know, vendors, partners, suppliers, so Nong, I'd love to hand it over to you, and see if you can maybe throw some light into how our customers are handling these use cases. >> Yeah, absolutely, and I love what you said about balancing agility and liberating, in the face of what may be seen as things that slow you down. So we work with customers across verticals with old and new regulations, so you know, you brought up GDPR. One of our clients is using this to great effect to power their ecosystem. They are a very large retail company that has operations and customers across the world, obviously the importance of GDPR, and the regulations that imposes on them are very top of mind, and at the same time, being able to do effective targeting analytics on customer information is equally critical, right? So they're exactly at that spot where they need this customer insight for powering their business, and then the regulatory concerns are extremely prevalent for them. So in the context of GDPR, you'll hear about things like consent management and right to be forgotten, right? I, as a customer of that retailer should say "I don't want my information used for this purpose," right? "Use it for this, but not this." And you can imagine at a very, very large scale, when you have a billion customers, managing that, all the data you've collected over time through all of your devices, all of your telemetry, really, really challenging. And they're leveraging Okera embedded into their analytics platform so they can do both, right? Their data scientists and analysts who need to do everything they're doing to power the business, not have to think about these kind of very granular customer filtering requirements that need to happen, and then they leverage us to do that. So that's kind of new, right, GDPR, relatively new stuff at this point, but we obviously also work with customers that have regulations from a long long time ago, right? So I think you also mentioned insider trading and that supply chain, so we'll talk to customers, and they want really data-driven decisions on their supply chain, everything about their production pipeline, right? They want to understand all of that, and of course that makes sense, whether you're the CFO, if you're going to make business decisions, you need that information readily available, and supply chains as we know get more and more and more complex, we have more and more integrated into manufacturing and other verticals. So that's your, you're a little bit stuck, right? You want to be data-driven on those supply chain analytics, but at the same time, knowing the details of all the supply chain across all of your dependencies exposes your internal team to very high blackout periods or insider trading concerns, right? For example, if you knew Apple was buying a bunch of something, that's maybe information that only a select few people can have, and the way that manifests into data policies, 'cause you need the ability to have very, very scalable, per employee kind of scalable data restriction policies, so they can do their job easier, right? If we talk about speeding things up, instead of a very complex process for them to get approved, and approved on SEC regulations, all that kind of stuff, you can now go give them access to the part of the supply chain that they need, and no more, and limit their exposure and the company's exposure and all of that kind of stuff. So one of our customers able to do this, getting two orders of magnitude, a 100x reduction in the policies to manage the system like that. >> When I hear you talking like that, I think the old days of "Oh yeah, regulatory, it kind of slows down innovation, got to go faster," pretty basic variables, not a lot of combination of things to check. Now with cloud, there seems to be combinations, Sanjeev, because how complicated has the regulatory compliance and audit environment gotten in the past few years, because I hear security in a supply chain, I hear insider threats, I mean these are security channels, not just compliance department G&A kind of functions. You're talking about large-scale, potentially combinations of access, distribution, I mean it seems complicated. How much more complicated is it now, just than it was a few years ago? >> So, you know the way I look at it is, I'm just mentioning these companies just as an example, when PayPal or Ebay, all these companies started, they started in California. Anybody who ever did business on Ebay or PayPal, guess where that data was? In the US in some data center. Today you cannot do it. Today, data residency laws are really tough, and so now these organizations have to really understand what data needs to remain where. On top of that, we now have so many regulations. You know, earlier on if you were healthcare, you needed to be HIPAA compliant, or banking PCI DSS, but today, in the cloud, you really need to know, what data I have, what sensitive data I have, how do I discover it? So that data discovery becomes really important. What roles I have, so for example, let's say I work for a bank in the US, and I decide to move to Germany. Now, the old school is that a new rule will be created for me, because of German... >> John: New email address, all these new things happen, right? >> Right, exactly. So you end up with this really, a mass of rules and... And these are all static. >> Rules and tools, oh my god. >> Yeah. So Okera actually makes a lot of this dynamic, which reduces your cloud migration overhead, and Nong used some great examples, in fact, sorry if I take just a second, without mentioning any names, there's one of the largest banks in the world is going global in the digital space for the first time, and they're taking Okera with them. So... >> But what's the point? This is my next topic in cloud migration, I want to bring this up because, complexity, when you're in that old school kind of data center, waterfall, these old rules and tools, you have to roll this out, and it's a pain in the butt for everybody, it's a hassle, huge hassle. Cloud gives the agility, we know that, and cloud's becoming more secure, and I think now people see the on-premise, certainly things that'd be on-premises for secure things, I get that, but when you start getting into agility, and you now have cloud regions, you can start being more programmatic, so I want to get you guys' thoughts on the cloud migration, how companies who are now lifting and shifting, replatforming, what's the refactoring beyond that, because you can replatform in the cloud, and still some are kind of holding back on that. Then when you're in the cloud, the ones that are winning, the companies that are winning are the ones that are refactoring in the cloud. Doing things different with new services. Sanjeev, you start. >> Yeah, so you know, in fact lot of people tell me, "You know, we are just going to lift and shift into the cloud." But you're literally using cloud as a data center. You still have all the, if I may say, junk you had on-prem, you just moved it into the cloud, and now you're paying for it. In cloud, nothing is free. Every storage, every processing, you're going to pay for it. The most successful companies are the ones that are replatforming, they are taking advantage of the platform as a service or software as a service, so that includes things like, you pay as you go, you pay for exactly the amount you use, so you scale up and scale down or scale out and scale in, pretty quickly, you know? So you're handling that demand, so without replatforming, you are not really utilizing your- >> John: It's just hosting. >> Yeah, you're just hosting. >> It's basically hosting if you're not doing anything right there. >> Right. The reason why people sometimes resist to replatform, is because there's a hidden cost that we don't really talk about, PaaS adds 3x to IaaS cost. So, some organizations that are very mature, and they have a few thousand people in the IT department, for them, they're like "No, we just want to run it in the cloud, we have the expertise, and it's cheaper for us." But in the long run, to get the most benefit, people should think of using cloud as a service. >> Nong what's your take, because you see examples of companies, I'll just call one out, Snowflake for instance, they're essentially a data warehouse in the cloud, they refactored and they replatformed, they have a competitive advantage with the scale, so they have things that others don't have, that just hosting. Or even on-premise. The new model developing where there's real advantages, and how should companies think about this when they have to manage these data lakes, and they have to manage all these new access methods, but they want to maintain that operational stability and control and growth? >> Yeah, so. No? Yeah. >> There's a few topics that are all (indistinct) this topic. (indistinct) enterprises moving to the cloud, they do this maybe for some cost savings, but a ton of it is agility, right? The motor that the business can run at is just so much faster. So we'll work with companies in the context of cloud migration for data, where they might have a data warehouse they've been using for 20 years, and building policies over that time, right? And it's taking a long time to go proof of access and those kind of things, made more sense, right? If it took you months to procure a physical infrastructure, get machines shipped to your data center, then this data access taking so long feels okay, right? That's kind of the same rate that everything is moving. In the cloud, you can spin up new infrastructure instantly, so you don't want approvals for getting policies, creating rules, all that stuff that Sanjeev was talking about, that being slow is a huge, huge problem. So this is a very common environment that we see where they're trying to do that kind of thing. And then, for replatforming, again, they've been building these roles and processes and policies for 20 years. What they don't want to do is take 20 years to go migrate all that stuff into the cloud, right? That's probably an experience nobody wants to repeat, and frankly for many of them, people who did it originally may or may not be involved in this kind of effort. So we work with a lot of companies like that, they have their, they want stability, they got to have the business running as normal, they got to get moving into the new infrastructure, doing it in a new way that, you know, with all the kind of lessons learned, so, as Sanjeev said, one of these big banks that we work with, that classical story of on-premise data warehousing, maybe a little bit of Hadoop, moved onto AWS, S3, Snowflake, that kind of setup, extremely intricate policies, but let's go reimagine how we can do this faster, right? What we like to talk about is, you're an organization, you need a design that, if you onboarded 1000 more data users, that's got to be way, way easier than the first 10 you onboarded, right? You got to get it to be easier over time, in a really, really significant way. >> Talk about the data authorization safety factor, because I can almost imagine all the intricacies of these different tools creates specialism amongst people who operate them. And each one might have their own little authorization nuance. Trend is not to have that siloed mentality. What's your take on clients that want to just "Hey, you know what? I want to have the maximum agility, but I don't want to get caught in the weeds on some of these tripwires around access and authorization." >> Yeah, absolutely, I think it's real important to get the balance of it, right? Because if you are an enterprise, or if you have diversive teams, you want them to have the ability to use tools as best of breed for their purpose, right? But you don't want to have it be so that every tool has its own access and provisioning and whatever, that's definitely going to be a security, or at least, a lot of friction for you to get things going. So we think about that really hard, I think we've seen great success with things like SSO and Okta, right? Unifying authentication. We think there's a very, very similar thing about to happen with authorization. You want that single control plane that can integrate with all the tools, and still get the best of what you need, but it's much, much easier (indistinct). >> Okta's a great example, if people don't want to build their own thing and just go with that, same with what you guys are doing. That seems to be the dots that are connecting you, Sanjeev. The ease of use, but yet the stability factor. >> Right. Yeah, because John, today I may want to bring up a SQL editor to go into Snowflake, just as an example. Tomorrow, I may want to use the Azure Bot, you know? I may not even want to go to Snowflake, I may want to go to an underlying piece of data, or I may use Power BI, you know, for some reason, and come from Azure side, so the point is that, unless we are able to control, in some sort of a centralized manner, we will not get that consistency. And security you know is all or nothing. You cannot say "Well, I secured my Snowflake, but if you come through HTFS, Hadoop, or some, you know, that is outside of my realm, or my scope," what's the point? So that is why it is really important to have a watertight way, in fact I'm using just a few examples, maybe tomorrow I decide to use a data catalog, or I use Denodo as my data virtualization and I run a query. I'm the same identity, but I'm using different tools. I may use it from home, over VPN, or I may use it from the office, so you want this kind of flexibility, all encompassed in a policy, rather than a separate rule if you do this and this, if you do that, because then you end up with literally thousands of rules. >> And it's never going to stop, either, it's like fashion, the next tool's going to come out, it's going to be cool, and people are going to want to use it, again, you don't want to have to then move the train from the compliance side this way or that way, it's a lot of hassle, right? So we have that one capability, you can bring on new things pretty quickly. Nong, am I getting it right, this is kind of like the trend, that you're going to see more and more tools and/or things that are relevant or, certain use cases that might justify it, but yet, AppSec review, compliance review, I mean, good luck with that, right? >> Yeah, absolutely, I mean we certainly expect tools to continue to get more and more diverse, and better, right? Most innovation in the data space, and I think we... This is a great time for that, a lot of things that need to happen, and so on and so forth. So I think one of the early goals of the company, when we were just brainstorming, is we don't want data teams to not be able to use the tools because it doesn't have the right security (indistinct), right? Often those tools may not be focused on that particular area. They're great at what they do, but we want to make sure they're enabled, they do some enterprise investments, they see broader adoption much easier. A lot of those things. >> And I can hear the sirens in the background, that's someone who's not using your platform, they need some help there. But that's the case, I mean if you don't get this right, there are some consequences, and I think one of the things I would like to bring up on next track is, to talk through with you guys is, the persona pigeonhole role, "Oh yeah, a data person, the developer, the DevOps, the SRE," you start to see now, developers and with cloud developers, and data folks, people, however they get pigeonholed, kind of blending in, okay? You got data services, you got analytics, you got data scientists, you got more democratization, all these things are being kicked around, but the notion of a developer now is a data developer, because cloud is about DevOps, data is now a big part of it, it's not just some department, it's actually blending in. Just a cultural shift, can you guys share your thoughts on this trend of data people versus developers now becoming kind of one, do you guys see this happening, and if so, how? >> So when, John, I started my career, I was a DBA, and then a data architect. Today, I think you cannot have a DBA who's not a developer. That's just my opinion. Because there is so much of CICD, DevOps, that happens today, and you know, you write your code in Python, you put it in version control, you deploy using Jenkins, you roll back if there's a problem. And then, you are interacting, you're building your data to be consumed as a service. People in the past, you would have a thick client that would connect to the database over TCP/IP. Today, people don't want to connect over TCP/IP necessarily, they want to go by HTTP. And they want an API gateway in the middle. So, if you're a data architect or DBA, now you have to worry about, "I have a REST API call that's coming in, how am I going to secure that, and make sure that people are allowed to see that?" And that was just yesterday. >> Exactly. Got to build an abstraction layer. You got to build an abstraction layer. The old days, you have to worry about schema, and do all that, it was hard work back then, but now, it's much different. You got serverless, functions are going to show way... It's happening. >> Correct, GraphQL, and semantic layer, that just blows me away because, it used to be, it was all in database, then we took it out of database and we put it in a BI tool. So we said, like BusinessObjects started this whole trend. So we're like "Let's put the semantic layer there," well okay, great, but that was when everything was surrounding BusinessObjects and Oracle Database, or some other database, but today what if somebody brings Power BI or Tableau or Qlik, you know? Now you don't have a semantic layer access. So you cannot have it in the BI layer, so you move it down to its own layer. So now you've got a semantic layer, then where do you store your metrics? Same story repeats, you have a metrics layer, then the data centers want to do feature engineering, where do you store your features? You have a feature store. And before you know, this stack has disaggregated over and over and over, and then you've got layers and layers of specialization that are happening, there's query accelerators like Dremio or Trino, so you've got your data here, which Nong is trying really hard to protect, and then you've got layers and layers and layers of abstraction, and networks are fast, so the end user gets great service, but it's a nightmare for architects to bring all these things together. >> How do you tame the complexity? What's the bottom line? >> Nong? >> Yeah, so, I think... So there's a few things you need to do, right? So, we need to re-think how we express security permanence, right? I think you guys have just maybe in passing (indistinct) talked about creating all these rules and all that kind of stuff, that's been the way we've done things forever. We get to think about policies and mechanisms that are much more dynamic, right? You need to really think about not having to do any additional work, for the new things you add to the system. That's really, really core to solving the complexity problem, right? 'Cause that gets you those orders of magnitude reduction, system's got to be more expressive and map to those policies. That's one. And then second, it's got to be implemented at the right layer, right, to Sanjeev's point, close to the data, and it can service all of those applications and use cases at the same time, and have that uniformity and breadth of support. So those two things have to happen. >> Love this universal data authorization vision that you guys have. Super impressive, we had a CUBE Conversation earlier with Nick Halsey, who's a veteran in the industry, and he likes it. That's a good sign, 'cause he's seen a lot of stuff, too, Sanjeev, like yourself. This is a new thing, you're seeing compliance being addressed, and with programmatic, I'm imagining there's going to be bots someday, very quickly with AI that's going to scale that up, so they kind of don't get in the innovation way, they can still get what they need, and enable innovation. You've got cloud migration, which is only going faster and faster. Nong, you mentioned speed, that's what CloudOps is all about, developers want speed, not things in days or hours, they want it in minutes and seconds. And then finally, ultimately, how's it scale up, how does it scale up for the people operating and/or programming? These are three major pieces. What happens next? Where do we go from here, what's, the customer's sitting there saying "I need help, I need trust, I need scale, I need security." >> So, I just wrote a blog, if I may diverge a bit, on data observability. And you know, so there are a lot of these little topics that are critical, DataOps is one of them, so to me data observability is really having a transparent view of, what is the state of your data in the pipeline, anywhere in the pipeline? So you know, when we talk to these large banks, these banks have like 1000, over 1000 data pipelines working every night, because they've got that hundred, 200 data sources from which they're bringing data in. Then they're doing all kinds of data integration, they have, you know, we talked about Python or Informatica, or whatever data integration, data transformation product you're using, so you're combining this data, writing it into an analytical data store, something's going to break. So, to me, data observability becomes a very critical thing, because it shows me something broke, walk me down the pipeline, so I know where it broke. Maybe the data drifted. And I know Okera does a lot of work in data drift, you know? So this is... Nong, jump in any time, because I know we have use cases for that. >> Nong, before you get in there, I just want to highlight a quick point. I think you're onto something there, Sanjeev, because we've been reporting, and we believe, that data workflows is intellectual property. And has to be protected. Nong, go ahead, your thoughts, go ahead. >> Yeah, I mean, the observability thing is critically important. I would say when you want to think about what's next, I think it's really effectively bridging tools and processes and systems and teams that are focused on data production, with the data analysts, data scientists, that are focused on data consumption, right? I think bridging those two, which cover a lot of the topics we talked about, that's kind of where security almost meets, that's kind of where you got to draw it. I think for observability and pipelines and data movement, understanding that is essential. And I think broadly, on all of these topics, where all of us can be better, is if we're able to close the loop, get the feedback loop of success. So data drift is an example of the loop rarely being closed. It drifts upstream, and downstream users can take forever to figure out what's going on. And we'll have similar examples related to buy-ins, or data quality, all those kind of things, so I think that's really a problem that a lot of us should think about. How do we make sure that loop is closed as quickly as possible? >> Great insight. Quick aside, as the founder CTO, how's life going for you, you feel good? I mean, you started a company, doing great, it's not drifting, it's right in the stream, mainstream, right in the wheelhouse of where the trends are, you guys have a really crosshairs on the real issues, how you feeling, tell us a little bit about how you see the vision. >> Yeah, I obviously feel really good, I mean we started the company a little over five years ago, there are kind of a few things that we bet would happen, and I think those things were out of our control, I don't think we would've predicted GDPR security and those kind of things being as prominent as they are. Those things have really matured, probably as best as we could've hoped, so that feels awesome. Yeah, (indistinct) really expanded in these years, and it feels good. Feels like we're in the right spot. >> Yeah, it's great, data's competitive advantage, and certainly has a lot of issues. It could be a blocker if not done properly, and you're doing great work. Congratulations on your company. Sanjeev, thanks for kind of being my cohost in this segment, great to have you on, been following your work, and you continue to unpack it at your new place that you started. SanjMo, good to see your Twitter handle taking on the name of your new firm, congratulations. Thanks for coming on. >> Thank you so much, such a pleasure. >> Appreciate it. Okay, I'm John Furrier with theCUBE, you're watching today's session presentation of AWS Startup Showcase, featuring Okera, a hot startup, check 'em out, great solution, with a really great concept. Thanks for watching. (calm music)

(upbeat music) Developers have become the new king makers in the world of digital and cloud. The rise of containers and microservices has accelerated the transition to cloud native applications. A lot of people will talk about application architecture and the related paradigms and the benefits they bring for the process of writing and delivering new apps. But a major challenge continues to be, the how and the what when it comes to accessing, processing and getting insights from the massive amounts of data that we have to deal with in today's world. And with me are two experts from the data management world who will share with us how they think about the best techniques and practices based on what they see at large organizations who are working with data and developing so-called data-driven apps. Please welcome Maria Colgan and Gerald Venzl, two distinguish product managers from Oracle. Folks, welcome, thanks so much for coming on. >> Thanks for having us Dave. >> Thank you very much for having us. >> Okay, Maria let's start with you. So, we throw around this term data-driven, data-driven applications. What are we really talking about there? >> So data-driven applications are applications that work on a diverse set of data. So anything from spatial to sensor data, document data as well as your usual transaction processing data. And what they're going to do is they'll generate value from that data in very different ways to a traditional application. So for example, they may use machine learning, they are able to do product recommendations in the middle of a transaction. Or we could use graph to be able to identify an influencer within the community so we can target them with a specific promotion. It could also use spatial data to be able to help find the nearest stores to a particular customer. And because these apps are deployed on multiple platforms, everything from mobile devices as well as standard browsers, they need a data platform that's going to be both secure, reliable and scalable. >> Well, so when you think about how the workloads are shifting I mean, we're not talking about, you know it's not anymore a world of just your ERP or your HCM or your CRM, you know kind of the traditional operational systems. You really are seeing an explosion of these new data oriented apps. You're seeing, you know, modeling in the cloud, you are going to see more and more inferencing, inferencing at the edge. But Maria maybe you could talk a little bit about sort of the benefits that customers are seeing from developing these types of applications. I mean, why should people care about data-driven apps? >> Oh, for sure, there's massive benefits to them. I mean, probably the most obvious one for any business regardless of the industry, is that they not only allow you to understand what your customers are up to, but they allow you to be able to anticipate those customer's needs. So that helps businesses maintain that competitive edge and retain their customers. But it also helps them make data-driven decisions in real time based on actual data rather than on somebody's gut feeling or basing those decisions on historical data. So for example, you can do real-time price adjustments on products based on demand and so forth, that kind of thing. So it really changes the way people do business today. >> So Gerald, you think about the narrative in the industry everybody wants to be a platform player all your customers they are becoming software companies, they are becoming platform players. Everybody wants to be like, you know name a company that is huge trillion dollar market cap or whatever, and those are data-driven companies. And so it would seem to me that data-driven applications, there's nobody, no company really shouldn't be data-driven. Do you buy that? >> Yeah, absolutely. I mean, data-driven, and that naturally the whole industry is data-driven, right? It's like we all have information technologies about processing data and deriving information out of it. But when it comes to app development I think there is a big push to kind of like we have to do machine learning in our applications, we have to get insights from data. And when you actually look back a bit and take a step back, you see that there's of course many different kinds of applications out there as well that's not to be forgotten, right? So there is a usual front end user interfaces where really the application all it does is just entering some piece of information that's stored somewhere or perhaps a microservice that's not attached to a data to you at all but just receives or asks calls (indistinct). So I think it's not necessarily so important for every developer to kind of go on a bandwagon that they have to be data-driven. But I think it's equally important for those applications and those developers that build applications, that drive the business, that make business critical decisions as Maria mentioned before. Those guys should take really a close look into what data-driven apps means and what the data to you can actually give to them. Because what we see also happening a lot is that a lot of the things that are well known and out there just ready to use are being reimplemented in the applications. And for those applications, they essentially just ended up spending more time writing codes that will be already there and then have to maintain and debug the code as well rather than just going to market faster. >> Gerald can you talk to the prevailing approaches that developers take to build data-driven applications? What are the ones that you see? Let's dig into that a little bit more and maybe differentiate the different approaches and talk about that? >> Yeah, absolutely. I think right now the industry is like in two camps, it's like sort of a religious war going on that you'll see often happening with different architectures and so forth going on. So we have single purpose databases or data management technologies. Which are technologies that are as the name suggests build around a single purpose. So it's like, you know a typical example would be your ordinary key-value store. And a key-value store all it does is it allows you to store and retrieve a piece of data whatever that may be really, really fast but it doesn't really go beyond that. And then the other side of the house or the other camp would be multimodal databases, multimodal data management technologies. Those are technologies that allow you to store different types of data, different formats of data in the same technology in the same system alongside. And, you know, when you look at the geographics out there of what we have from technology, is pretty much any relational database or any database really has evolved into such a multimodal database. Whether that's MySQL that allows you to store or chase them alongside relational or even a MongoDB that allows you to do or gives you native graph support since (mumbles) and as well alongside the adjacent support. >> Well, it's clearly a trend in the industry. We've talked about this a lot in The Cube. We know where Oracle stands on this. I mean, you just mentioned MySQL but I mean, Oracle Databases you've been extending, you've mentioned JSON, we've got blockchain now in there you're infusing, you know ML and AI into the database, graph database capabilities, you know on and on and on. We talked a lot about we compared that to Amazon which is kind of the right tool, the right job approach. So maybe you could talk about, you know, your point of view, the benefits for developers of using that converged database if I can use that word approach being able to store multiple data formats? Why do you feel like that's a better approach? >> Yeah, I think on a high level it comes down to complexity. You are actually avoiding additional complexity, right? So not every use case that you have necessarily warrants to have yet another data management technology or yet the special build technology for managing that data, right? It's like many use cases that we see out there happily want to just store a piece of a chase and document, a piece of chase in a database and then perhaps retrieve it again afterwards so write some simple queries over it. And you really don't have to get a new database technology or a NoSQL database into the mix if you already have some to just fulfill that exact use case. You could just happily store that information as well in the database you already have. And what it really comes down to is the learning curve for developers, right? So it's like, as you use the same technology to store other types of data, you don't have to learn a new technology, you don't have to associate yourself with new and learn new drivers. You don't have to find new frameworks and you don't have to know how to necessarily operate or best model your data for that database. You can essentially just reuse your knowledge of the technology as well as the libraries and code you have already built in house perhaps in another application, perhaps, you know framework that you used against the same technology because it is still the same technology. So, kind of all comes down again to avoiding complexity rather than not fragmenting you know, the many different technologies we have. If you were to look at the different data formats that are out there today it's like, you know, you would end up with many different databases just to store them if you were to fully religiously follow the single purpose best built technology for every use case paradigm, right? And then you would just end up having to manage many different databases more than actually focusing on your app and getting value to your business or to your user. >> Okay, so I get that and I buy that by the way. I mean, especially if you're a larger organization and you've got all these projects going on but before we go back to Maria, Gerald, I want to just, I want to push on that a little bit. Because the counter to that argument would be in the analogy. And I wonder if you, I'd love for you to, you know knock this analogy off the blocks. The counter would be okay, Oracle is the Swiss Army knife and it's got, you know, all in one. But sometimes I need that specialized long screwdriver and I go into my toolbox and I grab that. It's better than the screwdriver in my Swiss Army knife. Why, are you the Swiss Army knife of databases? Or are you the all-in-one have that best of breed screwdriver for me? How do you think about that? >> Yeah, that's a fantastic question, right? And I think it's first of all, you have to separate between Oracle the company that has actually multiple data management technologies and databases out there as you said before, right? And Oracle Database. And I think Oracle Database is definitely a Swiss Army knife has many capabilities of since the last 40 years, you know that we've seen object support coming that's still in the Oracle Database today. We have seen XML coming, it's still in the Oracle Database, graph, spatial, et cetera. And so you have many different ways of managing your data and then on top of that going into the converge, not only do we allow you to store the different data model in there but we actually allow you also to, you apply all the security policies and so forth on top of it something Maria can talk more about the mission around converged database. I would also argue though that for some aspects, we do actually have to or add a screwdriver that you talked about as well. So especially in the relational world people get very quickly hung up on this idea that, oh, if you only do rows and columns, well, that's kind of what you put down on disk. And that was never true, it's the relational model is actually a logical model. What's probably being put down on disk is blocks that align themselves nice with block storage and always has been. So that allows you to actually model and process the data sort of differently. And one common example or one good example that we have that we introduced a couple of years ago was when, column and databases were very strong and you know, the competition came it's like, yeah, we have In-Memory column that stores now they're so much better. And we were like, well, orienting the data role-based or column-based really doesn't matter in the sense that we store them as blocks on disks. And so we introduced the in memory technology which gives you an In-Memory column, a representation of your data as well alongside your relational. So there is an example where you go like, well, actually you know, if you have this use case of the column or analytics all In-Memory, I would argue Oracle Database is also that screwdriver you want to go down to and gives you that capability. Because not only gives you representation in columnar, but also which many people then forget all the analytic power on top of SQL. It's one thing to store your data columnar, it's a completely different story to actually be able to run analytics on top of that and having all the built-in functionalities and stuff that you want to do with the data on top of it as you analyze it. >> You know, that's a great example, the kilometer 'cause I remember there was like a lot of hype around it. Oh, it's the Oracle killer, you know, at Vertica. Vertica is still around but, you know it never really hit escape velocity. But you know, good product, good company, whatever. Natezza, it kind of got buried inside of IBM. ParXL kind of became, you know, red shift with that deal so that kind of went away. Teradata bought a company, I forget which company it bought but. So that hype kind of disapated and now it's like, oh yeah, columnar. It's kind of like In-Memory, we've had a In-Memory databases ever since we've had databases you know, it's a kind of a feature not a sector. But anyway, Maria, let's come back to you. You've got a lot of customer experience. And you speak with a lot of companies, you know during your time at Oracle. What else are you seeing in terms of the benefits to this approach that might not be so intuitive and obvious right away? >> I think one of the biggest benefits to having a multimodel multiworkload or as we call it a converged database, is the fact that you can get greater data synergy from it. In other words, you can utilize all these different techniques and data models to get better value out of that data. So things like being able to do real-time machine learning, fraud detection inside a transaction or being able to do a product recommendation by accessing three different data models. So for example, if I'm trying to recommend a product for you Dave, I might use graph analytics to be able to figure out your community. Not just your friends, but other people on our system who look and behave just like you. Once I know that community then I can go over and see what products they bought by looking up our product catalog which may be stored as JSON. And then on top of that I can then see using the key-value what products inside that catalog those community members gave a five star rating to. So that way I can really pinpoint the right product for you. And I can do all of that in one transaction inside the database without having to transform that data into different models or God forbid, access different systems to be able to get all of that information. So it really simplifies how we can generate that value from the data. And of course, the other thing our customers love is when it comes to deploying data-driven apps, when you do it on a converged database it's much simpler because it is that standard data platform. So you're not having to manage multiple independent single purpose databases. You're not having to implement the security and the high availability policies, you know across a bunch of different diverse platforms. All of that can be done much simpler with a converged database 'cause the DBA team of course, is going to just use that standard set of tools to manage, monitor and secure those systems. >> Thank you for that. And you know, it's interesting, you talk about simplification and you are in Juan's organization so you've big focus on mission critical. And so one of the things that I think is often overlooked well, we talk about all the time is recovery. And if things are simpler, recovery is faster and easier. And so it's kind of the hallmark of Oracle is like the gold standard of the toughest apps, the most mission critical apps. But I wanted to get to the cloud Maria. So because everything is going to the cloud, right? Not all workloads are going to the cloud but everybody is talking about the cloud. Everybody has cloud first mentality and so yes, it's a hybrid world. But the natural next question is how do you think the cloud fits into this world of data-driven apps? >> I think just like any app that you're developing, the cloud helps to accelerate that development. And of course the deployment of these data-driven applications. 'Cause if you think about it, the developer is instantly able to provision a converged database that Oracle will automatically manage and look after for them. But what's great about doing something like that if you use like our autonomous database service is that it comes in different flavors. So you can get autonomous transaction processing, data warehousing or autonomous JSON so that the developer is going to get a database that's been optimized for their specific use case, whatever they are trying to solve. And it's also going to contain all of that great functionality and capabilities that we've been talking about. So what that really means to the developer though is as the project evolves and inevitably the business needs change a little, there's no need to panic when one of those changes comes in because your converged database or your autonomous database has all of those additional capabilities. So you can simply utilize those to able to address those evolving changes in the project. 'Cause let's face it, none of us normally know exactly what we need to build right at the very beginning. And on top of that they also kind of get a built-in buddy in the cloud, especially in the autonomous database. And that buddy comes in the form of built-in workload optimizations. So with the autonomous database we do things like automatic indexing where we're using machine learning to be that buddy for the developer. So what it'll do is it'll monitor the workload and see what kind of queries are being run on that system. And then it will actually determine if there are indexes that should be built to help improve the performance of that application. And not only does it bill those indexes but it verifies that they help improve the performance before publishing it to the application. So by the time the developer is finished with that app and it's ready to be deployed, it's actually also been optimized by the developers buddy, the Oracle autonomous database. So, you know, it's a really nice helping hand for developers when they're building any app especially data-driven apps. >> I like how you sort of gave us, you know the truth here is you don't always know where you're going when you're building an app. It's like it goes from you are trying to build it and they will come to start building it and we'll figure out where it's going to go. With Agile that's kind of how it works. But so I wonder, can you give some examples of maybe customers or maybe genericize them if you need to. Data-driven apps in the cloud where customers were able to drive more efficiency, where the cloud buddy allowed the customers to do more with less? >> No, we have tons of these but I'll try and keep it to just a couple. One that comes to mind straight away is retrace. These folks built a blockchain app in the Oracle Cloud that allows manufacturers to actually share the supply chain with the consumer. So the consumer can see exactly, who made their product? Using what raw materials? Where they were sourced from? How it was done? All of that is visible to the consumer. And in order to be able to share that they had to work on a very diverse set of data. So they had everything from JSON documents to images as well as your traditional transactions in there. And they store all of that information inside the Oracle autonomous database, they were able to build their app and deploy it on the cloud. And they were able to do all of that very, very quickly. So, you know, that ability to work on multiple different data types in a single database really helped them build that product and get it to market in a very short amount of time. Another customer that's doing something really, really interesting is MindSense. So these guys operate the largest mines in Canada, Chile, and Peru. But what they do is they put these x-ray devices on the massive mechanical shovels that are at the cove or at the mine face. And what that does is it senses the contents of the buckets inside these mining machines. And it's looking to see at that content, to see how it can optimize the processing of the ore inside in that bucket. So they're looking to minimize the amount of power and water that it's going to take to process that. And also of course, minimize the amount of waste that's going to come out of that project. So all of that sensor data is sent into an autonomous database where it's going to be processed by a whole host of different users. So everything from the mine engineers to the geo scientists, to even their own data scientists utilize that data to drive their business forward. And what I love about these guys is they're not happy with building just one app. MindSense actually use our built-in low core development environment, APEX that comes as part of the autonomous database and they actually produce applications constantly for different aspects of their business using that technology. And it's actually able to accelerate those new apps to the business. It takes them now just a couple of days or weeks to produce an app instead of months or years to build those new apps. >> Great, thank you for that Maria. Gerald, I'm going to push you again. So, I said upfront and talked about microservices and the cloud and containers and you know, anybody in the developer space follows that very closely. But some of the things that we've been talking about here people might look at that and say, well, they're kind of antithetical to microservices. This is our Oracles monolithic approach. But when you think about the benefits of microservices, people want freedom of choice, technology choice, seen as a big advantage of microservices and containers. How do you address such an argument? >> Yeah, that's an excellent question and I get that quite often. The microservices architecture in general as I said before had architectures, Linux distributions, et cetera. It's kind of always a bit of like there's an academic approach and there's a pragmatic approach. And when you look at the microservices the original definitions that came out at the early 2010s. They actually never said that each microservice has to have a database. And they also never said that if a microservice has a database, you have to use a different technology for each microservice. Just like they never said, you have to write a microservice in a different programming language, right? So where I'm going with this is like, yes you know, sometimes when you look at some vendors out there, some niche players, they push this message or they jump on this academic approach of like each microservice has the best tool at hand or I'd use a different database for your purpose, et cetera. Which almost often comes across like us. You know, we want to stay part of the conversation. Nothing stops a developer from, you know using a multimodal database for the microservice and just using that as a document store, right? Or just using that as a relational database. And, you know, sometimes I mean, it was actually something that happened that was really interesting yesterday I don't know whether you follow Dave or not. But Facebook had an outage yesterday, right? And Facebook is one of those companies that are seen as the Silicon Valley, you know know how to do microservices companies. And when you add through the outage, well, what happened, right? Some unfortunate logical error with configuration as a force that took a database cluster down. So, you know, there you have it where you go like, well, maybe not every microservice is actually in fact talking to its own database or its own special purpose database. I think there, you know, well, what we should, the industry should be focusing much more on this argument of which technology to use? What's the right tool for a job? Is more to ask themselves, what business problem actually are we trying to solve? And therefore what's the right approach and the right technology for this. And so therefore, just as I said before, you know multimodal databases they do have strong benefits. They have many built-in functionalities that are already there and they allow you to reduce this complexity of having to know many different technologies, right? And so it's not only to store different data models either you know, treat a multimodal database as a chasing documents store or a relational database but most databases are multimodal since 20 plus years. But it's also actually being able to perhaps if you store that data together, you can perhaps actually derive additional value for somebody else but perhaps not for your application. But like for example, if you were to use Oracle Database you can actually write queries on top of all of that data. It doesn't really matter for our query engine whether it's the data is format that then chase or the data is formatted in rows and columns you can just rather than query over it. And that's actually very powerful for those guys that have to, you know get the reporting done the end of the day, the end of the week. And for those guys that are the data scientists that they want to figure out, you know which product performed really well or can we tweak something here and there. When you look into that space you still see a huge divergence between the guys to put data in kind of the altarpiece style and guys that try to derive new insights. And there's still a lot of ETL going around and, you know we have big data technologies that some of them come and went and some of them came in that are still around like Apache Spark which is still like a SQL engine on top of any of your data kind of going back to the same concept. And so I will say that, you know, for developers when we look at microservices it's like, first of all, is the argument you were making because the vendor or the technology you want to use tells you this argument or, you know, you kind of want to have an argument to use a specific technology? Or is it really more because it is the best technology, to best use for this given use case for this given application that you have? And if so there's of course, also nothing wrong to use a single purpose technology either, right? >> Yeah, I mean, whenever I talk about Oracle I always come back to the most important applications, the mission critical. It's very difficult to architect databases with microservices and containers. You have to be really, really careful. And so and again, it comes back to what we were talking before about with Maria that the complexity and the recovery. But Gerald I want to stay with you for a minute. So there's other data management technologies popping out there. I mean, I've seen some people saying, okay just leave the data in an S3 bucket. We can query that, then we've got some magic sauce to do that. And so why are you optimistic about you know, traditional database technology going forward? >> I would say because of the history of databases. So one thing that once struck me when I came to Oracle and then got to meet great people like Juan Luis and Andy Mendelsohn who had been here for a long, long time. I come to realization that relational databases are around for about 45 years now. And, you know, I was like, I'm too young to have been around then, right? So I was like, what else was around 45 years? It's like just the tech stack that we have today. It's like, how does this look like? Well, Linux only came out in 93. Well, databases pre-date Linux a lot rather than as I started digging I saw a lot of technologies come and go, right? And you mentioned before like the technologies that data management systems that we had that came and went like the columnar databases or XML databases, object databases. And even before relational databases before Cot gave us the relational model there were apparently these networks stores network databases which to some extent look very similar to adjacent documents. There wasn't a harder storing data and a hierarchy to format. And, you know when you then start actually reading the Cot paper and diving a little bit more into the relation model, that's I think one important crux in there that most of the industry keeps forgetting or it hasn't been around to even know. And that is that when Cot created the relational model, he actually focused not so much on the application putting the data in, but on future users and applications still being able to making sense out of the data, right? And that's kind of like I said before we had those network models, we had XML databases you have adjacent documents stores. And the one thing that they all have along with it is like the application that puts the data in decides the structure of the data. And that's all well and good if you had an application of the developer writing an application. It can become really tricky when 10 years later you still want to look at that data and the application that the developer is no longer around then you go like, what does this all mean? Where is the structure defined? What is this attribute? What does it mean? How does it correlate to others? And the one thing that people tend to forget is that it's actually the data that's here to stay not someone who does the applications where it is. Ideally, every company wants to store every single byte of data that they have because there might be future value in it. Economically may not make sense that's now much more feasible than just years ago. But if you could, why wouldn't you want to store all your data, right? And sometimes you actually have to store the data for seven years or whatever because the laws require you to. And so coming back then and you know, like 10 years from now and looking at the data and going like making sense of that data can actually become a lot more difficult and a lot more challenging than having to first figure out and how we store this data for general use. And that kind of was what the relational model was all about. We decompose the data structures into tables and columns with relationships amongst each other so therefore between each other. So that therefore if somebody wants to, you know typical example would be well you store some purchases from your web store, right? There's a customer attribute in it. There's some credit card payment information in it, just some product information on what the customer bought. Well, in the relational model if you just want to figure out which products were sold on a given day or week, you just would query the payment and products table to get the sense out of it. You don't need to touch the customer and so forth. And with the hierarchical model you have to first sit down and understand how is the structure, what is the customer? Where is the payment? You know, does the document start with the payment or does it start with the customer? Where do I find this information? And then in the very early days those databases even struggled to then not having to scan all the documents to get the data out. So coming back to your question a bit, I apologize for going on here. But you know, it's like relational databases have been around for 45 years. I actually argue it's one of the most successful software technologies that we have out there when you look in the overall industry, right? 45 years is like, in IT terms it's like from a star being the ones who are going supernova. You have said it before that many technologies coming and went, right? And just want to add a more really interesting example by the way is Hadoop and HDFS, right? They kind of gave us this additional promise of like, you know, the 2010s like 2012, 2013 the hype of Hadoop and so forth and (mumbles) and HDFS. And people are just like, just put everything into HDFS and worry about the data later, right? And we can query it and map reduce it and whatever. And we had customers actually coming to us they were like, great we have half a petabyte of data on an HDFS cluster and we have no clue what's stored in there. How do we figure this out? What are we going to do now? Now you had a big data cleansing problem. And so I think that is why databases and also data modeling is something that will not go away anytime soon. And I think databases and database technologies are here for quite a while to stay. Because many of those are people they don't think about what's happening to the data five years from now. And many of the niche players also and also frankly even Amazon you know, following with this single purpose thing is like, just use the right tool for the job for your application, right? Just pull in the data there the way you wanted. And it's like, okay, so you use technologies all over the place and then five years from now you have your data fragmented everywhere in different formats and, you know inconsistencies, and, and, and. And those are usually when you come back to this data-driven business critical business decision applications the worst case scenario you can have, right? Because now you need an army of people to actually do data cleansing. And there's not a coincidence that data science has become very, very popular the last recent years as we kind of went on with this proliferation of different database or data management technologies some of those are not even database. But I think I leave it at that. >> It's an interesting talk track because you're right. I mean, no schema on right was alluring, but it definitely created some problems. It also created an entire, you know you referenced the hyper specialized roles and did the data cleansing component. I mean, maybe technology will eventually solve that problem but it hasn't up at least up tonight. Okay, last question, Maria maybe you could start off and Gerald if you want to chime in as well it'd be great. I mean, it's interesting to watch this industry when Oracle sort of won the top database mantle. I mean, I watched it, I saw it. It was, remember it was Informix and it was (indistinct) too and of course, Microsoft you got to give them credit with SQL server, but Oracle won the database wars. And then everything got kind of quiet for awhile database was sort of boring. And then it exploded, you know, all the, you know not only SQL and the key-value stores and the cloud databases and this is really a hot area now. And when we looked at Oracle we said, okay, Oracle it's all about Oracle Database, but we've seen the kind of resurgence in MySQL which everybody thought, you know once Oracle bought Sun they were going to kill MySQL. But now we see you investing in HeatWave, TimesTen, we talked about In-Memory databases before. So where do those fit in Maria in the grand scheme? How should we think about Oracle's database portfolio? >> So there's lots of places where you'd use those different things. 'Cause just like any other industry there are going to be new and boutique use cases that are going to benefit from a more specialized product or single purpose product. So good examples off the top of my head of the kind of systems that would benefit from that would be things like a stock exchange system or a telephone exchange system. Both of those are latency critical transaction processing applications where they need microsecond response times. And that's going to exceed perhaps what you might normally get or deploy with a converged database. And so Oracle's TimesTen database our In-Memory database is perfect for those kinds of applications. But there's also a host of MySQL applications out there today and you said it yourself there Dave, HeatWave is a great place to provision and deploy those kinds of applications because it's going to run 100 times faster than AWS (mumbles). So, you know, there really is a place in the market and in our customer's systems and the needs they have for all of these different members of our database family here at Oracle. >> Yeah, well, the internet is basically running in the lamp stack so I see MySQL going away. All right Gerald, will give you the final word, bring us home. >> Oh, thank you very much. Yeah, I mean, as Maria said, I think it comes back to what we discussed before. There is obviously still needs for special technologies or different technologies than a relational database or multimodal database. Oracle has actually many more databases that people may first think of. Not only the three that we have already mentioned but there's even SP so the Oracle's NoSQL database. And, you know, on a high level Oracle is a data management company, right? And we want to give our customers the best tools and the best technology to manage all of their data. Rather than therefore there has to be a need or there should be a part of the business that also focuses on this highly specialized systems and this highly specialized technologies that address those use cases. And I think it makes perfect sense. It's like, you know, when the customer comes to Oracle they're not only getting this, take this one product you know, and if you don't like it your problem but actually you have choice, right? And choice allows you to make a decision based on what's best for you and not necessarily best for the vendor you're talking to. >> Well guys, really appreciate your time today and your insights. Maria, Gerald, thanks so much for coming on The Cube. >> Thank you very much for having us. >> And thanks for watching this Cube conversation this is Dave Vellante and we'll see you next time. (upbeat music)

(upbeat music) >> It'll be five, four, three and then silent two, one, and then you guys just follow my lead. We're just making some last minute adjustments. Like I said, we're down two hands today. So, you good Alex? Okay, are you guys ready? >> I'm ready. >> Ready. >> I got to get get one note here. >> So I noticed Maria you stopped anyway, so I have time. >> Just so they know Dave and the Boston Studio, are they both kind of concurrently be on film even when they're not speaking or will only the speaker be on film for like if Gerald's drawing while Maria is talking about-- >> Sorry but then I missed one part of my onboarding spiel. There should be, if you go into gallery there should be a label. There should be something labeled Boston live switch feed. If you pin that gallery view you'll see what our program currently being recorded is. So any time you don't see yourself on that feed is an excellent time to take a drink of water, scratch your nose, check your notes. Do whatever you got to do off screen. >> Can you give us a three shot, Alex? >> Yes, there it is. >> And then go to me, just give me a one-shot to Dave. So when I'm here you guys can take a drink or whatever >> That makes sense? >> Yeah. >> Excellent, I will get my recordings restarted and we'll open up when Dave's ready. >> All right, you guys ready? >> Ready. >> All right Steve, you go on mute. >> Okay, on me in 5, 4, 3. Developers have become the new king makers in the world of digital and cloud. The rise of containers and microservices has accelerated the transition to cloud native applications. A lot of people will talk about application architecture and the related paradigms and the benefits they bring for the process of writing and delivering new apps. But a major challenge continues to be, the how and the what when it comes to accessing, processing and getting insights from the massive amounts of data that we have to deal with in today's world. And with me are two experts from the data management world who will share with us how they think about the best techniques and practices based on what they see at large organizations who are working with data and developing so-called data-driven apps. Please welcome Maria Colgan and Gerald Venzl, two distinguish product managers from Oracle. Folks, welcome, thanks so much for coming on. >> Thanks for having us Dave. >> Thank you very much for having us. >> Okay, Maria let's start with you. So, we throw around this term data-driven, data-driven applications. What are we really talking about there? >> So data-driven applications are applications that work on a diverse set of data. So anything from spatial to sensor data, document data as well as your usual transaction processing data. And what they're going to do is they'll generate value from that data in very different ways to a traditional application. So for example, they may use machine learning, they are able to do product recommendations in the middle of a transaction. Or we could use graph to be able to identify an influencer within the community so we can target them with a specific promotion. It could also use spatial data to be able to help find the nearest stores to a particular customer. And because these apps are deployed on multiple platforms, everything from mobile devices as well as standard browsers, they need a data platform that's going to be both secure, reliable and scalable. >> Well, so when you think about how the workloads are shifting I mean, we're not talking about, you know it's not anymore a world of just your ERP or your HCM or your CRM, you know kind of the traditional operational systems. You really are seeing an explosion of these new data oriented apps. You're seeing, you know, modeling in the cloud, you are going to see more and more inferencing, inferencing at the edge. But Maria maybe you could talk a little bit about sort of the benefits that customers are seeing from developing these types of applications. I mean, why should people care about data-driven apps? >> Oh, for sure, there's massive benefits to them. I mean, probably the most obvious one for any business regardless of the industry, is that they not only allow you to understand what your customers are up to, but they allow you to be able to anticipate those customer's needs. So that helps businesses maintain that competitive edge and retain their customers. But it also helps them make data-driven decisions in real time based on actual data rather than on somebody's gut feeling or basing those decisions on historical data. So for example, you can do real-time price adjustments on products based on demand and so forth, that kind of thing. So it really changes the way people do business today. >> So Gerald, you think about the narrative in the industry everybody wants to be a platform player all your customers they are becoming software companies, they are becoming platform players. Everybody wants to be like, you know name a company that is huge trillion dollar market cap or whatever, and those are data-driven companies. And so it would seem to me that data-driven applications, there's nobody, no company really shouldn't be data-driven. Do you buy that? >> Yeah, absolutely. I mean, data-driven, and that naturally the whole industry is data-driven, right? It's like we all have information technologies about processing data and deriving information out of it. But when it comes to app development I think there is a big push to kind of like we have to do machine learning in our applications, we have to get insights from data. And when you actually look back a bit and take a step back, you see that there's of course many different kinds of applications out there as well that's not to be forgotten, right? So there is a usual front end user interfaces where really the application all it does is just entering some piece of information that's stored somewhere or perhaps a microservice that's not attached to a data to you at all but just receives or asks calls (indistinct). So I think it's not necessarily so important for every developer to kind of go on a bandwagon that they have to be data-driven. But I think it's equally important for those applications and those developers that build applications, that drive the business, that make business critical decisions as Maria mentioned before. Those guys should take really a close look into what data-driven apps means and what the data to you can actually give to them. Because what we see also happening a lot is that a lot of the things that are well known and out there just ready to use are being reimplemented in the applications. And for those applications, they essentially just ended up spending more time writing codes that will be already there and then have to maintain and debug the code as well rather than just going to market faster. >> Gerald can you talk to the prevailing approaches that developers take to build data-driven applications? What are the ones that you see? Let's dig into that a little bit more and maybe differentiate the different approaches and talk about that? >> Yeah, absolutely. I think right now the industry is like in two camps, it's like sort of a religious war going on that you'll see often happening with different architectures and so forth going on. So we have single purpose databases or data management technologies. Which are technologies that are as the name suggests build around a single purpose. So it's like, you know a typical example would be your ordinary key-value store. And a key-value store all it does is it allows you to store and retrieve a piece of data whatever that may be really, really fast but it doesn't really go beyond that. And then the other side of the house or the other camp would be multimodal databases, multimodal data management technologies. Those are technologies that allow you to store different types of data, different formats of data in the same technology in the same system alongside. And, you know, when you look at the geographics out there of what we have from technology, is pretty much any relational database or any database really has evolved into such a multimodal database. Whether that's MySQL that allows you to store or chase them alongside relational or even a MongoDB that allows you to do or gives you native graph support since (mumbles) and as well alongside the adjacent support. >> Well, it's clearly a trend in the industry. We've talked about this a lot in The Cube. We know where Oracle stands on this. I mean, you just mentioned MySQL but I mean, Oracle Databases you've been extending, you've mentioned JSON, we've got blockchain now in there you're infusing, you know ML and AI into the database, graph database capabilities, you know on and on and on. We talked a lot about we compared that to Amazon which is kind of the right tool, the right job approach. So maybe you could talk about, you know, your point of view, the benefits for developers of using that converged database if I can use that word approach being able to store multiple data formats? Why do you feel like that's a better approach? >> Yeah, I think on a high level it comes down to complexity. You are actually avoiding additional complexity, right? So not every use case that you have necessarily warrants to have yet another data management technology or yet the special build technology for managing that data, right? It's like many use cases that we see out there happily want to just store a piece of a chase and document, a piece of chase in a database and then perhaps retrieve it again afterwards so write some simple queries over it. And you really don't have to get a new database technology or a NoSQL database into the mix if you already have some to just fulfill that exact use case. You could just happily store that information as well in the database you already have. And what it really comes down to is the learning curve for developers, right? So it's like, as you use the same technology to store other types of data, you don't have to learn a new technology, you don't have to associate yourself with new and learn new drivers. You don't have to find new frameworks and you don't have to know how to necessarily operate or best model your data for that database. You can essentially just reuse your knowledge of the technology as well as the libraries and code you have already built in house perhaps in another application, perhaps, you know framework that you used against the same technology because it is still the same technology. So, kind of all comes down again to avoiding complexity rather than not fragmenting you know, the many different technologies we have. If you were to look at the different data formats that are out there today it's like, you know, you would end up with many different databases just to store them if you were to fully religiously follow the single purpose best built technology for every use case paradigm, right? And then you would just end up having to manage many different databases more than actually focusing on your app and getting value to your business or to your user. >> Okay, so I get that and I buy that by the way. I mean, especially if you're a larger organization and you've got all these projects going on but before we go back to Maria, Gerald, I want to just, I want to push on that a little bit. Because the counter to that argument would be in the analogy. And I wonder if you, I'd love for you to, you know knock this analogy off the blocks. The counter would be okay, Oracle is the Swiss Army knife and it's got, you know, all in one. But sometimes I need that specialized long screwdriver and I go into my toolbox and I grab that. It's better than the screwdriver in my Swiss Army knife. Why, are you the Swiss Army knife of databases? Or are you the all-in-one have that best of breed screwdriver for me? How do you think about that? >> Yeah, that's a fantastic question, right? And I think it's first of all, you have to separate between Oracle the company that has actually multiple data management technologies and databases out there as you said before, right? And Oracle Database. And I think Oracle Database is definitely a Swiss Army knife has many capabilities of since the last 40 years, you know that we've seen object support coming that's still in the Oracle Database today. We have seen XML coming, it's still in the Oracle Database, graph, spatial, et cetera. And so you have many different ways of managing your data and then on top of that going into the converge, not only do we allow you to store the different data model in there but we actually allow you also to, you apply all the security policies and so forth on top of it something Maria can talk more about the mission around converged database. I would also argue though that for some aspects, we do actually have to or add a screwdriver that you talked about as well. So especially in the relational world people get very quickly hung up on this idea that, oh, if you only do rows and columns, well, that's kind of what you put down on disk. And that was never true, it's the relational model is actually a logical model. What's probably being put down on disk is blocks that align themselves nice with block storage and always has been. So that allows you to actually model and process the data sort of differently. And one common example or one good example that we have that we introduced a couple of years ago was when, column and databases were very strong and you know, the competition came it's like, yeah, we have In-Memory column that stores now they're so much better. And we were like, well, orienting the data role-based or column-based really doesn't matter in the sense that we store them as blocks on disks. And so we introduced the in memory technology which gives you an In-Memory column, a representation of your data as well alongside your relational. So there is an example where you go like, well, actually you know, if you have this use case of the column or analytics all In-Memory, I would argue Oracle Database is also that screwdriver you want to go down to and gives you that capability. Because not only gives you representation in columnar, but also which many people then forget all the analytic power on top of SQL. It's one thing to store your data columnar, it's a completely different story to actually be able to run analytics on top of that and having all the built-in functionalities and stuff that you want to do with the data on top of it as you analyze it. >> You know, that's a great example, the kilometer 'cause I remember there was like a lot of hype around it. Oh, it's the Oracle killer, you know, at Vertica. Vertica is still around but, you know it never really hit escape velocity. But you know, good product, good company, whatever. Natezza, it kind of got buried inside of IBM. ParXL kind of became, you know, red shift with that deal so that kind of went away. Teradata bought a company, I forget which company it bought but. So that hype kind of disapated and now it's like, oh yeah, columnar. It's kind of like In-Memory, we've had a In-Memory databases ever since we've had databases you know, it's a kind of a feature not a sector. But anyway, Maria, let's come back to you. You've got a lot of customer experience. And you speak with a lot of companies, you know during your time at Oracle. What else are you seeing in terms of the benefits to this approach that might not be so intuitive and obvious right away? >> I think one of the biggest benefits to having a multimodel multiworkload or as we call it a converged database, is the fact that you can get greater data synergy from it. In other words, you can utilize all these different techniques and data models to get better value out of that data. So things like being able to do real-time machine learning, fraud detection inside a transaction or being able to do a product recommendation by accessing three different data models. So for example, if I'm trying to recommend a product for you Dave, I might use graph analytics to be able to figure out your community. Not just your friends, but other people on our system who look and behave just like you. Once I know that community then I can go over and see what products they bought by looking up our product catalog which may be stored as JSON. And then on top of that I can then see using the key-value what products inside that catalog those community members gave a five star rating to. So that way I can really pinpoint the right product for you. And I can do all of that in one transaction inside the database without having to transform that data into different models or God forbid, access different systems to be able to get all of that information. So it really simplifies how we can generate that value from the data. And of course, the other thing our customers love is when it comes to deploying data-driven apps, when you do it on a converged database it's much simpler because it is that standard data platform. So you're not having to manage multiple independent single purpose databases. You're not having to implement the security and the high availability policies, you know across a bunch of different diverse platforms. All of that can be done much simpler with a converged database 'cause the DBA team of course, is going to just use that standard set of tools to manage, monitor and secure those systems. >> Thank you for that. And you know, it's interesting, you talk about simplification and you are in Juan's organization so you've big focus on mission critical. And so one of the things that I think is often overlooked well, we talk about all the time is recovery. And if things are simpler, recovery is faster and easier. And so it's kind of the hallmark of Oracle is like the gold standard of the toughest apps, the most mission critical apps. But I wanted to get to the cloud Maria. So because everything is going to the cloud, right? Not all workloads are going to the cloud but everybody is talking about the cloud. Everybody has cloud first mentality and so yes, it's a hybrid world. But the natural next question is how do you think the cloud fits into this world of data-driven apps? >> I think just like any app that you're developing, the cloud helps to accelerate that development. And of course the deployment of these data-driven applications. 'Cause if you think about it, the developer is instantly able to provision a converged database that Oracle will automatically manage and look after for them. But what's great about doing something like that if you use like our autonomous database service is that it comes in different flavors. So you can get autonomous transaction processing, data warehousing or autonomous JSON so that the developer is going to get a database that's been optimized for their specific use case, whatever they are trying to solve. And it's also going to contain all of that great functionality and capabilities that we've been talking about. So what that really means to the developer though is as the project evolves and inevitably the business needs change a little, there's no need to panic when one of those changes comes in because your converged database or your autonomous database has all of those additional capabilities. So you can simply utilize those to able to address those evolving changes in the project. 'Cause let's face it, none of us normally know exactly what we need to build right at the very beginning. And on top of that they also kind of get a built-in buddy in the cloud, especially in the autonomous database. And that buddy comes in the form of built-in workload optimizations. So with the autonomous database we do things like automatic indexing where we're using machine learning to be that buddy for the developer. So what it'll do is it'll monitor the workload and see what kind of queries are being run on that system. And then it will actually determine if there are indexes that should be built to help improve the performance of that application. And not only does it bill those indexes but it verifies that they help improve the performance before publishing it to the application. So by the time the developer is finished with that app and it's ready to be deployed, it's actually also been optimized by the developers buddy, the Oracle autonomous database. So, you know, it's a really nice helping hand for developers when they're building any app especially data-driven apps. >> I like how you sort of gave us, you know the truth here is you don't always know where you're going when you're building an app. It's like it goes from you are trying to build it and they will come to start building it and we'll figure out where it's going to go. With Agile that's kind of how it works. But so I wonder, can you give some examples of maybe customers or maybe genericize them if you need to. Data-driven apps in the cloud where customers were able to drive more efficiency, where the cloud buddy allowed the customers to do more with less? >> No, we have tons of these but I'll try and keep it to just a couple. One that comes to mind straight away is retrace. These folks built a blockchain app in the Oracle Cloud that allows manufacturers to actually share the supply chain with the consumer. So the consumer can see exactly, who made their product? Using what raw materials? Where they were sourced from? How it was done? All of that is visible to the consumer. And in order to be able to share that they had to work on a very diverse set of data. So they had everything from JSON documents to images as well as your traditional transactions in there. And they store all of that information inside the Oracle autonomous database, they were able to build their app and deploy it on the cloud. And they were able to do all of that very, very quickly. So, you know, that ability to work on multiple different data types in a single database really helped them build that product and get it to market in a very short amount of time. Another customer that's doing something really, really interesting is MindSense. So these guys operate the largest mines in Canada, Chile, and Peru. But what they do is they put these x-ray devices on the massive mechanical shovels that are at the cove or at the mine face. And what that does is it senses the contents of the buckets inside these mining machines. And it's looking to see at that content, to see how it can optimize the processing of the ore inside in that bucket. So they're looking to minimize the amount of power and water that it's going to take to process that. And also of course, minimize the amount of waste that's going to come out of that project. So all of that sensor data is sent into an autonomous database where it's going to be processed by a whole host of different users. So everything from the mine engineers to the geo scientists, to even their own data scientists utilize that data to drive their business forward. And what I love about these guys is they're not happy with building just one app. MindSense actually use our built-in low core development environment, APEX that comes as part of the autonomous database and they actually produce applications constantly for different aspects of their business using that technology. And it's actually able to accelerate those new apps to the business. It takes them now just a couple of days or weeks to produce an app instead of months or years to build those new apps. >> Great, thank you for that Maria. Gerald, I'm going to push you again. So, I said upfront and talked about microservices and the cloud and containers and you know, anybody in the developer space follows that very closely. But some of the things that we've been talking about here people might look at that and say, well, they're kind of antithetical to microservices. This is our Oracles monolithic approach. But when you think about the benefits of microservices, people want freedom of choice, technology choice, seen as a big advantage of microservices and containers. How do you address such an argument? >> Yeah, that's an excellent question and I get that quite often. The microservices architecture in general as I said before had architectures, Linux distributions, et cetera. It's kind of always a bit of like there's an academic approach and there's a pragmatic approach. And when you look at the microservices the original definitions that came out at the early 2010s. They actually never said that each microservice has to have a database. And they also never said that if a microservice has a database, you have to use a different technology for each microservice. Just like they never said, you have to write a microservice in a different programming language, right? So where I'm going with this is like, yes you know, sometimes when you look at some vendors out there, some niche players, they push this message or they jump on this academic approach of like each microservice has the best tool at hand or I'd use a different database for your purpose, et cetera. Which almost often comes across like us. You know, we want to stay part of the conversation. Nothing stops a developer from, you know using a multimodal database for the microservice and just using that as a document store, right? Or just using that as a relational database. And, you know, sometimes I mean, it was actually something that happened that was really interesting yesterday I don't know whether you follow Dave or not. But Facebook had an outage yesterday, right? And Facebook is one of those companies that are seen as the Silicon Valley, you know know how to do microservices companies. And when you add through the outage, well, what happened, right? Some unfortunate logical error with configuration as a force that took a database cluster down. So, you know, there you have it where you go like, well, maybe not every microservice is actually in fact talking to its own database or its own special purpose database. I think there, you know, well, what we should, the industry should be focusing much more on this argument of which technology to use? What's the right tool for a job? Is more to ask themselves, what business problem actually are we trying to solve? And therefore what's the right approach and the right technology for this. And so therefore, just as I said before, you know multimodal databases they do have strong benefits. They have many built-in functionalities that are already there and they allow you to reduce this complexity of having to know many different technologies, right? And so it's not only to store different data models either you know, treat a multimodal database as a chasing documents store or a relational database but most databases are multimodal since 20 plus years. But it's also actually being able to perhaps if you store that data together, you can perhaps actually derive additional value for somebody else but perhaps not for your application. But like for example, if you were to use Oracle Database you can actually write queries on top of all of that data. It doesn't really matter for our query engine whether it's the data is format that then chase or the data is formatted in rows and columns you can just rather than query over it. And that's actually very powerful for those guys that have to, you know get the reporting done the end of the day, the end of the week. And for those guys that are the data scientists that they want to figure out, you know which product performed really well or can we tweak something here and there. When you look into that space you still see a huge divergence between the guys to put data in kind of the altarpiece style and guys that try to derive new insights. And there's still a lot of ETL going around and, you know we have big data technologies that some of them come and went and some of them came in that are still around like Apache Spark which is still like a SQL engine on top of any of your data kind of going back to the same concept. And so I will say that, you know, for developers when we look at microservices it's like, first of all, is the argument you were making because the vendor or the technology you want to use tells you this argument or, you know, you kind of want to have an argument to use a specific technology? Or is it really more because it is the best technology, to best use for this given use case for this given application that you have? And if so there's of course, also nothing wrong to use a single purpose technology either, right? >> Yeah, I mean, whenever I talk about Oracle I always come back to the most important applications, the mission critical. It's very difficult to architect databases with microservices and containers. You have to be really, really careful. And so and again, it comes back to what we were talking before about with Maria that the complexity and the recovery. But Gerald I want to stay with you for a minute. So there's other data management technologies popping out there. I mean, I've seen some people saying, okay just leave the data in an S3 bucket. We can query that, then we've got some magic sauce to do that. And so why are you optimistic about you know, traditional database technology going forward? >> I would say because of the history of databases. So one thing that once struck me when I came to Oracle and then got to meet great people like Juan Luis and Andy Mendelsohn who had been here for a long, long time. I come to realization that relational databases are around for about 45 years now. And, you know, I was like, I'm too young to have been around then, right? So I was like, what else was around 45 years? It's like just the tech stack that we have today. It's like, how does this look like? Well, Linux only came out in 93. Well, databases pre-date Linux a lot rather than as I started digging I saw a lot of technologies come and go, right? And you mentioned before like the technologies that data management systems that we had that came and went like the columnar databases or XML databases, object databases. And even before relational databases before Cot gave us the relational model there were apparently these networks stores network databases which to some extent look very similar to adjacent documents. There wasn't a harder storing data and a hierarchy to format. And, you know when you then start actually reading the Cot paper and diving a little bit more into the relation model, that's I think one important crux in there that most of the industry keeps forgetting or it hasn't been around to even know. And that is that when Cot created the relational model, he actually focused not so much on the application putting the data in, but on future users and applications still being able to making sense out of the data, right? And that's kind of like I said before we had those network models, we had XML databases you have adjacent documents stores. And the one thing that they all have along with it is like the application that puts the data in decides the structure of the data. And that's all well and good if you had an application of the developer writing an application. It can become really tricky when 10 years later you still want to look at that data and the application that the developer is no longer around then you go like, what does this all mean? Where is the structure defined? What is this attribute? What does it mean? How does it correlate to others? And the one thing that people tend to forget is that it's actually the data that's here to stay not someone who does the applications where it is. Ideally, every company wants to store every single byte of data that they have because there might be future value in it. Economically may not make sense that's now much more feasible than just years ago. But if you could, why wouldn't you want to store all your data, right? And sometimes you actually have to store the data for seven years or whatever because the laws require you to. And so coming back then and you know, like 10 years from now and looking at the data and going like making sense of that data can actually become a lot more difficult and a lot more challenging than having to first figure out and how we store this data for general use. And that kind of was what the relational model was all about. We decompose the data structures into tables and columns with relationships amongst each other so therefore between each other. So that therefore if somebody wants to, you know typical example would be well you store some purchases from your web store, right? There's a customer attribute in it. There's some credit card payment information in it, just some product information on what the customer bought. Well, in the relational model if you just want to figure out which products were sold on a given day or week, you just would query the payment and products table to get the sense out of it. You don't need to touch the customer and so forth. And with the hierarchical model you have to first sit down and understand how is the structure, what is the customer? Where is the payment? You know, does the document start with the payment or does it start with the customer? Where do I find this information? And then in the very early days those databases even struggled to then not having to scan all the documents to get the data out. So coming back to your question a bit, I apologize for going on here. But you know, it's like relational databases have been around for 45 years. I actually argue it's one of the most successful software technologies that we have out there when you look in the overall industry, right? 45 years is like, in IT terms it's like from a star being the ones who are going supernova. You have said it before that many technologies coming and went, right? And just want to add a more really interesting example by the way is Hadoop and HDFS, right? They kind of gave us this additional promise of like, you know, the 2010s like 2012, 2013 the hype of Hadoop and so forth and (mumbles) and HDFS. And people are just like, just put everything into HDFS and worry about the data later, right? And we can query it and map reduce it and whatever. And we had customers actually coming to us they were like, great we have half a petabyte of data on an HDFS cluster and we have no clue what's stored in there. How do we figure this out? What are we going to do now? Now you had a big data cleansing problem. And so I think that is why databases and also data modeling is something that will not go away anytime soon. And I think databases and database technologies are here for quite a while to stay. Because many of those are people they don't think about what's happening to the data five years from now. And many of the niche players also and also frankly even Amazon you know, following with this single purpose thing is like, just use the right tool for the job for your application, right? Just pull in the data there the way you wanted. And it's like, okay, so you use technologies all over the place and then five years from now you have your data fragmented everywhere in different formats and, you know inconsistencies, and, and, and. And those are usually when you come back to this data-driven business critical business decision applications the worst case scenario you can have, right? Because now you need an army of people to actually do data cleansing. And there's not a coincidence that data science has become very, very popular the last recent years as we kind of went on with this proliferation of different database or data management technologies some of those are not even database. But I think I leave it at that. >> It's an interesting talk track because you're right. I mean, no schema on right was alluring, but it definitely created some problems. It also created an entire, you know you referenced the hyper specialized roles and did the data cleansing component. I mean, maybe technology will eventually solve that problem but it hasn't up at least up tonight. Okay, last question, Maria maybe you could start off and Gerald if you want to chime in as well it'd be great. I mean, it's interesting to watch this industry when Oracle sort of won the top database mantle. I mean, I watched it, I saw it. It was, remember it was Informix and it was (indistinct) too and of course, Microsoft you got to give them credit with SQL server, but Oracle won the database wars. And then everything got kind of quiet for awhile database was sort of boring. And then it exploded, you know, all the, you know not only SQL and the key-value stores and the cloud databases and this is really a hot area now. And when we looked at Oracle we said, okay, Oracle it's all about Oracle Database, but we've seen the kind of resurgence in MySQL which everybody thought, you know once Oracle bought Sun they were going to kill MySQL. But now we see you investing in HeatWave, TimesTen, we talked about In-Memory databases before. So where do those fit in Maria in the grand scheme? How should we think about Oracle's database portfolio? >> So there's lots of places where you'd use those different things. 'Cause just like any other industry there are going to be new and boutique use cases that are going to benefit from a more specialized product or single purpose product. So good examples off the top of my head of the kind of systems that would benefit from that would be things like a stock exchange system or a telephone exchange system. Both of those are latency critical transaction processing applications where they need microsecond response times. And that's going to exceed perhaps what you might normally get or deploy with a converged database. And so Oracle's TimesTen database our In-Memory database is perfect for those kinds of applications. But there's also a host of MySQL applications out there today and you said it yourself there Dave, HeatWave is a great place to provision and deploy those kinds of applications because it's going to run 100 times faster than AWS (mumbles). So, you know, there really is a place in the market and in our customer's systems and the needs they have for all of these different members of our database family here at Oracle. >> Yeah, well, the internet is basically running in the lamp stack so I see MySQL going away. All right Gerald, will give you the final word, bring us home. >> Oh, thank you very much. Yeah, I mean, as Maria said, I think it comes back to what we discussed before. There is obviously still needs for special technologies or different technologies than a relational database or multimodal database. Oracle has actually many more databases that people may first think of. Not only the three that we have already mentioned but there's even SP so the Oracle's NoSQL database. And, you know, on a high level Oracle is a data management company, right? And we want to give our customers the best tools and the best technology to manage all of their data. Rather than therefore there has to be a need or there should be a part of the business that also focuses on this highly specialized systems and this highly specialized technologies that address those use cases. And I think it makes perfect sense. It's like, you know, when the customer comes to Oracle they're not only getting this, take this one product you know, and if you don't like it your problem but actually you have choice, right? And choice allows you to make a decision based on what's best for you and not necessarily best for the vendor you're talking to. >> Well guys, really appreciate your time today and your insights. Maria, Gerald, thanks so much for coming on The Cube. >> Thank you very much for having us. >> And thanks for watching this Cube conversation this is Dave Vellante and we'll see you next time. (upbeat music)

(upbeat music) >> Reporter: From around the globe, it's The Cube with digital coverage of enterprise data automation and event series brought to you by Io-Tahoe. >> Okay, we're back. Focusing on enterprise data automation, we're going to talk about the journey to the cloud. Remember, the hashtag is data automated. We're here with Lester Waters who's the CTO of Io-Tahoe, Lester, good to see you from across the pond on video, wish we were face to face, but it's great to have you on The Cube. >> Also I do, thank you for having me. >> Oh, you're very welcome. Hey, give us a little background on CTO, you got a deep expertise in a lot of different areas, but what do we need to know? >> Well, David, I started my career basically at Microsoft, where I started the Information Security Cryptography Group. They're the very first one that the company had and that led to a career in information security and of course, as you go along with the information security, data is the key element to be protected. So I always had my hands in data and that naturally progressed into a role with Io-Tahoe as their CTO. >> Guys, I have to invite you back, we'll talk crypto all day we'd love to do that but we're here talking about yeah, awesome, right? But we're here talking about the cloud and here we'll talk about the journey to the cloud and accelerate. Everybody's really interested obviously in cloud, even more interested now with the pandemic, but what's that all about? >> Well, moving to the cloud is quite an undertaking for most organizations. First of all, we've got as probably if you're a large enterprise, you probably have thousands of applications, you have hundreds and hundreds of database instances, and trying to shed some light on that, just to plan your move to the cloud is a real challenge. And some organizations try to tackle that manually. Really what Io-Tahoe is bringing is trying to tackle that in an automated version to help you with your journey to the cloud. >> Well, look at migrations are sometimes just an evil word to a lot of organizations, but at the same time, building up technical debt veneer after veneer and year, and year, and year is something that many companies are saying, "Okay, it's got to stop." So what's the prescription for that automation journey and simplifying that migration to the cloud? >> Well, I think the very first thing that's all about is data hygiene. You don't want to pick up your bad habits and take them to the cloud. You've got an opportunity here, so I see the journey to the cloud is an opportunity to really clean house, reorganize things, like moving out. You might move all your boxes, but you're kind of probably cherry pick what you're going to take with you and then you're going to organize it as you end up at your new destination. So from that, I get there's seven key principles that I like to operate by when I advise on the cloud migration. >> Okay. So, where do you start? >> Well, I think the first thing is understanding what you got, so discover and cataloging your data and your applications. If I don't know what I have, I can't move it, I can't improve it, I can't build up on it. And I have to understand there is dependency, so building that data catalog is the very first step. What do I got? >> Now, is that a metadata exercise? Sometimes there's more metadata than there is data. Is metadata part of that first step or? >> In deed, metadata is the first step so the metadata really describes the data you have. So, the metadata is going to tell me I have 2000 tables and maybe of those tables, there's an average of 25 columns each, and so that gives me a sketch if you will, of what I need to move. How big are the boxes I need to pack for my move to the cloud? >> Okay, and you're saying you can automate that data classification, categorization, discovery, correct using math machine intelligence, is that correct? >> Yeah, that's correct. So basically we go, and we will discover all of the schema, if you will, that's the metadata description of your tables and columns in your database in the data types. So we take, we will ingest that in, and we will build some insights around that. And we do that across a variety of platforms because everybody's organization has you've got a one yeah, an Oracle Database here, and you've got a Microsoft SQL Database here, you might have something else there that you need to bring site onto. And part of this journey is going to be about breaking down your data silos and understanding what you've got. >> Okay. So, we've done the audit, we know what we've got, what's next? Where do we go next? >> So the next thing is remediating that data. Where do I have duplicate data? Often times in an organization, data will get duplicated. So, somebody will take a snapshot of a data, and then ended up building a new application, which suddenly becomes dependent on that data. So it's not uncommon for an organization of 20 master instances of a customer. And you can see where that will go when trying to keep all that stuff in sync becomes a nightmare all by itself. So you want to understand where all your redundant data is. So when you go to the cloud, maybe you have an opportunity here to consolidate that data. >> Yeah, because you like to borrow in an Einstein or apply an Einstein Bromide right. Keep as much data as you can, but no more. >> Correct. >> Okay. So you get to the point to the second step you're kind of a one to reduce costs, then what? You figure out what to get rid of, or actually get rid of it, what's next? >> Yes, that would be the next step. So figuring out what you need and what you don't need often times I've found that there's obsolete columns of data in your databases that you just don't need, or maybe it's been superseded by another, you've got tables that have been superseded by other tables in your database. So you got to understand what's being used and what's not and then from that, you can decide, "I'm going to leave this stuff behind, "or I'm going to archive this stuff "cause I might need it for data retention "or I'm just going to delete it, "I don't need it at all." >> Well, Lester, most organizations, if they've been around a while, and the so-called incumbents, they've got data all over the place, their data marts, data warehouses, there are all kinds of different systems and the data lives in silos. So, how do you kind of deal with that problem? Is that part of the journey? >> That's a great point Dave, because you're right that the data silos happen because this business unit is chartered with this task another business unit has this task and that's how you get those instantiations of the same data occurring in multiple places. So as part of your cloud migration journey, you really want to plan where there's an opportunity to consolidate your data, because that means there'll be less to manage, there'll be less data to secure, and it'll have a smaller footprint, which means reduced costs. >> So, people always talk about a single version of the truth, data quality is a huge issue. I've talked to data practitioners and they've indicated that the quality metrics are in the single digits and they're trying to get to 90% plus, but maybe you could address data quality. Where does that fit in on the journey? >> That's, a very important point. First of all, you don't want to bring your legacy issues with you. As the point I made earlier, if you've got data quality issues, this is a good time to find those and identify and remediate them. But that can be a laborious task. We've had customers that have tried to do this by hand and it's very, very time consuming, cause you imagine if you've got 200 tables, 50,000 columns, imagine, the manual labor involved in doing that. And you could probably accomplish it, but it'll take a lot of work. So the opportunity to use tools here and automate that process is really will help you find those outliers there's that bad data and correct it before you move to the cloud. >> And you're just talking about that automation it's the same thing with data catalog and that one of the earlier steps. Organizations would do this manually or they try to do it manually and that's a lot of reason for the failure. They just, it's like cleaning out your data like you just don't want to do it (laughs). Okay, so then what's next? I think we're plowing through your steps here. What what's next on the journey? >> The next one is, in a nutshell, preserve your data format. Don't boil the ocean here to use a cliche. You want to do a certain degree of lift and shift because you've got application dependencies on that data and the data format, the tables on which they sit, the columns and the way they're named. So, some degree you are going to be doing a lift and shift, but it's an intelligent lift and shift using all the insights you've gathered by cataloging the data, looking for data quality issues, looking for duplicate columns, doing planning consolidation. You don't want to also rewrite your application. So, in that aspect, I think it's important to do a bit of lift and shift and preserve those data formats as they sit. >> Okay, so let me follow up on that. That sounds really important to me, because if you're doing a conversion and you're rewriting applications, that means that you're going to have to freeze the existing application, and then you going to be refueling the plane as you're in midair and a lot of times, especially with mission critical systems, you're never going to bring those together and that's a recipe for disaster, isn't it? >> Great analogy unless you're with the air force, you'll (mumbles) (laughs). Now, that's correct. It's you want to have bite-sized steps and that's why it's important to plan your journey, take these steps. You're using automation where you can to make that journey to the cloud much easier and more straightforward. >> All right, I like that. So we're taking a kind of a systems view and end to end view of the data pipeline, if you will. What's next? I think we're through. I think I've counted six. What's the lucky seven? >> Lucky seven, involve your business users. Really, when you think about it, your data is in silos. Part of this migration to the cloud is an opportunity to break down these silos, these silos that naturally occur as part of the business unit. You've got to break these cultural barriers that sometimes exist between business and say, so for example, I always advise, there's an opportunity here to consolidate your sensitive data, your PII, your personally identifiable information, and if three different business units have the same source of truth for that, there's was an opportunity to consolidate that into one as you migrate. That might be a little bit of tweaking to some of the apps that you have that are dependent on it, but in the long run, that's what you really want to do. You want to have a single source of truth, you want to ring fence that sensitive data, and you want all your business users talking together so that you're not reinventing the wheel. >> Well, the reason I think too that's so important is that you're now I would say you're creating a data driven culture. I know that's sort of a buzz word, but what it's true and what that means to me is that your users, your lines of business feel like they actually own the data rather than pointing fingers at the data group, the IT group, the data quality people, data engineers, saying, "Oh, I don't believe it." If the lines of business own the data, they're going to lean in, they're going to maybe bring their own data science resources to the table, and it's going to be a much more collaborative effort as opposed to a non-productive argument. >> Yeah. And that's where we want to get to. DataOps is key, and maybe that's a term that's still evolving. But really, you want the data to drive the business because that's where your insights are, that's where your value is. You want to break down the silos between not only the business units, as I mentioned, but also as you pointed out, the roles of the people that are working with it. A self service data culture is the right way to go with the right security controls, putting on my security hat of course in place so that if I'm a developer and I'm building a new application, I'd love to be able to go to the data catalog, "Oh, there's already a database that has the customer "what the customers have clicked on when shopping." I could use that. I don't have to rebuild that, I'll just use that as for my application. That's the kind of problems you want to be able to solve and that's where your cost reductions come in across the board. >> Yeah. I want to talk a little bit about the business context here. We always talk about data, it's the new source of competitive advantage, I think there's not a lot of debate about that, but it's hard. A lot of companies are struggling to get value out of their data because it's so difficult. All the things we've talked about, the silos, the data quality, et cetera. So, you mentioned the term data apps, data apps is all about streamlining, that data, pipelining, infusing automation and machine intelligence into that pipeline and then ultimately taking a systems view and compressing that time to insights so that you can drive monetization, whether it's cut costs, maybe it's new revenue, drive productivity, but it's that end to end cycle time reduction that successful practitioners talk about as having the biggest business impact. Are you seeing that? >> Absolutely, but it is a journey and it's a huge cultural change for some companies that are. I've worked in many companies that are ticket based IT-driven and just do even the marginalist of change or get insight, raise a ticket, wait a week and then out the other end will pop maybe a change that I needed and it'll take a while for us to get to a culture that truly has a self service data-driven nature where I'm the business owner, and I want to bring in a data scientist because we're losing. For example, a business might be losing to a competitor and they want to find what insights, why is the customer churn, for example, happening every Tuesday? What is it about Tuesday? This is where your data scientist comes in. The last thing you want is to raise a ticket, wait for the snapshot of the data, you want to enable that data scientist to come in, securely connect into the data, and do his analysis, and come back and give you those insights, which will give you that competitive advantage. >> Well, I love your point about churn, maybe it talks about the Andreessen quote that "Software's eating the world," and all companies are our software companies, and SaaS companies, and churn is the killer of SaaS companies. So very, very important point you're making. My last question for you before we summarize is the tech behind all of these. What makes Io-Tahoe unique in its ability to help automate that data pipeline? >> Well, we've done a lot of research, we have I think now maybe 11 pending patent applications, I think one has been approved to be issued (mumbles), but really, it's really about sitting down and doing the right kind of analysis and figuring out how we can optimize this journey. Some of these stuff isn't rocket science. You can read a schema and into an open source solution, but you can't necessarily find the hidden insights. So if I want to find my foreign key dependencies, which aren't always declared in the database, or I want to identify columns by their content, which because the columns might be labeled attribute one, attribute two, attribute three, or I want to find out how my data flows between the various tables in my database. That's the point at which you need to bring in automation, you need to bring in data science solutions, and there's even a degree of machine learning because for example, we might deduce that data is flowing from this table to this table and upon when you present that to the user with a 87% confidence, for example, and the user can go, or the administrator can go. Now, it really goes the other way, it was an invalid collusion and that's the machine learning cycle. So the next time we see that pattern again, in that environment we will be able to make a better recommendation because some things aren't black and white, they need that human intervention loop. >> All right, I just want to summarize with Lester Waters' playbook to moving to the cloud and I'll go through them. Hopefully, I took some notes, hopefully, I got them right. So step one, you want to do that data discovery audit, you want to be fact-based. Two is you want to remediate that data redundancy, and then three identify what you can get rid of. Oftentimes you don't get rid of stuff in IT, or maybe archive it to cheaper media. Four is consolidate those data silos, which is critical, breaking down those data barriers. And then, five is attack the quality issues before you do the migration. Six, which I thought was really intriguing was preserve that data format, you don't want to do the rewrite applications and do that conversion. It's okay to do a little bit of lifting and shifting >> This comes in after the task. >> Yeah, and then finally, and probably the most important is you got to have that relationship with the lines of business, your users, get them involved, begin that cultural shift. So I think great recipe Lester for safe cloud migration. I really appreciate your time. I'll give you the final word if you will bring us home. >> All right. Well, I think the journey to the cloud it's a tough one. You will save money, I have heard people say, you got to the cloud, it's too expensive, it's too this, too that, but really, there is an opportunity for savings. I'll tell you when I run data services as a PaaS service in the cloud, it's wonderful because I can scale up and scale down almost by virtually turning a knob. And so I'll have complete control and visibility of my costs. And so for me, that's very important. Io also, it gives me the opportunity to really ring fence my sensitive data, because let's face it, most organizations like being in a cheese grater when you talk about security, because there's so many ways in and out. So I find that by consolidating and bringing together the crown jewels, if you will. As a security practitioner, it's much more easy to control. But it's very important. You can't get there without some automation and automating this discovery and analysis process. >> Well, great advice. Lester, thanks so much. It's clear that the capex investments on data centers are generally not a good investment for most companies. Lester, really appreciate, Lester waters CTO of Io-Tahoe. Let's watch this short video and we'll come right back. You're watching The Cube, thank you. (upbeat music)

(upbeat music) >> Reporter: From around the globe, it's The Cube with digital coverage of enterprise data automation and event series brought to you by Io-Tahoe. >> Okay, we're back. Focusing on enterprise data automation, we're going to talk about the journey to the cloud. Remember, the hashtag is data automated. We're here with Lester Waters who's the CTO of Io-Tahoe, Lester, good to see you from across the pond on video, wish we were face to face, but it's great to have you on The Cube. >> Also I do, thank you for having me. >> Oh, you're very welcome. Hey, give us a little background on CTO, you got a deep expertise in a lot of different areas, but what do we need to know? >> Well, David, I started my career basically at Microsoft, where I started the Information Security Cryptography Group. They're the very first one that the company had and that led to a career in information security and of course, as you go along with the information security, data is the key element to be protected. So I always had my hands in data and that naturally progressed into a role with Io-Tahoe as their CTO. >> Guys, I have to invite you back, we'll talk crypto all day we'd love to do that but we're here talking about yeah, awesome, right? But we're here talking about the cloud and here we'll talk about the journey to the cloud and accelerate. Everybody's really interested obviously in cloud, even more interested now with the pandemic, but what's that all about? >> Well, moving to the cloud is quite an undertaking for most organizations. First of all, we've got as probably if you're a large enterprise, you probably have thousands of applications, you have hundreds and hundreds of database instances, and trying to shed some light on that, just to plan your move to the cloud is a real challenge. And some organizations try to tackle that manually. Really what Io-Tahoe is bringing is trying to tackle that in an automated version to help you with your journey to the cloud. >> Well, look at migrations are sometimes just an evil word to a lot of organizations, but at the same time, building up technical debt veneer after veneer and year, and year, and year is something that many companies are saying, "Okay, it's got to stop." So what's the prescription for that automation journey and simplifying that migration to the cloud? >> Well, I think the very first thing that's all about is data hygiene. You don't want to pick up your bad habits and take them to the cloud. You've got an opportunity here, so I see the journey to the cloud is an opportunity to really clean house, reorganize things, like moving out. You might move all your boxes, but you're kind of probably cherry pick what you're going to take with you and then you're going to organize it as you end up at your new destination. So from that, I get there's seven key principles that I like to operate by when I advise on the cloud migration. >> Okay. So, where do you start? >> Well, I think the first thing is understanding what you got, so discover and cataloging your data and your applications. If I don't know what I have, I can't move it, I can't improve it, I can't build up on it. And I have to understand there is dependency, so building that data catalog is the very first step. What do I got? >> Now, is that a metadata exercise? Sometimes there's more metadata than there is data. Is metadata part of that first step or? >> In deed, metadata is the first step so the metadata really describes the data you have. So, the metadata is going to tell me I have 2000 tables and maybe of those tables, there's an average of 25 columns each, and so that gives me a sketch if you will, of what I need to move. How big are the boxes I need to pack for my move to the cloud? >> Okay, and you're saying you can automate that data classification, categorization, discovery, correct using math machine intelligence, is that correct? >> Yeah, that's correct. So basically we go, and we will discover all of the schema, if you will, that's the metadata description of your tables and columns in your database in the data types. So we take, we will ingest that in, and we will build some insights around that. And we do that across a variety of platforms because everybody's organization has you've got a one yeah, an Oracle Database here, and you've got a Microsoft SQL Database here, you might have something else there that you need to bring site onto. And part of this journey is going to be about breaking down your data silos and understanding what you've got. >> Okay. So, we've done the audit, we know what we've got, what's next? Where do we go next? >> So the next thing is remediating that data. Where do I have duplicate data? Often times in an organization, data will get duplicated. So, somebody will take a snapshot of a data, and then ended up building a new application, which suddenly becomes dependent on that data. So it's not uncommon for an organization of 20 master instances of a customer. And you can see where that will go when trying to keep all that stuff in sync becomes a nightmare all by itself. So you want to understand where all your redundant data is. So when you go to the cloud, maybe you have an opportunity here to consolidate that data. >> Yeah, because you like to borrow in an Einstein or apply an Einstein Bromide right. Keep as much data as you can, but no more. >> Correct. >> Okay. So you get to the point to the second step you're kind of a one to reduce costs, then what? You figure out what to get rid of, or actually get rid of it, what's next? >> Yes, that would be the next step. So figuring out what you need and what you don't need often times I've found that there's obsolete columns of data in your databases that you just don't need, or maybe it's been superseded by another, you've got tables that have been superseded by other tables in your database. So you got to understand what's being used and what's not and then from that, you can decide, "I'm going to leave this stuff behind, "or I'm going to archive this stuff "cause I might need it for data retention "or I'm just going to delete it, "I don't need it at all." >> Well, Lester, most organizations, if they've been around a while, and the so-called incumbents, they've got data all over the place, their data marts, data warehouses, there are all kinds of different systems and the data lives in silos. So, how do you kind of deal with that problem? Is that part of the journey? >> That's a great point Dave, because you're right that the data silos happen because this business unit is chartered with this task another business unit has this task and that's how you get those instantiations of the same data occurring in multiple places. So as part of your cloud migration journey, you really want to plan where there's an opportunity to consolidate your data, because that means there'll be less to manage, there'll be less data to secure, and it'll have a smaller footprint, which means reduced costs. >> So, people always talk about a single version of the truth, data quality is a huge issue. I've talked to data practitioners and they've indicated that the quality metrics are in the single digits and they're trying to get to 90% plus, but maybe you could address data quality. Where does that fit in on the journey? >> That's, a very important point. First of all, you don't want to bring your legacy issues with you. As the point I made earlier, if you've got data quality issues, this is a good time to find those and identify and remediate them. But that can be a laborious task. We've had customers that have tried to do this by hand and it's very, very time consuming, cause you imagine if you've got 200 tables, 50,000 columns, imagine, the manual labor involved in doing that. And you could probably accomplish it, but it'll take a lot of work. So the opportunity to use tools here and automate that process is really will help you find those outliers there's that bad data and correct it before you move to the cloud. >> And you're just talking about that automation it's the same thing with data catalog and that one of the earlier steps. Organizations would do this manually or they try to do it manually and that's a lot of reason for the failure. They just, it's like cleaning out your data like you just don't want to do it (laughs). Okay, so then what's next? I think we're plowing through your steps here. What what's next on the journey? >> The next one is, in a nutshell, preserve your data format. Don't boil the ocean here to use a cliche. You want to do a certain degree of lift and shift because you've got application dependencies on that data and the data format, the tables on which they sit, the columns and the way they're named. So, some degree you are going to be doing a lift and shift, but it's an intelligent lift and shift using all the insights you've gathered by cataloging the data, looking for data quality issues, looking for duplicate columns, doing planning consolidation. You don't want to also rewrite your application. So, in that aspect, I think it's important to do a bit of lift and shift and preserve those data formats as they sit. >> Okay, so let me follow up on that. That sounds really important to me, because if you're doing a conversion and you're rewriting applications, that means that you're going to have to freeze the existing application, and then you going to be refueling the plane as you're in midair and a lot of times, especially with mission critical systems, you're never going to bring those together and that's a recipe for disaster, isn't it? >> Great analogy unless you're with the air force, you'll (mumbles) (laughs). Now, that's correct. It's you want to have bite-sized steps and that's why it's important to plan your journey, take these steps. You're using automation where you can to make that journey to the cloud much easier and more straightforward. >> All right, I like that. So we're taking a kind of a systems view and end to end view of the data pipeline, if you will. What's next? I think we're through. I think I've counted six. What's the lucky seven? >> Lucky seven, involve your business users. Really, when you think about it, your data is in silos. Part of this migration to the cloud is an opportunity to break down these silos, these silos that naturally occur as part of the business unit. You've got to break these cultural barriers that sometimes exist between business and say, so for example, I always advise, there's an opportunity here to consolidate your sensitive data, your PII, your personally identifiable information, and if three different business units have the same source of truth for that, there's was an opportunity to consolidate that into one as you migrate. That might be a little bit of tweaking to some of the apps that you have that are dependent on it, but in the long run, that's what you really want to do. You want to have a single source of truth, you want to ring fence that sensitive data, and you want all your business users talking together so that you're not reinventing the wheel. >> Well, the reason I think too that's so important is that you're now I would say you're creating a data driven culture. I know that's sort of a buzz word, but what it's true and what that means to me is that your users, your lines of business feel like they actually own the data rather than pointing fingers at the data group, the IT group, the data quality people, data engineers, saying, "Oh, I don't believe it." If the lines of business own the data, they're going to lean in, they're going to maybe bring their own data science resources to the table, and it's going to be a much more collaborative effort as opposed to a non-productive argument. >> Yeah. And that's where we want to get to. Data apps is key, and maybe that's a term that's still evolving. But really, you want the data to drive the business because that's where your insights are, that's where your value is. You want to break down the silos between not only the business units, as I mentioned, but also as you pointed out, the roles of the people that are working with it. A self service data culture is the right way to go with the right security controls, putting on my security hat of course in place so that if I'm a developer and I'm building a new application, I'd love to be able to go to the data catalog, "Oh, there's already a database that has the customer "what the customers have clicked on when shopping." I could use that. I don't have to rebuild that, I'll just use that as for my application. That's the kind of problems you want to be able to solve and that's where your cost reductions come in across the board. >> Yeah. I want to talk a little bit about the business context here. We always talk about data, it's the new source of competitive advantage, I think there's not a lot of debate about that, but it's hard. A lot of companies are struggling to get value out of their data because it's so difficult. All the things we've talked about, the silos, the data quality, et cetera. So, you mentioned the term data apps, data apps is all about streamlining, that data, pipelining, infusing automation and machine intelligence into that pipeline and then ultimately taking a systems view and compressing that time to insights so that you can drive monetization, whether it's cut costs, maybe it's new revenue, drive productivity, but it's that end to end cycle time reduction that successful practitioners talk about as having the biggest business impact. Are you seeing that? >> Absolutely, but it is a journey and it's a huge cultural change for some companies that are. I've worked in many companies that are ticket based IT-driven and just do even the marginalist of change or get insight, raise a ticket, wait a week and then out the other end will pop maybe a change that I needed and it'll take a while for us to get to a culture that truly has a self service data-driven nature where I'm the business owner, and I want to bring in a data scientist because we're losing. For example, a business might be losing to a competitor and they want to find what insights, why is the customer churn, for example, happening every Tuesday? What is it about Tuesday? This is where your data scientist comes in. The last thing you want is to raise a ticket, wait for the snapshot of the data, you want to enable that data scientist to come in, securely connect into the data, and do his analysis, and come back and give you those insights, which will give you that competitive advantage. >> Well, I love your point about churn, maybe it talks about the Andreessen quote that "Software's eating the world," and all companies are our software companies, and SaaS companies, and churn is the killer of SaaS companies. So very, very important point you're making. My last question for you before we summarize is the tech behind all of these. What makes Io-Tahoe unique in its ability to help automate that data pipeline? >> Well, we've done a lot of research, we have I think now maybe 11 pending patent applications, I think one has been approved to be issued (mumbles), but really, it's really about sitting down and doing the right kind of analysis and figuring out how we can optimize this journey. Some of these stuff isn't rocket science. You can read a schema and into an open source solution, but you can't necessarily find the hidden insights. So if I want to find my foreign key dependencies, which aren't always declared in the database, or I want to identify columns by their content, which because the columns might be labeled attribute one, attribute two, attribute three, or I want to find out how my data flows between the various tables in my database. That's the point at which you need to bring in automation, you need to bring in data science solutions, and there's even a degree of machine learning because for example, we might deduce that data is flowing from this table to this table and upon when you present that to the user with a 87% confidence, for example, and the user can go, or the administrator can go. Now, it really goes the other way, it was an invalid collusion and that's the machine learning cycle. So the next time we see that pattern again, in that environment we will be able to make a better recommendation because some things aren't black and white, they need that human intervention loop. >> All right, I just want to summarize with Lester Waters' playbook to moving to the cloud and I'll go through them. Hopefully, I took some notes, hopefully, I got them right. So step one, you want to do that data discovery audit, you want to be fact-based. Two is you want to remediate that data redundancy, and then three identify what you can get rid of. Oftentimes you don't get rid of stuff in IT, or maybe archive it to cheaper media. Four is consolidate those data silos, which is critical, breaking down those data barriers. And then, five is attack the quality issues before you do the migration. Six, which I thought was really intriguing was preserve that data format, you don't want to do the rewrite applications and do that conversion. It's okay to do a little bit of lifting and shifting >> This comes in after the task. >> Yeah, and then finally, and probably the most important is you got to have that relationship with the lines of business, your users, get them involved, begin that cultural shift. So I think great recipe Lester for safe cloud migration. I really appreciate your time. I'll give you the final word if you will bring us home. >> All right. Well, I think the journey to the cloud it's a tough one. You will save money, I have heard people say, you got to the cloud, it's too expensive, it's too this, too that, but really, there is an opportunity for savings. I'll tell you when I run data services as a PaaS service in the cloud, it's wonderful because I can scale up and scale down almost by virtually turning a knob. And so I'll have complete control and visibility of my costs. And so for me, that's very important. Io also, it gives me the opportunity to really ring fence my sensitive data, because let's face it, most organizations like being in a cheese grater when you talk about security, because there's so many ways in and out. So I find that by consolidating and bringing together the crown jewels, if you will. As a security practitioner, it's much more easy to control. But it's very important. You can't get there without some automation and automating this discovery and analysis process. >> Well, great advice. Lester, thanks so much. It's clear that the capex investments on data centers are generally not a good investment for most companies. Lester, really appreciate, Lester waters CTO of Io-Tahoe. Let's watch this short video and we'll come right back. You're watching The Cube, thank you. (upbeat music)

>> From theCUBE studios in Palo Alto and Boston, connecting with thought-leaders all around the world, this is a Cube Conversation. >> Hi everybody, this is Dave Vellante. Welcome to this Cube Conversation. We're really excited to have Wim Coekaerts in, he is the senior vice-president of software development at Oracle. Wim, it's great to have you on, and, you know I often say I wish we were face-to-face but if we were you'd have to cut off my tie, cause developers and ties just don't go together. >> No, I know, and this is my normal outfit, so this is me wherever I go. Hi again, good to see you. >> Yeah, great to see you. So, of course, you know a lot of people are confused about Oracle, and open-source, they say "Oracle? Open-source? What is that all about?" But I think you're misunderstood. People don't, first of all, realize you as the leader of the software-development community inside of Oracle, I mean, you've been involved in Linux since the early 90s. But you guys have a lot of committers, you do a lot. I want to talk about that. What is up with Oracle, and open-source? >> Ah, well, it's a broad question. So, you know, a couple of things. One is, we have many different areas within the company that are dealing with open-source. So we have the cloud team doing a lot of stuff around cloud SDKs and support for different languages like Python and Go, and of course Java and so forth, so they do a lot around ensuring that the Oracle ecosystem is integrated in the open-source tools that customers use, or developers use, Terraform companies and so forth. And then you have the Java team, and so forth. Java is open-source and then the Graal project, GraalVM which is a polyglot compiler that can run Java, and Python, and Javascript and so forth together in one. VM do really cool optimizations, that's an open-source project, also on GitHub. There's of course MySQL, which is along with Java, they're probably the two most popular and widely used open-source projects out there. There's VirtualBox which is of course also a very popular project that's open-source. There's all the work we do around Linux. And I think one of the things is that, when you have so many different areas, doing things that are for that area, then as a developer or as a customer, you typically just deal with that group. And what you see is, oh you're talking to the Java developers, so you know what's going on around Java. The Java developers might not necessarily say, "Oh well we also do MySQL, and we do Linux and VirtualBox and so forth," and so you get a rather myopic, narrow view of the larger company. When you add all these things up, and there will be one big slide that says "This is Oracle, these are all these open source projects," and there's multiple ways. One is, we have projects that we've open-sourced and all the code came from us and we made it publicly available, we're the main contributor and we get contributions back. There are other projects where we contribute to third-party in terms of enhancing things, like I said with the Cloud Team, and then in general something like Linux where we're part of an external project and we participate in development of that project at large. And so there's these three different ways, when you count up all the developers that we have that deal with open-source on a daily basis. And in terms of contributions, in terms of bug fixes, testing, and so forth, it's thousands, literally, full-time paid developers. And of course, all the projects are all either on GitHub or similar sites that are very popular. So yeah, I think the misunderstood is probably a lack of knowledge of the breadth of what we do. And, you know, our primary goal is to provide services and products to customers, and so the open-source part is sort of embedded in a development methodology. But that's not something we sell or market separately, we just work with customers and products and services, and so in some cases it's not well-understood. >> Yeah. Well, we're talking of course, we're talking about the state of the penguin, I think it's important for people to understand, Oracle got into the Linux game in the 90s, maybe the latter part of the 90s and Oracle, of course, wants to make Linux-- wants to make Oracle, it's applications and database run better on Linux, but as you're pointing out, your Linux distro, full support, end-to-end, thousands of people in your open-source community, and the contributions that you make to Linux, many if not most, they go upstream, everybody can benefit from those, but of course you want an Oracle distro that is going to make Oracle stuff run better, that's always kind of been the Oracle way. >> Well, so, yes, two things though. One is, so everything we do is upstream. So we have no Linux patches that are not contributed upstream; There's no proprietary code in Oracle Linux at all, it's all completely open, publicly available: the source code, the change log, all the commits, it's fully open and public, which sometimes is not well-understood, but it's completely open. And, everything we do in terms of feature development or functionality or bug fixes goes upstream to the Linux kernel mail-list. It's actually, it's the only way to be able to manage a Linux distribution and be a Linux vendor is to live in that eco-system. Otherwise, the cost of maintaining your own fork, so to speak, is very high and it doesn't really solve the problem. Now, the functionality we work on obviously is focused on making Oracle products run better, making Oracle Cloud run better, and so forth. However, again, what's important to understand, though, is an Oracle database is a program running on an operating system. It does IO, it does networking, it deals with memory management, lots of processing. So, for the most part, the things that we work on to improve that helps everyone out, right? It helps every other database run better, or helps every other language run better. So none of these changes are specific to Oracle, they're just things that we found doing performance benchmarks and testing and so forth, where we say "Hey, if Linux did the following, it would make boot-up faster. Now boot-up has nothing to do with the database. But our customers run on 1-terabyte, 4-terabyte, 8-terabyte systems, and so booting up, and Linux starting up, and cleaning up memory takes a long time. So we want to reduce that from an availability point of view. So here, we're now talking about just enterprise for you. So there's this broad set of things we work on that definitely help us, but they're actually really completely generic and help everyone out. >> Yeah, that's great. So I wanted to kind of get that out of the way and help our audience understand that. So let's get into it a little bit; What are you seeing, what's going on in IT, pick your observation space and your vision of what you see happening out there. >> Well, you know, it's very interesting, it's sort of, there's two... there's sort of two worlds, right, there's the cloud world and the move to cloud, and there's the on-premises world, where people run their systems on their own. And, one of the things that we've learned is, when you talk about machine-learning, obviously, is something that's very popular these days, and automation. And so in order to rely on machine-learning well, and have algorithms that are very effective, you need lots of data. And so being a cloud vendor, and having Linux in our cloud on tens of thousands, or hundreds of thousands of servers, or more, allows us to have a view of how an operating system works across an incredibly large scale. So we get lots of data. And so for us to figure out which algorithms work well in terms of how can we do network optimizations, how can we discover anomalies on the storage site, and deal with it and so forth, we can do that at scale. And what's interesting is, how do we then bring that on-prem? Well, if we can get the data and the learning done, the training done, in our cloud directly, then when we provide that service also for people running Oracle Linux on premises then that will work. The alternative is to have point solutions where you provide something to a customer, and he needs to learn something from small amounts of data. That doesn't work so well. So I think having both worlds, on-prem and cloud directly, allows us to kind of benefit from that. And I think that's important, because lots of customers are interested in going to cloud. Many of the enterprises have not yet. You know, they're starting, but there's still a huge on-premises space that's important. And so by being able to get them familiar with how these things work at scale, autonomy is again important, right, Autonomous Database is incredibly popular and so forth, that allows us to then say, "Here, try these things out here, it's a service. We can show you the benefits right away," and then as that improves we bring that, to a certain extent, on-premises as well. And then they can have it in both places. And that, I think, is something, again, that's relatively unique but also very important, is that we want to provide services and products that act similarly on-premises as well as in cloud, because at some point when people move we want to make that transition seamless. And what you have today for the most part is one world that's on-prem, and then the cloud world is completely different. And that is a big barrier of moving, and so we want to reduce that, we can run the same operating system local as well as cloud, you can the same functionality, and then that helps transition people over much easier. >> Yeah, well Oracle actually was one of the -- I think Oracle was the first company to actually market same-same, you actually used that term. Others put forth that concept, but Oracle was the first to announce products like Cloud at Customer, that were same-same, now it took some time to actually get it perfected, and get it to market, but the point is, and we've written about this, is Oracle, because of the ascendancy of cloud, flipped and has a cloud-first mentality, and you just kind of referenced that, you just said, "And you can bring that to on-prem." So I wonder if you could talk about that cloud-first mentality, and the impact on hybrid. >> So yeah, I think the cloud-first part is of course in cloud we work on services moreso than products that we deliver. And there's a number of things that are happening. So one is that we obviously continue to provide products to customers, you can download Oracle Linux, you can download the database and what not, you can install it on your own, you can do the traditional way of working. Then in the cloud-world, what typically happens is "Oh, I use a database service. I'm not installing anything, I push a button and I get an IP address and a SQL that connects extremely quickly to the database." And we take care of everything underneath that is on this database. Now, in order to do that, you need a whole infrastructure in place, you need log-in agents, you need a back-end that captures all that stuff, you need monitoring tools, you need all the automation scripts for bringing the service up and monitor it. And so, that takes a lot of time to do right, and we learn a lot by doing this. And so the cloud-first part of these services means that we get to experience this ourselves with direct access to everything. Now taking that service with all of the additional features like autonomy, and bringing that to an on-premises world, we have to make sure we can package that so that all these pieces around it go along with it. And that takes a little bit more time, so we can do everything at the same time. And so what we've done with Autonomous Database is we created everything in Oracle Cloud, we have the whole system running really well, and then we've been able to sort of package that and shrink it into something that can be installed on-premises, but then connected into Oracle Cloud again. And so that way we can get all the telemetry over the metric, and that allows us to scale. Because part of providing a cloud service that runs on-prem in the customer environment is that we need to be able to remotely manage that similar to how that runs in our own cloud. Right, otherwise it doesn't scale. And so that takes a little bit of time, but we've done all that work, and now with Cloud at Customer Database that's really in place. >> Yeah, you really want to have that same cloud experience, whether with on-prem, in the public cloud, hybrid, et cetera. So, I want to explore a little bit more who is using Oracle Linux, and what's the driver for using it. Can you describe maybe some of the types of customers and why they buy? >> Sure, so we started this fourteen years ago, in 2006, October 25th, 2006. I remember that day very well; Penguins on stage and a big launch for Oracle Linux in San Francisco Moscone Center. So, look, the initial driver for Oracle Linux was to ensure that Oracle database customers or Oracle product customers had a good operating system experience, and the ability to be able to handle critical issues when that occurs, because typically a database runs the company's critical data: the most essential stuff that a company has is typically in a database, an Oracle database. And so when that thing has issues with the operating system, you don't want just to talk to multiple vendors and have finger-pointing, and having to explain to an operating system vendor how the database works. In the Unix world, we had a good relationship with the OS vendors, and the hardware vendors, they were the same. And they knew our products really well, and in the Linux world, that was very different. The OS vendor basically did not want to understand or learn anything about the products living on top. And so while to a certain extent that makes sense, it's an enterprise world where time is of the essence, and downtime needs to be limited absolutely. We can't have these arguments and such. And that was the driver, initially, for doing Oracle Linux. It was to ensure there was a Linux distribution really backed by us, that we could fix, that we could fully support. That was completely the original intent. And so the early customer base was database customers. Database and middleware. Mostly database. But that has then evolved quickly, and so what happened was, people say "Look, I have a thousand servers, a hundred run Oracle, so we'll run Oracle Linux on those hundred, and we'll run something else on those other nine-hundred." Now after a year or so, they realize that our support is really good; We fix all these issues, and so then they're like "Why are we having two Linux distributions? This thing works really well, it runs any application, it's fully compatible, so we'll do a thousand with Oracle Linux." And so the early days, the first few years, was definitely Oracle Database as the core driver, and then it sort of expanded to the rest of the estate. And over the years, we've added lots of features and functionality, like Ksplice, and so forth. We have an attractive pricing model for running on servers, and so now lots of our customers have a very small Oracle percentage running and many other things running. So it's really become a all-or-nothing play in the Linux space, and we're well-known now, so it's actually very good. >> You just mentioned Ksplice. We've been talking about cloud, and on-prem, and hybrid. Let's talk about security, because security really is a differentiator, particularly if you're going to start to put stuff in the cloud. Talk about Ksplice specifically, but generally security and your policy there. >> So, "Security first" is sort of what you hear us say and do, in everything we do. The database obviously security, on the Linux site security matters. Ksplice as a technology is there to do critical bug-fixing and make sure that we can apply security vulnerability fixes without affecting the customer, and not have downtime. And if you look at most of the cases or many of the cases where you have security vulnerabilities and exploits, it tends to be because systems were not patched. Why were they not patched? Well not that our customer doesn't understand that it's important, but it's a whole train of events that needs to happen. You have to, you get notified that there's a security issue in your operating system or application. Then, well, an application typically means it's a multi-layered setup. So if you have to bring your database server down, then you first have to coordinate with the application users to bring the app server down, cause that talks to the database. So to patch one system, you basically have to bring down the whole application stack. You have to negotiate with the DBAs, you have to negotiate with the app admins, you have to negotiate with the user. It takes weeks to do that and find time. Well during that time, you're vulnerable. So the only way, really, to address security in a scalable and reducing that window of time is to do it without affecting the customer. And so Casewise is something that, it's a company we acquired in 2009, and have since evolved in terms of capabilities, and so it allows us to patch the Linux terminal without downtime. We lock the kernel for 8 microseconds. It's literally no downtime. You don't have to bring down applications, the user doesn't see it, there's no hang, there's no delay. And so by doing that, you can run a Linux operating system, or gLinux, and you can be fully patched on a system that hasn't rebooted for 3 years. You don't even know it. And so by doing that type of stuff, it makes customers more secure, and it avoids them-- It saves them a lot of money in terms of dealing with project management and so forth, but it really keeps them secure. And so we do that for the Linux kernel, we do that for some of the libraries on top that are critical like OpenSSL and 2 LVC, and, you know one example-- I can give you two examples. So one example is, Heartbleed was this bug in OpenSSL a number of years ago. And so everyone had to patch their SSH server. And that meant, basically, systems around the world had to reboot. Like a whole IT reboot across the world. With Ksplice today, if Heartbleed were to happen tomorrow, we would be able to patch this online for all the Oracle Linux customers without any downtime. No reboots, no restarting of applications, everything keeps running. The amount of money saved would be massive, and also, of course, the headache. Another example is, and this was in Oracle Cloud, when some of these CPU bugs that happened a few years ago that were rather damaging on the cloud side, where you could basically see memory potentially of other CPUs running, the cloud is incredibly critical. We were basically able to basically patch our entire cloud in four hours. And the customer didn't know, right, a hundred and twenty million patches, or something, that we applied within four hours, all online, without any downtime. And so that technology has been really helpful, both for us to run our cloud, but the exact same patches and same fixes go to customers on-premises as well. But this comes back to the whole, what we do in cloud we also do for customer. And I think that's a unique thing that we have at Oracle which is quite fascinating. The operating system we run for our customers, the operating system that's the host part of VMs, is the exact same binary and source code that we make available, just to be clear, the exact same binaries are the ones that you run as a customer on-premises. So if you run Oracle Linux with KVM, you run VMs, you're actually running the exact same stuff as we run underneath our customer's stuff. Nobody else does that, everyone else has a black box. So I think that helps a little bit with transparency as well. >> Yeah, and that homogeneity just creates an environment, you're talking about that sort of security mindset, it's critical, you're not just bolting it on, it's part of the culture. But you started your career, and then of course you were a Linux person when you came to Oracle, but then I think you spent some time in database, back in the day when there were serious database wars going on, before Oracle became the king of database. So now you've got, obviously, this great portfolio, and a lot of really sharp software developers; What should we expect going forward, from Oracle? What should we look for? >> You know, I was talking to some, I was welcoming some interns to the company, for their summer internship yesterday, and one of the things I mentioned to them was that -- so cloud obviously gives us a lot of opportunities, but there's a number of things. One is, we have such a breadth of applications and software and hardware together. We have the servers, we have the storage, we have the operating systems, we have the database layer and so forth, and we have the cloud side, and one of the great opportunities, and I think we've shown a lot of this happening with the ability to create something like Autonomous Database, is to combine all these things. Right, we have such a broad portfolio of really cool technology that by itself is okay, but if you combine the things it really becomes awesome. You cannot create autonomous database without having autonomous learning. You cannot create those two and make them really safe without also controlling the firmware on the hardware and so forth. So by being able to combine all these layers, and by having a really great relationship across the teams within the company, that opens up a lot of opportunities to do stuff really quickly. And having the scale for that. I think that has been, for the last few years, a really great thing, but I can see that being one of the advantages that we have going forward. We have Oracle Fusion Applications, which is incredibly popular, and has great growth, and then we have that running on Oracle Cloud, that talks to Oracle Autonomous Database, so we bring all these pieces together. And no other SaaS vendor can do that, because they don't have these other pieces. They have one area, we have all of them. And so that's the exciting part for me, it's not so much about making my own world better, and having Linux be better, and Casewise and so forth, which is important, but that becoming part of the bigger picture. And that's the exciting part. >> Well, Oracle's always invested in RND, we've made that point many, many times. Whether it's database, you know Fusion was a painful but worthy effort, the whole public cloud piece, obviously many acquisitions, but the investments that you've made in open-source as well, Wim, you're a great spokesperson, and a great representative of the open-source community generally, and then Oracle specifically, so thanks very much for coming on theCUBE and sharing with us the state of the penguin, and best of luck. >> You're welcome. Thank you, thanks for having me. >> Alright, and thank you for watching, everybody. This is Dave Vellante for theCUBE. We'll see you next time. (cheerful music).

>> From theCUBE studios in Palo Alto and Boston, connecting with thought-leaders all around the world, this is a Cube Conversation. >> Hi everybody, this is Dave Vellante. Welcome to this Cube Conversation. We're really excited to have Wim Coekaerts in, he is the senior vice-president of software development at Oracle. Wim, it's great to have you on, and, you know I often say I wish we were face-to-face but if we were you'd have to cut off my tie, cause developers and ties just don't go together. >> No, I know, and this is my normal outfit, so this is me wherever I go. Hi again, good to see you. >> Yeah, great to see you. So, of course, you know a lot of people are confused about Oracle, and open-source, they say "Oracle? Open-source? What is that all about?" But I think you're misunderstood. People don't, first of all, realize you as the leader of the software-development community inside of Oracle, I mean, you've been involved in Linux since the early 90s. But you guys have a lot of committers, you do a lot. I want to talk about that. What is up with Oracle, and open-source? >> Ah, well, it's a broad question. So, you know, a couple of things. One is, we have many different areas within the company that are dealing with open-source. So we have the cloud team doing a lot of stuff around cloud SDKs and support for different languages like Python and Go, and of course Java and so forth, so they do a lot around ensuring that the Oracle ecosystem is integrated in the open-source tools that customers use, or developers use, Terraform companies and so forth. And then you have the Java team, and so forth. Java is open-source and then the Graal project, GraalVM which is a polyglot compiler that can run Java, and Python, and Javascript and so forth together in one. VM do really cool optimizations, that's an open-source project, also on GitHub. There's of course MySQL, which is along with Java, they're probably the two most popular and widely used open-source projects out there. There's VirtualBox which is of course also a very popular project that's open-source. There's all the work we do around Linux. And I think one of the things is that, when you have so many different areas, doing things that are for that area, then as a developer or as a customer, you typically just deal with that group. And what you see is, oh you're talking to the Java developers, so you know what's going on around Java. The Java developers might not necessarily say, "Oh well we also do MySQL, and we do Linux and VirtualBox and so forth," and so you get a rather myopic, narrow view of the larger company. When you add all these things up, and there will be one big slide that says "This is Oracle, these are all these open source projects," and there's multiple ways. One is, we have projects that we've open-sourced and all the code came from us and we made it publicly available, we're the main contributor and we get contributions back. There are other projects where we contribute to third-party in terms of enhancing things, like I said with the Cloud Team, and then in general something like Linux where we're part of an external project and we participate in development of that project at large. And so there's these three different ways, when you count up all the developers that we have that deal with open-source on a daily basis. And in terms of contributions, in terms of bug fixes, testing, and so forth, it's thousands, literally, full-time paid developers. And of course, all the projects are all either on GitHub or similar sites that are very popular. So yeah, I think the misunderstood is probably a lack of knowledge of the breadth of what we do. And, you know, our primary goal is to provide services and products to customers, and so the open-source part is sort of embedded in a development methodology. But that's not something we sell or market separately, we just work with customers and products and services, and so in some cases it's not well-understood. >> Yeah. Well, we're talking of course, we're talking about the state of the penguin, I think it's important for people to understand, Oracle got into the Linux game in the 90s, maybe the latter part of the 90s and Oracle, of course, wants to make Linux-- wants to make Oracle, it's applications and database run better on Linux, but as you're pointing out, your Linux distro, full support, end-to-end, thousands of people in your open-source community, and the contributions that you make to Linux, many if not most, they go upstream, everybody can benefit from those, but of course you want an Oracle distro that is going to make Oracle stuff run better, that's always kind of been the Oracle way. >> Well, so, yes, two things though. One is, so everything we do is upstream. So we have no Linux patches that are not contributed upstream; There's no proprietary code in Oracle Linux at all, it's all completely open, publicly available: the source code, the change log, all the commits, it's fully open and public, which sometimes is not well-understood, but it's completely open. And, everything we do in terms of feature development or functionality or bug fixes goes upstream to the Linux kernel mail-list. It's actually, it's the only way to be able to manage a Linux distribution and be a Linux vendor is to live in that eco-system. Otherwise, the cost of maintaining your own fork, so to speak, is very high and it doesn't really solve the problem. Now, the functionality we work on obviously is focused on making Oracle products run better, making Oracle Cloud run better, and so forth. However, again, what's important to understand, though, is an Oracle database is a program running on an operating system. It does IO, it does networking, it deals with memory management, lots of processing. So, for the most part, the things that we work on to improve that helps everyone out, right? It helps every other database run better, or helps every other language run better. So none of these changes are specific to Oracle, they're just things that we found doing performance benchmarks and testing and so forth, where we say "Hey, if Linux did the following, it would make boot-up faster. Now boot-up has nothing to do with the database. But our customers run on 1-terabyte, 4-terabyte, 8-terabyte systems, and so booting up, and Linux starting up, and cleaning up memory takes a long time. So we want to reduce that from an availability point of view. So here, we're now talking about just enterprise for you. So there's this broad set of things we work on that definitely help us, but they're actually really completely generic and help everyone out. >> Yeah, that's great. So I wanted to kind of get that out of the way and help our audience understand that. So let's get into it a little bit; What are you seeing, what's going on in IT, pick your observation space and your vision of what you see happening out there. >> Well, you know, it's very interesting, it's sort of, there's two... there's sort of two worlds, right, there's the cloud world and the move to cloud, and there's the on-premises world, where people run their systems on their own. And, one of the things that we've learned is, when you talk about machine-learning, obviously, is something that's very popular these days, and automation. And so in order to rely on machine-learning well, and have algorithms that are very effective, you need lots of data. And so being a cloud vendor, and having Linux in our cloud on tens of thousands, or hundreds of thousands of servers, or more, allows us to have a view of how an operating system works across an incredibly large scale. So we get lots of data. And so for us to figure out which algorithms work well in terms of how can we do network optimizations, how can we discover anomalies on the storage site, and deal with it and so forth, we can do that at scale. And what's interesting is, how do we then bring that on-prem? Well, if we can get the data and the learning done, the training done, in our cloud directly, then when we provide that service also for people running Oracle Linux on premises then that will work. The alternative is to have point solutions where you provide something to a customer, and he needs to learn something from small amounts of data. That doesn't work so well. So I think having both worlds, on-prem and cloud directly, allows us to kind of benefit from that. And I think that's important, because lots of customers are interested in going to cloud. Many of the enterprises have not yet. You know, they're starting, but there's still a huge on-premises space that's important. And so by being able to get them familiar with how these things work at scale, autonomy is again important, right, Autonomous Database is incredibly popular and so forth, that allows us to then say, "Here, try these things out here, it's a service. We can show you the benefits right away," and then as that improves we bring that, to a certain extent, on-premises as well. And then they can have it in both places. And that, I think, is something, again, that's relatively unique but also very important, is that we want to provide services and products that act similarly on-premises as well as in cloud, because at some point when people move we want to make that transition seamless. And what you have today for the most part is one world that's on-prem, and then the cloud world is completely different. And that is a big barrier of moving, and so we want to reduce that, we can run the same operating system local as well as cloud, you can the same functionality, and then that helps transition people over much easier. >> Yeah, well Oracle actually was one of the -- I think Oracle was the first company to actually market same-same, you actually used that term. Others put forth that concept, but Oracle was the first to announce products like Cloud at Customer, that were same-same, now it took some time to actually get it perfected, and get it to market, but the point is, and we've written about this, is Oracle, because of the ascendancy of cloud, flipped and has a cloud-first mentality, and you just kind of referenced that, you just said, "And you can bring that to on-prem." So I wonder if you could talk about that cloud-first mentality, and the impact on hybrid. >> So yeah, I think the cloud-first part is of course in cloud we work on services moreso than products that we deliver. And there's a number of things that are happening. So one is that we obviously continue to provide products to customers, you can download Oracle Linux, you can download the database and what not, you can install it on your own, you can do the traditional way of working. Then in the cloud-world, what typically happens is "Oh, I use a database service. I'm not installing anything, I push a button and I get an IP address and a SQL that connects extremely quickly to the database." And we take care of everything underneath that is on this database. Now, in order to do that, you need a whole infrastructure in place, you need log-in agents, you need a back-end that captures all that stuff, you need monitoring tools, you need all the automation scripts for bringing the service up and monitor it. And so, that takes a lot of time to do right, and we learn a lot by doing this. And so the cloud-first part of these services means that we get to experience this ourselves with direct access to everything. Now taking that service with all of the additional features like autonomy, and bringing that to an on-premises world, we have to make sure we can package that so that all these pieces around it go along with it. And that takes a little bit more time, so we can do everything at the same time. And so what we've done with Autonomous Database is we created everything in Oracle Cloud, we have the whole system running really well, and then we've been able to sort of package that and shrink it into something that can be installed on-premises, but then connected into Oracle Cloud again. And so that way we can get all the telemetry over the metric, and that allows us to scale. Because part of providing a cloud service that runs on-prem in the customer environment is that we need to be able to remotely manage that similar to how that runs in our own cloud. Right, otherwise it doesn't scale. And so that takes a little bit of time, but we've done all that work, and now with Cloud at Customer Database that's really in place. >> Yeah, you really want to have that same cloud experience, whether with on-prem, in the public cloud, hybrid, et cetera. So, I want to explore a little bit more who is using Oracle Linux, and what's the driver for using it. Can you describe maybe some of the types of customers and why they buy? >> Sure, so we started this fourteen years ago, in 2006, October 25th, 2006. I remember that day very well; Penguins on stage and a big launch for Oracle Linux in San Francisco Moscone Center. So, look, the initial driver for Oracle Linux was to ensure that Oracle database customers or Oracle product customers had a good operating system experience, and the ability to be able to handle critical issues when that occurs, because typically a database runs the company's critical data: the most essential stuff that a company has is typically in a database, an Oracle database. And so when that thing has issues with the operating system, you don't want just to talk to multiple vendors and have finger-pointing, and having to explain to an operating system vendor how the database works. In the Unix world, we had a good relationship with the OS vendors, and the hardware vendors, they were the same. And they knew our products really well, and in the Linux world, that was very different. The OS vendor basically did not want to understand or learn anything about the products living on top. And so while to a certain extent that makes sense, it's an enterprise world where time is of the essence, and downtime needs to be limited absolutely. We can't have these arguments and such. And that was the driver, initially, for doing Oracle Linux. It was to ensure there was a Linux distribution really backed by us, that we could fix, that we could fully support. That was completely the original intent. And so the early customer base was database customers. Database and middleware. Mostly database. But that has then evolved quickly, and so what happened was, people say "Look, I have a thousand servers, a hundred run Oracle, so we'll run Oracle Linux on those hundred, and we'll run something else on those other nine-hundred." Now after a year or so, they realize that our support is really good; We fix all these issues, and so then they're like "Why are we having two Linux distributions? This thing works really well, it runs any application, it's fully compatible, so we'll do a thousand with Oracle Linux." And so the early days, the first few years, was definitely Oracle Database as the core driver, and then it sort of expanded to the rest of the estate. And over the years, we've added lots of features and functionality, like Ksplice, and so forth. We have an attractive pricing model for running on servers, and so now lots of our customers have a very small Oracle percentage running and many other things running. So it's really become a all-or-nothing play in the Linux space, and we're well-known now, so it's actually very good. >> You just mentioned Ksplice. We've been talking about cloud, and on-prem, and hybrid. Let's talk about security, because security really is a differentiator, particularly if you're going to start to put stuff in the cloud. Talk about Ksplice specifically, but generally security and your policy there. >> So, "Security first" is sort of what you hear us say and do, in everything we do. The database obviously security, on the Linux site security matters. Ksplice as a technology is there to do critical bug-fixing and make sure that we can apply security vulnerability fixes without affecting the customer, and not have downtime. And if you look at most of the cases or many of the cases where you have security vulnerabilities and exploits, it tends to be because systems were not patched. Why were they not patched? Well not that our customer doesn't understand that it's important, but it's a whole train of events that needs to happen. You have to, you get notified that there's a security issue in your operating system or application. Then, well, an application typically means it's a multi-layered setup. So if you have to bring your database server down, then you first have to coordinate with the application users to bring the app server down, cause that talks to the database. So to patch one system, you basically have to bring down the whole application stack. You have to negotiate with the DBAs, you have to negotiate with the app admins, you have to negotiate with the user. It takes weeks to do that and find time. Well during that time, you're vulnerable. So the only way, really, to address security in a scalable and reducing that window of time is to do it without affecting the customer. And so Casewise is something that, it's a company we acquired in 2009, and have since evolved in terms of capabilities, and so it allows us to patch the Linux terminal without downtime. We lock the kernel for 8 microseconds. It's literally no downtime. You don't have to bring down applications, the user doesn't see it, there's no hang, there's no delay. And so by doing that, you can run a Linux operating system, or gLinux, and you can be fully patched on a system that hasn't rebooted for 3 years. You don't even know it. And so by doing that type of stuff, it makes customers more secure, and it avoids them-- It saves them a lot of money in terms of dealing with project management and so forth, but it really keeps them secure. And so we do that for the Linux kernel, we do that for some of the libraries on top that are critical like OpenSSL and 2 LVC, and, you know one example-- I can give you two examples. So one example is, Heartbleed was this bug in OpenSSL a number of years ago. And so everyone had to patch their SSH server. And that meant, basically, systems around the world had to reboot. Like a whole IT reboot across the world. With Ksplice today, if Heartbleed were to happen tomorrow, we would be able to patch this online for all the Oracle Linux customers without any downtime. No reboots, no restarting of applications, everything keeps running. The amount of money saved would be massive, and also, of course, the headache. Another example is, and this was in Oracle Cloud, when some of these CPU bugs that happened a few years ago that were rather damaging on the cloud side, where you could basically see memory potentially of other CPUs running, the cloud is incredibly critical. We were basically able to basically patch our entire cloud in four hours. And the customer didn't know, right, a hundred and twenty million patches, or something, that we applied within four hours, all online, without any downtime. And so that technology has been really helpful, both for us to run our cloud, but the exact same patches and same fixes go to customers on-premises as well. But this comes back to the whole, what we do in cloud we also do for customer. And I think that's a unique thing that we have at Oracle which is quite fascinating. The operating system we run for our customers, the operating system that's the host part of VMs, is the exact same binary and source code that we make available, just to be clear, the exact same binaries are the ones that you run as a customer on-premises. So if you run Oracle Linux with KVM, you run VMs, you're actually running the exact same stuff as we run underneath our customer's stuff. Nobody else does that, everyone else has a black box. So I think that helps a little bit with transparency as well. >> Yeah, and that homogeneity just creates an environment, you're talking about that sort of security mindset, it's critical, you're not just bolting it on, it's part of the culture. But you started your career, and then of course you were a Linux person when you came to Oracle, but then I think you spent some time in database, back in the day when there were serious database wars going on, before Oracle became the king of database. So now you've got, obviously, this great portfolio, and a lot of really sharp software developers; What should we expect going forward, from Oracle? What should we look for? >> You know, I was talking to some, I was welcoming some interns to the company, for their summer internship yesterday, and one of the things I mentioned to them was that -- so cloud obviously gives us a lot of opportunities, but there's a number of things. One is, we have such a breadth of applications and software and hardware together. We have the servers, we have the storage, we have the operating systems, we have the database layer and so forth, and we have the cloud side, and one of the great opportunities, and I think we've shown a lot of this happening with the ability to create something like Autonomous Database, is to combine all these things. Right, we have such a broad portfolio of really cool technology that by itself is okay, but if you combine the things it really becomes awesome. You cannot create autonomous database without having autonomous learning. You cannot create those two and make them really safe without also controlling the firmware on the hardware and so forth. So by being able to combine all these layers, and by having a really great relationship across the teams within the company, that opens up a lot of opportunities to do stuff really quickly. And having the scale for that. I think that has been, for the last few years, a really great thing, but I can see that being one of the advantages that we have going forward. We have Oracle Fusion Applications, which is incredibly popular, and has great girth, and then we have that running on Oracle Cloud, that talks to Oracle Autonomous Database, so we bring all these pieces together. And no other SaaS vendor can do that, because they don't have these other pieces. They have one area, we have all of them. And so that's the exciting part for me, it's not so much about making my own world better, and having Linux be better, and Casewise and so forth, which is important, but that becoming part of the bigger picture. And that's the exciting part. >> Well, Oracle's always invested in RND, we've made that point many, many times. Whether it's database, you know Fusion was a painful but worthy effort, the whole public cloud piece, obviously many acquisitions, but the investments that you've made in open-source as well, Wim, you're a great spokesperson, and a great representative of the open-source community generally, and then Oracle specifically, so thanks very much for coming on theCUBE and sharing with us the state of the penguin, and best of luck. >> You're welcome. Thank you, thanks for having me. >> Alright, and thank you for watching, everybody. This is Dave Vellante for theCUBE. We'll see you next time. (cheerful music).

>> From the SiliconANGLE media office in Boston, Massachusetts, it's theCUBE. Now, here's your host, Dave Vellante. >> Hello, everyone, and welcome to this week's episode of theCUBE Insights, powered by ETR. In this Breaking Analysis, I want to do a quasi post-mortem on AWS re:Invent, and put the company's prospects into context using some ETR spending data. First I want to try to summarize some of the high-level things that we heard at the event. I won't go into all the announcements in any kind of great detail, there's a lot that's been written out there on what was announced, but I will touch on a few of the items that I felt were noteworthy and try to give you some of the main themes. I then want to dig into some of the spending data and share with you what's happening from a buyer's perspective in the context of budgets, and we'll specifically focus on AWS's business lines. And then I'm going to bring my colleague Stu Miniman into the conversation, and we're going to talk about AWS's hybrid strategy in some detail, and then we're going to wrap. So, the first thing that I want to do is give you a brief snapshot of the re:Invent takeaways, and I'll try to give you some commentary that you might not have heard coming out of the show. So, to summarize re:Invent, AWS is not being on rinsing and repeating, they have this culture of raising the bar, but one thing that doesn't change is this shock and awe that they do of announcements, it comes out each year, and it's obvious. It's always a big theme, and this year Andy Jassy really wanted to underscore the company's feature and functional lead relative to some of the other cloud providers. Now the overarching theme that Jassy brought home in his keynote this year is that the cloud is enabling transformation. Not just teeny, incremental improvement, he's talking about transformation that has to start at the very top of the organization, so it's somewhat a challenge and an appeal to enterprises, generally versus what is often a message to startups at re:Invent. And he was specifically talking to the c-suite here. Jassy didn't say this, but let me paraphrase something that John Furrier said in his analysis on theCUBE. He said if you're not born in the cloud, you basically better find the religion and get reborn, or you're going to be out of business. Now, one of the other big trends that we saw this year at re:Invent, and it's starting to come into focus, is that AWS is increasingly leveraging its acquisition of Annapurna with these new chip sets that give it higher performance and better cost structures and utilization than it can with merchant silicon, and specifically Intel. And here's what I'll say about that. AWS is one of the largest, if not the largest customer of Intel's in the world. But here's the thing, Intel wants a level playing field. We've seen this over the years, where it's in Intel's best interest to have that level playing field as much as possible, in its customer base. You saw it in PCs, in servers, and now you're seeing it in cloud. The more balanced the customer base is, the better it is for Intel because no one customer can exert undue influence and control over Intel. Intel's a consummate arms dealer, and so from AWS's perspective it makes sense to add capabilities and innovate, and vertically integrate in a way that can drive proprietary advantage that they can't necessarily get from Intel, and drive down costs. So that's kind of what's happening here. The other big thing we saw is latency, what Pat Gelsinger calls the law of physics. Well a few years ago, AWS, they wouldn't even acknowledge on-prem workloads, and Stu and I are going to talk about that, but clearly sees hybrid as an opportunity now. I'm going to talk more on detail and drill into this with Stu, but a big theme of the event was moving Outposts closer to on-prem workloads, that aren't going to be moving into the cloud anytime soon. And then also the edge, as well as, for instance, Amazon's Wavelength announcement that puts Outposts into 5G networks at major carriers. Now another takeaway is that AWS is unequivocal about the right tool for the right job, and you see this really prominently in database, where I've counted at least 10 purpose-built databases in the portfolio. AWS took some really indirect shots at Oracle, maybe even direct shots at Oracle, which, Oracle treats Oracle Database as a hammer, and every opportunity as a nail, antithetical to AWS's philosophy. Now there were a ton of announcements around AI and specifically the SageMaker IDE, specifically Studio, SageMaker Studio, which stood out as a way to simplify machine intelligence. Now this approach addresses the skillset problem. What I mean by that is, the lack of data scientists to leverage AI. But one of the things that we're kind of watching here is, it's going to be interesting to see if it exacerbates the AI black box issue. Making the logic behind the machines' outcomes less transparent. Now, all of this builds up to what we've been calling next-gen cloud, and we're entering a new era that goes well beyond infrastructure as a service, and lift and shift workloads. And it really ties back to Jassy's theme of transformation, where analytics approaches new computing models, like serverless, which are fundamental now, as is security, and a topic that we've addressed in detail in prior Breaking Analysis segments. AWS even made an announcement around quantum computing as a service, they call it Braket. So those are some of the things that we were watching. All right, now let's pivot and look at some of the data. Here's a reminder of the macro financials for AWS, we get some decent data around AWS financials, and this chart, I've showed before, but it's AWS's absolute revenue and quarterly revenue year on year with the growth rates. It's very large and it's growing, that's the bottom line, but growth is slowing to 35% last quarter as you can see. But to iterate, or reiterate, we're looking at a roughly 36 billion dollar company, growing at 35% a year, and you don't see that often. And so, this market, it still has a long way to go. Now let's look at some of the ETR tactical data on spending. Now remember, spending attentions according to ETR are reverting to pre-2018 levels, and are beginning to show signs of moderation. This chart shows spending momentum based on what ETR calls net score, and that represents the net percentage of customers that are spending more on a particular platform. Now, here's what's really interesting about this chart. It show the net scores for AWS across a number of the company's markets, comparing the gray, which is October '18 survey, with the blue, July '19, and the yellow, October '19. And you can see that workspaces, machine learning and AI, cloud overall, analytic databases, they're all either up or holding the same levels as a year ago, so you see AWS is bucking the trend, and even though spending on containers appears to be a little less than last year, it's holding firm from the July survey, so my point is that AWS is really bucking that trend from the overall market, and is continuing to do very very well. Now this next slide takes the same segments, and looks at what ETR refers to as market share, which is a measure of pervasiveness in the survey. So as you can see, AWS is gaining in virtually all of its segments. So even though spending overall is softening, AWS in the marketplace, AWS is doing a much better job than its peers on balance. Now, the other thing I want to address is this notion of repatriation. I get this a lot, as I'm sure do other analysts. People say to me, "Dave, you should really look into this. "We hear from a lot of customers "that they moved to the cloud, "now they're moving workloads back on-prem "because the cloud is so expensive." Okay, so they say "You should look into this." So this next chart really does look into this. What the chart shows is across those same offerings from AWS, so the same services, the percent of customers that are replacing AWS, so I'm using this as a proxy for repatriation. Look at the numbers, they're low single digits. You see traditional enterprise vendors' overall business growing in the low single digits, or shrinking. AWS's defections are in the low single digits, so, okay, now look at this next chart. What about adoptions, if the cloud is slowing down, you'd expect a slowdown in new adoptions. What this data shows is the percent of customers that are responding, that they're adding AWS in these segments, so there's a new platform. So look, across the board, you're seeing increases of most of AWS's market segments. Notably, in respondents citing AWS overall at the very rightmost bars, you are admittedly seeing some moderation relative to last year. So that's a bit of a concern and clearly something to watch, but as I showed you earlier, AWS overall, that same category, is holding firm, because existing customers are spending more. All right, so that's the data portion of the conversation, hopefully we put that repatriation stuff to bed, and I now want to bring in Stu Miniman to the conversation, and we're going to talk more about multicloud, hybrid, on-prem, we'll talk about Outposts specifically, so Stu, welcome, thank you very much for coming on. >> Thanks Dave, glad to be here with you. >> All right, so let's talk about, let's start with multicloud, and dig into the role of Kubernetes a little bit, let me sort of comment on how I think AWS looks at multicloud. I think they look at multicloud as using multiple public clouds, and they look at on-prem as hybrid. Your thoughts on AWS's perspective on multicloud, and what's going on in the market. >> Yeah, and first of all, Dave, I'll step back for a second, you talked about how Amazon has for years had shots against Oracle. The one that Amazon actually was taking some shots at this year was Microsoft, so, not only did they talk about Oracle, they talked about customers looking to flee their SQL customers, and I lead into that because when you talk about hybrid cloud, Dave, if you talked to any analyst over the last three, four years and you say "Okay, what vendor is best position in hybrid, "which cloud provider has the "best solution for hybrid cloud?" Microsoft is the one that we'd say, because their strong domain in the enterprise, of course with Windows, the move to Office 365, the clear number two player in Azure, and they've had Azure Stack for a number of years, and they had Azure Pack before that, they'd had a number of offerings, they just announced this year Azure Arc, so three, we've had at least three generations of hybrid multicloud solutions from Microsoft, Amazon has a different positioning. As we've talked about for years, Dave, not only doesn't Amazon like to use the words hybrid or multicloud, for the most part, but they do have a different viewpoint. So the partnership with VMware expanded what they're doing on hybrid, and while Andy Jassy, he at least acknowledges that multicloud is a thing, when he sat down with John Furrier ahead of the show, he said "Well, there might be reasons why customers "either there's a group inside "that has a service that they want, "that they might want to do a secondary cloud, "or if I'm concerned that I might fall out of love "with this primary supplier I have, "I might need a second one." Andy said in not so, just exactly, said "Look, we understand multicloud is a thing." Now, architecturally, Amazon's positioning on this is that you should use Amazon, and they should be the center of what you're doing. You talked a lot about Outposts, Outposts, critical to what Amazon is doing in this environment. >> And we're going to talk about that, but you're right, Amazon doesn't like to talk about multicloud as a term, however, and by the way, they say that multicloud is more expensive, less secure, more complicated, more costly, and probably true, but you're right, they are acknowledging at least, and I would predict just as hybrid, which we want to talk about right now, they'll be talking about, they'll be participating in some way, shape, or form, but before we go to multicloud, or hybrid, what about Kubernetes? >> So, right, first of all, we've been at the KubeCon show for years, we've watching Kubernetes since the early days. Kubernetes is not a magic layer, it does not automatically say "Hey, I've got my application, I can move it willy-nilly." Data gravity's really important, how I architect my microservices solution absolutely is hugely important. When I talk to my friends in the app dev world, Dave, hybrid is the way they are building things a lot, if I took some big monolithic application, and I start pulling it apart, if I have that data warehouse or data store in my data center, I can't just migrate that to the cloud, David Floyer for years has been talking about the cost of migration, so microservice architecture's the way most customers are building, a hybrid environment often is there. Multicloud, we're not doing cloud bursting, we're not just saying "Oh hey, I woke up today, "and cloud A is cheaper than cloud B, "let me move my workload." Absolutely, I had a great conversation with a good Amazon customer that said two years ago, when they deployed Kubernetes, they did it on Azure. You want to know why, the Azure solution was more mature and they were doing Azure, they were doing things there, but as Amazon fully embraced Kubernetes, not just sitting on top of their solution, but launched the service, which is EKS, they looked at it, and they took an application, and they migrated it from Azure to Amazon. Now, migrating it, there's the underlying services and everybody does things a little bit different. If you look at some of the tooling out there, great one to look at is HashiCorp has some great tooling that can span across multiple clouds, but if you look at how they deploy, to Azure, to Google, to AWS, it's different, so you got to have different code, there's different skillsets, it's not a utility and just generic compute and storage and networking underneath, you need to have specific skills there, so Kubernetes, absolutely when I've been talking to users for the last few years and saying "Why are you using Kubernetes?" The answer is "I need that eject lever, "so that if I want to leave AWS with an application, "I can do that, and it's not press a button and it's easy, "that easy, but I know that I can move that, "'cause underneath the pods, and the containers, "and all those pieces, the core building blocks "are the same, I will have to do some reconfiguration," as we know with the migration, usually I can get 80 to 90 percent of the way there, and then I need to make the last minute-- >> So it's a viable hedge on your AWS strategy, okay. >> Absolutely, and I've talked to lots of customers, Amazon shows that most cloud Kubernetes solutions out there are running on Amazon, and when I go talk to customers, absolutely, a lot of the customers that are doing Kubernetes in the public cloud are doing that on Amazon, and one of the main reasons they're using it is in case they do want to, as a hedge against being all-in on Amazon. >> All right, let's talk about Outposts, specifically as part of Amazon's hybrid strategy, and now their edge strategy as well. >> Right, so Azure Stack, I mentioned earlier from Microsoft has been out there for a few years. It has not been doing phenomenally well, when I was at Microsoft Ignite this year, I heard basically certain government agencies and service providers are using it and basically acting, delivering Azure as a service, but, Azure Stack is basically an availability zone in my data center, and Amazon looked at this and says "That's not how we're going to build this." Outposts is an extension of your local region, so, while people look at the box and they say, I took a picture of the box and Shu was like, "Hey, whose server and what networking card, "and the chipset and everything," I said "Hold on a second. "You might look at that box, "and you might be able to open the door, "but Amazon is going to deploy that, "they're going to manage that, "really you should put a curtain in front of it "and say pay no attention to what's behind here, "because this is Amazon gear, it's an Amazon "as a service in your data center, "and there are only a few handful of services "that are going to be there at first." If I want to even use S3, day one, the Amazon native services, you're going to just use S3 in your local region. Well, what if I need special latency? Well, Amazon's going to look at that, and see what's available, so, it is Amazon hardware, the Amazon software, the Amazon control plane, reaching into that data center, and very scalable, it's, Amazon says over time it should be able to go to thousands of racks if you need, so absolutely that cloud experience closer to my environment, but where I need certain applications, certain latency, certain pieces of data that I need to store there. >> And we've seen Amazon dip its toe into the hybrid on-prem market with Snowball and Greengrass and stuff like that before, but this is a much bigger commitment, one might even say capitulation, to hybrid. >> Well, right, and the reason why I even say, this is hybrid, but it's all Amazon, it is not "Take my private cloud and my public cloud "and tie 'em together," it's not, "I've taken cloud to customer" or IBM solution, where they're saying "I'm going to put a rack here "and a rack there, and it's all going to work the same." It is the same hardware and software, but it is not all of the pieces-- >> VMware and Outposts is hybrid. >> Really interesting, Dave, as the native AWS solution is announced first here in 2019, and the VMware solution on Outposts isn't going to be available until 2020. Draw what you will, it's been a strong partnership, there are exabytes of data in the VMware cloud on AWS now, but yeah, it's a little bit of a-- >> Quid pro quo, I think is what you call that. >> Well I'd say Amazon is definitely, "We're going to encroach a little bit on your business, "and we're going to woke you into our environment, too." >> Okay, let's talk about the edge, and Outposts at the edge, they announced Wavelength, which is essentially taking Outposts and putting it into 5G networks at carriers. >> Yeah, so Outposts is this building block, and what Amazon did is they said, "This is pretty cool, "we actually have our environment "and we can do other things with it." So sometimes they're just taking, pretty much that same block, and using it for another service, so one that you didn't mention was AWS Local Zones. So it is not a whole new availability zone, but it is basically extending the cloud, multi-tenant, the first one is done for the TME market in Los Angeles, and you expect, how does Amazon get lower latency and get closer, and get specialized services, local zones are how they're going to do this. The Wavelength solution is something they built specifically for the telco environment. I actually got to sit down with Verizon, this was at least an 18 month integration, anybody that's worked in the telco space knows that it's usually not standard gear, there's NEBB certification, there's all these things, it's often even DC power, so, it is leveraging Outposts, but it is not them rolling the same thing into Verizon that they did in their environments. Similar how they're going to manage it, but as you said, it's going to push to the telco edge and in a partnership with Verizon, Vodafone, SK, Telecom, and some others that will be rolling out across the globe, they are going to have that 5G offering and this little bit, I actually buy it from Amazon, but you still buy the 5G from your local carrier. It's going to roll out in Chicago first, and enabling all of those edge applications. >> Well what I like about the Amazon strategy at the edge is, and I've said this before, on a number of occasions on theCUBE Breaking Analysis, they're taking programmable infrastructure to the edge, the edge will be won by developers in my view, and Amazon obviously has got great developer traction, I don't see that same developer traction at HPE, even Dell EMC proper, even within VMware, and now they've got Pivotal, they've got an opportunity there, but they've really got a long way to go in terms of appealing to developers, whereas Amazon I think is there, obviously, today. >> Yeah, absolutely true, Dave. When we first started going to the show seven years ago, it was very much the hoodie crowd, and all of those cloud-native, now, as you said, it's those companies that are trying to become born again in the cloud, and do these environments, because I had a great conversation with Andy Jassy on air, Dave, and I said "Do we just shrink wrap solutions "and make it easy for the enterprise to deploy, "or are we doing the enterprise a disservice?" Because if you are truly going to thrive and survive in the cloud-native era, you've got to go through a little bit of pain, you need to have more developers. I've seen lots of stats about how fast people are hiring developers and I need to, it's really a reversal of that old outsourcing trend, I really need IT and the business working together, being agile, and being able to respond and leverage data. >> It's that hyperscaler mentality that Jassy has, "We got engineers, we'll spend time "on creating a better mousetrap, on lowering costs," whereas the enterprise, they don't have necessarily as many resources or as many engineers running around, they'll spend money to save time, so your point about solutions I think is right on. We'll see, I mean look, never say never with Amazon. We've seen it, certainly with on-prem, hybrid, whatever you want to call it, and I think you'll see the same with multicloud, and so we watch. >> Yeah, Dave, the analogy I gave in the final wrap is "Finding the right cloud is like Goldilocks "finding the perfect solution." There's one solution out there, I think it's a little too hot, and you're probably not smart enough to use it just yet. There's one solution that, yeah, absolutely, you can use all of your credits to leverage it, and will meet you where you are and it's great, and then you've got Amazon trying to fit everything in between, and they feel that they are just right no matter where you are on that spectrum, and that's why you get 36 billion growing at 35%, not something I've seen in the software space. >> All right, Stu, thank you for your thoughts on re:Invent, and thank you for watching this episode of theCUBE Insights, powered by ETR, this is Dave Vellante for Stu Miniman, we'll see you next time. (techno music)

>> Live from New York. It's theCUBE. Covering theCUBE New York City, 2018. Brought to you by SiliconANGLE Media, and it's ecosystem partners. >> I'm John Furrier with Peter Burris, our next two guests are Jim Franklin with Dell EMC Director of Product Management Anant Chintamaneni, who is the Vice President of Products at BlueData. Welcome to theCUBE, good to see you. >> Thanks, John. >> Thank you. >> Thanks for coming on. >> I've been following BlueData since the founding. Great company, and the founders are great. Great teams, so thanks for coming on and sharing what's going on, I appreciate it. >> It's a pleasure, thanks for the opportunity. >> So Jim, talk about the Dell relationship with BlueData. What are you guys doing? You have the Dell-ready solutions. How is that related now, because you've seen this industry with us over the years morph. It's really now about, the set-up days are over, it's about proof points. >> That's right. >> AI and machine learning are driving the signal, which is saying, 'We need results'. There's action on the developer's side, there's action on the deployment, people want ROI, that's the main focus. >> That's right. That's right, and we've seen this journey happen from the new batch processing days, and we're seeing that customer base mature and come along, so the reason why we partnered with BlueData is, you have to have those softwares, you have to have the contenders. They have to have the algorithms, and things like that, in order to make this real. So it's been a great partnership with BlueData, it's dated back actually a little farther back than some may realize, all the way to 2015, believe it or not, when we used to incorporate BlueData with Isilon. So it's been actually a pretty positive partnership. >> Now we've talked with you guys in the past, you guys were on the cutting edge, this was back when Docker containers were fashionable, but now containers have become so proliferated out there, it's not just Docker, containerization has been the wave. Now, Kubernetes on top of it is really bringing in the orchestration. This is really making the storage and the network so much more valuable with workloads, whether respective workloads, and AI is a part of that. How do you guys navigate those waters now? What's the BlueData update, how are you guys taking advantage of that big wave? >> I think, great observation, re-embrace Docker containers, even before actually Docker was even formed as a company by that time, and Kubernetes was just getting launched, so we saw the value of Docker containers very early on, in terms of being able to obviously provide the agility, elasticity, but also, from a packaging of applications perspective, as we all know it's a very dynamic environment, and today, I think we are very happy to know that, with Kubernetes being a household name now, especially a tech company, so the way we're navigating this is, we have a turnkey product, which has containerization, and then now we are taking our value proposition of big data and AI and lifecycle management and bringing it to Kubernetes with an open source project that we launched called Cube Director under our umbrella. So, we're all about bringing stateful applications like Hadoop, AI, ML to the community and to our customer base, which is some of the largest financial services in health care customers. >> So the container revolution has certainly groped developers, and developers have always had a history of chasing after the next cool technology, and for good reason, it's not like just chasing after... Developers tend not to just chase after the shiny thing, they chased after the most productive thing, and they start using it, and they start learning about it, and they make themselves valuable, and they build more valuable applications as a result. But there's this interesting meshing of creators, makers, in the software world, between the development community and the data science community. How are data scientists, who you must be spending a fair amount of time with, starting to adopt containers, what are they looking at? Are they even aware of this, as you try to help these communities come together? >> We absolutely talk to the data scientists and they're the drivers of determining what applications they want to consume for the different news cases. But, at the end of the day, the person who has to deliver these applications, you know data scientists care about time to value, getting the environment quickly all prepared so they can access the right data sets. So, in many ways, most of our customers, many of them are unaware that there's actually containers under the hood. >> So this is the data scientists. >> The data scientists, but the actual administrators and the system administrators were making these tools available, are using containers as a way to accelerate the way they package the software, which has a whole bunch of dependent libraries, and there's a lot of complexity our there. So they're simplifying all that and providing the environment as quickly as possible. >> And in so doing, making sure that whatever workloads are put together, can scaled, can be combined differently and recombined differently, based on requirements of the data scientists. So the data scientist sees the tool... >> Yeah. >> The tool is manifest as, in concert with some of these new container related technologies, and then the whole CICD process supports the data scientist >> The other thing to think about though, is that this also allows freedom of choice, and we were discussing off camera before, these developers want to pick out what they want to pick out what they want to work with, they don't want to have to be locked in. So with containers, you can also speed that deployment but give them freedom to choose the tools that make them best productive. That'll make them much happier, and probably much more efficient. >> So there's a separation under the data science tools, and the developer tools, but they end up all supporting the same basic objective. So how does the infrastructure play in this, because the challenge of big data for the last five years as John and I both know, is that a lot of people conflated. The outcome of data science, the outcome of big data, with the process of standing up clusters, and lining up Hadoop, and if they failed on the infrastructure, they said it was a failure overall. So how you making the infrastructure really simple, and line up with this time of value? >> Well, the reality is, we all need food and water. IT still needs server and storage in order to work. But at the end of the day, the abstraction has to be there just like VMware in the early days, clouds, containers with BlueData is just another way to create a layer of abstraction. But this one is in the context of what the data scientist is trying to get done, and that's the key to why we partnered with BlueData and why we delivered big data as a service. >> So at that point, what's the update from Dell EMC and Dell, in particular, Analytics? Obviously you guys work with a lot of customers, have challenges, how are you solving those problems? What are those problems? Because we know there's some AI rumors, big Dell event coming up, there's rumors of a lot of AI involved, I'm speculating there's going to be probably a new kind of hardware device and software. What's the state of the analytics today? >> I think a lot of the customers we talked about, they were born in that batch processing, that Hadoop space we just talked about. I think they largely got that right, they've largely got that figured out, but now we're seeing proliferation of AI tools, proliferation of sandbox environments, and you're psyched to see a little bit of silo behavior happening, so what we're trying to do is that IT shop is trying to dispatch those environments, dispatch with some speed, with some agility. They want to have it at the right economic model as well, so we're trying to strike a better balance, say 'Hey, I've invested in all this infrastructure already, I need to modernize it, and that I also need to offer it up in a way that data scientists can consume it'. Oh, by the way, we're starting to see them start to hire more and more of these data scientists. Well, you don't want your data scientists, this very expensive, intelligent resource, sitting there doing data mining, data cleansing, detail offloads, we want them actually doing modeling and analytics. So we find that a lot of times right now as you're doing an operational change, the operational mindset as you're starting to hire these very expensive people to do this very good work, at the corest of the data, but they need to get productive in the way that you hired them to be productive. >> So what is this ready solution, can you just explain what that is? Is it a program, is it a hardware, is it a solution? What is the ready solution? >> Generally speaking, what we do as a division is we look for value workloads, just generally speaking, not necessarily in batch processing, or AI, or applications, and we try and create an environment that solves that customer challenge, typically they're very complex, SAP, Oracle Database, it's AI, my goodness. Very difficult. >> Variety of tools, using hives, no sequel, all this stuff's going on. >> Cassandra, you've got Tensorflow, so we try fit together a set of knowledge experts, that's the key, the intellectual property of our engineers, and their deep knowledge expertise in a certain area. So for AI, we have a sight of them back at the shop, they're in the lab, and this is what they do, and they're serving up these models, they're putting data through its paces, they're doing the work of a data scientist. They are data scientists. >> And so this is where BlueData comes in. You guys are part of this abstraction layer in the ready solutions. Offering? Is that how it works? >> Yeah, we are the software that enables the self-service experience, the multitenancy, that the consumers of the ready solution would want in terms of being able to onboard multiple different groups of users, lines of business, so you could have a user that wants to run basic spark, cluster, spark jobs, or you could have another user group that's using Tensorflow, or accelerated by a special type of CPU or GPU, and so you can have them all on the same infrastructure. >> One of the things Peter and I were talking about, Dave Vellante, who was here, he's at another event right now getting some content but, one of the things we observed was, we saw this awhile ago so it's not new to us but certainly we're seeing the impact at this event. Hadoop World, there's now called Strata Data NYC, is that we hear words like Kubernetes, and Multi Cloud, and Istio for the first time. At this event. This is the impact of the Cloud. The Cloud has essentially leveled the Hadoop World, certainly there's some Hadoop activity going on there, people have clusters, there's standing up infrastructure for analytical infrastructures that do analytics, obviously AI drives that, but now you have the Cloud being a power base. Changing that analytics infrastructure. How has it impacted you guys? BlueData, how are you guys impacted by the Cloud? Tailwind for you guys? Helpful? Good? >> You described it well, it is a tailwind. This space is about the data, not where the data lives necessarily, but the robustness of the data. So whether that's in the Cloud, whether that's on Premise, whether that's on Premise in your own private Cloud, I think anywhere where there's data that can be gathered, modeled, and new insights being pulled out of, this is wonderful, so as we ditched data, whether it's born in the Cloud or born on Premise, this is actually an accelerant to the solutions that we built together. >> As BlueData, we're all in on the Cloud, we support all the three major Cloud providers that was the big announcement that we made this week, we're generally available for AWS, GCP, and Azure, and, in particular, we start with customers who weren't born in the Cloud, so we're talking about some of the large financial services >> We had Barclays UK here who we nominated, they won the Cloud Era Data Impact Award, and what they're actually going through right now, is they started on Prem, they have these really packaged certified technology stacks, whether they are Cloud Era Hadoop, whether they are Anaconda for data science, and what they're trying to do right now is, they're obviously getting value from that on Premise with BlueData, and now they want to leverage the Cloud. They want to be able to extend into the Cloud. So, we as a company have made our product a hybrid Cloud-ready platform, so it can span on Prem as well as multiple Clouds, and you have the ability to move the workloads from one to the other, depending on data gravity, SLA considerations. >> Compliancy. >> I think it's one more thing, I want to test this with you guys, John, and that is, analytics is, I don't want to call it inert, or passive, but analytics has always been about getting the right data to human beings so they can make decisions, and now we're seeing, because of AI, the distinction that we draw between analytics and AI is, AI is about taking action on the data, it's about having a consequential action, as a result of the data, so in many respects, NCL, Kubernetes, a lot of these are not only do some interesting things for the infrastructure associated with big data, but they also facilitate the incorporation of new causes of applications, that act on behalf of the brand. >> Here's the other thing I'll add to it, there's a time element here. It used to be we were passive, and it was in the past, and you're trying to project forward, that's no longer the case. You can do it right now. Exactly. >> In many respects, the history of the computing industry can be drawn in this way, you focused on the past, and then with spreadsheets in the 80s and personal computing, you focused on getting everybody to agree on the future, and now, it's about getting action to happen right now. >> At the moment it happens. >> And that's why there's so much action. We're passed the set-up phase, and I think this is why we're hearing, seeing machine learning being so popular because it's like, people want to take action there's a demand, that's a signal that it's time to show where the ROI is and get action done. Clearly we see that. >> We're capitalists, right? We're all trying to figure out how to make money in these spaces. >> Certainly there's a lot of movement, and Cloud has proven that spinning up an instance concept has been a great thing, and certainly analytics. It's okay to have these workloads, but how do you tie it together? So, I want to ask you, because you guys have been involved in containers, Cloud has certainly been a tailwind, we agree with you 100 percent on that. What is the relevance of Kubernetes and Istio? You're starting to see these new trends. Kubernetes, Istio, Cupflow. Higher level microservices with all kinds of stateful and stateless dynamics. I call it API 2.0, it's a whole other generation of abstractions that are going on, that are creating some goodness for people. What is the impact, in your opinion, of Kubernetes and this new revolution? >> I think the impact of Kubernetes is, I just gave a talk here yesterday, called Hadoop-la About Kubernetes. We were thinking very deeply about this. We're thinking deeply about this. So I think Kubernetes, if you look at the genesis, it's all about stateless applications, and I think as new applications are being written folks are thinking about writing them in a manner that are decomposed, stateless, microservices, things like Cupflow. When you write it like that, Kubernetes fits in very well, and you get all the benefits of auto-scaling, and so control a pattern, and ultimately Kubernetes is this finite state machine-type model where you describe what the state should be, and it will work and crank towards making it towards that state. I think it's a little bit harder for stateful applications, and I think that's where we believe that the Kubernetes community has to do a lot more work, and folks like BlueData are going to contribute to that work which is, how do you bring stateful applications like Hadoop where there's a lot of interdependent services, they're not necessarily microservices, they're actually almost close to monolithic applications. So I think new applications, new AI ML tooling that's going to come out, they're going to be very conscious of how they're running in a Cloud world today that folks weren't aware of seven or eight years ago, so it's really going to make a huge difference. And I think things like Istio are going to make a huge difference because you can start in the cloud and maybe now expand on to Prem. So there's going to be some interesting dynamics. >> Without hopping management frameworks, absolutely. >> And this is really critical, you just nailed it. Stateful is where ML will shine, if you can then cross the chasma to the on Premise where the workloads can have state sharing. >> Right. >> Scales beautifully. It's a whole other level. >> Right. You're going to the data into the action, or the activity, you're going to have to move the processing to the data, and you want to have nonetheless, a common, seamless management development framework so that you have the choices about where you do those things. >> Absolutely. >> Great stuff. We can do a whole Cube segment just on that. We love talking about these new dynamics going on. We'll see you in CF CupCon coming up in Seattle. Great to have you guys on. Thanks, and congratulations on the relationship between BlueData and Dell EMC and Ready Solutions. This is Cube, with the Ready Solutions here. New York City, talking about big data and the impact, the future of AI, all things stateful, stateless, Cloud and all. It's theCUBE bringing you all the action. Stay with us for more after this short break.