 Hello everyone and welcome to this CUBE conversation. We're going to dig into some of the more specific and sometimes gory details of managing the nuances of database, database management systems. You know, it's a lot of fun to get into the daily buzz of cloud and database competition, get a little snarky on Twitter, but there's a lot of mundane issues that you have to address to really do proper database sizing, capacity planning, and you know, whether or not database consolidation makes sense, these are not trivial issues. And decades ago, they spawned an entire role around the database administrator. They had to do the dirty work of database management so that users and customers would be satisfied. And while automation and cloud are changing that role, at the end of the day, somebody actually has to make the databases work in the cloud and make sure that the business doesn't feel any impact on the transition along the way. So on that note, we have with us Oracle Senior Director of Product Management for Mission Critical Databases. He works in Juan Loiz's group, Chris Kraft. And Steve Zavatic, whom we know well on theCUBE, says this guy is the Jedi master when it comes to consolidating databases in the cloud. Nobody knows more on the face of the planet Earth. So we're really excited, Chris, to have you inside theCUBE. Welcome. Thanks. Thanks, Dave. That's a very humble thanks. So when it comes to running databases in the cloud, can you explain the difference between sizing and capacity planning? Aren't they two sides of the same coin? Yeah, they really are. It's like sizing is really part of capacity planning. It's really, I look at sizing as a one-time effort whereas capacity planning is more your ongoing. You perform sizing initially when the application is deployed and then when you're changing platforms, like going from on-prem to the cloud, you're going to go through a sizing exercise because you're looking at going to a new platform. That's more about a one-time effort and then ongoing, you're looking at your capacity management over time. So yeah, they are very related, so. Okay, thank you. So we're going to talk about database consolidation. And a lot of people would say, look, the cloud makes consolidating databases, maybe not a relevant, but maybe not the best strategy because I got all these different purpose-built databases. Why consolidate databases if they're already kind of consolidated in the cloud in one location? Yeah, so we're really talking about in the cloud, you're running virtual machines, but consolidation still applies on the virtual machine. So if you have a virtual machine that's dedicated to a database, that database is that server, that virtual machine is going to be underutilized over time. So what we're doing with consolidation is running multiple databases within a virtual machine or what at Oracle, a virtual cluster, we do everything on clusters. So multiple machine, multiple databases within that will drive up the utilization and improve your cost structure. So it's a sizing, it's absolutely critical on even in the cloud. Okay, but wouldn't, I might say to that, wouldn't it be better to have each database have a dedicated VM from a performance perspective? It doesn't try to make the database do too much effect performance. Yeah, so whenever, so we know historically that a database on a dedicated server, back in the day that was a physical server, today it's a virtual machine. When you do that, your utilization will be in the range of 15 to 20%. And that's very highly underutilized systems when you do that. So we don't need to isolate things onto dedicated virtual machines for a performance perspective. There are other ways that we can manage that. We have resource management built into Oracle and on the Oracle database and then on Exadata we have an integrated IO resource management as well. So we can deal with that different ways. Okay, so you're basically proposing that you're putting these databases onto a single VM and managing it accordingly? Additional details you can provide on that? So, we don't put everything into literally one VM. You want to have some isolation built in there, but say and take a more pragmatic approach. Like every single database in one VM, that's the wrong way to go. Each database in a dedicated VM is also the other extreme is also the wrong way to go. So we're kind of right down the middle and be more pragmatic about it and do some level of consolidation to drive up utilization. I remember when I first started following tech, I was studying up on kind of how this drives work and so forth and there was probably like, I can't even remember what it was. It was like probably like 10 megabytes under an actuator and people were saying, oh my God, that's so much data. You got your blast radius is so big. You got to split that up. So it's the same concept apply with availability. Some would say there's a problem because you're consolidating all this data and you've got this blast radius that increases. How do you address that? So, redundancy. So we have redundancy at all levels. If you look at a single, so we're talking about Exadata here. In an Exadata machine, we can lose up to 24 disk drives out of 30, this machine with 36 disk drives, we can use 24 of those. So that'd be 12 per storage cell. You can lose two storage cells as 24 out of 36 drives that we can lose and keep on running. We can also cluster, we also do clustering. So the database servers are clustered together for high availability. So we can suffer multiple simultaneous failures and keep on running without performance impact either. So it's, so recovery, we handle that in different ways. So it's look at blast radius from a standpoint. We, you want some, some isolation for blast radius, but we have physical failures. It's just not something that we're concerned with. Why do you deal with taking down a VM? Doesn't that normally mean there's going to be some kind of disruption? Oh, so, you know, the Oracle database, we're talking about real application clusters on Oracle database on Exadata. We've got, we have a very fast detection of failures and then resolution of the failure. So we're looking at a small blip in performance. You know, we're looking at a few milliseconds to detect failure and then maybe up around three seconds to actually affect the failover. So applications that are not getting disconnected, they continue operating in that kind of condition. So that's kind of unique to the Exadata platform. And so, you know, in our cloud, we're running Exadata. We have this built in there. So we're resilient to that type of failure. So. And sorry, you mentioned real application clusters. You're saying because you're running real application clusters, that's how you're able to become more resilient. So yeah, so we have a, so Oracle database, real application clusters runs on top of a clustered, you know, clustered virtual machines on Exadata. And we have integration that optimizes the failover times of that clustering. So it's not the cluster's same. It's the optimizations are only built into Exadata. So we have much faster, much better, tighter integration. So much more scalability because of that integration that we have. Can I run Rack and other clouds? Can I put that into Amazon's cloud? So real application clusters requires two things. You require shared storage in a fast interconnect, a fast networking interconnect. And those things just don't exist in the other clouds. We have those built into Exadata in our cloud. And we also, we also allow real application clusters in our relational data, our database cloud service offering as well. But it's really the highest implementation of that is in Exadata. Well, of course I was tongue in cheek joking, but this is why I was listening to Arvin Krishna the other day in IBM Think, and he was saying only 25% of mission critical applications have moved into the cloud. I don't think it's that high. But what you're doing is basically building a mission critical cloud or a cloud for mission critical databases. And that's unique. I mean, I would expect other cloud vendors that eventually are going to get there, but you're kind of starting with the hard stuff and working backwards. But that is what I've always interpreted as is unique to Oracle. But how does that affect cost? Isn't that more expensive? I actually know it's that we're taking services that start out at a very similar price point. And then we drive. So what we've seen from other customers that are running in like Amazon, for example, we're seeing databases on dedicated virtual machines. They'll run anywhere from 15 to 20% utilization. So what we do is that low, low utilization, what we do is take that and in triple that. So we run maybe 50% utilization. At that point, we still have full redundancy, but we've now made the service one-third the cost. So we're starting at the very similar cost and then we drive it to three times utilization. This is not crazy numbers. This is 50% is fine and retain the redundancy at that level as well. Got it. Well, so we've seen is about a third the cost. Really? Okay, well, so, but what about like, for instance, on AWS, couldn't I run this in a multi-availability zone running RDS or some other cloud database? So you can run a multi-AZ environment like in Amazon, for example, you can run locals, that's what we call local standby. If you do that, you're now, instead of being one-third the cost, you're instead of being three times more expensive, you're now six times more expensive because that is another copy of the entire platform, the entire instance, the storage, everything on the other availability zone. So you're saying- So instead of being three times more, it's now six times more. Because you're essentially replicating everything in a brute force mode. Yeah, it's a data guard standby, local standby in another AZ or what we call an availability domain in our cloud. So let's maybe geek out a little bit. So let's talk more about availability. For a year, I remember going back to reading about this stuff with tandem computers, coincident failures, how are you dealing with those in today's modern world? So what we call simultaneous failures is on, so we deal with that with redundancy in the system. So we have redundancy at all layers in the storage. Like I said earlier, we can take across two storage cells and each storage cell has a dozen drives. So that's 24 disk drives. That's eight flash card failures simultaneously. And we keep on running, no data loss, no loss of service. That's at the storage layer. We have multiple redundant networking switches at the networking layer, the internal network. Then we go up into the database server, we then have redundancy across the nodes of a cluster. They have multiple virtual machines that comprise a virtual cluster. So it's at each and every level we have redundancy and then we drive the redundancy into the application using what's called application continuity. So the application connections have knowledge of the failure modes of the database that they can follow to the surviving node and continue operating. And you do this with math? You're doing some kind of magic bit slicing or how do you do that? So that is that particular thing. Application continuity, some technology that's been built into Oracle Database since 12C. And it's been around for quite a long time and it allows the application to follow the Rack cluster, any kind of issues with the Rack cluster. We can drain connections off. It's very well proven technology. And prior to proactive maintenance, we can drain connections over and then it will also handle a failure of the connection as well. So the application is following that. I learned from my old mainframe days of David and hanging around with David Floyers. Just always ask what happens when something goes wrong? It's all about recovery. And you guys have the gold standard there. I mean, we've talked about this a lot. So you got Exadata and that's what is behind your Exadata cloud service, X8M, I think you call it. And you got Autonomous Database. I'm not great with model numbers, but talk about the way you can handle simultaneous failures. I mean, are there like triple redundancies that you've built in? Yeah, so everything we're, what we do in our cloud is everything is triple redundancy by default. So we, you can suffer that way. We can suffer two failures and continue operating. So the other thing, so recovery, if you don't get transaction recovery, when a failure occurs, the transaction will flip, that session will flip to the machine that keeps running it will reposition all in the work that's in flight, any kind of in flight transactions, any in flight queries that are going on, reposition and continue operating. So you've essentially created like the old three site data centers, but you're in a single platform, of course you're a synchronous, but that's on the same concept in a package. It's a lot of times you show a picture of an Exadata, it looks like a single box, but in the box there's redundancy built in the box. And in fact, in the cloud, it's actually across an entire aisle. So it's, we kind of obscure that a little bit from this. You're provisioning our database nodes and our storage cells and in the cloud, but it's actually across an entire aisle of a data center. Okay, and of course that's within a synchronous location. As he says, let's talk about disaster recovery and what you're doing in that area around Oracle Cloud. What kind of, what are my options there? What's different from other cloud providers? We were talking earlier about AZs. How are you different? And what are you doing there? Yeah, so we talked earlier about the multi AZ deployment, what we call availability domain AD, so a little different terminology, but we can deploy another copy of the database into another availability domain if you like. It's not often that you lose an entire AZ or AD, it's more for protecting from regional failure. So across another region, and that's where we look at, we really look at that as that technology as a standby, as a data disaster recovery solution, not for HA. HA, we build HA into the machine itself. So you're saying, you're saying, we were talking earlier about AZs, you're saying that's for HA versus DR? Is that what you're contending of? Yeah, like the, again, we're, pick on Amazon for a second here. Amazon uses a standby database, what we would normally use for disaster recovery, they're using that for availability, and you're looking at a few minutes of time to flip over to another AZ, whereas within an exadata frame, we can flip over in milliseconds, where we keep, continue running, there is no loss of connectivity, and then we use the standby in another region for disaster, that's a true disaster solution. As opposed to incurring that penalty of latency or whatever to spin up the other resource. Right, right. Okay, so that's clear how kind of you guys address that challenge. Last question, maybe you could give us your take, again, folks coming out of Oracle's mouth, but what's the bottom line cost delta based on your experience between your service and competitive services? I love these conversations, because you're not afraid to talk about the competition, so bring it on. I've seen, so we've just based on what we've seen with customers deploying databases in Amazon versus what we've replaced that within in our cloud service. We're seeing from just a list price perspective. Now, we discount, I know Amazon discounts, but the only thing I really speak to is list price perspective. It's about a third the cost. So we're talking about a more powerful platform, runs faster, we get these incredible, we haven't even talked about performance here, talk about availability, performance, we're getting IO rates, IO latencies in the 19 microsecond range now with Exadata. That's going to be 50 times faster than what you get with these traditional cloud vendors, so much, much faster and a third the cost. So you're talking about discounts, I mean, I know Oracle discounts, Oracle, from list price, Oracle provides significant discounts. I'm not as familiar with your cloud pricing, but I mean, Amazon's discounts are really in the form of like reserved instances. Is your pricing similar in that regard? I mean, if I'm just paying on demand, I'm paying through the nose. I presume it's the same with you, but if I buy in bulk, I'm getting a discount. Is that what you mean by discount or is it more similar to the way you've traditionally discounted with large customers, the more you spend, the more you get kind of thing? There's a discount structure, so we don't have the same kind of lock-in like with reserved instance structure, but yeah, there are discounts and that's going to be very customer specific. So, but I think the end result we're starting at a 3x differential on the price. But the reason I'm in question is the stats you gave me are for list price, right? Yeah. And okay, I'm sure you're saying at a list price, you're less expensive. And again, my contention would be just by experiences that your discounts would be more aggressive. Traditionally in Oracle's traditional business, I've done a lot of Oracle negotiation in my days and if you're a big customer, you can get good deals. And again, I'm not as familiar with the cloud pricing, but still, that's good. If you're doing it on a list price basis, to me, that's a conservative statement if that makes any sense. Right. Yeah. We know that's where it's starting out. So, once you get into discounts, it's very customer specific, so. Right. We know the starting point is the 3x differential. Got it. Before you do something, the multi-AZ would be a 6x differential, by the way. So. Yeah, okay. All right, Chris. Well, hey, I appreciate you taking us through this. Good stuff and best of luck, good work. You know, you guys are keep, I always say Oracle invests. You guys spend a lot of money on R and D and you know, you're quiet for a while in the cloud and all of a sudden you came out like you invented it. So, good job. All right. All right, thanks. Thanks for coming on. All right. Thanks. Thank you. Thank you for watching everybody. This is Dave Vellante for CUBE Conversations. We'll see you next time.