Why to move to a managed database

Background

The lift-and-shift strategy is a common move for organizations making their first foray into the cloud. For example, the application compute that was running on VMware in your on-premises facility is now running on a virtualized instance on AWS. The Oracle database that was running in your colocation facility is now running on Amazon Elastic Compute Cloud (Amazon EC2).

This lift-and-shift strategy may feel like the easiest way to move to the cloud. Your architecture map still looks similar, and your team’s responsibilities don’t change. But you're not getting the full benefits of the cloud.

A recent IDC study commissioned by AWS considered customers who used Amazon Relational Database Service (Amazon RDS), which is a fully managed relational database service from AWS. The study found that the customers had 39 percent lower database operation costs and a 264 percent return on investment over three years. These customers work with AWS to learn how to embrace a cloud-first mindset.

To do that, you need to consider what really differentiates your company and relentlessly focus your innovation on those key differentiators.

Click through the following tabs to learn more about why to move to a managed database.

Why to Move to Managed Databases (10:25)
  • Database management is undifferentiated heavy lifting
  • Database failover and recovery are hard to get right
  • Flexible capacity planning and scaling
  • Database management is undifferentiated heavy lifting
  • For most companies, database management is undifferentiated heavy lifting. Your data is one of the most valuable assets your company owns, but the management of your database is not where you provide value.

    As a company, you provide value by innovating on behalf of your customers. As a database administrator, you provide value by assisting on schema design, query optimization, and access control. Properly managing backups and failover can prevent you from being fired, but providing application-specific guidance about efficient data use is what gets you promoted.

    AWS engineers have managed databases for some of the highest volume workloads in the world. They have built reliable tooling for all aspects of database management to ensure that your database is operating at the highest level. AWS managed databases handle all the fundamental operations. You get patching and minor upgrades without downtime, automated backups and failover, high availability and durability, and helpful support quickly.

    Allow your developers to deliver more value by focusing on the features that matter to your customers. 

  • Database failover and recovery are hard to get right
  • Managing a database is a sensitive, technical endeavor with the risk of a catastrophic downside. The 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.

    Disaster recovery plans are difficult to test given the sensitivity involved. It can be intimidating to truly simulate a disaster scenario on your production database. Accordingly, many operators of self-managed databases don't know how their database will handle an instance failure until it actually happens. Operating a rarely used runbook during the middle of a production incident is a stress-inducing time for all developers.

    The cloud has changed how you can handle failure in your applications. The AWS Cloud is split into different AWS Regions, which are geographic locations such as us-east-1 (N. Virginia, USA), us-west-2 (Oregon, USA), or ap-northeast-2 (Seoul, South Korea). Each Region is split into multiple Availability Zones, which are completely separate data centers within the Region.

    Each Availability Zone is designed to be isolated from the failure of other Availability Zones in the same Region. Many AWS managed databases take advantage of this isolation by running instances of your database in multiple Availability Zones within a Region. This helps minimize downtime for your end users.

    AWS has experience managing large numbers of databases for its customers. Because of this scale, AWS has developed the procedures and processes to manage all sorts of issues with databases. You can easily fail over to a backup instance in the event of an instance failure. You also can automate your database backups to comply with regulations and ensure that your data is safe in the event of an emergency.

  • Flexible capacity planning and scaling
  • When using on-premises data centers, capacity planning is a regular fact of life. You plan months in advance, guessing at your growth rate and hoping for the best. Usually, you overestimate to be safe, wasting money on unused infrastructure. Occasionally, you underestimate and leave your customers unhappy with unexpected downtime.

    The public cloud was designed to solve these problems. If you're running your own databases in the public cloud, you can vertically scale by increasing your instance size or horizontally scale by adding additional nodes. But these operations are risky and can result in downtime.

    When using managed databases on AWS, you can increase and decrease your database as needed. Your database storage is automatically scaled according to your needs, so you will never run out of disk space. Your database instance size or cluster size can be increased as needed quickly in the console. The resizing is managed for you, without the risk of data loss.

    Finally, many commercial databases require purchasing annual licenses up front with complex negotiations. With most AWS managed databases, you choose a pay-as-you-go model that is based only on the instance size and storage used. This results in more flexibility and less guessing up front.

Factors to consider when choosing a managed database

When moving from a self-managed database to a fully managed database, research your options carefully. The two most important factors to consider are the type of managed database you want to use and the process you will use to migrate your data.

  • Choosing a managed database type
  • Choosing a migration process
  • Choosing a managed database type
  • The first factor to consider when choosing a managed database is the database type. The number of database types has increased in recent years, from the traditional relational database to various flavors of NoSQL. Examples are document stores such as MongoDB and Amazon DocumentDB (with MongoDB compatibility), graph databases such as Amazon Neptune, and in-memory databases such as Redis and Memcached.

    AWS provides support for a wide variety of database types. If you are using a relational database, Amazon RDS includes support for seven different relational database engines. This could be open-source options such as MySQL and PostgreSQL, or commercial options such as Microsoft SQL Server and Oracle Database.

    If you are using a nonrelational database, AWS offers multiple options there too. Amazon DocumentDB is a fully managed, MongoDB-compatible document database. Amazon ElastiCache provides support for both Redis and Memcached databases. Amazon Keyspaces (for Apache Cassandra) is an Apache Cassandra–compatible database with serverless scaling and pricing characteristics.

    With this variety of database types available, you can find the right managed database for you on AWS.

  • Choosing a migration process
  • Migrating a database is a delicate process. Though you can gain many benefits by moving to a fully managed database, you need to be careful to ensure that the data migration is handled correctly and with minimal downtime to existing users.

    AWS includes a number of options to help you make your database migration successful. First, AWS offers AWS Database Migration Service (AWS DMS), a self-service option for migrating databases.

    You can use AWS DMS to migrate between homogeneous database types, such as going from one MySQL instance to a new MySQL instance. Or you can use AWS DMS to migrate between heterogeneous database types, such as moving from a commercial database such as Oracle to a cloud-native relational database such as Amazon Aurora. AWS also provides the AWS Schema Conversion Tool to help in migrating your database schema between heterogeneous database types.

    If you need additional assistance with your database migration, AWS has options available for you. The Database Freedom program provides expert advice and migration assistance to qualified customers. Use the knowledge of database migration experts to help you make your migration seamless.

    Finally, if you need hands-on assistance, consider the AWS Professional Services team. This team can work with you to plan and execute your migration and help you achieve a successful outcome. Additionally, a number of AWS Database Migration Service Partners are available.

In the rest of this course, you walk through examples of migrations from self-managed databases to fully managed databases on AWS.