 Welcome back to SuperCloud 2, where we're gathering a number of industry luminaries to discuss the future of cloud services and we'll be focusing on various real world practitioners today, their challenges, their opportunities with an emphasis on data, self-service infrastructure and how organizations are evolving their data and cloud strategies to prepare for that next era of digital innovation. And you know, we really believe that support for multiple cloud estates is a first step of any SuperCloud. And in that regard, Oracle surprised some folks with its Azure collaboration, the Oracle Database and Exadata-based services. And to discuss the challenges of developing a mission-critical SuperCloud, we welcome Juan Loiza, who's the executive vice president of Mission Critical Database Technologies at Oracle. Juan, you're a many-time CUBE alum, so welcome back to the show, great to see you. Great to see you and happy to be here with you. Thank you. A lot of people felt that Oracle was resistant to multi-cloud strategies and preferred to really have everything run just on the Oracle cloud infrastructure, OCI. And maybe that was a misperception, maybe you guys were misunderstood or maybe you had to change your heart. Take us through the decision to support multiple cloud platforms. No, we've supported multiple cloud platforms for many years, so I think that was probably a misperception, you know, Oracle Database. We partnered up with Amazon very early on in their cloud when they had kind of the first cloud out there. And, you know, we had Oracle Database running on their cloud, we had backup, we had a lot of stuff running. So yeah, part of the philosophy of Oracle has always been we partner with every platform, we're very open, you know, we started with SQL and APIs as we develop new technologies, we push them into the SQL standard. So that's always been part of the ecosystem at Oracle. That's how we think we get an advantage by being more open. I think if we try to create this isolated little world, you know, it actually hurts us and hurts customers. So for us, it's a win-win to be open across the clouds. So SuperCloud is this concept that we put forth to describe a platform, or some people think it's an architecture, if you have an opinion and I'd love to hear it, but it provides a programmatically consistent set of services that hosted on heterogeneous cloud providers. And so we look at the Oracle Database service where Azure is fitting within this definition. In your view, is this accurate? Yeah, I would broaden it. I see a little bit more than that. We just think that, you know, services should be available from everywhere, right? So, I mean, it's a little bit like, if you go back to the pre-internet world, there was, you know, things like AOL and CompuServe and those were kind of islands. And if you were on AOL, you really didn't have access to anything on CompuServe and vice versa. And the cloud world has evolved a little bit like that. And we just think that's the wrong model. They shouldn't, you know, these clouds are part of the world and they need to be interconnected like all the rest of the world. It's been a long time, you know, with telephones, internet, everything's interconnected. Everything should work seamlessly together. So that's how we believe, you know, if you're running in one cloud and you're running, you know, whatever, let's say an application, one cloud, you wanna use a service from another cloud should be completely simple to do that. It shouldn't be, I can only use what's in AOL or CompuServe or whatever else that should not be isolated. Well, we got a long way to go before that Nirvana exists, but one example is the Oracle Database Service with Azure. So what exactly does that service provide? I'm interested in how consistent the service experience is across clouds. You know, did you create a purpose-built PAS layer to achieve this common experience or is it off-the-shelf Terraform? Is there unique value in the PAS layer? Let's dig into some of those questions. I know I just threw six at you. Yeah, I mean, so what this is is, you know, what we're trying to do is very simple, which is, for example, starting with the Oracle Database, we wanna make that seamless to use from anywhere you're running, whether it's on-prem, on some other cloud, you know, anywhere else, you should be able to seamlessly use the Oracle Database. And it should look like, you know, kind of like the internet, there's no friction. There's not a lot of hoops you gotta jump just because you're trying to use a database that isn't local to you. So it's pretty straightforward. And in terms of things like Azure, you know, it's not easy to do because all these clouds have a lot of kind of very unique technologies. So what we've done is at Oracle is we've said, okay, we're gonna make Oracle Database look exactly like if it was running on Azure. That means we'll use the Azure security systems, identity management systems, the networking. There's things like monitoring and management. So we'll push all these technologies. For example, when we have monitoring event or we have alerts, we'll push those into the Azure console. So as a user, it looks to you exactly as if that Oracle Database was running inside Azure. Also, the networking is a big challenge across these clouds. So, you know, we've basically made that whole thing seamless. So we create the super high bandwidth network between Azure and Oracle. We make sure that's extremely low latency, you know, under two milliseconds around trip. It's all within the local metro region. So it's very fast, very high bandwidth, very low latency. And we take care, you know, establishing the links and making sure that it's secure, you know, all that kind of stuff. So at a high level, it looks to you like the Oracle Database is running. Even the look and feel of the screens, it's the Azure colors, it's the Azure buttons, it's the Azure layout of the screens. So it looks like you're running there. And we take care of all the technical details underlying that, which there's a lot. We've just taken, you know, a lot of work to make it work seamlessly. In the magic of that abstraction, Juan, does it happen at the past layer? Could you take us inside that a little bit? Is there intelligence in there that helps you deal with latency? Or are there any kind of purpose-built functions for this service? Yeah, you could think of it as, I mean, it happens at a lot of different layers. It happens at the identity management layer. It happens at the networking layer. It happens at the database layer. It happens at the monitoring layer, at the management layer. So all those things have been integrated. So it's not one thing that you just go and do. You have to integrate all these different services together. You can access files in Azure from the Oracle Database. Again, that's completely seamless. It's just like if it was local to our cloud, you get your Azure files in your kind of S3 equivalent. So yeah, it's not one thing. There's a whole lot of pieces to the ecosystem. And what we've done is we've worked on each piece separately to make sure that it's completely seamless and transparent. So you don't have to think about it. It just works. So you kind of answered my next question, which is what are the technical hurdles? It sounds like the technical hurdles are that integration across the entire stack. That's the sort of architecture that you've built. What was the catalyst for this service? Yeah, the catalyst is just fulfilling our vision of an open world, an open cloud world. It's really, like I said, Oracle from the very beginning has been believed in open standards. Customers should be able to have choice. Customers should be able to use whatever they want from wherever they want. And we saw that in the new world of cloud, that had broken down. Everybody had their own authentication system, management system, monitoring system, networking system, configuration system. And it became very difficult. There was a lot of friction to using services across cloud. So we said, well, okay, we can fix that. It's work, it's significant amount of work, but we know how to do it. And let's just go do it and make it easy for customers. So given as Oracle is really your main focuses on mission critical workloads, you talked about this low latency network, but you still have physical distances. So how are you managing that latency? What's the experience been for customers across Azure and OCI? Yeah, so it's a good point. I mean, latency can be an issue. So the good thing about clouds is we have a lot of cloud data centers. We have dozens and dozens of cloud data centers around the world. And Azure has dozens and dozens of cloud data centers. And in most cases, they're in the same metro region because there's kind of natural metro regions within each country that, you want to put your cloud data centers in. So most of our data centers are actually very close to the Azure data centers. There's kind of Northern Virginia, there's London, there's Tokyo, I mean, there's natural places where everybody puts their data centers, Seoul, et cetera. And so that's the real key. So that allows us to put a very high bandwidth and low latency network. The real problems with latency come when you're trying to go a long physical distance. If you're trying to connect across the Pacific or across the country or something like that, then you can get in trouble with latency. Within the same metro region, it's extremely fast. It tends to be around one, the highest two milliseconds. That's round trip through all the routers and connections and gateways and everything else with everything taken into consideration. Well, we guarantees it's always less than two millisecond which is a very low latency time. So that tends to not be a problem because it's extremely low latency. I was going to ask you less than two milliseconds. So earlier in the program, we had Jack Greenfield who runs architecture for Walmart. And he was explaining what we call their super cloud and it runs across Azure, GCP and they're on-prem. They have this thing called the triplet model. So my question to you is, are you in situations where you guaranteeing that less than two milliseconds, do you have situations where you're bringing Exadata Cloud and customer on-prem to achieve that or is this just across clouds? Yeah, in this case, we're talking public cloud data center to public cloud data center. Oh, okay. So add your public cloud data center to Oracle public cloud data center. They're in the same metro region. We set up the connections. We do all the technology to make it seamless. And from a customer point of view, they don't really see the network. Also remember that SQL is actually designed to have very low bandwidth and latency requirements. So it is a language. So you don't go to the database and say, do this one level thing for me. You send it a SQL statement that can actually access lots of data while in the database. So the real latency requirement of a SQL database is within the database. So I need to access all that data fast. So I need very fast access to storage, very fast access across nodes. That's what Exadata gives you. But you send one request and that request can do a huge amount of work and then return one answer. And that's kind of the design point of SQL. So SQL is inherently low bandwidth requirements. It was used back in the 80s when we used to have 10 megabit networks. And the biggest companies in the world ran back then. So right now we're talking over hundreds of gigabits. So it's really not much of a challenge when you're designed to run a 10 megabit to say, okay, I'm going to give you 10,000 times what you were designed for. It's a pretty low hurdle jump. What about the deployment models? How do you handle it? Is it a single global instance across clouds? Or do you sort of instantiate? And each of you got Exadata's in Azure and Exadata's in OCI. What's the deployment model look like? It's pretty straightforward. So customer decides where they want to run their application and database. So there's natural places where people go. If you're in Tokyo, you're going to choose the local Tokyo data centers for both Microsoft and Oracle. If you're in London, you're going to do that. If you're in California, you're going to choose maybe San Jose, something like that. So a customer just chooses, we both have data centers in that metro region. So they create their service on Azure. And then they go to our console, which looks just like an Azure console and say, all right, create me a database. And then we choose the closest Oracle data center, which is generally a few miles away. And then it all gets created. So from a customer point of view, it's very straightforward. I'm always in awe about how simple you make things sound. All right, what about security? You talked a little bit before about identity access, how you're sort of abstracting the Azure capabilities away so that you've simplified it for your customers. But are there any other specific security things that you need to do? How much did you have to abstract the underlying primitives of Azure or OCI to present that common experience to customers? Yeah, so there's really two big things. One is the identity management. Like my name is X on Azure and I have this set of privileges. Oracle has its own identity management system, right? So what we didn't want is that you have to kind of like bridge these things yourself. It's a giant pain to do that. So we actually, what we call federate across these identity manage. So you put your credentials into Azure and then they automatically get to use the exact same credentials and identity in the Oracle Cloud. So again, you don't have to think about it, it just works. And then the second part is that the whole bridging the network, so within a cloud, you generally have virtual network that's private to your company. And so at Oracle, we bridge the private network that you created in, for example, Azure to the private network that we create for you in Oracle. So it is still a private network without you having to do a whole bunch of work. So it's just like if you were in your own data center, other people can't get into your network. So it's secured at the network level. It's secured at the identity management and encryption level. And again, we did a lot of work to make that seamless for customers. And they don't have to worry about it because we did the work. That's really as simple as it gets. That's what SuperCloud is supposed to be all about. All right, we were talking earlier about sort of the misperception around multicloud. You know, your view of open, I think, which is you run the Oracle database, wherever the customer wants to run it. So you got this database service across OCI and Azure. Customers today, they run Oracle database in AWS. You got HeatWave, MySQL HeatWave that you announced on AWS. Google, it's a bare metal offering where you can run Oracle on GCP. Do you see a day when you extend an OCI Azure-like, you know, situation across multiple clouds? Would that bring benefits to customers? Or will the world of database generally remain largely fenced with maybe a few exceptions like what you're doing with OCI and Azure? I'm particularly interested in your thoughts on egress fees as maybe one of the reasons that is a barrier to this happening and why maybe these stovepipes, you know, exist today and in the future. What are your thoughts on that? Yeah, we're very open to working with, you know, everyone else out there. You know, I guess that we've always been, you know, big believers in customers should have choice and you should be able to run wherever you want. So it's been kind of a founding principle of Oracle. You know, we have the Azure, we did, you know, a partnership with them. We're open to doing other partnerships and you're gonna see other things coming down the pipe. On the topic of egress, yeah, you know, large egress fees, it's pretty obvious what goes on with that. You know, various vendors like to have large egress fees because they wanna keep things, you know, kind of locked into their cloud. So, you know, it's not a very customer friendly thing to do. And, you know, I think everybody recognizes that. It's really trying to, you know, kind of course or put a lot of friction on moving data out of the, out of a particular cloud. And, you know, that's not what we do. We have very, very, very low egress fees. So we don't really do that and we don't think anybody else should do that. But I think, you know, customers at the end of the day will win that battle. They're gonna have to go back to their vendor and say, well, you know, I have choice in clouds and if you're gonna impose these limits on me, you know, maybe I'll make a different choice. So that's ultimately how these things get resolved. So do you think other cloud providers are gonna take a page out of what you're doing with Azure and provide similar solutions? Yeah, well, I think customers, I mean, I've talked to a lot of customers, this is what they want, right? I mean, there's really no doubt. No customer wants to be locked into a single ecosystem. There's nobody out there that wants that. So, and as the competition, when they start seeing an open ecosystem evolving, they're gonna be like, okay, I'd rather go there than the closed ecosystem. And that's going to put pressure on the closed ecosystems, right? So that's the nature of competition, right? That's what ultimately will tip the balance on these things. So, Juan, even though you have this capability of distributing a workload across multiple clouds as in our super cloud premise, it's still something that's relatively new. It's a big decision that maybe many people might consider somewhat of a risk. So I'm curious, who's driving the decisions for your initial customers? What do they want to get out of it? What's the decision point there? Yeah, I mean, this is generally driven by customers that want a specific technology in a cloud. I think the risk, I haven't seen a lot of people worry too much about the risk. Everybody involved in this is a very well-known, very reputable firm. I mean, Oracle has been around for 40 years. We run most of the world's largest companies. I think customers understand we're not gonna build a solution that's gonna put their technology and their business at risk. And the same thing with Azure and others. So I don't see customers too worried about, this is a risky move, because it's really not, and everybody understands networking. The networking works. I mean, how does the internet work? It's a known quantity. It's not like it's some brand new invention. What we're really doing is breaking down the barriers to interconnecting things, automating and making them easy. So there's not a whole lot of risk here for customers. And like I said, every single customer in the world, loves an open ecosystem. There's, it's just not a question. If you go to a customer, would you rather have a closed, put your technology or your business to run on a closed ecosystem or an open system? It's kind of not even worth asking a question. It's a no-brainer. All right, so we got to go to my last question. What do you think of the term super cloud? Do you think it'll stick? We'll see. There's a lot of terms out there. And it's always fun to see which terms take. It's a cool term. I like it. But the decision makers are actually the public. What sticks and what doesn't. It's very hard to predict. It's been a lot of fun having you on. Juan, really appreciate your time and it's always good to see you. All right, Dave. Thanks a lot. It's always fun to talk to you. You bet. All right, keep it right there. More super cloud two content from the Cube community. Dave Vellante for John Furrier. We'll be right back.