Escape the Cloud Database Trap With Serverless

Chris Anderson Feb 03, 2017

If you rely on any cloud infrastructure, you know it is complex. It promises to free you from hardware—but you still have to worry about regions, zones, volumes, memory, software versions, and CPUs. Migrating from one service to another, or even simply changing capacity, is often a manual, error-prone process.

When I cofounded the company that became Couchbase, there was no cloud. Databases were built for physical infrastructure.

Databases were built for physical infrastructure.

Now the world has moved on, but databases have not. Cloud databases are still constrained by provisioning choices. But when demand spikes, shouldn’t your database have your back? Isn’t that what the cloud is for?

The Earthy History of the Cloud

The cloud’s abstractions are rooted in the physical infrastructure of the past. A decade ago, public clouds were designed to mimic physical datacenters because developers were only comfortable with physical hardware. Today, that model is pure overhead.

Buy the ticket, take the ride.

Using the cloud forces you to become an operations expert. “Even after building for the cloud, my team constantly spends time thinking about capacity planning, provisioning, sharding, backups, performance tuning, and monitoring,” said Rudy Winnacker, Head of Operations at Medium. “Cloud databases still incur significant operational overhead. We’re happy to see Fauna reducing this burden.”

At Fauna, I regularly hear prospective customers say: “we were told everything would be scalable, available, and cheap in the cloud, but the operational work to meet those goals never ends.”

Dangerous Data Games

Stateless applications (like web servers) are difficult to configure, but once you figure out the concurrency model, hardware profile, and packaging strategy, you can scale them up and down on demand. Stateful services are far more challenging, and operational databases are the most critical stateful services. That’s why databases are at the core of the cloud operations trap.

Adding more database nodes accomplishes nothing without repartitioning the data. Some systems, like MySQL, simply don’t support partitioning, and only offer simplistic replication strategies. Other systems, like DynamoDB, can partition and scale up, but not down. Still more, like Cassandra, can scale both up and down, but are extremely difficult to operate and have subtle performance limitations at scale.

You shouldn’t have to turn away customers because your product is too popular, but an unexpected traffic surge is also the worst time to mess with your database infrastructure—this is the cloud database trap.

An unexpected traffic surge is the worst time to mess with your database infrastructure. This is the cloud database trap.

Instead, databases should be adaptive—fitting themselves to apps and workloads, not the other way around—and serverless—only charging for queries actually run, and data actually stored.

Serverless Can Save Us

When I heard about Fauna’s vision for a serverless database future, I was hooked. FaunaDB Cloud is an adaptive, serverless database, launching to the public today. With pay-as-you-go pricing, your database costs nothing when no one is using it. Combine it with a function-as-a-service provider like AWS Lambda or Google Cloud Functions, and your entire cost structure scales dynamically with usage.

A serverless database costs nothing when no one is using it.

You can also run FaunaDB in your private cloud or own datacenter, eliminating infrastructure lock-in. The query language, data model (including graphs and change feeds), security features, strong consistency, scalability and performance are best in class.

An activity feed query in FaunaDB.

Move your database to the cloud, and you will find its operational burden still falls on your shoulders. But a serverless database vanishes into the network. Now your entire stack transparently scales up, down, and sideways—even across datacenters and different infrastructure vendors.