Ten years ago, Amazon Web Services (AWS) launched Amazon DynamoDB, a fast, flexible NoSQL database service that offers single-digit millisecond performance at any scale.
In an online post on Jan. 18, 2012, Werner Vogels, chief technical officer at Amazon.com, wrote: “Today is a very exciting day as we release Amazon DynamoDB, a fast, highly reliable and cost-effective NoSQL database service designed for internet scale applications. DynamoDB is the result of 15 years of learning in the areas of large scale non-relational databases and cloud services.
“Several years ago we published a paper on the details of Amazon’s Dynamo technology, which was one of the first non-relational databases developed at Amazon,” Vogels continued. “The original Dynamo design was based on a core set of strong distributed systems principles resulting in an ultra-scalable and highly reliable database system. Amazon DynamoDB, which is a new service, continues to build on these principles, and also builds on our years of experience with running non-relational databases and cloud services, such as Amazon SimpleDB and Amazon S3, at scale. It is very gratifying to see all of our learning and experience become available to our customers in the form of an easy-to-use managed service.”
One of Vogel’s coauthors on the 2007 Dynamo paper, and a key contributor to the development of DynamoDB was Swaminathan (Swami) Sivasubramanian, then an Amazon research engineer working on the design, implementation, and analysis of distributed systems technology, and now vice president of Database, Analytics, and Machine Learning at AWS.
More and more, CIOs and organizations are realizing that it is going to be survival of the most informed, and those that put their data to work are the ones that won't just survive, they will thrive.
A decade after the launch of DynamoDB, Sivasubramanian says we’re “experiencing an amazing era of renaissance when it comes to data and machine learning.”
“We now live in an era where you can actually store your data in these databases and quickly start building your data lakes within Amazon S3 and then analyze them using Amazon SageMaker in a matter of a couple of weeks, if not days. That is simply remarkable.
“We now have the opportunity to help customers gain insights from their data faster,” Sivasubramanian added. “This is a mission that truly excites me because customers really want to put their data to work to enable data-driven decision making. More and more, CIOs and organizations are realizing that it is going to be survival of the most informed, and those that put their data to work are the ones that won't just survive, they will thrive.”
To mark the 10-year anniversary of the launch of Amazon DynamoDB, Amazon Science asked Sivasubramanian three questions about the origins of DynamoDB, its progenitor Dynamo, and the future of DynamoDB.
Q. You were a co-author on the 2007 Dynamo paper. At that time, the industry was transitioning to a scale out vs scale up architectural approach. Can you tell us about the origin story for Dynamo?
To get to 2007, I have to start with 2004, 2005. Even as I was working on my PhD [Sivasubramanian earned his PhD in computer science in 2006 from Vrije Universiteit Amsterdam] I was contemplating where I would work. Ultimately what convinced me to join Amazon as a research engineer intern [2005] was seeing how Amazon was pushing the boundaries of scale.
I admit I was a little bit of a skeptic as an outsider. At that time, AWS didn’t even exist. But when I joined, I soon had an ‘a ha moment’ that, yes, Amazon was an e-commerce company, but actually it was a technology company that also did e-commerce. It was an interesting revelation for me seeing how Amazon had to invent so many new technologies to even support its e-commerce workload.
As an intern, I was working as an engineer on amazon.com and during our peak holiday traffic time we experienced a serious scaling failure due to a database transaction deadlocking issue. The problem was caused by the relational database from a commercial vendor that we were using at the time. A bunch of engineers got together and wrote what we call a COE, a correction of errors document in which we say what happened, what we learned, how we fixed the issue, and how we would avoid a recurrence.
I don't know if it was me being naive or just being confident in the way only a 20 something intern can be, but I asked the question ‘Why are we using a relational database for this? These workloads don't need the SQL level of complexity and transactional guarantees.’
This led us to start rethinking how we architected our underlying data stores altogether. At the time there wasn’t a scalable non-relational database. This is what led us to build the original Dynamo, and which led us to write the paper. Dynamo was not the only thing we were rethinking about our architecture at this time. We realized we also needed a scalable storage system, which led us to build S3, and we also realized that we needed a more managed relational database with the ability to do automated replication, failover, and backups/restore, which led us to build Amazon RDS.
One rule we had related to writing the original Dynamo paper was not to publish when we developed the original design, but first let Dynamo run in production supporting several Amazon.com services, so that the Dynamo paper would be an end-to-end experience paper. Werner and I felt very strongly about this because we didn't want it to be just another academic paper. That’s why I was very proud when 10 years later that paper was awarded a test of time award.
Q, What’s the origin story for DynamoDB, and how has the technology evolved in the past decade?
The idea behind DynamoDB developed from discussions with customers like Don MacAskill, the CEO of SmugMug and Flickr. More and more companies like Don’s were web-based companies, and the number of users online was exploding. The traditional relational database model of storing all the data in a single box was not scaling well. It forced the complexity back on the users to shard their relational databases and then manage all the partitioning and re-partitioning and so forth.
This wasn’t new to us; these challenges are why we built the original Dynamo, but it wasn’t yet a service. It was a software system that Amazon engineers had to operate. At some point in one of our customer advisory board meetings, Don said, ‘You all started Dynamo and showed what is possible with a scalable non-relational database system. Why can't we have that as an external service?’
All senior AWS executives were there, and honestly it was a question we were asking ourselves at the time. Don wasn’t the only customer asking for it, more and more customers wanted that kind of scalable database where they didn't have to deal with partitioning and re-partitioning, and they also wanted extreme availability. This led to the genesis of our thinking about what it would take to build a scalable cloud database that wasn’t constrained by the SQL API.
DynamoDB was different from the original Dynamo because it actually exposed several of the original Dynamo components via very easy-to-use cloud controls. Our customers didn’t have to provision clusters anymore. They could just create a table and seamlessly scale it up and down; they didn’t have to deal with any of the operations, or even install a single library to operate a database. This evolution of Dynamo to DynamoDB was important because we truly embraced the cloud, and its elasticity and scalability in an unprecedented manner.
We launched it on January 18th, 2012 and it was a hit right out of the gate. Don’s company and several others started using it. Right from the launch, not just elasticity, but single-digit latency performance was something that resonated really well with customers. We had innovated quite a bit, all the way from the protocol layer, to the underlying storage layer for SSD storage, and other capabilities that we enabled.
One of the first production projects was a customer with an interesting use case; they were doing a Super Bowl advertisement. Because DynamoDB was extremely elastic it could seamlessly scale up to 100,000 writes a second, and then scale down after the Super Bowl was over so they wouldn’t incur costs anymore. This was a big deal; it wasn’t considered possible at that time. It seems super obvious now, but at that time databases were not that elastic and scalable.
It was a bold vision. But DynamoDB’s built-for-the-cloud architecture made all of these scale-out use cases possible, and that is one of the reasons why DynamoDB now powers multiple high-traffic Amazon sites and systems including Alexa, Amazon.com, and all Amazon fulfillment centers. Last year, over the course of our 66-hour Prime Day, these sources made trillions of API calls and DynamoDB maintained high availability with single-digit millisecond performance, peaking at 89.2 million requests per second.
And since 2012, we have added so many innovations, not just for its underlying availability, durability, security and scale, but ease-of-use features as well.
We’ve gone beyond key value store and now support not just a hash-based partition but also range-based partitioning, and we’ve added support for secondary indexes to enable more complex query capabilities —without compromising on scale or availability.
We also now support scalable change data capture through Amazon Kinesis Data Steams for DynamoDB. One of the things I strongly believe with any database is that it should not be an island; it can’t be a dead end. It should generate streams of what data changed and then use that to bridge it to your analytics applications, or other data stores.
We have continued innovating across the board on features like backup and restore. For a large-scale database system like DynamoDB with millions of partitions, doing backup and restore isn’t easy, and a lot of great innovations went into making this experience easy for customers.
We have also added the ability to do global tables so customers can operate across multiple regions. And then we added the ability to do transactions with DynamoDB, all with an eye on how do you continue to keep DynamoDB’s mission around availability and scalability?
Recently we also launched the ability to reduce the cost of storage with the Amazon DynamoDB Standard Infrequent Access table class. Customers often need to store data long term, and while this older data may be accessed infrequently, it must remain highly available. For example, end users of social media apps rarely access older posts and uploaded images, but the app must ensure that these artifacts are immediately accessible when requested. This infrequently accessed data can represent significant storage expense for customers due to their growing volume and the relatively high cost of storing this data, so customers optimize costs in these cases by writing code to move older, less frequently accessed data from DynamoDB to lower cost storage alternatives like Amazon S3. So at the most recent re:Invent we launched Amazon DynamoDB Standard-Infrequent Access table class, a new cost-efficient table class to store infrequently accessed data, yet maintain the high availability and performance of DynamoDB.
We are on this journey of maintaining the original vision of DynamoDB as the guiding light, but continue to innovate to help customers with use cases around ease of querying, the ability to do complex, global transaction replication, while also continuing to manage costs.
Q. What might the next 10 years bring?
When we started with DynamoDB ten years ago, the cloud itself was something customers were just starting to understand better — its benefits and what they could do.
Now we live in a world where cloud is the new normal in terms of how customers are building IT applications, and scale is also the new normal because every app is being built to handle viral moments. DynamoDB itself will be on this continuous journey where we will continue to innovate on behalf of customers. One of the things we will continue moving toward is an end-to-end data strategy mission because, as I mentioned earlier, no database is an island.
Customers no longer want to just store and query the data in their databases. They then want to analyze that data to create value, whether that’s a better personalization or recommendation engine, or a forecasting system that you can run predictive analytics against using machine learning. Connecting the dots end to end, and continuing to make DynamoDB more secure, more available, more performant, and easier to use will be our never-ending journey.
