Amazon Aurora - a SQL-compatible database built for the cloud.

This blog is a summary of a talk given by Prasad Rao, Partner Solution Architect at AWS specialising in migrating and modernising Microsoft workloads onto AWS, at our recent Cloud Pathway event, 'Moving SQL Server to AWS Aurora'. The talk focused on purpose-built databases available in AWS, the limitations of traditional databases, cloud-native options like Amazon Aurora with a comparison between legacy features and cloud native alternatives. 

Watch the video here:

Choosing the right database

We hear a number of common reasons for choosing a database when working with our customers:

• the customer has heard of a new database and they would like to give it a try;
• generally if it's an enterprise organisation then they have been using a specific database for over a decade or so and they have licensing lying around so they would like to keep using the same database; 
• in some cases the team has developed a skill over time in developing and supporting a specific database so it is better to keep leveraging the existing skills of the team.

However, this isn’t necessarily the best angle to approach the task from. Prasad recommended taking an application perspective and considering what the data needs of the application are and the use-case that the project is trying to solve. Only then should you think about the database that best fits the application or the use case.  

There is a shift in mindset required, mainly because for decades the only database choice was a relational database so no matter the shape or function of the database, in the application the data was modelled relationally. Instead of the use case driving the requirements of the database it was the other way around; the database was driving the data model for the application use case.  Relational databases are purpose built for normalised schema and to enforce referential integrity but the key point Prasad made was that not all application data models or use cases match the relational model. Developers are building highly distributed and decoupled applications and AWS enables developers to build these cloud native applications by using multiple AWS services for scale performance and manageability. We should be able to access purpose built databases for different kinds of applications and use cases.

Choosing the right database, an application-use case perspective

Starting with your use-case, it helps to work backwards to make sure you are choosing the right database. If you're starting a green field project then you have the liberty of choosing a purpose built database. However, most organisations already have databases in use, which could benefit from modernisation. There are various modernisation paths to choose from but we'll focus on Re-host, Re-platform, Relocate and Refactor.

• Rehost: you can run your SQL server on Amazon Elastic Computing on Windows or you can use the managed version Amazon RDS for SQL server.
• Replatform: you can run your SQL server on Linux, using Amazon EC Linux instances and this will help to eliminate the cost of Windows server licenses.
• Refactor: this is how you achieve the greatest benefits of using cloud native services. It requires more effort, but yields greater benefit. You have two options: 1) Amazon Aurora comes in two flavours: mySQL and postgreSQL or 2) you can think about a noSQL purpose built database like Amazon DynamoDB, Neptune QLDB or DocumentDB, based on the use case.
• Relocate: this approach is mainly for if you would like to relocate your VMware workloads onto AWS.

Limitations of legacy databases

Why do we need to modernise? That's because legacy databases do have limitations. 

1. Expense: Legacy databases can be expensive in terms of licensing fees; 
2. Lack of innovation. Legacy databases are often proprietary platforms and that restricts innovation. Customers are locked in into using the proprietary database features, missing out on the innovation and flexibility offered by open source and cloud native databases;
3. Difficult to scale & accurately resource.  Traditional databases are structured as monolithic architectures, making them difficult to scale or innovate to support emerging use cases. Some companies employ licensing tactics that make it tricky to right-size a database. More often than not you end up either over-provisioning or under-provisioning a database, leads to either resources sitting idle or customer dissatisfaction. For example, if your application popularity grows and you suddenly have a million users coming on to your website, then you could hit the database scaling limits.

Enter Amazon Aurora.

Amazon Aurora is a MySQL and PostgreSQL compatible relational database built for the cloud that combines the performance and availability of traditional enterprise databases with the simplicity and cost effectiveness of open source databases. Amazon Aurora is up to five times faster than a standard MySQL database and three times faster than a standard PostgreSQL database. It delivers high performance and availability with low latency read replicas, point in time recovery, continuous backup and replication across three availability zones. It provides the security, availability and reliability of commercial databases at one tenth of the cost. Amazon Aurora features a distributed fault tolerant and self-healing storage system that auto scales up to  6 terabytes per database instance. And finally it is a fully managed service which means that it automates time consuming administration tasks like hardware provisioning, database setup, patching and backups.  

AWS re-imagined the database by tearing apart the layers that we found could scale independently, the logging layer and the storage layer. The key innovation comes from separating the compute, where the query processing happens, from logging and storage. Storage is distributed over a widespread, purpose built, database storage layer and this gives you image scalability, more throughput, better reliability and better durability. 

Amazon uses a distributed and shared storage architecture. When data is written to Amazon Aurora it is sent to six storage nodes in parallel and those storage nodes are spread across three availability zones which significantly improves durability and availability. Amazon S3 is designed to transparently handle the loss of up to two copies of data without affecting the write availability and up to three copies without affecting the read availability. 

You can learn more about the native features of AWS Aurora here.

Customers using AWS Aurora 

Aurora has been one of the fastest growing services in AWS history. Some specific examples are of course ASP, alongside clients like RyanAir, DowJones, Autodesk and more.

Considering modernising your workloads?

Cloudsoft are AWS Advanced Consulting Partners, and have migrated and modernised the workloads of numerous clients from a variety of industries. You can read more about modernisation here, or get in touch with one of our Solution Architects for a free, 30 minute  conversation about how we could help you adopt and make the most of the cloud: