This early Twitter engineer has a suggestion for your next database

Commentary: If Fauna's founder Evan Weaver (Employee #15 at Twitter) has his way, we'll stop talking about databases and instead build with a data API, Twitter-style.

sdecoret.jpg

Image: iStock/sdecoret

Years ago, Tim O'Reilly talked about how cloud services might supersede open source by delivering greater convenience that was "open enough." Who needs source code if you can easily get the benefit of the software without the mess? Fast forward to 2020 and FaunaDB asks a similarly provocative question: Who needs the cloud when all you really need is an API?

That's perhaps an overly imprecise way of describing FaunaDB, which isn't so much source code-less and cloud-less as serverless: A data API for client-serverless applications. Or, as Fauna founder Evan Weaver described FaunaDB in an interview, the team wanted to take what they'd learned as early systems engineers at Twitter and "take Twitter's ability to deliver an API-driven data platform and marry it with the capabilities that were missing from relational and NoSQL operational databases." 

So...the power of a database, but without the hassle. Just one data API in the sky.

SEE: Special report: Prepare for serverless computing (free PDF) (TechRepublic)

Like Twitter but without the politics

It's hard to overstate how much this Twitter experience has shaped Weaver's thinking. As Employee #15 at Twitter, he built the early distributed storage for the core application. Throughout it all, Twitter's system engineers chewed through a variety of options (MongoDB, Apache Cassandra, Redis), each time trying to get closer to a general purpose data platform they could use to build Twitter.com.

Intriguingly, as they fiddled and built, they noticed something happening within their external developer community, as Weaver remembered: "We saw Twitter's developer community using the API very, very aggressively, including doing programmatic things, not just scheduling tweets or exposing different client experiences, but really starting to use it as a general purpose data fabric or platform."

This kickstarted Weaver's thinking about what a database should look like. Or, rather, what it shouldn't look like: A database, for starters. 

"We're building a data API that helps small teams--like we were at Twitter--to build and ship different kinds of applications (consumer, B2B, etc.) at global scale without having to become distributed systems experts or DevOps experts or really need to develop expertise outside their core product development." The road there? Serverless.

Our goal is to have no operational burden whatsoever for anyone using Fauna in any capacity. Fauna is exposed as a web-native, secure global API. You don't think about provisioning. You don't have a container that spins up or down for your particular tenancy scope or anything like that. It's just the way you would consume the Twitter API as a developer. We didn't create a VM or racking machine for each developer who wanted to interact with Twitter: it was a global platform with dynamic isolation across clients.

Plug in, get data, move on. But will developers miss the freedom they get from open source?

A post open source world

"The world has moved on from that," said Weaver. "What we see with our audience in the serverless space and the JAMstack space, is that people aren't interested in ownership of the code. They're happy with a cloud solution. They don't want to operate the code." Instead of free software, he said, developers are looking for free development plans or other ways to interact with code at the same cost as free software, but without the burden of managing it. 

SEE: Serverless computing: A guide for IT leaders (TechRepublic Premium)

While "In the early days the conventional wisdom was that infrastructure has to be open source to get adoption, and that being open source would magically get you adoption. Such things might have been partially true at the time, but they're less and less true all the time." As such, "It never added up for us to become open source. As long as you give developers an API that's open and a cost model that works for them then they don't care. They just don't want to operate anything."

For this to work, Fauna must deliver on its promise of being dramatically easier than the traditional database. And, even if theoretically easier, why would a developer familiar with Postgres or MongoDB or any other traditional database choose to embrace this new data API approach?

The answer might well be that Fauna allows developers to think in terms of "and" rather than "or" when choosing their database, Weaver said. Though Fauna is great for SaaS or other applications that need to be global from the start, it might be even more appealing for those stuck with augmenting static or semi-static sites, or applications with messy infrastructure. Instead of futzing with the database (MySQL, whatever) that is storing their content data on the back-end, a developer can add Fauna to the front-end and build there, without disrupting the existing back-end architecture. If you know GraphQL, which Fauna supports, you're ready to roll.

But will developers roll with this new model? Time will tell, but Fauna has been moving swiftly up the database popularity charts, according to DB-Engines. Yes, it has a long way to go, but the Fauna team believes it has the right model for today's developers.

Disclosure: I work for AWS but the views herein are mine and don't represent those of AWS.

Also see