DEV Community

Cover image for The 9 AWS Serverless Databases ALL App Developers & Software Engineers Should Know About 👨‍💻💭
Brian H. Hough for AWS Community Builders

Posted on • Edited on

The 9 AWS Serverless Databases ALL App Developers & Software Engineers Should Know About 👨‍💻💭

Here's all you need to know about the 9 different AWS Databases and their use cases that EVERY app developer and software engineer should know about 👨‍💻💭

Last week on Friday, I was invited by WhizLabs to give a webinar on "AWS Databases Demystified With Their Use Cases" in the launch of their #100DaysOfCloud. In episode 6 of the Tech Stack Playbook podcast, I'm covering an in-depth overview of the 9 AWS serverless databases developers should know about, architecture diagrams of how they work, how they can be used in production, and 2 live demos of DynamoDB and RDS.

Here’s a glance at what you’ll learn in this episode:
00:00 Webinar Primer
06:18 Overview of a Database
07:37 Brief history of serverless Databases
09:36 Walkthrough of 9 AWS Databases and their use cases + how to get started with your own apps
30:48 How to set up a DynamoDB table and query your data
36:02 How to spin up an RDS instance in a VPC and manage/update this database with MySQL Workbench
1:03:12 Q&A + Quiz Time!
1:18:19 Conclusion

Brief History of Serverless Databases

I see data as the energy flowing through a home while databases are the electrical grid system.

So specifically, data can be the users’ information that could be a username, a password, song, title, author, anything. You can create role-based permissions and share certain types of data with specific groups. Data is the mechanism powering user interactions. The databases define what the users can do in their accounts and in other accounts within the system. And then, data can also determine the rules supporting your software system, and this can be back-end logic.

This can explain how the system shares data with users, how they get recommendations, for example on a platform like Netflix. See how you get recommendations for the movies you watch! So when we think about front-end and back-end data, now everything is moving towards full-stack.

This trend has been visible all throughout the history of databases, as you will see here:

1D: Physical Databases

The history of databases goes way back to the abacus. That’s a physical database where the limitation was that you’re limited to the data that the system itself can process.

2D: Server Databases

In the next data dimension, we see that server databases are limited to specific devices that you have to manage, you have to maintain, and you have to patch it to provide updates. There’s a lot of effort that has to be put into it, so it is cost-intensive, requires skilled professionals at both hardware and software, and can take time away from the important development work you probably need to be doing.

3D: Serverless Databases

This is when we move towards a three-dimensional space of serverless databases. Here, the users can scale their own databases from an operating system and an internet connection. This is the ecosystem AWS has created for developers, for example, a whole ecosystem behind serverless technologies – such as, Virtual Private Cloud (VPC) and Elastic Cloud Compute (EC2).

Now you are able to compute network servers, but you don’t have to manage them because they’re managed by other large facilities, managing a ton of different technologies and servers that you’re using every day. So AWS databases can help you manage and permit your own servers, you can now borrow compute from someone else.

4D: Data-driven Development

The future is moving rapidly towards prioritizing data-driven development, where it’ll not just be enough to make an app or software, but you will also have to create a data model and manage the data amongst your users.

Artificial intelligence and machine learning technologies like AWS' SageMaker, DeepComposer, and more provide next generation capacities to turn data into predictive engines. This allows software to anticipate patterns, predict risks or irregularities, and "see" into the future based on the data flowing into the system.

A Walkthrough of 9 AWS Databases & Their Use Cases

Relational Database Service (RDS)

Relational Database Service (RDS) is quick to create the framework for a relational AWS database, using a number of different engines. The available DB engines are Aurora from Amazon, PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server. They’re extremely cost-efficient and highly scalable while maintaining top security. So they allow you to offload read traffic, create and connect to the database within seconds. You can run RDS with a VPC, serverless. In the lab at the end of the video, I'll show you how to create a database using MySQL Workbench and show what you can use it for to update the database and connect to it.

DynamoDB

DynamoDB is one of the most popular AWS database use cases that is a really fast, flexible, no SQL database. It lets you use a primary key to index items and have unique identifiers for all the elements in the database. It offers high performance and availability with single-digit latency. Top companies like Lyft, Airbnb, Capital One, Samsung, and Toyota use this AWS database. DynamoDB is accurately designed for application developers who can scale up and down based on their need to create interactive websites, mobile apps, microservices, etc.

Elasticache

Elasticache is used for deploying and scaling in-memory data stores. This can happen serverless, using caching rather than just normal, non-performant loading. Caching is really helpful for improving performance and response time – operations happening under a millisecond. As an AWS database use case, it offers fully managed Redis and Memcached. As this AWS database is an in-memory data store, it provides low latency and high elasticity for companies like Airbnb, Tinder, or The Pokemon Company.

Neptune

Neptune is a fully managed service for graph databases. Graph databases are interrelations between users and the data that users generate for our system. This AWS database simply offers the potential to map how users interact, work together, or maybe share information amongst each other. This building of knowledge graphs and identity graphs is very similar to the operating model of Netflix. Let’s say that you’re watching a lot of documentaries, maybe about history, then you’re going to be recommended more documentaries about history, because other people who also watch historical documentaries, might like this specific segment. So using this AWS database use case, you can also create something like identity graphs and start doing pattern detection. Apache Tinkerpop and Gremlin are two services that can work with Neptune, and help you build a graph database architecture.

Redshift

Redshift is a relational database management system that is lightning fast and can optimize data at a high scale. With this AWB database, you can implement data encryption and compression as well. Redshift leverages three times better price-performance with high-end AWS designed-hardware. With the help of AWS Nitro Systems, data compression can be accelerated. It is the most widely used cloud data warehouse for combining exabytes of semi-structured and structured data.

Quantum Ledger Database (QLDB)

One of the most important AWS databases, QLDB is a fully managed serverless database. It has the potential to automatically scale up to support the user’s demands. As per your own terms, you can also monitor the metrics. It uses PartiQL, a SQL-compatible query language that provides 2-3x faster execution than the common blockchain frameworks.

Managed Blockchain

In a managed blockchain, data is stored in a fully managed ledger database but it is not centralized and is distributed among the series of nodes. Hyperledger Fabric or Ethereum makes it easier to join public networks or create and manage private networks. Adding new nodes and members is very easy with this AWS database, while it is highly scalable and secure. The security of transactions is maintained through traceability across the blockchain network as it stores changelogs for the entire history of events.

DocumentDB

If you’re interested in leveraging MongoDB for high scalability and availability, then DocumentDB is a great AWS database use case for that. It uses JSON-like data to process millions of requests per second and offers 15 low latency read replicas over three availability zones, within seconds or minutes. And you can scale up very quickly and also have very high availability, up to 99.99%. For instance, you have a MongoDB shell setup and it connects to the DocumentDB cluster with a few instances that are happening within a virtual private cloud. And they’re all happening within an AWS region. This is highly professional and will allow you to leverage MongoDB services, right within AWS.

Keyspaces

Keyspaces is a serverless database with Apache Cassandra, which is a distributed, wide-column store, no SQL database management system. This AWS database offers a management system for huge amounts of data with no single point of failure. So you never have to worry about servers anymore, or provisioning or patching, that you are usually concerned with while managing servers in-house. Now you can build apps with low latency that can process data incredibly fast. And you can run Cassandra app codes right from AWS, which is almost like a talk-to-type skill.

Check out the full recording below:


If you got value from this article, please LIKE 👏, COMMENT 📝, and SHARE ↩️ this post with your network, as well as FOLLOW 📲 my Twitter, Instagram and LinkedIn accounts for further insights on technology, innovation, and our digital world.

Top comments (4)

Collapse
 
polaroidkidd profile image
Daniel Einars

Why should a front-end/App (iOS/Android) dev care what DB is running in the backend?

Collapse
 
brianhhough profile image
Brian H. Hough • Edited

@DanielEinars — great question! Personally, I got into software development because I wanted to bring my UI/UX designs to life. As I've been learning all that encompasses (the industry is near-endless), I found that front-end has a lot of back-end needs. Some examples that come to mind for me are:

  • understanding the logic model of authentication (and knowing how to render this in the app)
  • knowing how data is stored in a db and how to call that into the front-end
  • general understanding of how data is persisted across a user account

I found that designs will stay designs until we bring in the front end. Front-end will stay front-end until we bring in the back-end. Back-end will stay back-end until we can deploy the app.

If you want to scale software and apps, working with DBs will be a must 😊 But that's not to say front-end is INCREDIBLY valuable because it is!!! They're the ones that make our apps amazing and fun too use and keep us coming back for more. BUT....to scale software, back-end and db skills will be an absolute must!

Curious to hear what you think too!!

Collapse
 
polaroidkidd profile image
Daniel Einars

Hmm, I see your points. In my mind I'd never directly interface with a database from the front-end (web) but always via a specific REST API, which is implemented in a separate service. It would handle all the complex storing logic, authentication & authorization and only expose the bare minimum to keep public exposure to a minimum. In the end I don't really care what specific DB is running in the backend, but how I interface with the REST API to satisfy my frontend requirements. However, if I'm in the backend I do very much care about which DB is running where since that will effect scalability.

I don't have a whole lot of backend experience but I do know that I have to mentality switch thinking when going from web to backend from

"One user uses this website at a time"

To

"What happens if suddenly 10'000 separate users use this backend simultaneously."

Being informed about DB options empowers you to make the right decisions in the long run on my view.

Thanks for sharing btw, it's a great read!

Collapse
 
timhub profile image
Tech Tim (@TechTim42)