Hello everyone, my name is Akanksha. Welcome to today's session. There are three new trends we are seeing and I'm going to talk about each one of them in detail. The first trend we are seeing is that there is an explosion of data from all the connected devices. The growth of data is coming from devices like mobile phones, smartwatches, IoT devices and many more connected devices. Even applications are actually generating data, the social media, the way we are purchasing things. So mobile phones generate a lot of data. By our own estimate, the volume of data is growing from ten x every five years. To take advantage of all of this data, you need to be able to partner with someone who can easily manage this volume of data. The second trend that we are seeing is microservices. Now, microservices are now more popular because application needs have changed. Applications now need to scale quickly to potentially millions of users. They need to have global availability, manage petabytes of data and responses in milliseconds. Now, microservices allow small groups of developers to build these modern applications and innovate faster AWS. They can independently build and grow new products for their businesses without bringing the whole application or the website down. And the third trend that we are seeing is there's a transition to DevOps models. Now businesses are transforming from an IT model to a DevOps model, which gives developer more power to push code to production faster. It also uses automated tools like continuous development, continuous deployment and continuous integration of new code. So these are like three trends that are driving the new requirement and need for purpose build databases. Now let's also transition into topic of self managed databases. Self managing your database is a tedious, time consuming and expensive task. And if you guys have worked on databases or worked as a DBS, and I think you can really correlate to what I'm saying now, is you have to worry about your operational efficiency issues such as hardware and software installation. You need to make sure that your database is fully patched, all the cpu patches are done, make sure the backups are done and they're done correctly and accurately as well. Performance and availability issues are taken care of and there could be failures, and failures could be very huge ones, which is like a failure of a primary instance can mean downtime for your application and lost money for your company. In the worst case, a faulty backup plan can result in permanent data loss. Now, many dbas don't even know how the databases will handle an instance failure until it actually happens. Now, when using an on premise data center, capacity planning is regular fact of life. You plan months in advance, guessing at your growth rate, and then you overestimate to be on the safer side. And by doing this you're wasting money on unused infrastructure. And occasionally, if you're not good in projecting your growth rate or your need, you underestimate it and then you leave your customers unhappy with unexpected downtime. Now as a DBA, we really want you to innovate on behalf of your customers and not manage infrastructure. This is like a shared model that we have, but we'll start off with the left hand side. So if you look at the left hand column, this is what we actually spoke about just now, where you look after the whole stack, starting from server provisioning, patching, configuration and recovery. And on the right hand side is shared model by AWS, which is also like our fully managed database services. By AWS we handle all the fundamental operation. You get the patching, minor upgrades without downtime, automated backup failover, high availability and durability is taken care of and we are able to provide you all these features through a console with single click because we are using AWS cloud the AWS cloud is split into different AWS region. Each region is split into multiple availability zone which acts like a separate data centers within the region. When you're using managed databases on AWS, your database storage is automatically scaled according to your needs so you will never have to run out of disk space. Your database instance size or the cluster size can be increased as needed quickly in the console. We are based on the model which is like pay as you go model which is based on you pay only for the instance and storage that you use. This results in more flexibility and obviously less using upfront. As a database administrator, you provide value by assisting on schema design, query optimization and access control, building new applications and making your customers happy, and not by managing infrastructure for the new modern architecture. AWS offers 15 purpose built database engines that support diverse data models that allow you to build use case driven, highly scalable distributed applications. By picking the best database to solve the specific problem, customer can break away from the concept of one size fits all database and focus on building applications to meet the needs of their business. This allows customers to scale faster, innovate faster, build new features faster. Now let's look at the fully managed database services that we have. We provide a wide variety of database types. Now if you're using a relational database, then Amazon RDS includes supports for seven different relational database engines. This could be open source options such as MySQL and postgres. NoSQL or a commercial option such as Microsoft NoSQL Server or Oracle database. If you're using a non relational database, AWS offer multiple options there too. AWS document DBS is a fully managed MongoDB compatible document database. Amazon Elastic Cache provides support for both Redis and Memcache, and Amazon Keyspace is an Apache Cassandra compatible database with serverless scaling and pricing characteristics. Now let's look into the managed database that we have and how do you move basically to the managed database services? The most straightforward and simple solution for customers who are struggling to maintain their own relational databases at scale is to move to a managed database service like Amazon RDS or Amazon Aurora. In most cases, the customers can migrate workloads and application to a managed service without needing to rearchitect their application, and their teams can continue to leverage the same database skill set. Now some of the customers who migrate to self managed databases are essentially running the databases on on premises. They would like to reduce database burden, they do not want to re architect and they would like to have better performance and availability and scalability. Now the easy way is customer can lift and shift their self managed databases like Oracle SQL Server and postgres NoSQL MariaDB to Amazon RDS. For customer looking for a better performance and availability, they can move their lift and shift their NoSQL and postgres databases to Amazon Aurora and get three to five times better through output. Now Amazon RDS provides a couple of very nice features. For example, it provides you the scale and performance and it automates the time consuming administrative tasks like provisioning and database setup and patching, and the backup customers who are using non relational databases like MongoDB and Redis as document and in memory databases for use cases such as content management, personalization, mobile application catalog, real time gaming. So the most straightforward and simple solution for these customers who are struggling to maintain their non relational databases is to move any of into our fully managed non relational database services like moving self managed Mongo databases to Amazon document DB, moving self managed in memory databases like Redis and elastic cache to Amazon Elastic cache. And in most cases, these customers can migrate workloads and applications to a managed service without needing to re architect their applications and their team can continue to leverage the databases that they are using now. Customer wants to move away I think most of you will also correlate it. You would like to move away from old car databases because they are expensive, there's a proprietary, there's a lock in, they offer pumative licensing and comes in with frequent audits from their vendors, which nobody really likes. So even if you are not using that feature, but if you clicked it, then it will be flagged in the audits and you have to pay for it. So there's a common trend that we're seeing is customers would like to move away and go into like a license free model where they don't have to pay for any license to any of the vendors. And for that we have built Amazon Aurora, a MySQL PostgreSQL compatible relational database built for the cloud that combines the performance and availability of commercial databases while providing the cost effectiveness of open source databases. Now there are no annual licenses you pay for the capacity you use. This turns your capital expenditure into operational expenditure and better matches your cost with your revenue. Now some of the Aurora key features are it is highly durable Amazon Aurora database volumes are up to ten gb in segments and each segment is replicated six ways across availability zone. It's highly fault tolerance because it handles the loss of up to two out of six data copies without losing write availability or three out of six copies without losing read availability. It monitors your disk and nodes for failure and automatically replaces or repairs them if it finds out anything is not working fine. There's a continuous backup, incremental continuous backup with no impact on database performance. It is obviously designed to be compatible with MySQL and PostgreSQL. So if you are on any of the commercial database engines and if you would like to go into microservices, this is also the right time to think about going completely license free and move to any of the cloud native databases that we have. And Amazon Aurora is actually one of them. Now let's look into how is the application landscape changing right now. Back in 1670s, mainframe was prominent way of building application. This lasted until 80s where the client server was introduced and then that also significantly changed the way applications were built. And then the Internet arrived in ninety s and as a result the underlying data model also changed predominantly and database still remained monolithic. But now this has changed. Now we fast forward it again to today. Then you see that microservice architectures are how applications are built in the cloud. Microservices has finally reached the database and this allows developers to do what they do best. They break large applications into smaller services and pick the right tool for the right job. They want to avoid a single overburdened database with one storage engine and one compute engine trying to handle every single excess pattern. Now there are other things that we have also seen that latency requirements are much lower and they are expected to be able to handle millions of transactions per second. So in general, the application landscape is changing. And if you look into this, the change requirement of applications, the user growth is also changing, right? So the applications are going global, right? Businesses are capturing more data. As I said earlier, there's a huge data growth happening, there's a huge emphasis on performance. Businesses don't want to dilute the user experience these days, right? And if you talk about scalability, then a lot of businesses are embarking their digital transformation. And these measures of scales are component by number of devices that access their application. There are billion of smartphones in the world and mobile is bare minimum expectations in 2021. So all of these requirements are actually changing the application landscape, the user expectations and the requirements around it. And to tackle this, we have provided 15 purpose build database engines that support diverse data models that allow you to build use case driven applications by picking the best database to solve specific problem and customer can break free from one size fits all. And if you go from here, then you can see we have relational databases and we have document DB. We have in memory cache databases. Let's look at the variety of purposeful databases that we have. We have key value database DynamoDb which stores database as a collection of key value pairs and it is idly used for ecommerce shopping cart product catalog. The next one we have is document DBS that stores data in a JSON or JSON live document. And it's ideal for mobile applications and cataloging in memory databases. Store databases in memory for low latency access and they're ideal for caching and gaming. We have craft databases that represents relationship directly and are ideally used for social networking or fraud detection. Then we have time series databases that stores data in time order and append only, which is ideal for DevOps and application monitoring. And last, we have ledger databases that stores in immutable or transmittable cryptographic logs. And it is ideal for finance, manufacturing, HR, payroll, retail invoices that I can think of. So we have a huge broad spectrum of all these purpose build databases. Now in the next step, I really want to dive deep into DynamoDB. It is a key value and document database that delivers single digit, multi second performance at any scale. It's a fully managed, multi region, multi master database that is built in with security, backup and restore. And some of the key features or some of the highlights are DynamoDB can handle more than 10 trillion requests per day and can support peaks of more than 20 million requests per second. Okay, so DynamoDB actually automatically scales tables to adjust for capacity and maintains performance with zero administration. Availability and fault tolerance are built in eliminating the need to architect your application for these availabilities. It encrypts all the data at rest. By default. We have point in time recovery feature that helps you protect your tables from accidental delete or write operations. DynamoDB is serverless. Also it integrates with lambda AWS lambda to provide triggers, and using triggers you can automatically execute a custom function when item level changes are done in the DynamoDB table. So hundreds of thousands of AWS customers have chosen DynamoDB as their key value document database for mobile, web, gaming, IoT and all applications that need low latency data access at any scale. The next database I would like to talk about is documentDB. A large variety of applications, drivers and tools that customers already use today with their MongoDB non relational databases can be used with Amazon document DBS with little or no change. It is compatible with MongoDB 3640 drivers and tools and latest support can be found on our website. But with the launch of the support of MongoDB 40 compatibility, Amazon document DB supports the ability to perform asset transaction across customers. Customers can easily migrate their MongoDB databases on premises or from on premises to either EC two or to document DB. Document DB is also very much integrated with our Amazon Cloud Watch which provides you metrics for your database instances and it provides you some very key operational metrics. For example, how does your cluster look like compute memory storage through output. So since it is integrated you can get alerts. You can see the current status of these metrics here and as well. And lastly, it supports 15 database read replicas as well. Now database Freedom is an AWS database and analytics modernization incentive focused on accelerating enterprise migrations from Oracle and SQL server, Netiza, Teradata Cassandra or MongoDB platform to AWS cloud native database services. It is an incentive program, but it not only provides you an expert advice, it provides you workshop partners migration assistant to help you with your migrations and guide you through your migrations. Now we have a series of migration workbooks or playbooks that we call them. They are freely available for download on our website and provides a step by step guide outlining how migrating your databases or what you should look out for. These are extraordinarily detailed and can help anyone who's looking to migrate themselves with common technological hurdles or things to watch out for. I also would like to talk about DMS which is data migration service that we have and it is used to migrate between homogeneous database types, such as going from one MySQL instance to a new MySQL instance. Or you can use DMs to migrate between heterogeneous databases, such as moving from a commercial databases like cloud to a cloud, native relational databases like Aurora. There's another great tool that we have which is schema conversion tool, and it helps you to migrate your database schema between heterogeneous data types. It attempts to convert all the schema and code objects of the target database engines, including the stored procedures and functions. It also scans and converts your embedded SQL statement in application code. So in combination of playbook dms, it is very easy to migrate your databases to AWS let's look into partners we have quite a range of partners with us, but the question that I get asked is why do we need partners? We really recommend looking into our partners that can help you to do any proof of concept or actually can do migrations for you as well. They help you reduce your operational cost so that you can focus on innovation as well. So here is quite a few of our partners. We have migration partners. We also have license advisory partner here as well. So if you would like any help on your licenses or you would like to know more about them, then you can refer any of our partners here to help you with that. And lastly, we have lot of resources. We have also launched our database certification. So if you guys would like to know more about databases, you can visit the website mentioned here, or you can take the database certification as well. More information, contact us and then once again, thank you for joining today's session.