>> Narrator: From around the globe. It's theCUBE with digital coverage of Postgres vision 2021 brought to you by EDB. >> Welcome back to Postgres Vision 21. My name is Dave Vellante. We're thrilled to welcome Carl Olofsen to theCUBE. Carl is a research vice president at IDC focused on data management. The long-time database analyst is the technologist and market observer. Carl, good to see you again. >> Thanks Dave. Glad to be here. >> All right. Let's let's get into it. Let's talk about, let's go right to the, to the source the open source database space. You know, how, what changes have you seen over the last couple of years in that marketplace? >> Well, this is a dynamic area and it's continuing to evolve. When we first saw the initial open source products like mysQl and PostgreSQL on the early days they were very limited in terms of functionality. They were espoused largely by sort of true believers. You know, people who said everything should be open source. And we saw that mainly they were being used for what I would call rather prosaic database applications. But as time has gone by they both of these products improve. Now there's one key difference, of course, which is a mySQL is company owned open source. So the IP belongs to Oracle corporation. Whereas PostgreSQL is community open source, which means that the IP belongs to the PostgreSQL community. And that can have a big difference in terms of things like licensing and so forth, which really matters now that we're coming into the cloud space because as open-source products moving into the cloud space the revenue model is based on subscriptions. And of course they are always based on subscription to open source cause you don't charge for the license. So what you charge for its support, but in the cloud what you can do is you can set up a database service, excuse me, a database service and then you charge for that service. And if it's open source or it's not open source that actually doesn't matter to the user. If you see what that I mean because they still are paying a subscription fee for a service and they get the service. The main difference between the two types is that if you're a commercial provider of PostgreSQL like enterprise DB, you don't have control over where it goes and you don't have control over the IP and how people use it in different ways. Whereas Oracle owns mySQL so they have a lot more control and they can do things to it on their own. They don't have to consult the community. Now there's also, non-relational open source including MongoDB. And as you may be aware, MongoDB has changed their license. So that it's not possible for third party to offer Mongo DB as a complete managed database service without paying a license fee to MongoDB for that. And that's because they own the IP too. And we're going to see a lot more of this sort of thing. I have conversations with open source all the time and they are getting a little concerned that it has become possible for somebody to simply take their technology, make a lot of money off that. And no money goes back to the community. No money goes back to the IRS. It's a company it's just stays with the supplier. So I think, you know it'll be interesting to see how all this is over time. >> So you're suggesting that the Postgres model then is, is I guess I'll use the word cleaner. And so that feels like it's a it's a benefit or is it a two-edged sword kind of thing? I mean, you were saying before, you know a company controls the IP so they could do things without having to go to the community. So maybe they can do things faster. But at the other hand like you said, you get handcuffed. You think you're going to be able to get a, you know a managed service, but then all of a sudden you're not and the rules change midstream saying it, am I correct? That Postgres, the model is cleaner for the customer? >> Well, you know, I mean, a lot of my friends who are in the open source community don't even consider company owned open source to be true open source because the IP is controlled by a company, not by a community. >> Dave: Right >> So from that perspective certainly Postgres SQL is considered, I don't know if you want to use the word cleaner or more pure or something along those lines, but also because of that the nature of community open source it can be used in many different ways. And so we see Postgres popping up all over the place sometimes partially and sometimes altogether, in other words, a service, a cloud service, we'll take a piece of Postgres and stick it on top of their own technology and offer it. And the reason they do that is they know there are a lot of developers out there who already know how to code for Postgres. So they are immediately first-class users of the service that they're offering. >> So, talk a little bit more about what you're seeing. You just mentioned a lot of different use cases. That's interesting. I didn't realize that was, that was happening. The, what are you seeing in terms of adoption in let's say the last 18, 24 months specific to Postgres? >> Yeah, we're seeing a fair amount of adoption in especially in the middle market. And of course there is rapid adoption in the tech sector. Now, why would that be? Well it's because they have armies of technologists. Who know how to program this stuff. You know, when you, you know, a lot of them will use PostgreSQL without a contract without a support contract, they'll just support themselves. And they can do that because they have the technicians who are capable of doing it. Most regular businesses can't do that. They don't have the staff so they need that support contract. And so that's where a company like enterpriseDB comes. I mentioned them only because they're the leading supplier Postgres to all their other suppliers. >> I was talking to Josh Burgers, red hat and he was, you know, he had just come off a Cubacon and he was explaining kind of what's happening in that community. Big focus of course on security and the whole, you know, so-called shift left. We were having a good discussion about, you know when does it make sense to use, you know Postgres in a container environment should you use Postgres and Kubernetes and he sort of suggested that things have rapidly evolved. There's still, you know, considerations but what are you seeing in terms of the adoption of microservices architectures containers, generally Kubernetes how has that affected the use of things like postsgres? >> So those are all different things or need to be kind of custody. >> Pick your favorite. >> They're related then. So microservices, the microservice concept is that you take an application break it up into little pieces and each one becomes a microservice that's invoked through an API. And then you have this whole structure API system that you use to drive the application and they run. They typically, they run in containers usually Kubernetes govern containers but the reason you do this and this is basically a efficiency because especially in the cloud, you want only to pay for what you use. So when you're running a microservice based application. Applications have lots of little pieces when something needs to be done, microservice fires up it does the thing that needs to be done. It goes away. You only pay for that fraction of a second that the microservice is running. Whereas in a conventional application you load this big heavyweight application. It does stop. It sets some weights with things and does more stuff and sits and waits for things. And you pay for compute for that entire period. So it's much more cost effective to use a microservices application. The thing is that microservice, the concept of microservices is based on the idea that the code is stateless but database code isn't stateless cause it has its attraction to the database which is the ultimate kind of like stateful environment right? So it's a tricky business. Most database technologies that are claimed to be container-based actually run in containers the way they run in servers. In other words, they're not microservice-based they do run in containers. And the reason they're doing that is for portability so that you can deploy them anywhere and you can move them around. But you know deploying a microservice based database is, well, it's it's a big technical project. I mean, that is hard to do. >> Right and so talk about, I mean again we're talking to Josh it was clear that that Kubernetes has evolved, you know quite rapidly at the same time there were cautions. In other words, he would say I think suggested things like, you know, there were known at one point, there were known, you know flaws and known bugs that ship the code that's been been remediated or moderated in terms of that practice but still there's there's considerations just in terms of the frequency of updates. I think he gave the example of when was the last time you know, JVM got, you know, overhauled. And so what kind of considerations should customers think about when considering them, they want the Kubernetes they want the flexibility and the agility but at the same time, if they're going to put it production, they've got to be careful, right? >> Yeah, I think you need to make sure you're using you're using functions that are well-established, you know you wouldn't want to put something into production that's new. They say, oh, here's a new, here's a new operation. Let's try that. And then, you know, you get in trouble. So you want to deal conservative that way you know, Kubernetes is open-source so and the updates and the testing and all that follows a rather slow formal process, you know from the time that the submission comes in to the time that it goes out, whereas you mentioned JVMs JV, but it was owned by Oracle. And so JVMs are managed like products. Now there's a whole sort of legal thing I don't want to get into it as to whether it's legal. They claim it's not libero third parties to build JVMs without paying a licensing. I don't want to talk about that, but it's based on a very state that has a very stable base, you know whereas this area of Kubernetes and govern containers is still rapidly evolving but this is like any technology, right? I mean, when you, if you're going to commit your enterprise to functions that run on an emerging technology then you are accepting some risk. You know, that there's no question about it. >> So we talked about the cloud earlier and the whole trend toward managed services. I mean, how does that specifically apply to Postgres? You can kind of imagine like a sidecar, a little bit of Postgres mixed in with, you know, other services. So what do you see and what do you, what's your telescope say in terms of the the Postgres adoption cloud? How do you see that progressing? >> I think there's a lot of potential. There's a lot of potential there. I think we are nowhere near the option that it should be able to achieve. I say that because for one thing, even though we analyze the future at IDC, that doesn't mean we actually know the future. So I can't say what its adoption will be but I can say that there's a lot of potential there. There's a tremendous number of Postgres developers out there. So there's a huge potential for adoption. And especially in cloud adoption, the main thing that would help that is independent. And I know that enterpriseDB has one independent a managed cloud service. So I think they do. >> Yeah I think so. >> But you know, why do I say that? I say that because alternatives these days there are some small companies that maybe they'll survive and maybe they won't, but that, you know, do you want to get involved with them or the cloud platform providers, but if you use their Postgres you're locked into that cloud platform. You know, if you use Amazon, go press on RDS, right? You're not, you become quickly locked in because you're starting using all the AWS tools that surround it to build and manage your application. And then you can't move. If you see what I mean. >> Dave: Yeah . >> They have have an RDS labor Aurora, and this is actually one of the things that it's really just a thin layer of Postgres interaction code underneath Aurora is their own product. so that's an even deeper level of commitment. >> So what has to happen for, so obviously cloud, you know, big trend. So the Postgres community then adopts the code base for the cloud. Obviously EDB has, you know hundreds of developers contributing to that, but so what does that mean to be able to run in the cloud? Is that making it cloud native? Is that extensions? Is it, you know, what technically has to occur and what has occurred and how mature is it? >> Well, so smaller user organizations are able to migrate fairly quickly cloud because most of their applications are you know, commercially purchased. They're like factories applications. When they move to the cloud, they get the SAS one and often the SAS equivalent runs on Postgres. So that's just fine. Larger enterprises are a real mess. If you've ever been in a large enterprise data center you know what I'm talking about? It's just, there's just servers and storage everywhere. There's, all these applications, databases connections. They are not moving to the cloud anytime soon. But what they are doing is setting up things like private cloud environments and applying in there. And this is a place where if you're thinking about moving to something like a Postgres you know most of these enterprises use the big commercial databases. Oracle SQLserver DB two and so forth. If you're thinking of moving from that to a a PostgreSQL development say, then the smart thing to do would be first to do all your work in the private cloud where you'd have complete control over the environment. It also makes sense still to have a commercial support contract from a vendor that you trust, because I've said this again, unless you are, you know, Cisco or somebody, you know, some super tech company that's got all the technicians you need to do the work. You really don't want to take on that level of risk. If you see that, I mean. Another advantage to working with a supplier, a support supplier, especially if you have a close, intimate relationship is they will speed your security patches on a regular basis which is really important these days, because data security is as you know, a growing concern all over the place. >> So let's stay on the skillsets for a minute. Where do you see the gaps within enterprises? What kind of expertise you mentioned, you know support contracts, what are the types of things that a customer should look for in terms of the the expertise to apply to supporting Postgres databases? >> Well, obviously you want them to do the basics that any software company does, right? You want them to provide you with regular updates and binary form that you can load and, you know test and run. You want to have the you know, 24 hour hotline you know, telephone support, all that kind of thing. I think it's also important to have a solid ability on the part of the vendor that you're working with to provide you with advice and counseling as you, especially, if you're migrating from another technology, help your people convert from what they were using to what they're going to be using. So those are all aspects that I would look for in a vendor for supporting a product like PostgreSQL. >> When you think about the migration to the cloud, you know of course Amazon talks a lot about cloud migration. They have a lot of tooling associated with that. >> Carl: Right. >> But when you step back and look at it it did to a point earlier, I mean a lot of the hardcore mission, critical stuff isn't going to move it, hasn't moved, but a lot of the fat middle, you know, is, are good candidates for it. >> Carl: Right. >> How do you think about that? And how do you look at that? I mean, obviously Oracle is trying to shove everything into OCI and they're, you know, they're all in because they realized that could make a lot of money doing that. But what do you, what are the sort of parameters that we should think about when considering that kind of migration, moving a legacy database into the cloud? >> Well, it has to be done piecemeal. You're not going to be able to do it all at once. You know, if you have hundreds of applications, you're not just you don't even want to, you know, it's a good time to take you into it. And what you've got running, ask yourself are these applications really serving the business interests today and will they in the future or is this a good time to maybe consider something else? Even if you have a packaged application, there might be one that is more aligned with your future goals. So it's important to do that. Look at your data integration, try to simplify it. You know, most data integration that most companies has done piecemeal project by project. They don't reference each other. So you have this chaos of ETL jobs and transformation rules and things like that that are just, you know, even difficult to manage. Now, just forget about any kind of migration or transformation considerations, just trying to run it now is becoming increasingly difficult. You know, maybe you want to change your strategy for doing data integration. Maybe you want to consolidate you want to put more data in one database. I'm not an advocate of the idea that you can put all application data in one database by the way, we know from bitter experience that doesn't work, but we can be rational about the kinds of databases that we use and how they sit together. >> Well, I mean, you've been following this for a long time and you saw the sort of rise and fall of the big data meme. And you know, this idea that you can shove everything into a single place, have a single version of the truth. It's like, it's just never seemed to happen. >> Carl: Right. >> So, you know, Postgres has been around a long time. It's evolved. I mean, I remember when, you know, VMware's ascendancy and people are like, okay, should I, you know should I virtualize my Postgres database is your, you know similar conversations that we were having earlier about Kubernetes. You've seen the move to the cloud. We're going to have this conversation about the edge at some point in time. So what's your outlook for Postgres, the Postgres community and, you know database market overall? >> Well, I really think the future for database growth is in the cloud. That's what all the data we're looking at and the case that's what our recent surveys indicate. As I said before, the rate of change depends on the size of the enterprise. Smaller advices are moving rapidly, large enterprises much more slowly and cautiously for the very simple reason that it's a very complex proposition. And also in some cases, they're wondering if they can move certain data or will they be violating your some sort of regulatory constraint or contractual issue. So they need to deal with those things too. That's why the private cloud is the perfect place to get started and get technology all lined up storing your data center is still under your control no legal issues there, but you can start, you know converting your applications to micro-service architected applications running in containers. You can start replacing your database servers with ones that can run in a container environment and maybe in the future, maybe hope that in the future, some of those will actually also be able to run as microservices. I don't think it's impossible but it just involves programming the database server in a very different way than we've done in the past. But you do those things. You can do those things under your own control over time in your own dataset. And then you reach a point where you want to take the elements of your application environment and say, what pieces of this, can I move to the cloud without creating disruption and issues regarding things like data egress and latency from cloud to data center and that kind of thing. And prepare for that. And then you're doing the step wise and then you start converting in a stepwise manner. I think ultimately it just makes so much sense to be in the cloud that the cloud vendors have economies of scale. They can deploy large numbers of servers and storage systems to satisfy the needs of large numbers of customers and create, you know great considerable savings. Some of which of course becomes their profit which is what's due to them. And some of that comes back to the users. So that's what I expect. We're going to see. And oh gosh, I would say that starting from about three years from now the larger enterprises start making their move and then you'll really start to see changes in the numbers in terms of cloud and cloud revenue. >> Great stuff, Carl, thank you for that. So any cool research you're working on lately, how you're spending your your work time, anything you want to plug? >> Well, working a lot on just as these questions, you know cloud migration is a hot topic, another which is really sort of off the subject. And what we've been talking about is graph database which I've been doing a fair amount of research into. I think that's going to be really important in the coming years and really, you know working with my colleagues in a project called the future of intelligence which looks at all the different related elements not just database, data integration but artificial intelligence, data communications and so on and so forth and how they come together to create a more intelligent enterprise. And that's a major initiative that I see. It's one of the, we call the future of initiatives. >> Great, Carls, thanks so much for coming back to theCUBE. It's great to have you, man. I appreciate it. >> Well, I enjoyed it. Now I have to do it again sometime. >> All right you got it. All right thank you everybody for watching theCUBEs. Continuous coverage of Postgres vision 21. This is Dave Vellante keep it right there. (upbeat music)

>> Live from Las Vegas, it's theCUBE, covering AWS re:Invent 2018, brought to you by Amazon Web Services, Intel, and their ecosystem partners. >> Hi everybody, welcome back to Las Vegas. I'm Dave Vellante with theCUBE, the leader in live tech coverages. This is day three from AWS re:Invent, #reInvent18, amazing. We have four sets here this week, two sets on the main stage. This is day three for us, our sixth year at AWS re:Invent, covering all the innovations. Markus Strauss is here as a Product Manager for database security at McAfee. Markus, welcome. >> Hi Dave, thanks very much for having me. >> You're very welcome. Topic near and dear to my heart, just generally, database security, privacy, compliance, governance, super important topics. But I wonder if we can start with some of the things that you see as an organization, just general challenges in securing database. Why is it important, why is it hard, what are some of the critical factors? >> Most of our customers, one of the biggest challenges they have is the fact that whenever you start migrating databases into the cloud, you inadvertently lose some of the controls that you might have on premise. Things like monitoring the data, things like being able to do real time access monitoring and real time data monitoring, which is very, very important, regardless of where you are, whether you are in the cloud or on premise. So these are probably really the biggest challenges that we see for customers, and also a point that holds them back a little, in terms of being able to move database workloads into the cloud. >> I want to make sure I understand that. So you're saying, if I can rephrase or reinterpret, and tell me if I'm wrong. You're saying, you got great visibility on prem and you're trying to replicate that degree of visibility in the cloud. >> Correct. >> It's almost the opposite of what you hear oftentimes, how people want to bring the cloud while on premise. >> Exactly. >> It's the opposite here. >> It's the opposite, yeah. 'Cause traditionally, we're very used to monitoring databases on prem, whether that's native auditing, whether that is in memory monitoring, network monitoring, all of these things. But once you take that database workload, and push it into the cloud, all of those monitoring capabilities essentially disappear, 'cause none of that technology was essentially moved over into the cloud, which is a really, really big point for customers, 'cause they cannot take that and just have a gap in their compliance. >> So database discovery is obviously a key step in that process. >> Correct, correct. >> What is database discovery? Why is it important and where does it fit? >> One of the main challenges most customers have is the ability to know where the data sits, and that begins with knowing where the database and how many databases customers have. Whenever we talk to customers and we ask how many databases are within an organization, generally speaking, the answer is 100, 200, 500, and when the actual scanning happens, very often the surprise is it's a lot more than what the customer initially thought, and that's because it's so easy to just spin off a database, work with it, and then forget about it, but from a compliance point of view, that means you're now sitting there, having data, and you're not monitoring it, you're not compliant. You don't even know it exists. So data discovery in terms of database discovery means you got to be able to find where your database workload is and be able to start monitoring that. >> You know, it's interesting. 10 years ago, database was kind of boring. I mean it was like Oracle, SQL Server, maybe DB2, maybe a couple of others, then all of a sudden, the NoSQL explosion occurred. So when we talk about moving databases into the cloud, what are you seeing there? Obviously Oracle is the commercial database market share leader. Maybe there's some smaller players. Well, Microsoft SQL Server obviously a very big... Those are the two big ones. Are we talking about moving those into the cloud? Kind of a lift and shift. Are we talking about conversion? Maybe you could give us some color on that. >> I think there's a bit of both, right? A lot of organizations who have proprietary applications that run since many, many years, there's a certain amount of lift and shift, right, because they don't want to rewrite the applications that run on these databases. But wherever there is a chance for organizations to move into some of their, let's say, more newer database systems, most organizations would take that opportunity, because it's easier to scale, it's quicker, it's faster, they get a lot more out of it, and it's obviously commercially more valuable as well, right? So, we see quite a big shift around NoSQL, but also some of the open source engines, like MySQL, ProsgreSQL, Percona, MariaDB, a lot of the other databases that, traditionally within the enterprise space, we probably wouldn't have seen that much in the past, right? >> And are you seeing that in a lot of those sort of emerging databases, that the attention to security detail is perhaps not as great as it has been in the traditional transaction environment, whether it's Oracle, DB2, even certainly, SQL Server. So, talk about that potential issue and how you guys are helping solve that. >> Yeah, I mean, one of the big things, and I think it was two years ago, when one of the open source databases got discovered essentially online via some, and I'm not going to name names, but the initial default installation had admin as username and no password, right? And it's very easy to install it that way, but unfortunately it means you potentially leave a very, very big gaping hole open, right? And that's one of the challenges with having open source and easily deployable solutions, because Oracle, SQLServer, they don't let you do that that quickly, right? But it might happen with other not as large database instances. One of the things that McAfee for instance does is helps customers making sure that configuration scans are done, so that once you have set up a database instance, that as an organization, you can go in and can say, okay, I need to know whether it's up to patch level, whether we have any sort of standard users with standard passwords, whether we have any sort of very weak passwords that are within the database environment, just to make sure that you cover all of those points, but because it's also important from a compliance point of view, right? It brings me always back to the compliance point of view of the organization being the data steward, the owner of the data, and it has to be our, I suppose, biggest point to protect the data that sits on those databases, right? >> Yeah, well there's kind of two sides of the same coin. The security and then compliance, governance, privacy, it flips. For those edicts, those compliance and governance edicts, I presume your objective is to make sure that those carry over when you move to the cloud. How do you ensure that? >> So, I suppose the biggest point to make that happen is ensure that you have one set of controls that applies to both environments. It brings us back to the hybrid point, right? Because you got to be able to reuse and use the same policies, and measures, and controls that you have on prem and be able to shift these into the cloud and apply them to the same rigor into the cloud databases as you would have been used to on prem, right? So that means being able to use the same set of policies, the same set of access control whether you're on prem or in the cloud. >> Yeah, so I don't know if our folks in our audience saw it today, but Werner Vogels gave a really, really detailed overview of Aurora. He went back to 2004, when their Oracle database went down because they were trying to do things that were unnatural. They were scaling up, and the global distribution. But anyway, he talked about how they re-architected their systems and gave inside baseball on Aurora. Huge emphasis on recovery. So you know, being very important to them, data accessibility, obviously security is a big piece of that. You're working with AWS on Aurora, and RDS as well. Can you talk specifically about what you're doing there as a partnership? >> So, AWS has, I think it was two days ago, essentially put the Aurora database activity stream into private preview, which is essentially a way for third party vendors to be able to read a activity stream off Aurora, enabling McAfee, for instance, to consume that data and bring customers the same level of real-time monitoring to the database as the servers were, as were used to on prem or even in a EC2 environment, where it's a lot easier because customers have access to the infrastructure, install things. That's always been a challenge within the database as the servers were because that access is not there, right? So, customers need to have an ability to get the same level of detail, and with the database activity stream and the ability for McAfee to read that, we give customers the same ability with Aurora PostgreSQL at the moment as customers have on premise with any of the other databases that we support. >> So you're bringing your expertise, some of which is really being able to identify anomalies, and scribbling through all this noise, and identifying the signal that's dangerous, and then obviously helping people respond to that. That's what you're enabling through that connection point. >> Correct, 'cause for organizations, using something like Aurora is a big saving, and the scalability that comes with it is fantastic. But if I can't have the same level of data control that I have on premise, it's going to stop me as an organization, moving critical data into that, 'cause I can't protect it, and I have to be able to. So, with this step, it's a great first step into being able to provide that same level of activity monitoring in real time as we're used to on prem. >> Same for RDS, is that pretty much what you're doing there? >> It's the same for RDS, yes. There is a certain set level of, obviously, you know, we go through before things go into GA but RDS is part of that program as well, yes. >> So, I wonder if we can step back a little bit and talk about some of the big picture trends in security. You know, we've gone from a world of hacktivists to organized crime, which is very lucrative. There are even state sponsored terrorism. I think Stuxnet is interesting. You probably can't talk about Stuxnet. Anyway-- >> No, not really. >> But, conceptually, now the bar is raised and the sophistication goes up. It's an arms race. How are you keeping pace? What role does data have? What's the state of security technology? >> It's very interesting, because traditionally, databases, nobody wanted to touch the areas. We were all very, very good at building walls around and being very perimeter-oriented when it comes to data center and all of that. I think that has changed little bit with the, I suppose the increased focus on the actual data. Since a lot of the legislations have changed since the threat of what if GDPR came in, a lot of companies had to rethink their take on protecting data at source. 'Cause when we start looking at the exfiltration path of data breaches, almost all the exfiltration happens essentially out of the database. Of course, it makes sense, right? I mean I get into the environment through various different other ways, but essentially, my main goal is not to see the network traffic. My main goal as any sort of hacker is essentially get onto the data, get that out, 'cause that's where the money sits. That's what essentially brings the most money in the open market. So being able to protect that data at source is going to help a lot of companies make sure that that doesn't happen, right? >> Now, the other big topic I want to touch on in the minute we have remaining is ransomware. It's a hot topic. People are talking about creating air gaps, but even air gaps, you can get through an air gap with a stick. Yeah, people get through. Your thoughts on ransomware, how are you guys combating that? >> There is very specific strains, actually, developed for databases. It's a hugely interesting topic. But essentially what it does is it doesn't encrypt the whole database, it encrypts very specific key fields, leaves the public key present for a longer period of time than what we're used to see on the endpoint board, where it's a lot more like a shotgun approach and you know somebody is going to pick it up, and going to pay the $200, $300, $400, whatever it is. On the database side, it's a lot more targeted, but generally it's a lot more expensive, right? So, that essentially runs for six months, eight months, make sure that all of the backups are encrypted as well, and then the public key gets removed, and essentially, you have lost access to all of your data, 'cause even the application that access the data can't talk to the database anymore. So, we have put specific controls in place that monitor for changes in the encryption level, so even if only one or two key fields starting to get encrypted with a different encryption key, we're able to pick that up, and alert you on it, and say hey, hang on, there is something different to what you usually do in terms of your encryption. And that's a first step to stopping that, and being able to roll back and bring in a backup, and change, and start looking where the attacker essentially gained access into the environment. >> Markus, are organizations at the point where they are automating that process, or is it still too dangerous? >> A lot of it is still too dangerous, although, having said that, we would like to go more into the automation space, and I think it's something as an industry we have to, because there is so much pressure on any security personnel to follow through and do all of the rules, and sift through, and find the needle in the haystack. But especially on a database, the risk of automating some of those points is very great, because if you make a mistake, you might break a connection, or you might break something that's essentially very, very valuable, and that's the crown jewels, the data within the company. >> Right. All right, we got to go. Thanks so much. This is a really super important topic. >> Appreciate all the good work you're doing. >> Thanks for having me. >> You're very welcome. All right, keep it right there, everybody. You're watching theCUBE. We'll be right back, right after this short break from AWS re:Invent 2018, from Las Vegas. We'll be right back. (techno music)

(lively music) >> Announcer: It's the CUBE, covering SAPPHIRE NOW 2017, brought to you by SAP cloud platform and HANA Enterprise Cloud. >> Welcome back, everybody. Jeff Frick here with the CUBE with our ongoing coverage of SAP SAPPHIRE 2017 down in Orlando. Really exciting day today, day two, 'cause we got to see Hasso Plattner. Got up and gave his keynote. Joined by George Gilbert. George, great to see you. I know you've known Hasso for years and years and years. Impressions of the kfeynote. God, there is so much stuff that we can dig into. I'm looking forward to it. >> Hasso almost never disappoints, 'cause he's just got %a richness of history and of vision that goes all the way back to the beginning. He was probably the technical visionary from the very beginning. He was the guy who took them from the first super integrated mainframe ERP package all the way to the client server age with R3, and now beyond into sort of in-memory, cloud ready, and with machine learning and iOT baked in. >> But he really speaks like a developer. You can really tell that he likes the technology, he understands the technology, he's kind of a no-BS guy. Some of the Q&A afterwards, people were trying to trip him up and challenge him on stuff. And he would either say, "I don't know," or, "I don't believe that," or, "Here's our impression." Really you could tell he's a humble guy, smart guy, and really has a grasp of what the heck is going on here. Let's jump into it. So many themes we could talk about. But the one that started out early in the conversation was, he literally said, "We need to get as quickly "to the cloud as possible." This is coming from a guy who built the company based on on prem ERP heavy lifting. And even he said today, 2017, "We need to get to the cloud as quickly as possible." >> I think there are a few things going on behind there, when you unpack it. One is, they did start building for the cloud in the early 2000's. It was meant to be a product for the mid-market. In fact, actually its first objective wasn't to be cloud-ready. The first objective was to be highly configurable so that you could bend it to the needs of many customers without customizing it, because typically with the customizations, it made it very difficult to upgrade. In making it configurable first and cloud-read second, they kind of accomplished neither. But they learned a lot. So they started on this next version, which was, okay, we're going to take an in-memory database which we're building from the ground up, 'cause Oracle wasn't building it at the time, and then we're going to build SAP ERP from scratch on top of this new database, 'cause database was so high performance that they didn't have to sepyarate analytics from transactions the way traditionally you do, you had to do in all applications. So they could simplify the app. Then, in simplifying it, they could make it easier to run in the cloud. And now, just like Oracle, just like Microsoft, they now build cloud first and on-prem second, because by building it cloud first, it sort of simplifies the assumptions that you have to make. >> Right, and he talked quite a bit about so much effort now is around integration connectors, to get stuff in and out of this thing. And that's a big focus, he said. It's not that we're ignoring it, it's just a big, hard, hairy problem that we're attacking. >> Yeah, and this is interesting and there's a lot of history behind this. Oracle, in the 90s, up until about the late 90s, their greatest success was in their industry-specific applications, where they took different modules from different vendors and stitched them together. That was how they built, like, a special solution for a consumer package goods company. But it turned out that that wasn't really workable because the different modules for the different vendors6 upgraded at different rates. So there was no way coherently to integrate them and tie them together. And SAP had said that all along. They were, like, this wasn't going to work. Fast forward to the last five-plus years, SAP started buying products from a bunch of different vendors, Ariba, SuccessFactors, Concur, Hybris. So you're, like, "Aren't they doing the same thing "Oracle did 10 year, 15 years before?" But no, and this is what Hasso was talking about today, which was, once those apps are in the cloud, you only have to build the integration points once. It's not like when it's on every customer's data center, you have to build integrations that work for every version that every customer has. So I think that's what he was talking about. You put it all in the cloud, you integrate it once. >> Another thing that he talked, he really, he spoke in tweets. (mumbles) goes to buy Twitter feed, I was basically, like, bang, bang, bang as he was talking. He talked about databases, and databases in the cloud. Nobody cares, right? It's a classic theme we hear over and over. "We presume it works. "We just want it to work." You know, it should just work. Nobody really cares what the underlying database is. >> But he was, in those cases, referring to these purchased apps, Concur, SuccessFactors, Ariba, Hybris. He was, like, "Some of them work on SQLServer, "some of 'em work on Oracle. "But you know what? "Until we get around to upgrading them to HANA, "it doesn't matter because you, the customer, "don't know that." If they were on prem and you had to support all those different databases, it might be a different story. But he's, like, "We'd rather give you the functionality "that's baked into them now "and get around to upgrading the databases later." >> Another thing that came up, and he actually reference the conversation with Michael Dell from yesterday's keynote, about the evolution of compute horsepower. You know, you had CPUs and CPUs kind of topped out. Then you had multicore CPUs. Now we have GPUs that he said you can put 10s or 100s of 1,000s on the board at one time. Basically he's smart guy, he's down the road a few steps from delivering today's product, saying that, you know, we're basically living in a era of unlimited free compute and kind of asymptotically approaching. But that's where we are. And how does that really change the way that we look now at new application development. I thought that was a pretty interesting thing. >> And sort of big advances in software architecture come from when you have a big change in the relative cost of compute memory, network storage. So as you were saying, cost of compute is approaching zero. But the same time, the cost of memory relative to storage is coming way down. So not only do you have these really beefy clusters with lots of compute, but you also have lots of memory. He was talking about something like putting 16 terabytes of memory in a server and putting 64 servers in a cluster, and all of a sudden, I can't do that math, being that I was a humanities major, but all of a sudden, you're talking about huge databases where you can crunch through this stuff very, very fast because it's all, you have lots of processors running in parallel and you have lots of memory. >> It's pretty interesting. He made an interesting statement. He used a sailor reference. He said, "You know, we are through the big waves "and now we're in the smooth water," and really saying that all this heavy lifting and now that this cloud architecture is here and we have this phenomenal compute and store technology, that he can kind of take a breath and really refresh a look out into the future as to, how do we build modern apps that have intelligence with basically unlimited resources, and how does that change the way that we go forward? I thought that was an interesting point of view, especially 'cause he has been at it for decades. >> You know, I think he was probably looking back to some of the arrows he had in his back from having done an in-memory database essentially before anyone else did for mission critical apps. I think when he's saying we're out of the choppy water and into the smooth water, because we now have the hardware that lets us run essentially these very resource-intensive databases and the apps on 'em, so that we no longer have to worry, are we overtaxing the infrastructure? Is it too expensive to outfit the hardware for a customer? So his, when he talks about rethinking the apps, he, like, "We don't have to have separate analytical systems "from the transaction systems. "And not only that. "We can simplify because we don't have to have" what he's calling aggregates. In other words, we don't have to, we don't, let's say, take an order and all the line items in an order, and then pre-aggregate all the orders. It's, like, we do that on the fly. And that simplifies things a lot. Then, not only that. Because we have all this memory, we can do, like, machine learning very inexpensively. >> A whole another chapter in his keynote was about modern software design. A lot of really interesting things, especially in the context of SAP, which was a big, monolithic application, hard to learn, hard to understand, hard to manage. I remember a start, that were were (mumbles) using is a core V to C commerce engine. And to add 16 colors of shirts times 10 neck sizes and 10 sleeve sizes was just a nightmare. You're not going to have some merchant that works at Macy's to put that into the system. But he talked about intelligent design, which is pretty interesting. We're hearing that more and more in a lot of work done over at Stanford, intelligent design. He's talking about no manuals. He's, like, "If I can't figure it out, "I need to understand." He talked about intelligent applications that continue to learn as the applications get more data. And specifically, the fact that machines don't get bored testing 100s or 1,000s or even millions of scenarios and grinding through those things to get the intelligence to start to learn about what's going on. So a very different kind of an application, both development, delivery approach, than what we think of historically as R3. >> Yeah, like the design thinking was, they have this new UI called Fiori. I mean, if you go back 10, 15 years, let's say, when they started, 15 years, when they started trying to put browser-based user interfaces on what was a client server system, they had 10s and 10s of 1,000s of forms-based screens. They had to convert them one by one to work in a browser. I think what he's saying now is, they can mock up these prototypes in a simple tool and they can essentially recreate the UI. It's not going to be the exact same forms, but they can recreate the UI to the entire system so that it's much more accessible. On the machine learning front, he was talking about one example was, like, matching up invoices that you going to have to pay. So that you going to train the system with all these invoices. It learns how to essentially do the OCR, recognize the text. And it gets smarter to the point where it can do 95% of it without-- >> Human interaction. >> Yeah, human inter-. >> You know, it's interesting, we were at Service Now last week, as well. And they are using AI to do relatively mundane tasks that people don't want to do, that machines are good at, things like categorization and assignment and things that are relatively straightforward processes but very time-consuming and again, if you can get to a 70% solution, 80% solution, 90% solution, to free people up to do other things on the stuff that's relatively routine. Right, if the invoice matches the anticipated bill in the system, pay it. Does somebody really have to look at it? So I thought that was really interesting. Something I want to dig in with you, he talked a lot about data, where the data lives, data gravity. He even said that he fought against data warehousing in the 90s and lost. A lot of real passionate conversation about where is data and how should apps interact with data, and he's really against this data replication and a data lake and moving this stuff all around, but having it kind of central. Want to just get your thoughts on that history. What do you think he means now, and where's that going? >> It's a great question. There's a lot of history behind that. Not everyone would remember, but there was an article in Fortune Magazine in the late 90s, where it described him getting up in a small conference of software CEOs, enterprise software CEOs, and he said basically, "We're going to grind you into dust, "because everything comes in our system integrated. "And if you leave it up to the customer "to try and stitch all this stuff together, "it's going to be a nightmare." And that was back when everyone was thinking, "One company can't do it all." And the reality was, that was the point in time where we really had given go past go, collect $200, to every best-of-breed little software vendor. It did prove out over the next decade that the fewer integration points there were, that it meant much lower cost of ownership for the customer. Not only lower cost of ownership, but better business process integration, 'cause you had the (mumbles) integration. I bring this up because, well, actually, I was there when he said it. (laughs) But I bring it up because he's essentially saying the same thing now, which is, "We'll put all the machine learning technology, "the building blocks, in SAP. "If you need any contextual data, "bring it into our system. "You don't want to take our data out "and put it into all these other machine learning programs "'cause there's security issues, "there's, again, the breakdown "in the business process integration." He did acknowledge that with data warehouses, if you have 100s of other sources, yes, you may need a external data warehouse. But I think that he's going to find with machine learning the greatest value with the data that you use in machine learning is when you're always adding richer and richer contextual data. That contextual data means you're getting it from other sources. I don't think he's going to win this battle in terms of keeping most of it within SAP. >> It kind of bring up this other intersection that he talked about. In now delivering SAP as a cloud application, he said, "Now we have to learn how to run our application, "not our customers," a very different way of looking at the world. The other thing that piggybacks off of what you just said is, we've seen this trend towards configuration, not customization. It used to be probably, back in the days, if you had the big SI's, they loved customization, 'cause it's a huge project, multi-years. I used to talk to one of our center partners, like, "How do you manage a multi-year SAP project "when most the people that started it "probably aren't even there the day you finish it?" But he had a specific quote I wanted to call out now, what you just said, is that he said, "Only our customers have the data, "the desire, and the domain knowledge "to make the most out of it." So it's a really interesting recognition that yes, you want customers to have this configuration option. But we keep hearing more and more, it's config, not-- >> Both: Customization. >> For upgrades and all these other things, which now when you go to a cloud-based application, that becomes significant. You don't want customizations, 'cause that's just complicates everything. >> You can't. I don't know if he said this today. I guess he must have said it today. But basically, when you're in the cloud, I forgot the terminology for the different instances. But when you're in, like, the SAP cloud, you can only configure. There's essentially a set of greater constraints on you. When you go to the other end of the spectrum, let's say you run it in your own data center, you can customize it. But when you're running it, essentially sharing the infrastructure, you're constrained. You're much more constrained. And they build it for that environment first. >> Right. But at the same time, they've got the data. Again, this has come up with other SAS companies that we've talked to, is hopefully, their out of the box business process covers 90% of the basics. I think there's been a realization on the business analyst side that we think we're special, but really most of the time, order to cash is order to cash. So if you got to tweak your own internal process to match best-of-breed, do it. You're much better off than trying to shape that computing system to fill your little corner cases. >> It's funny that you mention that, because what happened in the 90s was that by far the biggest influencers in the purchase decision and the overall lifecycle of the app were the big system integrators. They could typically collect $10 in implementation and change management fees for every dollar of license that went to the software vendors. So they had a huge incentive to tell the customer, "Well, you really should customize this "around your particular needs," because they made all the money off that. >> Right, right. Another huge theme. Again, it was such a great keynote. We watch a lot of keynotes, and I have a very high bar for what I consider a great keynote. This was a great keynote by a smart guy who knows his stuff and got history. But another theme was just really about AI. He talked a little bit, which I thought was great. Nobody talks about the fact that airplanes have been flying themselves for a very long time. So it is coming. I think he even said, maybe this is the age of AI. But there always have to be some humans involved. It's not a complete hand-over of control. But it is coming, and it's coming very, very quickly. >> I actually thought that they were a little further behind than might expected, considering that it's been years now that people in software have seen this coming. But they have in the dozens of applications or functions right now that are machine learning enabled. But if you look out at their roadmap, where they get to predictive accounting, customer behavior segmentation, profile completeness for in sales, solution recommenders, model training infrastructure for the base software foundation, they have a pretty rich roadmap. But I guess I would have thought it'd be a little farther along. But then Oracle isn't really any farther along. (mumbles) has done some work for HR. For whatever reason, I think that enterprise application vendors, I think they found this challenging for two reasons. On the technical side, machine learning is very different from the traditional analytics they did, which was really essentially OLAP, you know, business intelligence. This requires the data scientists and the white lab coats and instead of backward-looking business intelligence this forward-looking predictive analytics. The other thing is, I think you sell this stuff differently, which is, when it was business intelligence, you're basically selling reporting on what happened to department heads or function leaders, whereas when you're selling predictive capabilities, it's a little more transformative and you're not selling efficiency, which is what these applications have always, that's been their value preposition. You're selling transformational outcomes, which is a different sort of selling motion. >> It's funny, I heard a funny quote the other day. We used to look backwards for the sample of the data. (laughs thinly) Now we're in real time with-- >> Both: All the data. >> Very different situation-- >> And forward-looking. >> And forward-looking as well, with the predictive. >> That's a great quote, yeah. >> Again, he touched on so many things. But one of the things he brought up is Tesla. He actually said he has two Teslas, or he has a second Tesla. And there was question and answer afterwards really about the Tesla, not as the technology platform. And he poked fun at Germans. He said Germans have problems with simplicity. He referenced, I presume, a Mercedes or a Porsche, you know, the perfectly ergonomically placed buttons and switches. He goes, "You sit in a Tesla "and it just all comes up on the touch screen. "And if you want to do an update overnight, "they update your software, "and now you have the newer version of the car," versus the Mercedes, where it takes 'em three years to redesign the buttons and switches. I thought that was interesting. Then one of the Q&A people said, "But what about the buying experience? "If you (mumbles) ever bought a Tesla, "it's a very different experience "than buying a car." How does that really apply to selling software? It was pretty interesting. He said we're not there yet. But he has clearly grasped on, it's a new world and it's a new way to interact with the customers, kind of like his no manuals comment, that Tesla is defining a new way to buy a car, experience a car, upgrade a car. >> Operate it. >> At the same time, he got the crazy mode, fanatical mode, like, ludicrous mode, so that he could stop and tell the Porsche guys that you're falling behind further every single day. So I thought, really interesting, bringing that kind of consumer play and kind of a cutting edge automotive example into what was historically pretty stodgy enterprise software space. >> You know, it's funny, I listened when you're saying that. That was almost like the day one objective from SalesForce, which was, we want an enterprise app like Sebol, but we want an eBay-like, or Yahoo-like experience. And that did change the experience for buying it and for operating it. I think that was almost 20 years ago, where that was Marc Benioff's objective and he's saying it's easier to do that for CRM, but it's now time to bring that to ERP. >> The other thing he brought in which I was happy, being a Bay Area resident, is the Sharks. Because he's a part owner of San Josey Sharks, obviously it's SAP Center now, also known as the Shark Tank. It used to be owned by another technology company. But he made just a funny thing. "I like hockey, so I should like SAP," and he was talking about the analysis of how often the logos come up on the telecast et cetera. But the thing that struck me is, he said the analysis is actually now faster than the game. Pretty interesting way to think about this data in flow, in that the analysis coming out of the game that feeds Vegas, it feeds all these stat lines, it feeds fantasy, it feeds all this stuff, it feeds the advertising purchase and the ROI on my logo, is it in the corner, is it on the ice, is it in the middle, is actually moving faster than the hockey game. And hockey is a pretty fast game. Very different world in which we live, even on the mar-tech side. >> That was an example of one of the machine learning-type apps, because I think in their case, they were using, I think, Google image recognition technology to parse out essentially all the logos and see what type of impact your brand made relative to your purchase. >> I mean, I could go on and on. I've so many notes. Again, I live tweeted a lot of it, you know, he's just such a humble guy. He's a smart guy. He comes at it with a technology background, but he said we're a little bit slower than we'd like, he talked about some things taking longer than he thought they would. But he also now sees around the corner, that we are very quickly going to be in this age of infinite compute, and we are already in an age of, no one's reading manuals. Just seemed very kind of customer-centric, we're no longer the super-smart Germans that, "We'll do it our way or the highway, "and you will adapt your process to us," but really customer-centric point of view, design thinking, talked about sharing their roadmap as far out in advance as possible. I think he specifically, when he got questioned on design thinking, he's, like, "You know, the studies show that a collaborative effort "yields better results. "It's no longer, 'We're the smartest guy in the room "'and we're going to do it this way "'and you're going to adapt.'" So really progressive. >> And he talked about, with Concur, he said their UI is so easy that you really don't need a manual. In fact, if you do, you failed. And I think what he's trying to say is, we're going to take that iterative prototyping capability agile development and extend it to the rest of the ERP family. With their Fiori UI and the tools that build those screens that it'll make that possible. >> You've handled CAP. We don't spend enough investment on design in UI, 'cause it is such an important piece of the puzzle. But George, we're running out of time here. I want to give you the last word. You've been paying attention to SAP for a very long time. Hasso's terrific, but then Hasso gets off the stage and he said, "I don't run the company any more. "I only make recommendations." As you look at SAP, and Bill McDermott was yesterday, are they changing? Are they just stuck in an innovator's dilemma because they just make so much money on their historical business? Or are they really changing? What's your take as they develop, where they are now, and what do you see going forward for SAP? >> Well it's a really good question. I would say, I look at the value of the business processes that they are either augmenting or automating. I hesitate to say automate because, as he said, you still want the pilot in the cockpit. >> Jeff: In proximity to take control. >> Right. And he was, like, "Look, when we do the invoice matching, "it's not like we're going to get 100% right. "We're going to get it," I think he was saying, like, in the labs right now it's, like, 94% right. So we're going to make you more productive, we're not going to eliminate that job. But when you're doing invoice matching, that's not a super high value business process. If you're doing something where you're predicting churn and making a next best offer to a customer, that's a higher value process. Or if you have a multi-touchpoint commerce solution where you can track the customer, whether it's mobile, whether he's coming via chat, whether he's in the store, and you're able to see his history or her history and what's most appropriate given their context at any one moment, that's higher value. And then it's super high value to be able to take that back upstream towards, "Okay, here's where the inventory is. "I have some in this store. "I can't fulfill that clothing item directly from the store, "but I can fulfill it from this one," or, "I have it in another warehouse," when you have that level of awareness and integration, that's high value. >> Yeah, but I want to push back a little bit on you, George, 'cause I do think the invoice ma-, if he can automatically match 94% of the invoices, that is tremendous value. I just think it's so creative when you apply this machine learning to tasks that feel relatively mundane. But if you're speeding your cash flow along, if you get 94% of your invoices done one day faster and you're a multimillion dollar business, what is the direct dollar impact on the bottom line, like, immediately? It's huge. And then you can iterate and move into other processes. I think what's termed a low value transaction is actually a lot higher value than people give it credit. It's just like again, another one we hear about all the time, automation of password reset. Some of these service desks, password reset, I heard a stat, and one of them was 70% of the calls are password reset. So if you could automate password reset, sounds kind of silly and mundane, oh my gosh, it's like 70% of your calls. It's humongous. >> I hear what you're saying. Let me give you another counter example, which was, I think he brought this up. I don't know if it was today or when Michael Dell spoke, which was that Dell's revolution wasn't that they were more efficient than doing what Compaq did. It's that they had a different business model, which was specifically, they got paid before they even procured or assembled the components. >> Or paid for them, right? >> George: Yes, yes. >> They had no inventory carry costs. >> In fact, that meant their working capital, their working capital needs were negative. In fact, the bigger they got, the more money they collected before they had to spend it. That's a different business model. That wasn't automating the invoice matching. That was, we have such good systems that we don't even have to pay for them and then assemble the stuff until after the customer gave us their credit card. >> Right, right, right. >> I think those are the things that new types of applications can make possible. >> Right. Well, we see it time and time again. It's all about scale, it's all about finding inefficiencies, and there's a lot more inefficiencies around than people give credit, as Uber showed with a lot of cars that sit in driveways and Amazon and the public clouds are showing with a lot of inefficient, not used utilization and private data centers. So the themes go on and on, and they're pretty universal. So, exciting keynote. Any last comment before we sign off for today? >> I guess we want to take a close look at Oracle next and see how their roadmap looks like in terms of applying these new technologies, iOT, machine learning, block chain. Because all of these can remake how you build a business. >> All right, that's George Gilbert from Wikibon. I'm Jeff Frick from the CUBE. We are covering ongoing coverage of SAP SAPPHIRE 2017. Thanks for watching, we'll be back with more after this short break. Thanks. (lively music)

>> Announcer: Please welcome Vice President of Worldwide Marketing, Amazon Web Services, Ariel Kelman. (applause) (techno music) >> Good afternoon, everyone. Thank you for coming. I hope you guys are having a great day here. It is my pleasure to introduce to come up on stage here, the CEO of Amazon Web Services, Andy Jassy. (applause) (techno music) >> Okay. Let's get started. I have a bunch of questions here for you, Andy. >> Just like one of our meetings, Ariel. >> Just like one of our meetings. So, I thought I'd start with a little bit of a state of the state on AWS. Can you give us your quick take? >> Yeah, well, first of all, thank you, everyone, for being here. We really appreciate it. We know how busy you guys are. So, hope you're having a good day. You know, the business is growing really quickly. In the last financials, we released, in Q four of '16, AWS is a 14 billion dollar revenue run rate business, growing 47% year over year. We have millions of active customers, and we consider an active customer as a non-Amazon entity that's used the platform in the last 30 days. And it's really a very broad, diverse customer set, in every imaginable size of customer and every imaginable vertical business segment. And I won't repeat all the customers that I know Werner went through earlier in the keynote, but here are just some of the more recent ones that you've seen, you know NELL is moving their their digital and their connected devices, meters, real estate to AWS. McDonalds is re-inventing their digital platform on top of AWS. FINRA is moving all in to AWS, yeah. You see at Reinvent, Workday announced AWS was its preferred cloud provider, and to start building on top of AWS further. Today, in press releases, you saw both Dunkin Donuts and Here, the geo-spatial map company announced they'd chosen AWS as their provider. You know and then I think if you look at our business, we have a really large non-US or global customer base and business that continues to expand very dramatically. And we're also aggressively increasing the number of geographic regions in which we have infrastructure. So last year in 2016, on top of the broad footprint we had, we added Korea, India, and Canada, and the UK. We've announced that we have regions coming, another one in China, in Ningxia, as well as in France, as well as in Sweden. So we're not close to being done expanding geographically. And then of course, we continue to iterate and innovate really quickly on behalf of all of you, of our customers. I mean, just last year alone, we launched what we considered over 1,000 significant services and features. So on average, our customers wake up every day and have three new capabilities they can choose to use or not use, but at their disposal. You've seen it already this year, if you look at Chime, which is our new unified communication service. It makes meetings much easier to conduct, be productive with. You saw Connect, which is our new global call center routing service. If you look even today, you look at Redshift Spectrum, which makes it easy to query all your data, not just locally on disk in your data warehouse but across all of S3, or DAX, which puts a cash in front of DynamoDB, we use the same interface, or all the new features in our machine learning services. We're not close to being done delivering and iterating on your behalf. And I think if you look at that collection of things, it's part of why, as Gartner looks out at the infrastructure space, they estimate the AWS is several times the size business of the next 14 providers combined. It's a pretty significant market segment leadership position. >> You talked a lot about adopts in there, a lot of customers moving to AWS, migrating large numbers of workloads, some going all in on AWS. And with that as kind of backdrop, do you still see a role for hybrid as being something that's important for customers? >> Yeah, it's funny. The quick answer is yes. I think the, you know, if you think about a few years ago, a lot of the rage was this debate about private cloud versus what people call public cloud. And we don't really see that debate very often anymore. I think relatively few companies have had success with private clouds, and most are pretty substantially moving in the direction of building on top of clouds like AWS. But, while you increasingly see more and more companies every month announcing that they're going all in to the cloud, we will see most enterprises operate in some form of hybrid mode for the next number of years. And I think in the early days of AWS and the cloud, I think people got confused about this, where they thought that they had to make this binary decision to either be all in on the public cloud and AWS or not at all. And of course that's not the case. It's not a binary decision. And what we know many of our enterprise customers want is they want to be able to run the data centers that they're not ready to retire yet as seamlessly as they can alongside of AWS. And it's why we've built a lot of the capabilities we've built the last several years. These are things like PPC, which is our virtual private cloud, which allows you to cordon off a portion of our network, deploy resources into it and connect to it through VPN or Direct Connect, which is a private connection between your data centers and our regions or our storage gateway, which is a virtual storage appliance, or Identity Federation, or a whole bunch of capabilities like that. But what we've seen, even though the vast majority of the big hybrid implementations today are built on top of AWS, as more and more of the mainstream enterprises are now at the point where they're really building substantial cloud adoption plans, they've come back to us and they've said, well, you know, actually you guys have made us make kind of a binary decision. And that's because the vast majority of the world is virtualized on top of VMWare. And because VMWare and AWS, prior to a few months ago, had really done nothing to try and make it easy to use the VMWare tools that people have been using for many years seamlessly with AWS, customers were having to make a binary choice. Either they stick with the VMWare tools they've used for a while but have a really tough time integrating with AWS, or they move to AWS and they have to leave behind the VMWare tools they've been using. And it really was the impetus for VMWare and AWS to have a number of deep conversations about it, which led to the announcement we made late last fall of VMWare and AWS, which is going to allow customers who have been using the VMWare tools to manage their infrastructure for a long time to seamlessly be able to run those on top of AWS. And they get to do so as they move workloads back and forth and they evolve their hybrid implementation without having to buy any new hardware, which is a big deal for companies. Very few companies are looking to find ways to buy more hardware these days. And customers have been very excited about this prospect. We've announced that it's going to be ready in the middle of this year. You see companies like Amadeus and Merck and Western Digital and the state of Louisiana, a number of others, we've a very large, private beta and preview happening right now. And people are pretty excited about that prospect. So we will allow customers to run in the mode that they want to run, and I think you'll see a huge transition over the next five to 10 years. >> So in addition to hybrid, another question we get a lot from enterprises around the concept of lock-in and how they should think about their relationship with the vendor and how they should think about whether to spread the workloads across multiple infrastructure providers. How do you think about that? >> Well, it's a question we get a lot. And Oracle has sure made people care about that issue. You know, I think people are very sensitive about being locked in, given the experience that they've had over the last 10 to 15 years. And I think the reality is when you look at the cloud, it really is nothing like being locked into something like Oracle. The APIs look pretty similar between the various providers. We build an open standard, it's like Linux and MySQL and Postgres. All the migration tools that we build allow you to migrate in or out of AWS. It's up to customers based on how they want to run their workload. So it is much easier to move away from something like the cloud than it is from some of the old software services that has created some of this phobia. But I think when you look at most CIOs, enterprise CIOs particularly, as they think about moving to the cloud, many of them started off thinking that they, you know, very well might split their workloads across multiple cloud providers. And I think when push comes to shove, very few decide to do so. Most predominately pick an infrastructure provider to run their workloads. And the reason that they don't split it across, you know, pretty evenly across clouds is a few reasons. Number one, if you do so, you have to standardize in the lowest common denominator. And these platforms are in radically different stages at this point. And if you look at something like AWS, it has a lot more functionality than anybody else by a large margin. And we're also iterating more quickly than you'll find from the other providers. And most folks don't want to tie the hands of their developers behind their backs in the name of having the ability of splitting it across multiple clouds, cause they actually are, in most of their spaces, competitive, and they have a lot of ideas that they want to actually build and invent on behalf of their customers. So, you know, they don't want to actually limit their functionality. It turns out the second reason is that they don't want to force their development teams to have to learn multiple platforms. And most development teams, if any of you have managed multiple stacks across different technologies, and many of us have had that experience, it's a pain in the butt. And trying to make a shift from what you've been doing for the last 30 years on premises to the cloud is hard enough. But then forcing teams to have to get good at running across two or three platforms is something most teams don't relish, and it's wasteful of people's time, it's wasteful of natural resources. That's the second thing. And then the third reason is that you effectively diminish your buying power because all of these cloud providers have volume discounts, and then you're splitting what you buy across multiple providers, which gives you a lower amount you buy from everybody at a worse price. So when most CIOs and enterprises look at this carefully, they don't actually end up splitting it relatively evenly. They predominately pick a cloud provider. Some will just pick one. Others will pick one and then do a little bit with a second, just so they know they can run with a second provider, in case that relationship with the one they choose to predominately run with goes sideways in some fashion. But when you really look at it, CIOs are not making that decision to split it up relatively evenly because it makes their development teams much less capable and much less agile. >> Okay, let's shift gears a little bit, talk about a subject that's on the minds of not just enterprises but startups and government organizations and pretty much every organization we talk to. And that's AI and machine learning. Reinvent, we introduced our Amazon AI services and just this morning Werner announced the general availability of Amazon Lex. So where are we overall on machine learning? >> Well it's a hugely exciting opportunity for customers, and I think, we believe it's exciting for us as well. And it's still in the relatively early stages, if you look at how people are using it, but it's something that we passionately believe is going to make a huge difference in the world and a huge difference with customers, and that we're investing a pretty gigantic amount of resource and capability for our customers. And I think the way that we think about, at a high level, the machine learning and deep learning spaces are, you know, there's kind of three macro layers of the stack. I think at that bottom layer, it's generally for the expert machine learning practitioners, of which there are relatively few in the world. It's a scarce resource relative to what I think will be the case in five, 10 years from now. And these are folks who are comfortable working with deep learning engines, know how to build models, know how to tune those models, know how to do inference, know how to get that data from the models into production apps. And for that group of people, if you look at the vast majority of machine learning and deep learning that's being done in the cloud today, it's being done on top of AWS, are P2 instances, which are optimized for deep learning and our deep learning AMIs, that package, effectively the deep learning engines and libraries inside those AMIs. And you see companies like Netflix, Nvidia, and Pinterest and Stanford and a whole bunch of others that are doing significant amounts of machine learning on top of those optimized instances for machine learning and the deep learning AMIs. And I think that you can expect, over time, that we'll continue to build additional capabilities and tools for those expert practitioners. I think we will support and do support every single one of the deep learning engines on top of AWS, and we have a significant amount of those workloads with all those engines running on top of AWS today. We also are making, I would say, a disproportionate investment of our own resources and the MXNet community just because if you look at running deep learning models once you get beyond a few GPUs, it's pretty difficult to have those scale as you get into the hundreds of GPUs. And most of the deep learning engines don't scale very well horizontally. And so what we've found through a lot of extensive testing, cause remember, Amazon has thousands of deep learning experts inside the company that have built very sophisticated deep learning capabilities, like the ones you see in Alexa, we have found that MXNet scales the best and almost linearly, as we continue to add nodes, as we continue to horizontally scale. So we have a lot of investment at that bottom layer of the stack. Now, if you think about most companies with developers, it's still largely inaccessible to them to do the type of machine learning and deep learning that they'd really like to do. And that's because the tools, I think, are still too primitive. And there's a number of services out there, we built one ourselves in Amazon Machine Learning that we have a lot of customers use, and yet I would argue that all of those services, including our own, are still more difficult than they should be for everyday developers to be able to build machine learning and access machine learning and deep learning. And if you look at the history of what AWS has done, in every part of our business, and a lot of what's driven us, is trying to democratize technologies that were really only available and accessible before to a select, small number of companies. And so we're doing a lot of work at what I would call that middle layer of the stack to get rid of a lot of the muck associated with having to do, you know, building the models, tuning the models, doing the inference, figuring how to get the data into production apps, a lot of those capabilities at that middle layer that we think are really essential to allow deep learning and machine learning to reach its full potential. And then at the top layer of the stack, we think of those as solutions. And those are things like, pass me an image and I'll tell you what that image is, or show me this face, does it match faces in this group of faces, or pass me a string of text and I'll give you an mpg file, or give me some words and what your intent is and then I'll be able to return answers that allow people to build conversational apps like the Lex technology. And we have a whole bunch of other services coming in that area, atop of Lex and Polly and Recognition, and you can imagine some of those that we've had to use in Amazon over the years that we'll continue to make available for you, our customers. So very significant level of investment at all three layers of that stack. We think it's relatively early days in the space but have a lot of passion and excitement for that. >> Okay, now for ML and AI, we're seeing customers wanting to load in tons of data, both to train the models and to actually process data once they've built their models. And then outside of ML and AI, we're seeing just as much demand to move in data for analytics and traditional workloads. So as people are looking to move more and more data to the cloud, how are we thinking about making it easier to get data in? >> It's a great question. And I think it's actually an often overlooked question because a lot of what gets attention with customers is all the really interesting services that allow you to do everything from compute and storage and database and messaging and analytics and machine learning and AI. But at the end of the day, if you have a significant amount of data already somewhere else, you have to get it into the cloud to be able to take advantage of all these capabilities that you don't have on premises. And so we have spent a disproportionate amount of focus over the last few years trying to build capabilities for our customers to make this easier. And we have a set of capabilities that really is not close to matched anywhere else, in part because we have so many customers who are asking for help in this area that it's, you know, that's really what drives what we build. So of course, you could use the good old-fashioned wire to send data over the internet. Increasingly, we find customers that are trying to move large amounts of data into S3, is using our S3 transfer acceleration service, which basically uses our points of presence, or POPs, all over the world to expedite delivery into S3. You know, a few years ago, we were talking to a number of companies that were looking to make big shifts to the cloud, and they said, well, I need to move lots of data that just isn't viable for me to move it over the wire, given the connection we can assign to it. It's why we built Snowball. And so we launched Snowball a couple years ago, which is really, it's a 50 terabyte appliance that is encrypted, the data's encrypted three different ways, and you ingest the data from your data center into Snowball, it has a Kindle connected to it, it allows you to, you know, that makes sure that you send it to the right place, and you can also track the progress of your high-speed ingestion into our data centers. And when we first launched Snowball, we launched it at Reinvent a couple years ago, I could not believe that we were going to order as many Snowballs to start with as the team wanted to order. And in fact, I reproached the team and I said, this is way too much, why don't we first see if people actually use any of these Snowballs. And so the team thankfully didn't listen very carefully to that, and they really only pared back a little bit. And then it turned out that we, almost from the get-go, had ordered 10X too few. And so this has been something that people have used in a very broad, pervasive way all over the world. And last year, at the beginning of the year, as we were asking people what else they would like us to build in Snowball, customers told us a few things that were pretty interesting to us. First, one that wasn't that surprising was they said, well, it would be great if they were bigger, you know, if instead of 50 terabytes it was more data I could store on each device. Then they said, you know, one of the problems is when I load the data onto a Snowball and send it to you, I have to still keep my local copy on premises until it's ingested, cause I can't risk losing that data. So they said it would be great if you could find a way to provide clustering, so that I don't have to keep that copy on premises. That was pretty interesting. And then they said, you know, there's some of that data that I'd actually like to be loading synchronously to S3, and then, or some things back from S3 to that data that I may want to compare against. That was interesting, having that endpoint. And then they said, well, we'd really love it if there was some compute on those Snowballs so I can do analytics on some relatively short-term signals that I want to take action on right away. Those were really the pieces of feedback that informed Snowball Edge, which is the next version of Snowball that we launched, announced at Reinvent this past November. So it has, it's a hundred-terabyte appliance, still the same level of encryption, and it has clustering so that you don't have to keep that copy of the data local. It allows you to have an endpoint to S3 to synchronously load data back and forth, and then it has a compute inside of it. And so it allows customers to use these on premises. I'll give you a good example. GE is using these for their wind turbines. And they collect all kinds of data from those turbines, but there's certain short-term signals they want to do analytics on in as close to real time as they can, and take action on those. And so they use that compute to do the analytics and then when they fill up that Snowball Edge, they detach it and send it back to AWS to do broad-scale analytics in the cloud and then just start using an additional Snowball Edge to capture that short-term data and be able to do those analytics. So Snowball Edge is, you know, we just launched it a couple months ago, again, amazed at the type of response, how many customers are starting to deploy those all over the place. I think if you have exabytes of data that you need to move, it's not so easy. An exabyte of data, if you wanted to move from on premises to AWS, would require 10,000 Snowball Edges. Those customers don't want to really manage a fleet of 10,000 Snowball Edges if they don't have to. And so, we tried to figure out how to solve that problem, and it's why we launched Snowmobile back at Reinvent in November, which effectively, it's a hundred-petabyte container on a 45-foot trailer that we will take a truck and bring out to your facility. It comes with its own power and its own network fiber that we plug in to your data center. And if you want to move an exabyte of data over a 10 gigabit per second connection, it would take you 26 years. But using 10 Snowmobiles, it would take you six months. So really different level of scale. And you'd be surprised how many companies have exabytes of data at this point that they want to move to the cloud to get all those analytics and machine learning capabilities running on top of them. Then for streaming data, as we have more and more companies that are doing real-time analytics of streaming data, we have Kinesis, where we built something called the Kinesis Firehose that makes it really simple to stream all your real-time data. We have a storage gateway for companies that want to keep certain data hot, locally, and then asynchronously be loading the rest of their data to AWS to be able to use in different formats, should they need it as backup or should they choose to make a transition. So it's a very broad set of storage capabilities. And then of course, if you've moved a lot of data into the cloud or into anything, you realize that one of the hardest parts that people often leave to the end is ETL. And so we have announced an ETL service called Glue, which we announced at Reinvent, which is going to make it much easier to move your data, be able to find your data and map your data to different locations and do ETL, which of course is hugely important as you're moving large amounts. >> So we've talked a lot about moving things to the cloud, moving applications, moving data. But let's shift gears a little bit and talk about something not on the cloud, connected devices. >> Yeah. >> Where do they fit in and how do you think about edge? >> Well, you know, I've been working on AWS since the start of AWS, and we've been in the market for a little over 11 years at this point. And we have encountered, as I'm sure all of you have, many buzzwords. And of all the buzzwords that everybody has talked about, I think I can make a pretty strong argument that the one that has delivered fastest on its promise has been IOT and connected devices. Just amazing to me how much is happening at the edge today and how fast that's changing with device manufacturers. And I think that if you look out 10 years from now, when you talk about hybrid, I think most companies, majority on premise piece of hybrid will not be servers, it will be connected devices. There are going to be billions of devices all over the place, in your home, in your office, in factories, in oil fields, in agricultural fields, on ships, in cars, in planes, everywhere. You're going to have these assets that sit at the edge that companies are going to want to be able to collect data on, do analytics on, and then take action. And if you think about it, most of these devices, by their very nature, have relatively little CPU and have relatively little disk, which makes the cloud disproportionately important for them to supplement them. It's why you see most of the big, successful IOT applications today are using AWS to supplement them. Illumina has hooked up their genome sequencing to AWS to do analytics, or you can look at Major League Baseball Statcast is an IOT application built on top of AWS, or John Deer has over 200,000 telematically enabled tractors that are collecting real-time planting conditions and information that they're doing analytics on and sending it back to farmers so they can figure out where and how to optimally plant. Tata Motors manages their truck fleet this way. Phillips has their smart lighting project. I mean, there're innumerable amounts of these IOT applications built on top of AWS where the cloud is supplementing the device's capability. But when you think about these becoming more mission-critical applications for companies, there are going to be certain functions and certain conditions by which they're not going to want to connect back to the cloud. They're not going to want to take the time for that round trip. They're not going to have connectivity in some cases to be able to make a round trip to the cloud. And what they really want is customers really want the same capabilities they have on AWS, with AWS IOT, but on the devices themselves. And if you've ever tried to develop on these embedded devices, it's not for mere mortals. It's pretty delicate and it's pretty scary and there's a lot of archaic protocols associated with it, pretty tough to do it all and to do it without taking down your application. And so what we did was we built something called Greengrass, and we announced it at Reinvent. And Greengrass is really like a software module that you can effectively have inside your device. And it allows developers to write lambda functions, it's got lambda inside of it, and it allows customers to write lambda functions, some of which they want to run in the cloud, some of which they want to run on the device itself through Greengrass. So they have a common programming model to build those functions, to take the signals they see and take the actions they want to take against that, which is really going to help, I think, across all these IOT devices to be able to be much more flexible and allow the devices and the analytics and the actions you take to be much smarter, more intelligent. It's also why we built Snowball Edge. Snowball Edge, if you think about it, is really a purpose-built Greengrass device. We have Greengrass, it's inside of the Snowball Edge, and you know, the GE wind turbine example is a good example of that. And so it's to us, I think it's the future of what the on-premises piece of hybrid's going to be. I think there're going to be billions of devices all over the place and people are going to want to interact with them with a common programming model like they use in AWS and the cloud, and we're continuing to invest very significantly to make that easier and easier for companies. >> We've talked about several feature directions. We talked about AI, machine learning, the edge. What are some of the other areas of investment that this group should care about? >> Well there's a lot. (laughs) That's not a suit question, Ariel. But there's a lot. I think, I'll name a few. I think first of all, as I alluded to earlier, we are not close to being done expanding geographically. I think virtually every tier-one country will have an AWS region over time. I think many of the emerging countries will as well. I think the database space is an area that is radically changing. It's happening at a faster pace than I think people sometimes realize. And I think it's good news for all of you. I think the database space over the last few decades has been a lonely place for customers. I think that they have felt particularly locked into companies that are expensive and proprietary and have high degrees of lock-in and aren't so customer-friendly. And I think customers are sick of it. And we have a relational database service that we launched many years ago and has many flavors that you can run. You can run MySQL, you can run Postgres, you can run MariaDB, you can run SQLServer, you can run Oracle. And what a lot of our customers kept saying to us was, could you please figure out a way to have a database capability that has the performance characteristics of the commercial-grade databases but the customer-friendly and pricing model of the more open engines like the MySQL and Postgres and MariaDB. What you do on your own, we do a lot of it at Amazon, but it's hard, I mean, it takes a lot of work and a lot of tuning. And our customers really wanted us to solve that problem for them. And it's why we spent several years building Aurora, which is our own database engine that we built, but that's fully compatible with MySQL and with Postgres. It's at least as fault tolerant and durable and performant as the commercial-grade databases, but it's a tenth of the cost of those. And it's also nice because if it turns out that you use Aurora and you decide for whatever reason you don't want to use Aurora anymore, because it's fully compatible with MySQL and Postgres, you just dump it to the community versions of those, and off you are. So there's really hardly any transition there. So that is the fastest-growing service in the history of AWS. I'm amazed at how quickly it's grown. I think you may have heard earlier, we've had 23,000 database migrations just in the last year or so. There's a lot of pent-up demand to have database freedom. And we're here to help you have it. You know, I think on the analytic side, it's just never been easier and less expensive to collect, store, analyze, and share data than it is today. Part of that has to do with the economics of the cloud. But a lot of it has to do with the really broad analytics capability that we provide you. And it's a much broader capability than you'll find elsewhere. And you know, you can manage Hadoop and Spark and Presto and Hive and Pig and Yarn on top of AWS, or we have a managed elastic search service, and you know, of course we have a very high scale, very high performing data warehouse in Redshift, that just got even more performant with Spectrum, which now can query across all of your S3 data, and of course you have Athena, where you can query S3 directly. We have a service that allows you to do real-time analytics of streaming data in Kinesis. We have a business intelligence service in QuickSight. We have a number of machine learning capabilities I talked about earlier. It's a very broad array. And what we find is that it's a new day in analytics for companies. A lot of the data that companies felt like they had to throw away before, either because it was too expensive to hold or they didn't really have the tools accessible to them to get the learning from that data, it's a totally different day today. And so we have a pretty big investment in that space, I mentioned Glue earlier to do ETL on all that data. We have a lot more coming in that space. I think compute, super interesting, you know, I think you will find, I think we will find that companies will use full instances for many, many years and we have, you know, more than double the number of instances than you'll find elsewhere in every imaginable shape and size. But I would also say that the trend we see is that more and more companies are using smaller units of compute, and it's why you see containers becoming so popular. We have a really big business in ECS. And we will continue to build out the capability there. We have companies really running virtually every type of container and orchestration and management service on top of AWS at this point. And then of course, a couple years ago, we pioneered the event-driven serverless capability in compute that we call Lambda, which I'm just again, blown away by how many customers are using that for everything, in every way. So I think the basic unit of compute is continuing to get smaller. I think that's really good for customers. I think the ability to be serverless is a very exciting proposition that we're continuing to to fulfill that vision that we laid out a couple years ago. And then, probably, the last thing I'd point out right now is, I think it's really interesting to see how the basic procurement of software is changing. In significant part driven by what we've been doing with our Marketplace. If you think about it, in the old world, if you were a company that was buying software, you'd have to go find bunch of the companies that you should consider, you'd have to have a lot of conversations, you'd have to talk to a lot of salespeople. Those companies, by the way, have to have a big sales team, an expensive marketing budget to go find those companies and then go sell those companies and then both companies engage in this long tap-dance around doing an agreement and the legal terms and the legal teams and it's just, the process is very arduous. Then after you buy it, you have to figure out how you're going to actually package it, how you're deploy to infrastructure and get it done, and it's just, I think in general, both consumers of software and sellers of software really don't like the process that's existed over the last few decades. And then you look at AWS Marketplace, and we have 35 hundred product listings in there from 12 hundred technology providers. If you look at the number of hours, that software that's been running EC2 just in the last month alone, it's several hundred million hours, EC2 hours, of that software being run on top of our Marketplace. And it's just completely changing how software is bought and procured. I think that if you talk to a lot of the big sellers of software, like Splunk or Trend Micro, there's a whole number of them, they'll tell you it totally changes their ability to be able to sell. You know, one of the things that really helped AWS in the early days and still continues to help us, is that we have a self-service model where we don't actually have to have a lot of people talk to every customer to get started. I think if you're a seller of software, that's very appealing, to allow people to find your software and be able to buy it. And if you're a consumer, to be able to buy it quickly, again, without the hassle of all those conversations and the overhead associated with that, very appealing. And I think it's why the marketplace has just exploded and taken off like it has. It's also really good, by the way, for systems integrators, who are often packaging things on top of that software to their clients. This makes it much easier to build kind of smaller catalogs of software products for their customers. I think when you layer on top of that the capabilities that we've announced to make it easier for SASS providers to meter and to do billing and to do identity is just, it's a very different world. And so I think that also is very exciting, both for companies and customers as well as software providers. >> We certainly touched on a lot here. And we have a lot going on, and you know, while we have customers asking us a lot about how they can use all these new services and new features, we also tend to get a lot of questions from customers on how we innovate so quickly, and they can think about applying some of those lessons learned to their own businesses. >> So you're asking how we're able to innovate quickly? >> Mmm hmm. >> I think there's a few things that have helped us, and it's different for every company. But some of these might be helpful. I'll point to a few. I think the first thing is, I think we disproportionately index on hiring builders. And we think of builders as people who are inventors, people who look at different customer experiences really critically, are honest about what's flawed about them, and then seek to reinvent them. And then people who understand that launch is the starting line and not the finish line. There's very little that any of us ever built that's a home run right out of the gate. And so most things that succeed take a lot of listening to customers and a lot of experimentation and a lot of iterating before you get to an equation that really works. So the first thing is who we hire. I think the second thing is how we organize. And we have, at Amazon, long tried to organize into as small and separable and autonomous teams as we can, that have all the resources in those teams to own their own destiny. And so for instance, the technologists and the product managers are part of the same team. And a lot of that is because we don't want the finger pointing that goes back and forth between the teams, and if they're on the same team, they focus all their energy on owning it together and understanding what customers need from them, spending a disproportionate amount of time with customers, and then they get to own their own roadmaps. One of the reasons we don't publish a 12 to 18 month roadmap is we want those teams to have the freedom, in talking to customers and listening to what you tell us matters, to re-prioritize if there are certain things that we assumed mattered more than it turns out it does. So, you know I think that the way that we organize is the second piece. I think a third piece is all of our teams get to use the same AWS building blocks that all of you get to use, which allow you to move much more quickly. And I think one of the least told stories about Amazon over the last five years, in part because people have gotten interested in AWS, is people have missed how fast our consumer business at Amazon has iterated. Look at the amount of invention in Amazon's consumer business. And they'll tell you that a big piece of that is their ability to use the AWS building blocks like they do. I think a fourth thing is many big companies, as they get larger, what starts to happen is what people call the institutional no, which is that leaders walk into meetings on new ideas looking to find ways to say no, and not because they're ill intended but just because they get more conservative or they have a lot on their plate or things are really managed very centrally, so it's hard to imagine adding more to what you're already doing. At Amazon, it's really the opposite, and in part because of the way we're organized in such a decoupled, decentralized fashion, and in part because it's just part of our DNA. When the leaders walk into a meeting, they are looking for ways to say yes. And we don't say yes to everything, we have a lot of proposals. But we say yes to a lot more than I think virtually any other company on the planet. And when we're having conversations with builders who are proposing new ideas, we're in a mode where we're trying to problem-solve with them to get to yes, which I think is really different. And then I think the last thing is that we have mechanisms inside the company that allow us to make fast decisions. And if you want a little bit more detail, you should read our founder and CEO Jeff Bezos's shareholder letter, which just was released. He talks about the fast decision-making that happens inside the company. It's really true. We make fast decisions and we're willing to fail. And you know, we sometimes talk about how we're working on several of our next biggest failures, and we hope that most of the things we're doing aren't going to fail, but we know, if you're going to push the envelope and if you're going to experiment at the rate that we're trying to experiment, to find more pillars that allow us to do more for customers and allow us to be more relevant, you are going to fail sometimes. And you have to accept that, and you have to have a way of evaluating people that recognizes the inputs, meaning the things that they actually delivered as opposed to the outputs, cause on new ventures, you don't know what the outputs are going to be, you don't know consumers or customers are going to respond to the new thing you're trying to build. So you have to be able to reward employees on the inputs, you have to have a way for them to continue to progress and grow in their career even if they work on something didn't work. And you have to have a way of thinking about, when things don't work, how do I take the technology that I built as part of that, that really actually does work, but I didn't get it right in the form factor, and use it for other things. And I think that when you think about a culture like Amazon, that disproportionately hires builders, organizes into these separable, autonomous teams, and allows them to use building blocks to move fast, and has a leadership team that's looking to say yes to ideas and is willing to fail, you end up finding not only do you do more inventing but you get the people at every level of the organization spending their free cycles thinking about new ideas because it actually pays to think of new ideas cause you get a shot to try it. And so that has really helped us and I think most of our customers who have made significant shifts to AWS and the cloud would argue that that's one of the big transformational things they've seen in their companies as well. >> Okay. I want to go a little bit deeper on the subject of culture. What are some of the things that are most unique about the AWS culture that companies should know about when they're looking to partner with us? >> Well, I think if you're making a decision on a predominant infrastructure provider, it's really important that you decide that the culture of the company you're going to partner with is a fit for yours. And you know, it's a super important decision that you don't want to have to redo multiple times cause it's wasted effort. And I think that, look, I've been at Amazon for almost 20 years at this point, so I have obviously drank the Kool Aid. But there are a few things that I think are truly unique about Amazon's culture. I'll talk about three of them. The first is I think that we are unusually customer-oriented. And I think a lot of companies talk about being customer-oriented, but few actually are. I think most of the big technology companies truthfully are competitor-focused. They kind of look at what competitors are doing and then they try to one-up one another. You have one or two of them that I would say are product-focused, where they say, hey, it's great, you Mr. and Mrs. Customer have ideas on a product, but leave that to the experts, and you know, you'll like the products we're going to build. And those strategies can be good ones and successful ones, they're just not ours. We are driven by what customers tell us matters to them. We don't build technology for technology's sake, we don't become, you know, smitten by any one technology. We're trying to solve real problems for our customers. 90% of what we build is driven by what you tell us matters. And the other 10% is listening to you, and even if you can't articulate exactly what you want, trying to read between the lines and invent on your behalf. So that's the first thing. Second thing is that we are pioneers. We really like to invent, as I was talking about earlier. And I think most big technology companies at this point have either lost their will or their DNA to invent. Most of them acquire it or fast follow. And again, that can be a successful strategy. It's just not ours. I think in this day and age, where we're going through as big a shift as we are in the cloud, which is the biggest technology shift in our lifetime, as dynamic as it is, being able to partner with a company that has the most functionality, it's iterating the fastest, has the most customers, has the largest ecosystem of partners, has SIs and ISPs, that has had a vision for how all these pieces fit together from the start, instead of trying to patch them together in a following act, you have a big advantage. I think that the third thing is that we're unusually long-term oriented. And I think that you won't ever see us show up at your door the last day of a quarter, the last day of a year, trying to harass you into doing some kind of deal with us, not to be heard from again for a couple years when we either audit you or try to re-up you for a deal. That's just not the way that we will ever operate. We are trying to build a business, a set of relationships, that will outlast all of us here. And I think something that always ties it together well is this trusted advisor capability that we have inside our support function, which is, you know, we look at dozens of programmatic ways that our customers are using the platform and reach out to you if you're doing something we think's suboptimal. And one of the things we do is if you're not fully utilizing resources, or hardly, or not using them at all, we'll reach out and say, hey, you should stop paying for this. And over the last couple of years, we've sent out a couple million of these notifications that have led to actual annualized savings for customers of 350 million dollars. So I ask you, how many of your technology partners reach out to you and say stop spending money with us? To the tune of 350 million dollars lost revenue per year. Not too many. And I think when we first started doing it, people though it was gimmicky, but if you understand what I just talked about with regard to our culture, it makes perfect sense. We don't want to make money from customers unless you're getting value. We want to reinvent an experience that we think has been broken for the prior few decades. And then we're trying to build a relationship with you that outlasts all of us, and we think the best way to do that is to provide value and do right by customers over a long period of time. >> Okay, keeping going on the culture subject, what about some of the quirky things about Amazon's culture that people might find interesting or useful? >> Well there are a lot of quirky parts to our culture. And I think any, you know lots of companies who have strong culture will argue they have quirky pieces but I think there's a few I might point to. You know, I think the first would be the first several years I was with the company, I guess the first six years or so I was at the company, like most companies, all the information that was presented was via PowerPoint. And we would find that it was a very inefficient way to consume information. You know, you were often shaded by the charisma of the presenter, sometimes you would overweight what the presenters said based on whether they were a good presenter. And vice versa. You would very rarely have a deep conversation, cause you have no room on PowerPoint slides to have any depth. You would interrupt the presenter constantly with questions that they hadn't really thought through cause they didn't think they were going to have to present that level of depth. You constantly have the, you know, you'd ask the question, oh, I'm going to get to that in five slides, you want to do that now or you want to do that in five slides, you know, it was just maddening. And we would often find that most of the meetings required multiple meetings. And so we made a decision as a company to effectively ban PowerPoints as a communication vehicle inside the company. Really the only time I do PowerPoints is at Reinvent. And maybe that shows. And what we found is that it's a much more substantive and effective and time-efficient way to have conversations because there is no way to fake depth in a six-page narrative. So what we went to from PowerPoint was six-page narrative. You can write, have as much as you want in the appendix, but you have to assume nobody will read the appendices. Everything you have to communicate has to be done in six pages. You can't fake depth in a six-page narrative. And so what we do is we all get to the room, we spend 20 minutes or so reading the document so it's fresh in everybody's head. And then where we start the conversation is a radically different spot than when you're hearing a presentation one kind of shallow slide at a time. We all start the conversation with a fair bit of depth on the topic, and we can really hone in on the three or four issues that typically matter in each of these conversations. So we get to the heart of the matter and we can have one meeting on the topic instead of three or four. So that has been really, I mean it's unusual and it takes some time getting used to but it is a much more effective way to pay attention to the detail and have a substantive conversation. You know, I think a second thing, if you look at our working backwards process, we don't write a lot of code for any of our services until we write and refine and decide we have crisp press release and frequently asked question, or FAQ, for that product. And in the press release, what we're trying to do is make sure that we're building a product that has benefits that will really matter. How many times have we all gotten to the end of products and by the time we get there, we kind of think about what we're launching and think, this is not that interesting. Like, people are not going to find this that compelling. And it's because you just haven't thought through and argued and debated and made sure that you drew the line in the right spot on a set of benefits that will really matter to customers. So that's why we use the press release. The FAQ is to really have the arguments up front about how you're building the product. So what technology are you using? What's the architecture? What's the customer experience? What's the UI look like? What's the pricing dimensions? Are you going to charge for it or not? All of those decisions, what are people going to be most excited about, what are people going to be most disappointed by. All those conversations, if you have them up front, even if it takes you a few times to go through it, you can just let the teams build, and you don't have to check in with them except on the dates. And so we find that if we take the time up front we not only get the products right more often but the teams also deliver much more quickly and with much less churn. And then the third thing I'd say that's kind of quirky is it is an unusually truth-seeking culture at Amazon. I think we have a leadership principle that we say have backbone, disagree, and commit. And what it means is that we really expect people to speak up if they believe that we're headed down a path that's wrong for customers, no matter who is advancing it, what level in the company, everybody is empowered and expected to speak up. And then once we have the debate, then we all have to pull the same way, even if it's a different way than you were advocating. And I think, you always hear the old adage of where, two people look at a ceiling and one person says it's 14 feet and the other person says, it's 10 feet, and they say, okay let's compromise, it's 12 feet. And of course, it's not 12 feet, there is an answer. And not all things that we all consider has that black and white answer, but most things have an answer that really is more right if you actually assess it and debate it. And so we have an environment that really empowers people to challenge one another and I think it's part of why we end up getting to better answers, cause we have that level of openness and rigor. >> Okay, well Andy, we have time for one more question. >> Okay. >> So other than some of the things you've talked about, like customer focus, innovation, and long-term orientation, what is the single most important lesson that you've learned that is really relevant to this audience and this time we're living in? >> There's a lot. But I'll pick one. I would say I'll tell a short story that I think captures it. In the early days at Amazon, our sole business was what we called an owned inventory retail business, which meant we bought the inventory from distributors or publishers or manufacturers, stored it in our own fulfillment centers and shipped it to customers. And around the year 1999 or 2000, this third party seller model started becoming very popular. You know, these were companies like Half.com and eBay and folks like that. And we had a really animated debate inside the company about whether we should allow third party sellers to sell on the Amazon site. And the concerns internally were, first of all, we just had this fundamental belief that other sellers weren't going to care as much about the customer experience as we did cause it was such a central part of everything we did DNA-wise. And then also we had this entire business and all this machinery that was built around owned inventory business, with all these relationships with publishers and distributors and manufacturers, who we didn't think would necessarily like third party sellers selling right alongside us having bought their products. And so we really debated this, and we ultimately decided that we were going to allow third party sellers to sell in our marketplace. And we made that decision in part because it was better for customers, it allowed them to have lower prices, so more price variety and better selection. But also in significant part because we realized you can't fight gravity. If something is going to happen, whether you want it to happen or not, it is going to happen. And you are much better off cannibalizing yourself or being ahead of whatever direction the world is headed than you are at howling at the wind or wishing it away or trying to put up blockers and find a way to delay moving to the model that is really most successful and has the most amount of benefits for the customers in question. And that turned out to be a really important lesson for Amazon as a company and for me, personally, as well. You know, in the early days of doing Marketplace, we had all kinds of folks, even after we made the decision, that despite the have backbone, disagree and commit weren't really sure that they believed that it was going to be a successful decision. And it took several months, but thankfully we really were vigilant about it, and today in roughly half of the units we sell in our retail business are third party seller units. Been really good for our customers. And really good for our business as well. And I think the same thing is really applicable to the space we're talking about today, to the cloud, as you think about this gigantic shift that's going on right now, moving to the cloud, which is, you know, I think in the early days of the cloud, the first, I'll call it six, seven, eight years, I think collectively we consumed so much energy with all these arguments about are people going to move to the cloud, what are they going to move to the cloud, will they move mission-critical applications to the cloud, will the enterprise adopt it, will public sector adopt it, what about private cloud, you know, we just consumed a huge amount of energy and it was, you can see both in the results in what's happening in businesses like ours, it was a form of fighting gravity. And today we don't really have if conversations anymore with our customers. They're all when and how and what order conversations. And I would say that this going to be a much better world for all of us, because we will be able to build in a much more cost effective fashion, we will be able to build much more quickly, we'll be able to take our scarce resource of engineers and not spend their resource on the undifferentiated heavy lifting of infrastructure and instead on what truly differentiates your business. And you'll have a global presence, so that you have lower latency and a better end user customer experience being deployed with your applications and infrastructure all over the world. And you'll be able to meet the data sovereignty requirements of various locales. So I think it's a great world that we're entering right now, I think we're at a time where there's a lot less confusion about where the world is headed, and I think it's an unprecedented opportunity for you to reinvent your businesses, reinvent your applications, and build capabilities for your customers and for your business that weren't easily possible before. And I hope you take advantage of it, and we'll be right here every step of the way to help you. Thank you very much. I appreciate it. (applause) >> Thank you, Andy. And thank you, everyone. I appreciate your time today. >> Thank you. (applause) (upbeat music)