 From around the globe, it's theCUBE with digital coverage of AWS re-invent 2020. Sponsored by Intel and AWS. Welcome back here to our coverage here on theCUBE of AWS re-invent 2020. It's now a pleasure to welcome Sean Bice to the program as the vice president of databases at AWS and Sean, good day to you. How you doing, sir? I'm doing great, thank you for having me. You bet, you bet, thanks for carving out time. I know it was a very busy couple of weeks for the AWS team and certainly was kicked off keynotes today. We heard right away that there's some fairly significant announcements that I know certainly affect your world at AWS. Tell us a little bit about those announcements and then we'll do a little deeper dive as you go through. Sure, Andy made three big announcements this morning as it relates to databases. One of them was around Aurora Serverless V2. And you can just think of that as no infrastructure whatsoever to manage and Aurora Serverless that can scale from zero to hundreds of thousands of transactions in a fraction of a second literally with no infrastructure to manage. So it's a really easy way to build applications in the cloud. So we're excited about that. Another big announcement was related to a lot of our customers today are really they're using the right tool for the right job. In other words, they're not trying to jam all of their data into one database management systems. They're breaking app down into smaller parts. They pick the right tool for the right job. And with that context, we announced Glue Elastic Views which just allows you to very easily write a SQL query. There was a lot of developers that understand SQL. So if I could easily write a SQL query to reach out to these source databases and then materialize that data into a different target, that's a real simple way to build new customer experiences and make the most of the databases you have. And then the third big announcement we made today was called Babel. So Babelfish is really a compatibility or a SQL Server compatibility layer on Aurora Postgres. So if you have a SQL Server application, you've been trying to migrate it to Postgres and you've been wishing for an easier way to get that done, Babelfish allows you to take your T-SQL or your Microsoft SQL Server application connected to Postgres using your same client drivers with little to no code change. So that's a big deal for those that are trying to migrate from commercial systems to open source. And then finally, we didn't stop there as we thought about Babel and talk to a lot of customers about it. We actually are open sourcing the technology. So it'll be available later in 21. All the development will be done open, transparently hosted on GitHub and licensed under Apache 2.0. So that's kind of one lap around the track if you have all the big announcements from today. How big is the open source announcement? To me, I mean, that's fairly significant that you're opening up this new opportunity to the entire community, that you're willing to open it up. And I'm sure you're gonna have, I mean, this is gonna be, I would imagine a very popular destination for a lot of folks. Yeah, I think so too. You know, I'm personally, I'm a believer that every customer can use data to build a foundation for future innovation. And to me, a lot of things start and end with data. And as we know, data really is a foundational component of apps as well as systems. And what we found is not every customer can plan for every contingency that happens. But what they can do is build a strong foundation. And with a strong foundation, you really stand a best chance to overcome whatever that next unexpected thing is or innovate new ways. And with that as a backdrop, we think this open source piece is a big deal. Why? I'll tell you, it's just us right now. But if I told you the story behind the story, I have met so many customers over the last few years that John, if you and I were sitting down with them, it kind of sounds like this. You sit down, you talk to somebody and they'll say things like, hey, we've built years and years and years of application development against SQL Server. We really don't like the punitive commercial licensing. And we're trying to get over to open source but we need an easier way. And we've thought about that long and hard. And the team came up with a wonderful solution for this. But to tell you the truth, as we were building Babelfish and talking to customers, what became really clear with the community, enterprises in ISVs and SIs, is they all basically said, hey, if there was a way where we could go and extend this for like it could be, boy, if this thing supported two more features, that would be awesome. But boy, if it was open source, that would be even better because then we could take things under our own control. So that's what truly motivated this decision to go open source. And based on conversations we've had and the decisions we made, we actually think it's really big. It's really big for everybody who's been trying to move off of commercial systems and over to open source. You know, let's talk about transforming your kind of your database mindset in general right now from a client's perspective, especially for somebody who is considering, substantial moves, major reconfigurations of their processes. What's the process that you go through with them to evaluate their needs, to evaluate their capabilities, to evaluate their storage, all of that that comes into play here and to help them to get to the kind of the end of the rainbow. Yeah, yeah, it's absolutely, so it really depends on who you're talking to. Yeah, and at this stage of the game, the cloud's been around now for 10, 14 years, I think it is something in that range. So a lot of the early cloud adopters, they've been here and they've been building in a certain way. And you and I know early cloud adopters by way of watching streaming media, ordering rideshare, taking a selfie. And we have these great application experiences and we expect them to work all the time at super low latency, they should always be available. So the single biggest thing we learned from early cloud builders was, there's no such thing as one size fits all. One thing doesn't fit anything at all. That's kind of the way data was 20 years ago. But today, if you take the learning from these early cloud builders, the journey that we go on with, let's say a mid to late stage cloud adopter, we're all excited on sort of, if they can start now today, where early cloud builders have done a bunch of pioneering, they get excited. So what happens is, there's usually two kinds of conversations. One is how do we, we've got all these databases that we self-manage on premise, how do we bring those into the cloud? And then how do we stop doing undifferentiated heavy lifting? In other words, what they're saying is we don't wanna do patching and backup and monitoring. That's, instead, our precious resources should be working on innovations for the business. So in that context, you and I would end up talking to somebody about moving to fully managed services like in RDS, for example. And then the other conversation we have with customers is the one about breaking free, which is, hey, I've been on commercial, I wanna move to open source. And in that context, there are a lot of customers today that they'll move to the cloud. And then when they get there as a first step, their second step is to migrate over to open source. And then that third piece is folks that are trying to build for the cloud, these modern apps. And in that context, they follow the playbook of these early cloud builders, which is what you take this big app, you break it into smaller parts, and then they pick the right tool for the right job. So that's kind of the conversation that we go through there. And finally, what I would say is, most customers say to me, what do you mean by picking the right tool for the right job? And the mindset is very different than the one that we all grew up in from 20 years ago. 20 years ago, you just bought a database platform, and then whatever the business was trying to do, you would try to support that access pattern on that database choice. But today, the new world that we live in, it really is, let's start with the business use case first, understand the access pattern, and then pick the best optimized database storage for that. So that's kind of how those conversations go. Yeah, you've got, what, I mean, 14, 15 different database instruments, you know, like in your tool chest. How has that evolution occurred? Because I'm sure, you know, one begat another, begat another, begat another, looking at different capabilities, different needs. So, I mean, kind of walk me through that a little bit, and how have you gotten to the point that you've got 15 to all of them in the question? Yeah, so one of the things that, you know, I'd start off with here, like the question is, well, if there's 15 today, is there gonna be 100 tomorrow? The real answer is I don't know, you know, and but what I do know is there's really a handful of categories around data models and access patterns that if you will kind of fill out the portfolio, if you will. The first one is around relational. So relational databases have been around for a long time. It has a certain set of characteristics that people have come to appreciate and understand. And, you know, and we provide a set of services that provide fully managed relational services. Let it be for things like Oracle or SQL Server or open source like MariaDB or MySQL or Postgres and even Aurora, which provides commercial grade performance availability and scale at about a 10th the cost of commercials. So, you know, there's a handful of different services in that context, but there's new services in this key value and think of a key value access pattern along the lines of you imagine we order, you order a rideshare and you're trying to track a vehicle every second. So on your phone, you can see it moving across your phone. And now imagine if you were building that app, are a million people going to do that all at the same time or 10? So in that kind of access pattern, a product like DynamoDB is excellent because it's designed for basically unlimited scale, really high throughput. So a developer doesn't have to really worry about a million people, 10 million people are one. This thing can just scale inevitably. It's not an issue, right? Yeah, it's just not an issue. And, you know, I'll give you one other example like in Neptune, which is a graph database. So you and I would know graph databases by way of seeing a product recommendation, for example. And, you know, the beauty of a graph database is it's optimized for highly connected data. In other words, as a developer, I can, what I can do with a few lines of code in a graph database because it's optimized for all these different relationships, I might try to do that in a different system that I might write 1500 lines of codes in because it was never designed for something like highly connected data like graphs. So that's kind of the evolution of how things, there's just these different categories that have to do with access patterns and data models. And our strategy is simple. In each category, we wanna have the very best APIs available for our customers. Let's talk about security here for a moment because you have these tremendous reservoirs now, right? That you've built up in capabilities, you've got new data centers going up every day, it seems like around the country and around the world, security or securing data, never more important and never more, I guess on the radar of the bad actors too at the same time, right? Because of the value of that data. So just if you would paint the picture in terms of security awareness, the encryption devices that you're now deploying, the stuff that's keeping you up at night, I would think, probably falls into this category a little bit. So let's just take it on security and the level of concern and then what you at AWS are doing about that. Yeah, so when I talk to customers, I always remind people, security is a shared responsibility. And so Amazon's piece of that is the infrastructure that we build, the processes that we have, from how people can enter a building to what they can do in an environment, to the auditing, to the encryption systems that we build, there's the infrastructure responsibility which we think about every second of every day. And it's, yes, it's one of those things that keeps you up at night, but you have to kind of have this level of paranoia, if you will, there's bad actors everywhere. And that mindset is kind of helps you stay focused. And then there's the customer's responsibility too, in terms of how they think about security. So, and what that means is, best practices around how they integrate identity and access management into their solution, how they use, how they rotate encryption keys, how they apply encryption and all the safeguards that you would expect a customer to do. So together, we work with our customers to ensure that our systems are secure. And the only other thing that I would add to this is that kind of in the old world, and I keep bringing up the old world because security in the old world is sort of one of those things. Like if you go back 20 years ago, security sometimes is one of those things that you think about a little bit later in the cycle. And I've met a lot of customers that try to bolt on security and it never works. It's just hard to just bolt it into an app. But the really nice thing about these fully managed services in the cloud, they have security built right in. So security performance and availability is built right into these fully managed APIs so a customer doesn't have to think about, well, how do I add this capability onto it? In some sense, it could be as simple as turning a feature on or something like encryption being turned on by default and they don't have to do anything. So it's just a completely different world that we live in today and we try to improve it every second of every day. Sean, it's nice to know that you're experiencing the paranoia for all your customers. That's a very, very gracious gesture there. Thanks for the time. I appreciate it. I know you're very busy the next couple of weeks with a number of leadership sessions and intermediate sessions as well with AWS re-invent. So thanks again for carving out a little bit of time for us here today on theCUBE. You bet, Sean. Thank you. I really appreciate it. Take care.