 Good morning, everyone. So we changed the title slightly, because we wanted to add not only the database part, which we are going to explain, but also everything else that you can do in modern applications using data lakes, big data and machine learning. So in today's world, the old paradigm of just having a single database, a single system in which you would just try to add as much data as possible. It was row-based, and that was the only thing that you could do to maintain your system main friends as well. It's actually not coping with the needs of customers. We, as Amazon, ourselves, used to be based on traditional database technologies. And as we grew as a company, we started to be challenged by data volumes and by finding workloads like the e-commerce, like machine learning, big data that the traditional row-based databases didn't work for us. So we've seen from our customers that the need of the e-commerce, so for the e-commerce, the traditional databases relational don't work. We find key value and document databases much better fit. Media streaming, how to collect all the data, how to actually analyze the data and be able to get and obtain information that you can enrich with your application afterwards, social media, gaming, and all sorts of applications. And also take into account the response times. Many of the e-commerce, Amazon, or anything else, at Christmas time, they have peaks of thousands of users that actually need to connect to the same platform. And you need to scale, too. You need to be able to have a database, a system that actually allows you to connect to the platform without having an impact in performance. So those are many things that we see from customers. And depending on the pattern of behavior, depending on what the customers want to do, we might recommend one solution versus another. Rather than telling them, eat only one database and do everything with that database, we will actually segment that by the patterns. So that is also bringing us that it's not only about databases. Today, we need to take into account that there is a significant amount of data being created from those databases, and you want to analyze it. You want to do things like forecasting. You want to do things like recommendations. You want to add information coming from IoT, and so forth, from social media. And that is a challenge that you need to take into account as well when building those modern applications. The microservices. So we are a company that will help you, and that's the main thing of today, with specific solutions that will help you driving a microservice-oriented architecture and a strategy in your company. So everything we're going to talk today is a service. You don't need to maintain it at all. You need to focus on your application. Everything is an API. Everything is fully integrated, and you can actually drive more successful your microservice strategy in your company. And the DevOps. In order to be very agile, you need to have systems that allow you to be agile. If you keep doing the old things of maintaining, patching, upgrading, scaling applications on databases and systems, then you're not going to be this agile. And that's super important in every conversation we have with customers. And this is a trend why they're using specific money services from AWS. So why is that important? Because today we see that many of the things that you might be doing, if you're not using services, cloud services, money services, and you do it yourself on pure bare metal or compute capacity, is that you're going to spend more time in maintaining the system, unless time in building that application. I was in Mallorca a couple of weeks ago meeting with a company. They've been spending the last two years, for example, in building a data lake on a database, which I think is wrong. And that was because they were building everything themselves, rather than focusing on, let's build a data lake with a solution that scales. Let's build a data lake with a solution that doesn't require me to do the heavy lifting. I'm going to spend most of the time on the heavy lifting on the business value. Guess what will happen after two years of you trying to make something work? You're at risk. The project is at risk. And that's what we want to help you guys with. And we want you to actually focus more on the business use cases from the IT perspective, focus more on delivering what the business want on those applications, unless on the heavy lifting, less on managing the solution. And that's a super important paradigm that the cloud brings. If you're going to use the cloud just to do exactly the same you do on premises, don't do it. OK, OPEX, CAPEX, you're going to save some money? Yeah? But all the agilities know about having compute capacity only, which is important for certain workloads. It's about how can I improve and shorten the time to value in those applications? How can I be more agile as an IT department? How can I meet more of the business requirements with those databases, rather than creating indexes, patching the systems, and scaling the systems? So that is something that you need to think yourself. If you have any questions, you will have a booth outside to the left, and we can actually answer any questions. Because that is what I said. You can actually focus on those applications. You can actually focus on what the business requirements of the companies are. And you can actually focus on the needs of the business. And I've seen many IT departments that have passed from a call center in which they were seeing people that spend money and delay business projects to people that actually drive innovation in those companies, drive new applications, new adoption, new use cases. And that is super important for you to remember. So as I said before, you could try to fit any workloads into a single database. You could try to fit an ERP, CRM, into a transactional database. Yes, that's the right one, probably. Especially if you have something like SAP, or I call those transactional databases beneath. But then if you try to push those transactional databases role-based into analytics, then you start to struggle. You need to actually start building indexes and aggregates and many of the heavy lifting and partitions and many of the things that you don't want to do in analytics. And if you want to, for example, create a new web application, how many times have you been to an app on your mobile and you click on something and it takes forever? That's not normal. And that's probably because they're using the wrong technology. If they were using something like a key value database or document database, they would get faster performance and a better customer experience by using those applications. If you're having IoT applications that you need to actually store data, you need a stream series database. So there are many things that you will need the right to for the right job. And put yourself in the shoes of, think yourself on how you eat your food. Sometimes you need a knife, sometimes you need a fork, spoon or chopsticks. Depending on what you are eating, you need a different tool, a different instrument to do that. So you have a little kid of his two years old. He tries to eat his soup with a fork. He tries, he does, eventually, after two hours. But it's not the right tool to do the job. And that's why we're recommending that whenever you have a new workload, whenever you have a new application, you really consider what is the right solution beneath that application. And we are here to help you. We can actually make recommendations. And the beauty of this is, again, we're not asking you to install anything. We're not asking you to maintain anything because most of those services we're going to propose are either serverless already or very managed and advanced in terms of you don't need to do much in order to maintain those services. What you need to care about is your application, the value you want to bring and the business solution you want to put in the hands of your customers. So let me give you a highlight of the different solutions, different databases and different technologies that you can use in your modern application. First, relational. If you have any projects in which you want to use Oracle SQL, MariaDB, MySQL, Postgres, and so forth and so on, you can use RDS. RDS is our relational database service. It's fully managed. You don't need to manage that. We do the backups. We do the snapshots. We patch it. We can actually have standby. We do everything for you that is heavy lifting and you just need to bring your application on top of the RDS service and it will scale for you. Inside that, we have two major databases are called Aurora. Aurora for Postgres and MySQL that are giving you the performance and the scalability and the features that an Oracle or an SQL server database could have. And we have tools to migrate from Oracle SQL Server to Aurora and it's fully compatible with the open source technologies. And giving you the performance that you require to build those enterprise-ready applications on transactional databases. And it's a service. We also have key value. So remember I told you about Amazon. We were running on a database. We migrated that database to something called DynamoDB. DynamoDB was based on the Dynamo paper. I don't know if you read that paper was the first no SQL white paper that we created that was created around the world and it's based on key value. So if you have application like e-commerce, like mobile applications and so forth and you want the super fast performance database in which you don't focus on the schema. So the schema is not defined, okay? It's a schema less and you focus more on the application and what you want is super fast performance and whether you have one user, one million user connecting a single point in time and it will scale for you. That is DynamoDB, okay? So that is what is behind Amazon.com. That is what is behind Jatam. That is what is behind many applications you use today. Not only from Amazon, from many vendors. If however, you are coming from the world of a document store. By the way, Dynamo can do that as well. You can use Dynamo to store as well document in JSON or if you like how Mongo works but you prefer to use a money service from Amazon, we have a database called DocumentDB. So DocumentDB is fully compatible with MongoDB. It uses all the APIs and you can just migrate that. What we will do for you is just to make sure that we manage, scale and optimize the system for you and you spend less money in managing the database, the underlying database. If you have applications in which, especially with relational, we have seen that a lot but also in machine learning use cases. If you have applications that need millisecond response time, super fast response time, okay? We have actually a service called Elastic Cache. Elastic Cache is supporting Redis, Memcache. It's the open source technology you know but we manage the service for you. So it's fully integrated with the RDS system so you could actually say that you can do lazy caching in the Elastic Cache and you can actually use that for any transactional application. I've seen as well in my conversation with machine learning that some models require certain data for the model to be super fast because it's like a recommendation engine with many parameters in an e-commerce and I've seen that there are data scientists as well caching certain values in Elastic Cache so the data that is being sent to the model, to the inference is actually based on the data in Elastic Cache. So anything that you require acceleration of time to value in terms of response time, we've seen that in a lot of transactional systems that is Elastic Cache and we have that as a service as well. Graph databases. If however your use case is unique to understand relationships in between people or machines and you want to have a very scalable but managed graph database, we have something called Neptune. Let me give you a use case. I was talking to an IT department, they have the mainframe, they have different systems, they are afraid of touching certain computers because they know if they touch that computer they don't know the impact and the relationship of that system versus the other applications. So they are building a system based on Neptune in which they are going to actually load from the logs all the relationships, the graphical relationships of the different IT solutions and infrastructure so that if they didn't need to do a patching, if they didn't need to actually decommission a mainframe or a cluster or a server or an application they know immediately what is going to be impacted and they decide whether they want to actually do it or not and the risks because they understand the full relationship between that. Also for security of fraud, if you want to understand who is talking to who, who is actually the closer person to into that relationship and so forth, all those use cases that are more related to the nodes, the connections, the path to that person, the network, those are very well fitted to graph databases and that's why we have something called Neptune. Time series, if you are in an IoT project, most likely you would like to store the data as it is happening in data series and for that you could again try it with all the databases but why not to try it with a database that is fully defined and architected to actually store that data efficiently. We have something for that as well, time series databases. And last but not least, if you're looking to the world of blockchain, okay, anything that needs to be traceable, any application that is going to be dependent on the blockchain concept, we also have a ledger database available for you. So as you see, you could try to do everything with that guy, with the relational database. What I've seen is that most of the time in my work, I will be a very big effort to do that and that's what we want to avoid to you guys because everything is in the same platform. You just choose and pick whatever solution is better for you and the learning curve is very little and you focus on the application, you don't focus on the database. Also, once you have all that data, you probably heard or you're probably familiar with the concept because the conference today is about data, how much you're learning, the concept of the data lake. We can also help you and we'll have an schema at the end, a whiteboard to explain everything put together. We can also help you building data lakes in weeks rather than month of year. Remember the customer I was telling you before? They were building a data lake on a database and that was the wrong decision. They've been struggling for two years and they're now considering moving to our data lake. So we can help you building a data lake in weeks. We have a technology that takes the best practices, can capture the data from guys all these databases and third-party databases and on-premises databases. So we can capture that with crawlers. We can actually build a data lake which is decoupled from the application layer and will give you all your data in a data catalog. It will do the cleansing. It will give you the data catalog with all the key values. It will give you permissions and security rights. It will give you the power to actually store the data in the raw format because remember, it's decoupled. You don't need to actually put that in a Hadoop cluster, in an HDFS. That's the wrong thing if you actually build a data lake on HDFS. The right thing is to have a data lake regardless of what you are going to use on top of. Hadoop, Spark, data warehouses, machine learning, that's the right approach. So we can also help you when building those modern applications to store and capture all the data, transactional data into the data lake and then you apply what is the right tool for you to analyze the data. Whether it is analytics with Hadoop, EMR, data warehousing, streaming data, BI, or queries directly to the data lake or whether you want to actually build your first project with machine learning and we will touch on that in a second. So let me give you a few examples of customers using the three paradigms, data lake, the analytics, the machine learning. So this is Capital One. Capital One is one of the major financial institutions in the world, they are based in the US but they also have offices in Europe. They fully migrated by the way all the solutions to AWS and then one of the reasons why they migrated to AWS was of the database, analytics, and machine learning managed services. They didn't want to manage that anymore. So they migrated everything together with the security. So this application, for example, or any of the applications they are building, they're choosing the right tool for this application they're using DynamoDB, it's a mobile application. In the old days, everything was dependent of the main frame in the company. With DynamoDB, and it could have been DocumentDB, it could have been the right solution for the right job, they're actually having very good performance in terms of response time for a mobile application which is super important because we could be, and pardon what I'm going to say, lazy and try to use the same database but if the performance is not good, sometimes it gets frustrated with some mobile applications and it stops using them. And that's not what you want to do. That's not the behavior you want to drive. What you want to drive is that people stay on your application, feel comfortable with your application, actually use you more on the application. And that's why they selected DynamoDB because that was perfect. It was key value, response time was super fast and I could do that very quickly and focus more on the design of the application rather than the maintenance of the database. DynamoDB and Domino's Pizza for every channel and from every portal that they build on top of us, they have embedded in top of that, they have got the data from all the transactions you as a customer from the transactional systems and they actually build a data lake and on top of that data lake, they're using an AI service, okay? So they have embedded into the application, interaction with customers, a recommendation engine, but they didn't know how to do that recommendation engine so they use an AI service called Personalize and Personalize is based on what Amazon.com have done for many years in terms of recommendations is using O2ML. So you could actually have your application on a database like, for example, MySQL. You could capture the key values of those information insights from those customers. Run a recommendation engine using Personalize. Personalize is going to learn about your data. So the model is going to be learning about the data or better say the solution is going to learn about the data and create a model based on your data, it's O2ML. And then it will create an API. So that API is now connected to the portals and when you connect, when there is a campaign, whatever, it will actually understand who you are and make the right recommendation depending on the profile. And that's a way to actually enrich as well and to have better capabilities into applications. Another example is Expedia. Expedia is doing exactly the same, have a portal, it's running on databases, it's capturing the data. It's also storing pictures. So it's enriching with further data, the information they have about hotels and what you like. And what they do with that information about what you like and the hotels and the pictures is they run a machine learning model on AWS that actually renders the right picture for you. What is the right picture to have successful in getting the hotel? What is the best picture to make a recommendation for you? So it's not only about the database, it's also about collecting the data and it's also about how much you can enrich with third party data that before was impossible or difficult and now we're making that possible. Think about Netflix, guys. What is Netflix when you connect, doing? What is the thumb that you're getting? It's slightly different than the one that your partner or your kids are getting because they're optimizing the picture about the film depending on what you like to make you more attractive to actually click on that picture and therefore watch that film. So that is actually something that in any applications we can enrich as well with the right engines. Let me put that all together. So you want to build your model applications, okay? So you have your application layer but what are the needs? What are the things that you need? Remember we were touching different things. You might want to have an ERP. You might want to use a transactional system because there is another angle that I like to comment. It's also about you having the choices of what you want to use in a single place. So if what you want to use plus the use case is better fitted to use transactional databases which is an ERP or CRM, okay? You will go one path. However, you are starting your new e-commerce. You could try to do that with the relation database but most likely you're going to struggle that we did many years ago. That's why we moved to NoSQL for the e-commerce. You might have new applications. It could be a mobile application or it could be a social media application or security application or fraud detection application. Anything that is slightly different and the way to store the data in a transactional database is not the best suited way to actually have the best performance to scale which is very important because you're small. You want to scale eventually. You will need to take that into account and you don't want to actually do that by yourself. That's why we help you with the managed databases. And those are significant different use cases. So for the first one, we can have the others, okay? So we could put Oracle. We could put SQL Server if that's what you want to use. That's good for us as well. However, if you want to move from SQL Server or Oracle because you want an open source databases, we can also help you migrate in those doing transformation to another open source database but fully managed by us. So it could be MySQL, it could be Postgres and so forth and so on. And you can add in terms of performance, especially for shopping lists, cards and things like that in memory capabilities by using elastic cache. And that is fully integrated with the RDS service and you can use it straight away. However, you have new projects like the e-commerce and then you can choose a different database. So you can use DynamoDB for key value and documents, okay? So anything that is a mobile application, anything that is an e-commerce, anything that is super fast, key value, find the value, do that also for developers. When you have, I didn't mention that before, but when you are defining an application, you have the dependency of the DBA or the database administrator. If you have a NoSQL database, you don't need to tell the DBA how to create the schema and how to maintain the schema because it's schema less. It will write the values they happen and you will have a key value, an index that you will use as an option. It could be an ID from the customer, but everything else will value in time, will change in time. And then you can be more agile as a developer to create those applications not having dependencies on the database. Same with DocumentDB, especially if you like Mongo or if you want to migrate from Mongo to DocumentDB. Neptune, if you want to have that graph experience on how to create or understand relationships between nodes, between personas, between machines, we can use graph databases. That's good. That would end there, but we want to help you in reaching and creating those applications with more capabilities. So what we can do for you is helping you build in that data lake, which is based on S3. So, for example, Netflix has a 25 petabyte data lake on us. Okay? It's full independent, guys. We're not telling you even to use one of those databases. It wouldn't make sense to build a data lake on a database. We ask you to actually have, or we give you capability to have a full independent data lake technology. It's decoupled, so you don't need to have any compute capacity. You pay less, by the way, because of that. We have a life cycle, so we can have actually different temperature of the data, hot, warm, cold, and you will pay less. The more data you put there, the cheaper it gets. And as I said, we have crawlers. It will crawl. It will actually find and identify the values. It will actually do fuzzy matching for data cleansing. And it will help you accelerate in the time to value of a data lake. So that will give you, together with web logs, sensors from IoT, social media pictures and videos, images. It will give you a full 360 degree view of your business. That's good. I have the data. It's secure. I know what to do. But what can I do on top of that data? First, you can do analytics, okay? You could do, if you like the world of Hadoop, you can use EMR, okay? And there are many companies using EMR, Hadoop, Spark, the ecosystem of big data to run modern application, to do sophisticated analysis on top of the data lake. But the value is, guys, look at this. The data lake sits at the bottom. The analytics sit on the top. There is a full integration to have full capacity of connecting to the data, but also great performance. The moment you do your analytics on Hadoop and you are done with the job, you kill the cluster and you stop paying. So you don't need to install a full cluster to be 24-7 and pay for that. You don't need to install all the components on Hadoop because you need to, just in case, you can just spin up whatever product or service solution inside Hadoop, like Impala or Presto or Hi, whatever you want to actually launch, you will launch it with the right version. We have different versioning, so you can choose and only launch five-node, 100-node, 10-node. Do the calculation, the computation in time. Save the results and that can be used in your application or have a cluster that is smaller, just serving traffic to the application. The second option is, if you don't like the world of Hadoop and I met a customer in Germany on Monday and they don't, they are more inclined towards data warehouses, but they like the concept of a data lake. You can launch something which is another database called Redshift. Redshift scales automatically horizontally, okay? Redshift can have the very hot data of an iceberg inside the cluster on the disk, but look at this, this is very unique. You can read directly from the data lake and only pay for the queries you execute. So you could do very sophisticated analytics either on Hadoop with EMR or with the data warehouse with Redshift directly into the data lake. And you don't need to pay for a Humongous cluster with all that data in it. You only put the very hot data on the top of the iceberg. That is going to be recurrently being consumed on daily basis. And eventually, when you need that query once a week or once a month or once a quarter, it will actually query the data from the data lake and it will join the data from the hot data. Then you can serve highly sophisticated analytics, things that need to be computed very quickly like columnar databases, not transactional databases, and embed that into your application if you want, okay? Then you can do machine learning. Again, the same place where you have all your 360 degree view of your business can help you running machine learning. So we have two options and there are two strategies guys when running machine learning. One is data centric, which is you build a data lake and you have a data scientist team and then you use something called SageMaker, which is our platform for machine learning. I will describe that in a second and how it works with applications. The second one is if you have a use case that is very well-defined today and you have the set of data for that use case like a recommendation engine, but you don't have data scientist, you can use an AI service. So you didn't need to have data scientist in your team, in your company to do that, okay? So I will touch on that in a second. So SageMaker, coming back to SageMaker is working with TensorFlow. 84% of the TensorFlow workloads are on AWS. MXNet, Spark, ML. We have different algorithms that are super fast. We can guarantee that the performance when training the model from that data lake is going to be very, very efficient and the GPUs and CPUs are going to be never idle. The second one that is about service and this is the message today. Why services are so important is when you train either with Hadoop or with SageMaker, we give you a capability that is very unique in the market. It's called SPOT. SPOT means we can save you 90% of the cost of a training model because we have so much capacity. So if you take us, it's the aggregation of many of the other vendors together multiplied by several times, okay? Because we have so much capacity at a certain even point in time, you can decide to tell us, okay, Amazon, for this training, I want to do it at 11 at night when no one is consuming these GPUs and CPUs and rather than paying this amount, I want half of the price, or up to 90% of the price saving. And then that training of the model, that insight, that recommendation engine that you create, that anomaly detection, that whatever you want to do with machine learning will actually be done at a significant, slightly smaller amount of money. And it does not trivial, guys, because many of the analytics and machine learning projects don't go to production because it's too expensive. The cost of doing ML, or AI, is so expensive that even if the value of the use case is there, the cost is superior. It's avoiding us from going there. So that sophistication of having a platform that connects the, give you an API, because SageMaker will give you the same as the AI services, will give you an API. You can do A.V. testing. We do the hyperparameter optimization for you, by the way, guys, and we will actually allow you to have an API that you can have up to five different models and then you can do the A.V. testing. That API can actually be connected as a recommendation engine, as inference, and you will elastically, also as SageMaker, allow you to elastically have capacity for as many people connecting to your application asking for recommendations to serve that traffic. So it's not only about the training, which is one part, it's also about the inference that we can do for you guys. And by the way, you can export that as well to the edge. So the model string on SageMaker can be exported, and can be compressed, and that can be run on a machine, on a car, something like that. So how do I monetize that data? So I have my applications. I choose the right database. I enrich that with data in a data lake, and then I choose my analytics, and I choose how to enrich and has my model. So you can do BI with that. So we have a service called QuickSight in memory as well. So we have many companies embedded embedding into those applications, a dashboard on QuickSight, which is in memory technology as well, and you will pay maximum 30 cents for every 30 minutes that a user is connected. If a user is connected more than $5, that's the maximum they're going to pay per month. So that's a very compelling, super fast in memory technology on top of this analytics that can be embedded into the application, another engine that you could enrich the application with. We can help you doing forecasting. So we have a service, an AI service. You can create the model yourself, or you can just have the right data and do a forecasting model using something called Amazon Forecast. It will look at your data, it will cleanse the data, it will select the right features, the columns, and then it will create a specific model for your business that is exposed as an API, and you can do a forecasting into your application. Demand forecasting, workload forecasting, financial forecasting that could be included inside your application. You can do personalizations exactly the same concept, but based on 20 years plus of experience on Amazon, doing recommendation engines. So if you want to create your own model for recommendations, usage maker, it will make you more agile. If you don't know how to do it, you just personalize. You can start tonight. So I was in Dubai a month ago, the city of a perfume company, Spanish guy from the north, actually made it work in one evening, and they're putting two people that were doing forecasting doing something else because now they have a solution that can be embedded into the forecasting of the company and know the exact amount of product that they need to send to the shops. So that is forecast, but also for personalized, for recommendation like Domino's Pizza. Image recognition, guys. One thing that people forget is you collect data, but you can enrich the data about that. Imagine you have an application with pictures, guys, and videos. Imagine you want to tag those pictures. You want to have the gender, whether it's appropriate as a content, so we can block it. You can detect whether it's a female, male, age, maybe for security because you want to recognize the face. You want to enrich, especially in media, companies that are super popular at the moment. We can have you and give you capabilities to enrich the metadata around pictures and videos using a service called recognition. Save it back into the data lake, and you can use that to have a more richer experience of the information to actually do better recommendations in your application. Comprehend, if you want to do sentiment analysis, whether the people are happy or unhappy with the feedback they're putting. So you can use comprehend. We have a demo, you can Google that in YouTube, in which there is a call center. People are calling the call center, and automatically using our voice services, we are putting that voice is being translated into different languages, like in English, and then that voice is being analyzed in real time, we comprehend, and we are giving the call center operators the capacity to understand whether it's positive, negative, or neutral, also detect organizations, times, and things like that. So that could either power your application in real time, like with chatbots, or enrich your view of the customers, and then you can have capabilities like chatbots to actually help and support the customers with the right recommendations based on the other engines and data, or even your own employees when they don't know there are many companies today embedding chatbots into their operations to know exactly what to do next with a customer, to share the knowledge base of people that have been in the company before. With that, you can fit back into your application and you have the perfect circle of how to build a modern application that goes beyond just a traditional database, use the right database to scale, and reach with that data and other pieces of data, a data lake, and reach that application guys, don't go there. If you want to really be competitive, more than to bring extra value to actually create new experience for customers, collect all the data in a way that is not expensive and insecure, run analytics or machine learning with the right approach, other you have data scientists, usage maker, or the AI service, then create the key insights and the key capabilities you want to embed into the application, and because everything is an API, it can be connected to the application. Thank you. I have one and a half minutes. If anyone wants to ask a question, I'm happy to. If not, I'll be at the booth and then we can talk at the booth as well. Thank you guys.