A Conversation with Evan Weaver, Co-founder of Fauna

Well, welcome everyone to our Cloudflare TV segment. So today with me, I have Aly and Evan. So I will let you two introduce yourselves. Sounds good. Sorry, did you did you say Evan or me start? Oh, you know, you go. Okay, sounds good. Sorry, Evan, I cut in line. So I'm Aly Cabral. I am director of product on the workers team. And I think what brings us all together in this group conversation is that we love building things that solve developer problems. And that's what we're going to talk about today. So I'm excited to do that. All right, Evan, I'll toss it to you. Hey, I'm Evan Weaver, co founder and CTO of Fauna. Fauna is building the data API for client serverless applications. I love the term client serverless is replacing client server. Yeah. Yeah, I think that's really, really cool. Evan, will you tell us a little bit about the origin story of Fauna? Like, why did you feel like you needed to found this company and solve the problems that Fauna solves? Yeah, that's a good question. Especially, you know, database companies aren't the easiest companies to build. And I think people who work in data in particular, usually, you know, there's some there's some love and joy in it. But there's also a sort of deep seated rage that things are never better than they currently are. I was employee 15 at Twitter, I joined early on and ran what we called the infrastructure team there. We built all the distributed storage for the core business objects. This is in the hyper growth days, like 2008 through 2012. And at the time we had looked at, you know, off the shelf data solution, SQL, we use MySQL extensively as Twitter's first database. And, you know, a lot of my background was MySQL performance optimization. We also invested a lot in Cassandra, we looked at Mongo and Redis and use Memcached and other, you know, early NoSQL solutions. But what we didn't have in Twitter was the kind of platform that would let us, because we were a small team, especially when I started, there were only like five or six engineers, kind of the first cohort of professional developers in the company, and we just wanted the site to work. But there wasn't any off the shelf tooling that would let a small team like us build and ship a consumer application to global scale, we had to re-architect everything, you know, on an annual basis, essentially. And it was very expensive, it was very, you know, problematic in terms of resiliency, but also even more problematic in terms of developer flexibility. And we knew that based on our experience there building these purpose built solutions for Twitter .com and the API, there wasn't anything in information science that required you to have to re-architect these systems. And we wanted to, you know, take that experience basically and translate it into a general purpose platform instead of the purpose built, you know, essentially, table by table, business object by business object distributed storage solutions we had built for Twitter, which were very, very fast, but very, very brittle and very, very inflexible. Ali, you come from a distributed data background as well, right? Can you tell us a little bit about that? Well, I think that it's funny because people somewhat idealize the past and then somewhat kind of like want to disregard the past and move forward with the future. And one of the things that I think is really interesting about how the market is shifting overall is a lot of like legacy databases were built for a different world, like a different world where your application developers had like different wants and needs, but so did the users. Like we talk about like when MySQL or when Oracle or when Postgres or others were like all kind of like the genesis of those databases, we're talking like 30 or 40 years ago. And not just like our world looks different, but the software landscape looks different and not just that, but like our users look different. One of the things I like to say is like, we've never seen users that are more latency sensitive, not just like applications and software, but like users that care about their online experiences because online experiences now are like the window to the rest of the world. And in a very real way, especially now, like this is our window. This is how we connect with people. This is like how we live our lives. That wasn't the case 30 or 40 years ago. Like most of our life was outside of like a computer, outside of a smartphone in my pocket. You know, like, so the users kind of have demanded a change in the software and put a lot of pressure on applications and thus application developers to go build new and interesting things that are both conformed to the needs of latency, but also that, you know, like our users are less forgiving of downtime because when they're disconnected from an application, they're disconnected from the whole of their life. You know, like software like is such a part of our lives now that downtime is just like not a thing that people can kind of like, you know, get behind or become okay with. So I think that like a lot of these databases are built with this modern world in mind where we have like a different audience and we have a different set of developer needs coming from that. What I think is interesting is not only users' expectations have changed, but users themselves, like the demographics are different. You can no longer assume that all of your users are necessarily in North America where maybe, yeah, the performance is pretty tolerable. Yeah, I think more and more developers care about their users outside of that realm as well. Evan, what were you going to say? Yeah, I agree. You know, latency was part of the Twitter experience too because Twitter was the first, you know, big consumer social network to be built for mobile. Yeah. And, you know, Facebook followed broadband penetration, basically, and also had very vocal users going to school. But everybody here, people do care more about resiliency than they did, for example, in the Twitter whale days where, you know, is it nice for Twitter to be up? Yes. Is it life or death? Probably not. Usually not. People still get paid. They can still go to work. And now for services, you know, financial services, employment services, Zoom, Slack, what have you. If those things are down, it's an existential crisis for people. And that's one of the things we wanted to fix with Fauna. We knew you can build a global data API that would let you serve customers, users all around the world. Everyone's shipping their apps to a global audience now. And do it with resiliency, with correctness, without having to give up the stuff you expected to get when you had like a, I don't know, like a cold fusion and side based box like in the closet of your workplace. But, you know, like everyone works from everywhere now, especially with the transitions we're going through globally with COVID. I think it's, you know, we've found that our growth has only increased. And I think that speaks to kind of how rapidly some of these transformations, both in behavior and in development methodology are happening. Yeah. And there's also been this shift with cloud. So like we used to, you know, my first job out of college was at IBM. IBM makes a ton of money selling huge machines that are like mainframes that people spend millions of dollars on. That's not the reality anymore, right? Like people are running on the cloud and commoditized hardware, not on huge mainframes that are maybe more reliable, but also a single source of failure. When those mainframes do go down, they go down in real ways, taking your entire business with it. Whereas the push to kind of cloud and commoditized hardware, you're actually building things with the expectation that some parts will fail. You can't make these assumptions that, you know, I have a single source of failure, but it won't ever fail in the mainframe days. And I think that's also kind of forced a shift here too, with how we think about and how we talk about resiliency too, being more about like, at any point, some part of my system can fail. All of this needs to be resilient. Otherwise, my customer experiences or my user experiences in jeopardy. I think all of those things are really, really interesting. Yeah. So how do you think, how do you guys both think applications have changed at all? Or like, how are these new technologies kind of like impacting or solving these problems for folks? I mean, what we've seen is, you know, I feel like, you know, we're at the beginning of a new revolution, a new methodology and development. And I think we get these about every 10 years. And I kind of grew up, so to speak, initially in the LAMP era. And the big innovation was that you didn't have to call Oracle on the phone to get a database, right? You can do everything with open source. You can do it on your PC. Nobody had laptops. But, you know, you can do it for free. You didn't have to go through these gatekeepers to build something. And we got, you know, the beginnings of the web, I really grew up on those tools. And the tools are very immature, you know, from a CES perspective, they were basically garbage, but they solved a productivity problem. And then we sort of had an iteration of that in the, you know, that was the 90s. We had an iteration of that in the O's with the Agile era and things like Rails and JTW and Hibernate, you know, now made it more productive to model your data. You weren't just throwing a SQL query behind a single PHP page and that kind of thing. And you can do more dynamic Web 2.0 applications. Then we had another transition, which is, you know, dear to your heart, Oli, with Mongo, Meanback, rendering, you can do more sophisticated UX experiences, but business logic by and large stayed server side, you know, running adjacent to the database. And what we've now seen is a return, you know, to the early 90s, except instead of having these rich clients' workstations talking to the database in the closet, you know, rich clients everywhere, and people are building and shipping consumer and SaaS apps to this like global compute fabric, which is on the edge. And now that calls back to APIs, just like, you know, your desktop applications or your Microsoft Access app or something would be calling back to internal APIs. And one of the things that is really interesting is, you know, in each revolution of the stack, you know, the motivator is always productivity. People need to get to market faster. They have fewer resources. They're trying to do more, build a more polished user experience. Like, you know, Twitter 1 .0 is rounded corners on a text area in an HTML page. Like, that was it. Like, you can't do that and build a business anymore. You have to really do it. You have to have, you know, billing and SaaS and like telemetry and all this like business stuff, product stuff for good user experience. You have to shift to multiple mobile platforms and have a responsive web app. And there's just too much to do. And that pushed users and developers to look for these more productive platforms of which, you know, I think client serverless is the overall trend. But then we have things like Jamstack and React.js and GraphQL within it, you know, sort of staking out their version of the tool chain, what they believe is the best user experience, the best development experience. And it's really about, at the end of the day, that ability to build a polished, a complete consumer or SaaS or, you know, IT application without having to do any operations or server side code whatsoever. Yeah, I think one of the really interesting things about this evolution as well is that with every paradigm shift, the technology became somewhat more democratized. So it allowed a smaller and smaller organization to become less efficient. And I think one of the things that's really interesting about this latest iteration, I feel like, or as you say, there's been this drive towards productivity, but it's not only capability. It's not only can you be more productive, it's who can be more productive. And to me, one of the really interesting things about Jamstack and GraphQL and everything being built off of APIs is that it's opening up this development world to, for every developer to be able to be like a full stack developer kind of more truly, and it is more accessible to front end developers who are familiar with these paradigms, and then like back end developers can also more easily build all this stuff. Yeah, it makes it more accessible, like the full stack more accessible to every persona, like every developer persona out there. I think that's definitely true. Yeah, I mean, I mean, I think the first language I learned was was quick basic on a PC, and people are learning JavaScript in the browser now and that's their that's their window into the world of development. You know, we've seen, you know, especially in the Jamstack community, like, you know, we're not we're not really like, you know, fun is a great database, but like our pitch is not, you know, fun is better than some other database. Fun makes dynamic applications possible. And that's the news, like, because these people, they've no experience with building such a complex application, they start from a static mentality, similar to how you might write a shell script or something. And then, you know, you learn, I can connect to the Internet and I can do more than just run locally in one process in one browser, that kind of thing. So yeah, I think the fact that browsers are ubiquitous and PCs and even some of the mobile development, the web repels and environments and low code environments and that kind of thing are really pushing, pushing and expanding the audience of people who need these tools. Yeah, and definitely most modern applications as they exist today are distributed in some way, whether that's you have some functionality on a phone, a mobile device, you have some functionality in the browser, and then some that lives in a serverless platform, maybe some that lives on the edge, you know, like just a ton of like different. There's so much that goes into any kind of experience in software today. Have you seen developers embrace learning more about distributed systems or do you think they look to tools to kind of like abstract away those choices and make choices that you like that are the best for them in applications? Yeah, I think developers are embracing product development. In the Twitter days and before, it was cool and fun to have to like fight with these archaic databases to get something to scale, but now people are kind of over unless they're a specialist, like learning about scale for its own sake or distributed systems properties. And they just want their application to work. They're looking for API switch, which make that possible. And that's why, you know, for Fauna, we have to deliver an API, which is global, which is correct. So it doesn't matter. Oh, did you query US East one or some other like replica, which isn't consistent? Oh, you know, where's the slow log, you got to go optimize this query because it killed the rest of your cluster. That stuff just interferes with with building product and getting into market. And I think one of the things which has changed is in product scale even faster now than they ever did before. So you just don't, you know, the conventional wisdom, which wasn't even really true. You know, when I was working in Twitter, but the conventional wisdom was if you, if you say you're a startup, like you build a new product, you find product market fit, you start to grow, oh, you'll have time to re -architect. It doesn't matter if the tools you use don't scale. But we arguably didn't have enough time in Twitter and survived by the skin of our teeth. And now, you know, if you if you can't scale, if you can't deliver a good experience out of the box, your customers will leave. I think people are really, really looking to outsource that. Similar to the way, you know, I think there's there's interest in open source if you're a specialist in some domain, but we see less interest overall in demand for like a pure open source stack. Like if you're not going to operate the software yourself anyway, what good does it do to have access to the source code? You don't develop that expertise to do anything with it. Yeah, I think people are looking to platforms that they can grow with, right, not platforms that they'll quickly outgrow and, you know, have to rewrite or re-architect their entire application because of it. We like to think of Cloudflare Workers as a platform you don't have to graduate out of either, where some other serverless platforms may have that kind of, you know, market perception, at least. Yeah, speaking of that, like how do you feel about the tradeoff between configurability and ease of use or like onboarding friction or whatnot? Like what, how do you decide what concepts to introduce to developers and when, what's important for them to know and what will just slow them down? I mean, I think that's a tricky question and Fauna kind of came at it from the other direction. You know, Fauna, like maybe it used to be the classic Silicon Valley play, but it's not anymore. Like we built tech first and then took it to market. So a lot of the usability has been, you know, a later addition or evolution of Fauna compared to the core technology with the global low latency transactionality, the multi -tenant, you know, free forever cloud service, that kind of thing. But what we've seen, this partly drove our adoption of GraphQL. Like even though open source isn't as important as it once was, open standards are still important, specifically because they eliminate the learning curve to get to getting started. And so most people with Fauna, you know, they come in with GraphQL, they like it, they start to build something to get that experience of success. And then, you know, they have the sort of the activation energy to start exploring the more sophisticated parts of Fauna and the non -standard capability like Fauna functions, where you can write any kind of business logic you please in FQL, the database language. And, you know, there's things we need to do there still to make it even more intuitive, more conventional, more familiar to people. But broadly, I think that's sort of the play we typically see with other vendors too. Like users are committed to a standard, it gives them some peace of mind about portability and the investment they're making, both in their product and their career. They'll come in and try that out. And if that's a good experience, then they'll start to commit more specifically to the value add of that specific vendor and explore the more sophisticated, I won't say darker, more sophisticated corners and aspects of the systems. Because especially in operational data, you know, at the end of the day, portability isn't real. Like you can't swap one SQL database for another and expect your application to still work. And people know this, but they want to be able to try and, you know, get a feel for what it's like to use both the software and the service. You know, the operational characteristics and the reliability before they make that commitment to learning the specifics of that particular platform. And you probably see the same thing with workers and WebAssembly and that kind of thing. I actually don't know this. How old is GraphQL and why do you think it's taken off so much and become so popular? I mean, I think it came out of Facebook maybe four or five years ago. There's sort of been a convergence in the ecosystem of a bunch of adjacent technologies and they've all kind of like been put together by the community into a stack. I think GraphQL, although it's not a query language per se, it serves the same purpose as SQL in that it gives you a data description language and a way to talk about the API and the endpoints and the capabilities you're building, which is common. But it's not just databases anymore. It lets you describe any API and it lets you decouple the descriptions of those APIs from their implementation. So we see it as being very important, you know, really at all layers of the stack because it gives you this common language and this common set of primitives to talk about your data. You have things like Gatsby that use it purely in the front end. You have a bunch of middleware vendors that are using it in like a traditional data virtualization capability that lets you mix and match APIs and let the product teams do what they need to do without having to have back-end teams go write Go services for everything. Then you also see it natively at the database layer where if you have new workloads, new applications, you know, you don't have a legacy commitment to integrating with some other data. Like, why not just use GraphQL directly? Why jump through some hoops to have middleware in the way? Yeah, I think that makes a lot of sense. So one of the things I really like about working on developer-facing products or software that helps developers build things is the scope of impact, right? Working on things that others use to build all the things gives compounding impact on your day-to-day work, which is really fun for me. In what moments have you been confronted with how powerful the software you're building is? Have there been any interesting moments you'd like to share? Yeah, I mean, it's always exciting to be surprised by the product somebody built on your platform or, you know, sometimes the bug they exploited to do something they weren't really supposed to do, but, you know, it got them to the next step in the application they were trying to build. I mean, I think, you know, the dream for Fauna is the same as the dream we had at Twitter. We wanted a platform that we could rely on and be product-focused and just ship to global scale without having to think about it. And every time that happens with one of our customers, it's very, very gratifying. You know, we see people who just have no interest, concept, need to invest in their backend. You know, they use Netlify or Vercel. They use, you know, Next.js or React directly or something. They do all their integration on the front end. They use Stripe, Twilio, Cloudflare Workers for backend stuff. They use Fauna for the database. It all works. And they're like, why would you do it any other way? Like, this was the easiest path for me to get to market, to see my dream become real in the world. I didn't have to become an expert in these disciplines, which are unrelated to that. And I think, you know, there's been, you know, for the last decade, you know, there's been lots of missed opportunities where people had product vision so they couldn't execute on just because the learning curve and the cost of the tools is too high. And I'm sure there'll be another revolution in due time if people will be like, oh, the serverless stuff is too hard to use. Like, oh, I don't know. Like, the new way, whatever the new way will become. But right now, I think seeing people who couldn't accomplish something that, you know, and like similar to the learning curve, like, you know, when they realize they can accomplish their goals, they get excited, right? So, you get to participate in the customer joy in the process as well. To your point about they find unexpected bugs and exploit them, what's something that was completely unexpected, not necessarily a bug, but that a customer built? I know for workers, sometimes I'll hear a customer build something, you know, completely blow my mind, like, oh, my God, I cannot believe that they thought to do this. Users are just so much more creative than you could ever imagine. What's something that someone built on Fauna that really blew you away? I mean, in the bugs category, I think somebody realized that reads against the schema are not build. And there's a comments field, you can attach arbitrary data to schema objects, and they're starting to store a bunch of stuff in the schema specifically because they wouldn't get charged for it. Fauna does not charge you very much. So, this is not an issue for our user base overall, but that was an unexpected quirk in the API, which is, you know, foreseeable in hindsight, but had to be addressed. At the same time, you know, we also see, you know, things like the, some of the more unique capabilities like temporality is a good one. Fauna is a temporal database, which lets you go back in time and query at different points. You know, it's interesting to see people use that to build a queue or in one case with the customer shift X, you know, one of the key features in their application is the ability to take your document, essentially, and look at it at any point in time. And getting that for free from the database is very gratifying for us, because that's the kind of stuff that takes, you know, tremendous amounts of work to build as a one-off in an app. And if you can just enable it directly and let people, you know, take these capabilities and expose them to their customer base and make their product better, then it's very satisfying for us. Time travel is always cool when we see people pick that up and use it in a product-centric way. That's really cool. I actually didn't know about that capability, and now I'm super curious to go check it out. We have a couple minutes left. So I would love to hear from both you and Ali. If you're building an application right now, or for so many people who are building things, like what would be the advice that you would give to someone starting out on their, like, new Twitter adventure? Yeah, so for me, I like to give advice that someone should think about what is the real differentiator for their application. So, like, what is the business value that they're looking to provide? And that should be the majority of where they spend their time, right? They shouldn't be, like, picking up tools and software to kind of build against if they're forced to spend most of their time on things that aren't actually delivering the business value for them. So that would be my core advice, at least someplace to start. Yeah, I think similar to that, one of the things... You have about 30 seconds of it. Similar to that, I would advise people to choose a stack and stick with it. Because, you know, if you choose, you know, a bunch of best individual tools that aren't well integrated, and you spend all your time on the integration, then you'll be much more productive if you pick a stack and stick with it until you have reason to deviate from those choices. All right. Well, thank you both so much. Thank you.