Brendan Downing: Hello, and welcome to PodRocket. I'm Brendan, I'm your host. And I'm on the engineering team here at LogRocket. Today our guest is Rob Sutter, Head of Developer Advocacy at Fauna. Rob recently gave a talk at Serverless in the Park about building data-driven APIs at the edge, so we are excited to dive into that and hopefully some related topics in Serverless as well. Rob, welcome to the show. Thanks for being here. Rob Sutter: Hey, good morning, Brandon. Thank you for having me. Brendan Downing: I thought before we talk about APIs, and functions, and all that good stuff, maybe you could quickly sort of introduce yourself to our audience, talk a little bit about sort of your story and how you got here. I know you've been a founder, you've worked at Amazon on Serverless stuff, so maybe story tell a little bit about what's led you to this podcast as the culmination of your career? Rob Sutter: Yeah, it's been a wandering path through the woods and I certainly wouldn't recommend it to anybody else, even though it's worked out well for me. the first time I put code into production was in 1995, that was Visual Basic at Royal Insurance Company, so that was hefty code, but it's been a while. I'm going to fast forward a lot to 20 years later when I really came back to tech and that's 2015 and that's when I co-founded Workfone, which was a software as a service startup as you mentioned. Workfone was virtual mobile infrastructure, so most people are familiar with virtual desktop infrastructure like remote desktop, Citrix, almost everybody who's worked in a corporate environment, knows it and has used it. Well, this was the same principle for mobile devices, so if your mobile device was lost or stolen, there wasn't really anything corporate on it. Rob Sutter: You just revoke access and there's really no harm or risk to the company coming out of it. The technical thing that was interesting about Workfone, there were a lot, was that it was a multi-region Cloud application way before people were thinking about doing this, right? Like even today multi-region on Cloud is pretty painful. And of course, 2015 to 2017 Edge computing as a concept wasn't there yet. And so the idea that you could run the same workload in more than one place, wasn't really something that the Cloud service providers had considered. And so we had to cobble a lot of that together, ourselves. It involved learning a lot about networking, and IPSec, and VPNs. And we were already doing all of these interconnects with mobile virtual network operators, so there was just a tremendous amount of undifferentiated, heavy lifting to get to the starting line. Rob Sutter: That's really informed a lot of what I've done since and winding up at AWS, as you mentioned on the Serverless team as a DA was sort of a, we love this word don't we, orthogonal step forward in my career where it was more the application integration side, and step functions, and event bridge in particular, but it was still tied into one region. And then when I came to Fauna or more accurately, when Fauna approached me and started talking about, well, we're a distributed database across multiple regions that you just turn it on and it's there, it's a single API call. I immediately got it, right. A, where were you seven years ago when I needed you? And B, the value proposition was immediate and clear for me. I was excited to come over and tell more people how they could run their applications in more than one place. Brendan Downing: Yeah. And I guess you've now been in dev advocacy for a while. I would love to hear sort of a little bit more about how you see your role as a dev advocate and dev advocate leader, and sort of what appeals to you about doing that job every day? Rob Sutter: Yeah. I'm kind of a spicy dev advocate, so this may not be the mainstream take, but I'll try to keep it valuable for listeners, right? The main thing that I'm here for is to help companies understand what developers need to build, and to help developers understand how to build with what companies offer. And that sort of informs all the other aspects or dimensions of developer relations or developer advocacy that we can talk about, where do I think it should live? And how do you approach it? What are your goals? What are your metrics? Let's take that first one. I think it's pretty commonly understood today that developer advocacy should either live in marketing or should live in product. I don't come down on there being a right answer here, much like anything, if you've been in your career long enough, the answer is it depends. Rob Sutter: Companies that understand how to market effectively and then understand how to measure their marketing effectively are probably going to be more effective at having their developer relations function inside the marketing team. Companies that thrive on customer feedback in a meaningful way that are really willing to say, oh, well, here's our 18 month roadmap. And we're now going to throw it away because we've gotten consistent customer feedback in a different direction. That type of company is really going to thrive having developer advocacy underneath its product team, because that is the value of an experienced DA is what does it feel like build with this product? And what do I want it to feel like to build with this product? And if the product team's willing to hear that message, then it can be really powerful. And just by way of quick caveat, both at AWS and at Fauna, I was in the product work. AWS has both, Fauna does not. Brendan Downing: Do you feel like that's sort of, obviously at AWS and at Fauna, you're working on pretty heavily developer focused like platform as a service type tools, do you feel like that leads more towards that developer advocate sitting in the product org versus maybe more of a like B2B API product that's less platform focused or do you think it really just has more to do with the organization? Rob Sutter: Maybe. I want to say yes, that it does. And I think there's a part that you're being too kind to mention here that both AWS and Fauna are extremely complex products and they have to be, the developer advocate's role is to make sure that they're not complicated products, right? There's an essential complexity to these products because they're making opinionated decisions for you all the way up the stack until you get to a point. Each one of those decisions has artifacts that leaks through to the next layer where the developer interfaces, and only by building at that layer, can you say whether you're making the right abstractions or making the right decisions and exposing the right amount of complexity while avoiding unnecessary complication, so one of the things that I love about the role back to your first question is that there's a large educational aspect to it. Rob Sutter: People say, if you didn't have to worry about money, what would you do? And I always answer education. And I think that's how I wound up in developer advocacy, right? Because you're taking a very... at least with AWS and Fauna, you're taking a very complex topic and breaking it down, there's a pedagogy to it, right. There's building it up from first principles, from things you know, there's elements of storytelling, there's layering in only one change at a time, and guiding readers or viewers, listeners, builders along a path in the way that they want to be led rather than in the way that you want to force that information on them. And that's one of the things that I think I enjoy the most. Brendan Downing: Yeah. Maybe too pointed a question, or maybe a reductive question, but do you need to have been a developer to be a good developer advocate? Rob Sutter: Well, I can't wait for this thread to blow up on Twitter. It depends. Brendan Downing: Great answer. Rob Sutter: I would say to be a product focused developer advocate or a DA in a product team, you absolutely have to, right. You have to have burned your hand on the frying pan a few times to know how to make effective safety equipment, right. Otherwise, you're doing it in a vacuum. Now, do you have to know everything or be specific to the topic at hand? No. And in a lot of cases, it can be helpful to say I've been an engineer my entire career, but this thing that I'm now a DA for is new to me, that was my case when I came into the database space, right. I had used databases, but I never built a database. And in a lot of ways, I think that's been advantageous for me because I don't care about the underlying technical constraints. Rob Sutter: Don't ship those to customers, right. I care about what it feels like to consume a database, to store my data in the database, to retrieve it, right. I care about that aspect, and I'm deeply familiar with that aspect, and so I can give that valuable feedback to the product team. Whereas if I say, well, okay, listen at company X, we built our data store with blah, blah, blah, that's not helpful. Especially in this role. Now the marketing side, I want to be really careful here because I don't want to get into a disparaging conversation. And I think I've seen this conversation occur, and I think it's garbage. I think the gate keeping aspects of it are absolutely garbage because you're either taking an engineer and asking them to scale up or to skill up on marketing, which is a complicated discipline, or you're taking someone who's already skilled up in other aspects of a business and asking them to skill up on engineering, also a complicated discipline. Rob Sutter: And there's no reason to expect that anyone should be better at one of those than the other, or that one of those adds more value than the other, it's about fit. And so if you're in a company like you've talked about where the API is more or less fixed, and you're helping educate people on how to build with it and why it's effective for their use cases, what does that sound like? To me, that sounds like empathy and empathy is a skill that can be developed across a lot of different career tracks, certainly not just engineering. And if you're bringing deep empathy to that role and skilling up on the specific technical details, then I think that's a valid path as well. But I do think there is that bifurcation between if you want to be a product focused DA, you need to at least be able to dig down the layer and understand why product decisions are being made from an engineering perspective. And I think it's extremely difficult to do that without having shipped code, without having an engineering background. Brendan Downing: Let's dive into some of the interesting tech here. We're probably going to go pretty deep on some specific technologies and problems related to Fauna and Edge computing. Before we do that, I thought it might make sense to set the table for the audience and just sort of define some of the terms and concepts here, so what do we mean when we're talking about serverless systems? What do we mean when we're talking about compute at the edge? And why are those things that I, as a web developer should care about? Rob Sutter: At its core, serverless is about only doing things that add value, and only paying for the value that you add. And I always thought AWS had a good definition of it. There was a slide X access, Y access, four quadrants, and one of them is no servers to provision, run times to manage. One of them is pay for value. One of them is automatic scaling without intervention. Sorry, I should hold my fingers up higher for viewers. And the fourth is secure and highly available by design, right? And that's one way to think of it. If you're a pancake stack thinker, then everything below your run time, like no-js, et cetera is taken care of for you. No-js what version you can specify that, but patches are applied. What operating system is it running on? It's irrelevant to you, but it's there. Rob Sutter: It's managed, patches are supplied, what hardware, et cetera, all the way down to the like where does my power come from? And all of that stuff you give up and everything starts with an event. A user has sent a request to my rep, to my website. And it's literally an HTTP request object that you get, all those other things you don't have to think about it. It's okay, that user sent a create shipment request with a shipment event in there. I need to process that, store in the database, and return to them and say, good to go. Or whoops, there was an error. And all of that, that you just thought about is domain logic, right? It's what is your company's value proposition? That's where you just spent all of your time. Your company's not going to beat the competition by patching its servers faster. Rob Sutter: It's only an opportunity to fall behind, right? You can patch your server slower and create problems for yourself, but you're not creating customer value by doing it better, so don't do it, let a professional service do it. And that same thing applies to Fauna, right? All of those principles, the four quadrants that I talked about apply, the idea that how many shards do you need? You don't, that's not actually a thing that we even do, right? You just write and retrieve like you do with Stripe or Twilio or any other API that you're used to consuming. What version do you need to be on you? You don't. Is it patched underneath? It is, you don't need to worry about it, we have it. And you know, we're not just asking you to trust us. We have SOC 2 Type 2 and other audit and compliance frameworks that are available for our customers, so it's not just a Hey, trust me, I got it. And we don't do it. Rob Sutter: It's that added value up the chain. And if you want to write a hundred thousand transactions per second, or if you want to write a transaction an hour, we can support both of those. And you're just going to pay 100,000 times 60, times 60, more for a hundred thousand transactions per second, right. Math, I can't do math off the top of my head, but it's a lot. But it will scale it, it follows those same principles, it scales underneath. Now the Edge, I think was the second part of your question, right? Brendan Downing: Yeah. Let's talk about the Edge. Rob Sutter: The Edge is, let's compare the Edge to classical serverless computing for a second there. In the archetypal classical Serverless service is AWS Lambda, right? Just put your compute there in the region with the rest of your workload, run what you need to run when you need to run it, and don't worry about the rest. And that's great and very effective for the workloads that it's very good at, and has a well deserved place and growth amongst computing workloads on the AWS. It's a fantastic service, but your users aren't in your region all the time. They're certainly not inside your VPC and they may not be in your geographic region, but they're certainly not in your AWS region. Rob Sutter: And this is where Edge compute became a thing. Your users are closer to points of presence. And AWS themselves recognize this when they pushed out Lambda@Edge, which was more of a request mangling and response mangling framework than it is a full compute service. But then other entrants like Cloudflare Workers in particular is the one that's probably garnered the most attention said, well, look, we're already at now 275 points of presence around the world. We're right there, sub millisecond for you. What if we gave you an option to compute right there as well. Brendan Downing: And when we say points of presence, we're usually talking about literally physical data centers. This is where your traffic goes to get onto the big sort of internet backbones. Rob Sutter: Right, so if you think about from my house, I happen to know that my point of presence is in the Bronx, right? CloudFlare literally has a big old data center right there, where, from my ISP into there for people that use CloudFlare or for Workers, that's where all these requests are handled. And when you think about speed of light there, it ain't much. I'm in New York Metro, so it's right there. Even the difference between that and Northern Virginia, where US-East 1 is located, which is my closest geographical AWS region. It's pretty significant for some workloads. It's not the kind of thing that I can necessarily detect as a human, right? The lived experience of browsing or playing a game or something. But it is the kind of thing I can detect if I'm over in Seattle or something like that, or even further away, right. Rob Sutter: And that gets worse and worse the further you spread out around the globe, but with 275 points of presence, there's always going to be one closer to you. And there's a lot of strategies beyond this, but that's your first point of interaction with the application. And so if you're getting these sub millisecond or low single digit millisecond responses, as humans that's impossible for us to pick up on and comprehend. And I keep saying, as humans, as people, comprehension, noticing. And I think this leads into like, what are the use cases for this as opposed to something else? And human involvement is probably the first. Brendan Downing: Right. And I think I'm sort of remembering when Lambda@Edge came out and like you said, it was sort of a very limited product, like you could sort of manipulate a simple subset of the fields and HTTP request, proxy that through, and that was kind of the entire service it provided. And obviously there's times where you want to do that, right. Maybe just adding a header saves you a roundtrip to the server. But I think as you're alluding to, there's a whole bunch of sort of more complex and richer problems that we might want to solve at the Edge that these sort of first generation Edge computing products were not solving, so maybe what are some of these examples of problems that lead us towards Fauna, where the sort of just simply running some code at the Edge wasn't enough? Rob Sutter: Right. I want to go back and be kind to the Lambda@Edge team for a minute, because I have used Lambda@Edge in production and it's limited, but you got to keep in mind when it came out, just like any- Brendan Downing: Oh, it's unbelievable. Rob Sutter: Yeah. Brendan Downing: It's like being able to do that and not have to have it go all the way back to your servers, it was like life changing for me. Rob Sutter: Yeah. Yeah. It had its downsides, its rough edges, but it's also like when we compare Fauna to other databases, which I'm not going to do here, we do that privately. You can't be confrontational, aggressive, or dismissive about it, right? Like you've got to look at them in the context of when they were built and how revolutionary they were. Even some of the more recent ones that are like 10 years old and starting to show their age now, they're starting to show their age because people started doing things with them that they never imagined when they were designed. And when they were designed, they were the best thing in the world at the task they were designed for, right. But you do have workloads that evolve directly to your question that makes something like Fauna more applicable, whereas other solutions aren't. And the first use case that you're going to look at is anything where time is money, right? Rob Sutter: And this is where you get into like perceived experience or I like to talk about it as lived experience, right? If I'm the customer, I click on your website and it's slow to load, I don't care what your monitoring told you the request time was. I care that my actual lived experience was that your app was slow and in some cases I'll abandon, right? There's the big famous study, I always forget the reference, but it was every hundred milliseconds of added latency results in a 1% decrease in conversion for online, for eCommerce, for a lot of businesses that matters, for a lot of businesses going from Seattle to US-East 1 is a hundred milliseconds. And so in particular, when you think about like population distribution in the US, and I don't want to make this geocentric to the US, this applies on the whole world, but it's just where I live, so it's easier to talk about it. Rob Sutter: The US population is distributed out to the coast, statistically. Yes, people live in the middle, but when you're doing things on margins and looking for statistical gains in revenue, you're going to improve the experience where people live the most, so there's also not very many data centers in the middle of the country that you could use. Now you need to go out to this concept of, okay, in general, if I can have my application respond from the closest place possible for every customer, I should see my conversion rates increase. That's one, another is simplicity. And this happens in a couple dimensions. And I want to talk again very carefully because this is not negative against Lambda, but I want to talk about as Lambda has matured as an offering, there are tons of configuration options on it. And they're all there for a very good reason. Rob Sutter: That very good reason is that AWS is customer obsessed and customers asked for those, but it can be overwhelming, but they're necessary. Let me talk about a use case that's not good for Edge functions. Then we'll come back. That Lambda addresses and that's all of your compute is centralized, all of your line of business applications that are happening inside your region, where the data's being generated, where your workflows are running, where your batch jobs are running, that aren't related to receiving input from all over the world from mobile devices or anything like that. Your simulations, if you're in financial services and you're using data to run Monte Carlo simulations to project what your next trade should be, why would you push that out from a centralized location to a decentralized location that's not designed to run it and try to run it? Rob Sutter: When you look at a Worker, for example gives you, what is it? 50 milliseconds of CPU time to complete on a standard basis, and Lambda gives you 15 minutes. When a Worker limits you to 128MB of RAM, Lambda gives you 10GB, right? That's why it's complicated is because it's offering all of these hidden things that when you only look at web and mobile apps, you don't think about, but that are crucial to running businesses, compliance, KYC, inventory management, all kinds of workloads, those should be centralized. Back out at the Edge, you don't care about that, you're you're having that human interaction and you're browsing the website. You're adding an item to your cart, you're trying to check out, and the more of that you can do as close as possible, the more effective you're going to be, or the happier you're going to be as a user. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers, so check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show. Brendan Downing: And I think we're kind of circling in on the thing that's like classically hard about this, right? Why haven't, this seems obvious why haven't web applications done this since the beginning of time, since the nineties. Rob Sutter: Yeah. Brendan Downing: And I think generally the answer is that the data part of this is very hard. Rob Sutter: Yeah. Brendan Downing: Can you sort of start talking a little bit about that? Rob Sutter: Yeah. And it's still hard. One of our co-founders Evan talks about how we have a technical marketing challenge because this problem is so hard and has been so hard for so long that a lot of times people don't believe we can do what we say we can do. And so when we talk about it, they just dismiss it because the patterns that they've known for good reason for decades don't allow it. And I'll give you an example, right? If you have 275 points of presence and a database in one region, you still have that latency gap to contend with, right? If you can do simple things that don't require state or data at the Edge then hooray, but how many of those things are actually functional and useful for your applications? The answer is very few. You need the data. Rob Sutter: In Fauna, we address this with the concept of a region group. And this is where, for example, with the US region group, we have you on the east coast and west coast distributed replication. And that means that you're moving this sort of, I hate this metaphor and nobody's given me a better one yet, onion like architecture, or maybe it's a tree like architecture, but you're moving in a level so that the parts that can be handled directly at the Edge without state are very snappy. The parts that need to come in are now only coming into your nearest region. And again, if you're in Seattle, that's US-West 1 or US-West 2, if you're on the east coast, it's US-East 1 or US-East 2. And now you're at a much faster experience, how do you get that state consistent? And that is the absolute hard part why people don't do this, right? Rob Sutter: Because, other offerings throw their hands up in the air on this problem, somewhere. Relational databases are famously bad at doing this. If you want to have distributed replicas of a relational database, the pattern is well known. It's multi-phase lock and commit on transactions. First, the leader has to say, Hey, every replica lock this record, I'm about to write to it. And so you make cross country speed of light trips to every replica to get them to agree on the happy path, that's a cross country round trip to lock. You make the change, commit the change, send it around, release the lock, and now you're done. You can see now instead of like just having the one trip to a single destination. Now you've made all these trips across the country and it's actually worse performance, if you need that strong consistency and the asset transactions around it, which strong consistency and asset transactions are like the whole reason or most of the reason to use a relational database, right? Rob Sutter: You have those guarantees around the correctness of your data, so you need to scale up, and up, and up, and up, as long as you can add a bigger instance to it to guarantee it, but it doesn't help you with that replication, so the moment that you go into the replication land, you've given up all of those guarantees and the actual reason that you're fighting with a relational database in the first place. Enter the document database and enter eventual consistency, which again, like many things that came out of the mid two thousands brilliant approaches to overcome the limitations of the time. But they put a lot of load onto the developer. Listen, just write it, and it's done. It's done right there, single digit millisecond. Oh, hooray, that's awesome. What happens if I read it over here? Oh, right. And hopefully you've seen the cartoon right. Rob Sutter: Where the guy comes along to get the lady's cat out of the tree. And he like, instead of trying to climb the tree, he reaches down into the panel below and pulls the cat up and it's in the panel twice. And she's like, wait, what? And he goes, just wait a minute. And they go through the bottom panels and the cat disappears. And now at the end, everything is correct, right. That's what's happening when you're reading state from eventual consistency and all of that gets put onto the developer to manage. In a lot of cases this doesn't matter, like we have to be honest about that. A lot of cases, it doesn't matter if you make a product update on description content, there's a typo and you change it, and it's not like inventory of hard goods or fast moving consumer goods. Rob Sutter: Does it really matter if it takes a second to replicate around the world? No. But if you have a launch of new sneakers, limited edition, 50,000, and they're all identified by serial number and you expect 10 million people to come in and bid for them, you can't have eventual consistency there, right? Like each one needs to be accounted for strongly, individually, and committed as a transaction. But the thing is those 10 million users are all over the world, right? Fast moving consumer goods is a really, and especially the inventory management side of it is a really good use case for Edge and Fauna, because you're coming in to the system to get a quick, you want to know, otherwise you're going to sit there and reload and add more load to the system, which is, you're creating this vicious cycle, but if you have an architecture that can handle and absorb that load with strong transactions, you're actually helping the load manage itself, if that makes sense. Brendan Downing: I mean, this sounds like the story of all of the early, like COVID vaccine booking sites, where they were overloaded and people would then sit there, refreshing them and eventually just completely bring them down, trying to get the page to load in the first place. Rob Sutter: Yeah. Brendan Downing: It's that like classic web impatience death spiral. Rob Sutter: Yeah. Brendan Downing: But so I'm curious, I guess, to hear in that case what you're doing at Fauna that's different and how you're attacking this problem in a way that you think is sort of unique or innovative? Rob Sutter: Yeah, so for my deep readers and database theorists out there, I'm going to give you a link right now fauna.link/calvin C-A-L-V-I-N, for the origin paper. I'll give you that link again at the end of this. Brendan Downing: We'll drop it in the show notes. Rob Sutter: Okay, nice. Fauna is informed by Calvin. I don't know that we say that it's an implementation of Calvin, but it's certainly informed by it. Calvin is a 2012 paper out of Yale, a lot of people very much smarter than me at databases got together and realized that if you combine determinism and serializability in a linear fashion, then you don't need agreement. And this might sound a lot like functional programming, Monads and Actors and all of these things, right? And at its core it is, right. If you get to the point where you have essentially no un-agreed mutations, where every mutation has to be serialized, done in a specific order, then there is no way that any participant can get out of order and can get different data. What this means is when you, when you want to say, Hey, add or subtract this item from the inventory, you don't go out and lock that record everywhere. Rob Sutter: You get the agreement that listen, we're at transaction seven, transaction eight is going to be remove this item from the inventory, everybody good? And it sends that out with the act and that's done, that's your strong right, right. The transaction coordinator has serialized every request that's coming in. And if you get lots of these requests at once, then it just stacks them up and applies them in order. Ultimately, one of these may fail because you've run out of inventory. But the thing with deterministic serializability is the same one is going to fail at the same point on every participant, regardless of things like clock synchronization and all of that stuff, right? The transactions themselves are ordered. And to our listeners, this is going to sound one of two ways, extremely complicated or extremely oversimplified, and you're both correct because it's about context, right? Rob Sutter: If you're the user, just know that the order that you ask for things is the order that they're going to occur, and it's going to happen, and we're sorting that out for you. The Jepsen test was done. The Jepsen banking test, which is a test of correctness in databases, correctness and other things. You know, if you deposit $20, withdraw 10, deposit a hundred, withdraw a hundred. That's a very different thing from if you deposit 20, withdraw a hundred, deposit a hundred, withdraw 10, right. Order matters in these types of use cases. One, you get hit with a fee, it's not your fault. The other, everything happens and you have a balance, a positive balance remaining in your account. $10, if I remember correctly. For the database theorists and the people much smarter than me, who say, you just washed over a bunch of this stuff, I would encourage you to read the Calvin paper itself, as well as Dr. Daniel Abadi's blog on fauna.com/blog, comparing Calvin and Spanner. It's like distribution without clocks. We'll get that right in the show notes for you, but that's the general concept on it. Brendan Downing: And so I guess for probably the majority of us here who aren't database theorists- Rob Sutter: Myself included. Brendan Downing: When I zoom up to the developer level of what does it look like to interact with this database? Like, what's not my experience as a developer of, okay, I want to write a system that's going to do some transactions, insert some product IDs. Does this feel like a SQL database? Does this feel like MongoDB? Like what is the experience that I'm having as a user working with this tool? Rob Sutter: Yeah, so it feels different. That's good and bad. And we're working to address the bad ways. Let me talk about both. It feels different in a good way, because you make a single API call just like you would do response.send, or transaction.charge, you do FANDA.query, create database. And in about 40 milliseconds in the region group, you'll get a response. And what it's done is created a database that spans the entire region group and is available for you. And I want to spend a little bit of time talking about this because for competitive analyses lately, I've had to go through other platforms that I won't name, but a lot of them, and to get global you go anywhere from like five minutes to an hour if you're doing things like provisioning clusters yourself to hours, you could. Rob Sutter: And again, like there's no small amount of magic involved there, when they were designed that was an improvement. But you think about today in CICD pipelines running multiple times an hour and continuous delivery of things into production. And part of that for mature tech ecosystem companies is look, give me an entire new environment that just matches everything, spin it up with infrastructure as code, run all these unit and integration tests against it. If they all pass, tear it down. Now you can deliver it into the first of several laddered rollouts. 40 milliseconds and a couple hours are very different experiences in those pipelines. And that's like the heart of developer experience, right? What does that feedback loop look like? Rob Sutter: If you spin something up, load it up, and we're much faster at loading data as well, we've done recent tests. You're doing the exact same thing, this is the actual production database that you're doing this in, it's just a different production database. You're on the same platform. And if you can do that in seconds, minutes, pass or fail your test. Let's be honest, they're going to fail more often than they're going to pass. And you now know where and can start digging, that's a massive improvement in developer productivity. Now, there's always a cost, there's always a trade off. The trade off is we hinted at that, like the functional nature of that earlier. And Fauna's current query language, Fauna query language, FQL is a Lisp inspired, functional programming language. If that frightens you, we're bringing you another way. If you're like, oh yeah, I love Pascal. Rob Sutter: And I get this and I love Closure, and this is what I've been looking for. Come join us because it is every bit as powerful as you would expect. You get all the benefits of composition, you can write very simple fragments, unit test them, and then compose those fragments into very like arbitrarily complex queries and be confident in the queries because you know each component works individually. And then you only write your test against the entire component. This should sound very familiar to anybody who's been building in JavaScript on the front end for the past five years, right. Rob Sutter: And that's great. But the fact is what is that like 10, 15% of developers are really comfortable with functional programming. We're working on the next version of our query language, which is heavily inspired by customer obsessed feedback. It follows the document and object model that you're used to with dot notation for methods and fields, and it very much looks like GraphQL, JSON, TypeScript, all the things that people know, so sit tight with us. If you get in there and you get a little scared, DA's doing some education pieces for you to bring you along, but it's also going to get easier, it gets easier in two directions there. Brendan Downing: I think also interesting that it feels like the end of that story with a lot of companies would have been sort of converging on a SQL dialect as the answer for how do you make your query language accessible. And so I'm, I'm very curious to hear why you've sort of landed on something that's not SQL flavored as sort of the direction you want to go in. And whether that's sort of more opinionated or more of a sort of technical design constraint? Rob Sutter: No, I don't think it's given anything a way to say that we want to support SQL eventually. And we're doing the work to do that. This is another aspect of developer experience that's really interesting, you talked about Serverless in the Park. I also moderated a panel there with Brian LaRoche of Began. And he made a point that a lot of people confuse familiarity with developer experience. People want SQL because they're familiar with it. SQL is if you go away from it and come back to it, man, it's sets and you don't write the rest of your program that way. And don't get me wrong, I'm not anti-SQL people ask for it, they're right to ask for it, and we're going to give it to them. Rob Sutter: But when you're a company looking to grow, you need to look at what's going to be intuitive for the broadest amount of developers. It's why almost all companies publish their documentation or their blog post tutorials, et cetera in JavaScript first, right. It's what people know, so if you can reach people in something that's like JavaScript, that's like GraphQL, that's like calling an, I mean, it is calling an API, just like we keep talking about Stripe, Twilio, SendGrid, and others. If you can reach them with the patterns that they're already building with, you don't have to teach them, oh man, oh, I'm going to steal that as my own soundbite. Rob Sutter: If you can reach them, you don't have to teach them. Going to customers where they are puts a lot of work on a product team, on a DX team, but it pays big dividends. And that work that you're doing is taking the complication away so that you give them a good interface for something that is complex, but you're taking the work on yourself because who's better positioned to do it than you. You're the builder, so you understand how this thing works. If everybody is cutting their thumb on this thing, we are the ones that should fix it rather than giving all of our customers a bandaid and saying, Hey, when you cut your thumb on this thing, put a bandaid on it. Brendan Downing: Yeah. Great. That's a great note to sort of close on, I guess I'll wrap up with a flavor of the question we usually wrap up here, which is what is Fauna going to be long term? Like if you look like three, five years in the future, what sort of big problems do you want to be solving for developers? Rob Sutter: Ooh, ask me when we're done recording the show. No, so first and foremost, Fauna is a database, right? Fauna is distributed data simplified, distributed applications just continue to grow with the release of like Vercel Edge functions and CloudFlare Workers, all the integrations that you see, all of workloads are going to push out to the Edge. I really believe Fauna is the best way to manage state for those applications, so whatever else we become, we're going to become an even better data store, that's even easier to use. Now, there are a lot of things we can build that are adjacent to that. But right now, if we look at those, we're going to lose sight of the most important thing we can be doing, which is reducing the complications so that we can meet users where they are, because there are tons of users who need to store and retrieve their data simply all over the world. Rob Sutter: And so we're just going to get better at that. There's plenty of market in being the best at that. There's plenty of space and room for us to grow in being the best at that. You know, we want to be your first choice when you build that app, whether in your business or at home, because it's one API call in 40 milliseconds to get your database up, full infrastructure as code, and unit testing on everything. As we get that better, we'll be okay. Brendan Downing: Amazing. Well, it was great to chat with you really enjoyed having you on. Is there anything else you'd like to point our audience to? Rob Sutter: If you want to get started with Fauna and you're that front end GraphQL builder, we have a workshop for you graphql.workshops.fauna.com. We'll get that in the show notes. And in one hour, it'll take you through the entire introduction to Fauna just in the browser, right? That's all you need. And in two hours, you'll build an application either in Next.js or SvelteKit, that has authentication, user defined functions, customer resolvers, all this stuff, right? If it sounds like a lot, trust me, just go through those two hours and you'll be ready to go out there and build your own application, so I'd love to see what you build. Brendan Downing: I'm sold. Awesome. Rob, thanks so much for being with us. Rob Sutter: Yeah, thank you for having me Brendan. Brendan Downing: All right, take care and we'll see you online. Kate: Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.