Nick Schrock: The workflow engines or orchestrators are effectively the circulatory system of data in an enterprise. And in the modern world, that means it's a circulatory system of the business itself. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. We've got Nick Schrock here with us today, who is the creator of Dagster. I'm sure many of you know, Nick. Thanks for joining. Nick Schrock: Thanks for having me. Eric Anderson: Nick, if I recall, we met years ago, and I was privy to the early days of Dagster to a degree. Maybe you can start us off and tell everyone what Dagster is. Nick Schrock: Yeah. So Dagster is a data orchestration platform. So within every company, of any non-trivial size or enterprise, there's typically a data platform. Meaning that there's a bunch of different people using tons of different tools, putting data products into production. And in order to do so, they have to work together because typically one team creates data products, and then another team consumes those, and so on and so forth. So these data orchestrators or workflow engines become critical pieces of infrastructure in these enterprises. Nick Schrock: And we just thought there's a huge opportunity here. Because just the overall theme we're seeing is that people, and this has taking years to realize, but people in the data domain are beginning to realize and are in the process of realizing that this is a software engineering discipline. And you really want to have a full proper software engine life cycle with a delightful developer experience testing fast deployment. And then in data, we think you need to also track the produced assets. So Dagster is an orchestration platform that really thinks about this problem. And a lot of people call it software engineeringification, different terms. Some people call it data ops. Some people call it the modern data stack. But whether or not, how you use the term, we believe we're kind of the orchestrator that fits into that theme. Eric Anderson: Yeah. And I how you described this as new awareness around how critical this is. I think there was a time when people wrote scripts and threw them over the fence and called it good. And there was some acknowledged and accepted messiness to this world. Nick Schrock: Totally. For example, I don't have a billion Twitter followers, I'm not a Chamath or something, but one tweet I tweeted that went super viral recently was about it's time for the term data cleaning to be officially retired because it isn't that. Data cleaning is the work. And what it is is a process of putting data products into production. And it's hard and it takes real engineering. And just referring to it as cleaning, not there's anything wrong with cleaners, but it undersells the sophistication and the importance and criticality of what this are. Because a model you might throw away, but all the data products that you produce leading up to that live forever, and are incredibly important assets to an organization. Eric Anderson: Yeah. And now let's figure out how you got to Dagster. I'd be curious to go back to GraphQL if you don't mind, because I feel that's where some of us know you from, and how that led you to figure out the need for this Dagster thing. And then the early days of Dagster. Nick Schrock: Totally. So yeah, as you mentioned, I worked at Facebook from 2009 to 2017. And actually, I believe I was the one who started this group called product infrastructure. It started three engineers, but it really expanded and grew. And that team's job was to serve our application developers and make them more efficient and productive. And out of that group, a very special group of people, I didn't have anything to do with the project, but React came out of that group, which obviously is an open source runaway success. And then I personally was the original creator of GraphQL. And then co-wrote the spec, which we then open-sourced. And I learned a lot in that experience about the power of open source communities, and just how these technologies can take off. Nick Schrock: And I left Facebook in 2017, and was figuring out what to do next. And I was just talking to companies about what their technology challenges were, both legacy or traditional enterprises, as well as companies that are in SoMa or in the Valley. And I mean, just, it was 100%, their biggest technical liabilities and challenges were around, some call it data infrastructure, or some called it [inaudible 00:04:37] infrastructure, but just this entire domain was just a mess. It is just critically important to the functions of these businesses and to society at large. Nick Schrock: And I looked into the tooling and how people were working. And effectively what I saw was the biggest mismatch between the complexity and criticality of a problem domain, and the tools and processes to support that domain that I've ever seen in my engineering career. The only thing that came close was web development in the early 2010s when everyone was just whining about IE6, and everything was awful, and engineers didn't even want to engage with it, and JavaScript community didn't take itself seriously. Now it might be the opposite problem. Now it might take itself too seriously. But if you travel on time from 2009 to 2021, and you're a front end developer, what is happening in front end development now would look like alien spacecraft had landed, and it's just a completely world transformed. And I thought the same thing needed to happen in the data domain. Nick Schrock: And a lot of the maladies, both cultural and technologically, are similar. So for example, in 2010, people would be like, "Oh, I'm just a JavaScript script kiddie." And it wasn't considered real engineering and so on and so forth. And I think there's a lot of analogy to calling themselves data cleaners or data janitors, and kind of being in love with the tools they hate. There's almost this Stockholm syndrome that goes on there. So I thought there was very similar properties. And then when I see a developer experience dumpster fire like that, I'm kind of drawn to it like a moth to a flame. I really surveying other engineers and making their lives better. And when I see inefficiencies like that, I just get kind of mad and frustrated on other people's behalfs, and I really want to work on it. So that's kind of how we got here. Eric Anderson: And not to overdraw the analogy, but that's a little bit of what you did at Facebook, no? There was a group of engineers, and you said how do you make their lives easier? And you came up with this spec which codified a relationship and kind of enforced expectations. And in some ways, that's a little bit of what you maybe saw in this situation. Here's a bunch of engineers and there's no expectations. There's no system, there's no discipline around the work they're doing. Nick Schrock: Yeah, totally. And to be clear, it's not when I started at Facebook in 2009, I had a vision of GraphQL in my head or something. You just get in the muck with people and figure out what they're doing. And you kind of scratch and claw, and deliver value to them. And incrementally build up to something that's greater by holding a vision in your head about how things should work in a broad sense, and then engaging super deeply with users. So definitely trying to do the same thing here, and an open source community is a way to engage with that. Eric Anderson: So I'm curious, we haven't quite talked about how you built Dagster yet, but we now have your understanding of the need, and how you're engaging people with folks. As you start forming this idea of Dagster, was it obvious from day one this was going to be an open source project, we got to build a community? Or how do you go through that process of thinking? Nick Schrock: Yeah, I guess it's funny, maybe I should have been more deliberate about it, but I really didn't even consider doing it another way. Partially it's because it's what I know, and I believe in the bottoms up adoption story for developers. You don't need to open source to do bottoms up adoption, but it's a whole different discussion. But in general, the type of systems that I like and think to build is you build APIs that kind of have what I would call an intimate relationship with the developer's program. Meaning it's in your process, you're coding to it. Its run time is calling into user code and interacting with it in very rich ways. Nick Schrock: And I just think for practical purposes, a tool like that, at least a subset of code that lives in process with a developer's code needs to be open source, just for very practical reasons. This is going to be in Python. We want to install with pip. It's normative that those are open source. The code is in the developers stack, physical computation stack. So there's very practical reasons. And then I just like open source communities. I like the vibe that comes out of them. I like the kind of deep connection that people have with open source communities, but I'm no open sources zealot. I think it's perfectly acceptable to build proprietary technology that supports open source, and that is kind of on our roadmap as well. Nick Schrock: But what you're really trying to do in open source in a way is develop an open standard. So you want your API to be standardized. And that was also a big takeaway from the GraphQL experience because what was interesting about GraphQL, is that we open sourced a document. That was the primary artifact that we open sourced. We open sourced a document and some JavaScript code that was only written to execute that document. It was not a production system at Facebook at all. So in the GraphQL experience, the most important thing was not software. The most important thing was this document we open sourced. So I don't want to speak for Lee and Dan, the co-creators, but if someone implemented a proprietary service behind the document, go for it. If it delivers value to developers, good for them. So I'm not an open source zealot in any sort of way, but I just truly enjoy working in those communities. And it lends itself to the type of problems that I want to work on. Eric Anderson: Yeah. So you're knee deep with these folks in their data problems. And how soon does the beginnings of Dagster emerge? Nick Schrock: So I originally was calling the system... I don't know. I started to prototype some ideas that were totally disconnected from Dagster in maybe summer of 2017. And then I honed in our orchestration kind of early 2018, and was actually prototyping stuff alongside. I was actually talking to Abe Gong a lot about this. He was the founder of Superconductive and the creator of Great Expectations. So just getting lots of contacts in the data space through him. And then we kind of launched Dagster, raised some money in May 2018 just to do exploratory work, and hired a few full-time folks then. And well, actually didn't hire any full-time folks until early 2019. So I was kind of dicking around and building some prototypes, working with the contractor, exploring ideas. The project really started to takeoff when we did our more public rollout in mid 2019. And we wrote a Medium article, and started gaining traction. Then we started working on getting early design partners then, and then it's been kind of off to the races since then. Eric Anderson: And it was probably fairly clear in the beginning that there would be some workflow element to this because that's kind of the work that needs to get done. And then other elements kind of emerged to kind of support the workflow piece. Is that fair? Nick Schrock: Totally. So the initial insight, which still holds true today, is that these DAGs that people build, that are hosted in, currently, kind of the incumbent system that is adjacent to us, I like to call it, because we kind of have different views of what these systems are, is Airflow. And when I see an Airflow installation with thousands of DAGs and tens of thousands of tasks, I don't see a bunch of graphs. I see a full application. In the same that in front end 10 years ago, people would say like, "Oh, these are just some scripts." And then it took kind of the folks at React and those tools to be like, actually, no, these are full applications, and they need a full software engineering process. Nick Schrock: So that was still the kind of initial insight that these dependency graphs that people build to do data processing, and I use data processing deliberately, because data engineering and data science and other elements as well, making those graphs and far richer constructs that are self-describing, that are aware of the data they produce, that are functional, that embrace testability, that have a great local development experience, that all has been constant since the beginning. What's been developing and more interesting is that, at first, I thought it could just be a pure programming model, an overlay on top of existing systems. But it became clear that in order to accomplish everything we wanted to accomplish, we needed to do more vertical integration and take over more of the infrastructure. So that's been a really interesting journey to kind of make it into a more full fledged full stack system. Eric Anderson: Yeah. And requires a little more resources. But at the same time you can deliver maybe a better user experience. I imagine that's what you're getting at is that you try the programming model on top of existing stuff, and it never quite solved the problem in the way you want it to. Nick Schrock: That's right. For example, for a long time, we didn't control the actual instigation of the runs, the run scheduling. So we would kind of interface with a cron system like System Cron or Kubernetes CronJob or something. And that just was not sufficient to all the things we wanted to do because it didn't provide a smooth enough out of the box experience. You need vertical integration for the scheduler to get some reliability that you want. And also we just wanted to enable fundamental new run scheduling capabilities. We're enabling not just time-based schedules like most of these systems do, but think that we're really investing heavily in event based schedules. So runs at kickoff because something did happen in the world other than time proceeding. And in order to implement those features in the way we wanted, we needed to take more control. Eric Anderson: I often think of these things as being kind of the back office tasks that keep the data up-to-date. When people want to go to their tables and run queries, the thing that keep those tables up to date are these tasks and workflows and processes. But increasingly, as you pointed out with the event triggering, they're kind of intertwined into much more than just the BI system or the kind of the data warehouse. They're plumbing everything to everywhere. Nick Schrock: That's right. And it's only getting more complicated and heterogenous in our view. Yeah. There's been some consolidation around cloud data warehouses, for sure. But any data processing or data movement has to be managed by one of these systems. So that encompasses data warehousing, yes, but it also encompasses moving data from any source to any other source. And there's a very heterogenous database. You might want to do a time series database. You want to move data back into SaaS apps. You're moving out of SaaS apps. Then there's the entire ML space where you're producing models. Those models in turn affect the behavior of the pipelines, which produce further models. Nick Schrock: Once you put a tool like this in the hands of developers, the use cases expand as well. Because so many computations can be modeled as directed graphs. So we just see the purview and scope of these systems expanding. And the workflow engine, the orchestrators, are effectively the circulatory system of data in an enterprise. And in the modern world, that means it's a circulatory system of the business itself. So these data platforms in these companies are utterly critical and incredibly sophisticated, and under tooled in our view. Eric Anderson: I actually don't know if this is true, Nick, but I feel you're kind of overseeing also a big shift in the market. Where before you started on Dagster, these systems existed and they were under engineered, but also most of compute before now, I guess, was apps serving transactional databases behind them. There was a time when Hadoop emerged and people got excited about big data, maybe for the first time. Let's store all the things, and then we can query them. But a lot of those promises went unfulfilled. Eric Anderson: And now with machine learning, suddenly the compute of old was largely serving apps and running transactional databases. And compute of the future, it feels it's increasingly all data. The primary workload of cloud is now data. Whether that's all the machine learning stuff we're doing, or to solve the kind of plumbing to move data from where it's captured to where it needs to be consumed. So I feel you solve these problems and fix them, but at the same time, you're kind of riding this wave as the world explodes in data, and data becomes the primary workload. Am I more excited about this than I should be? Or are you seeing similar things? Nick Schrock: No, I mean, apps are going to be important, and it's still getting a lot of workloads. But yeah, I mean, I see the same thing in terms of just the importance and investment in data infrastructure and data processing more broadly being just a massive, massive trend. I mean, you see that in terms of investment activity, which is out of control as well as the amount of investment that companies are making into these tools. Nick Schrock: And you also see it in the performance of these companies in public markets, right? Snowflake famously has a blockbuster IPO, but the metrics that people are really wowed by them, and I think rightfully so, is what's called net dollar retention. Which means that, effectively, if you kept the same exact customers and held them a year, how much more revenue would you get out of them including turn? And there's, I believe, is at 160% or so. Which means that even if they stopped acquiring new customers, the business will be still be growing 60% year over year, which is completely wild. And that's an indication. And the reason why it's an indication is that Snowflake is usage based, which means the more you use the tool, the more you pay. And so I think the fact that these data companies have such high MBRs is another metric that indicates that usage of these systems is just exploding. So you feel it anecdotally when you talk to engineers, and then you can see it verifiably in metrics in private and public markets. Eric Anderson: Got it. Well, I digress a little bit. So as we tell your story, you've now got the workflow plus plus kind of system coming together. And you're now kind of engaging with kind of these partners that you've been working with for some time. What are some of the learnings, what are some of the things you see in the field as people engage with Dagster for the first time? How is this changing how they work? Any kind of specific experiences where Dagster are really helped out folks? Nick Schrock: Yeah. Well, I think the first thing that people feel, the gut punch so to speak, is that the spin-up process is effectively instantaneous. You write six lines of code, and you type one thing in your command line, and you have our full graphical tool loaded up, and you can start executing your pipelines immediately. And that's just a dramatically faster and easier spin-up experience than anything. And that, it doesn't just save time, it's also kind of an indication, the value proposition of the system, that we've really thought about local development and ensuring that individual developers and practitioners who are using the orchestrator in developing these graphs feel empowered. Meaning they can just locally develop, they can do everything themselves. And then we have a fast developer loop. Nick Schrock: So in their Slack, people are like, "Oh my God, I can actually execute one of my tasks in isolation, and test all this business logic without pushing this to prod. This is such a breath of fresh air." So I think it was right for us to focus on this spin-up and local development experience and testing. because people really kind of feel that immediately. And then the other thing, developers deserve well-designed consumer grade tooling. They live in these tools. They're a very important constituency. So we've really put a lot of time and effort into making the ergonomics of our UI very nice. And people definitely appreciate that. So that's another thing. Nick Schrock: Another kind of learning, I guess, or lesson, I like the word lesson better learning, is never underestimate your developers, especially in these open source communities. It's just really exciting to engage with people and have them surprise you. One of our partners, my team is probably like can you stop talking about them, but I love the way they use product is at Good Eggs. And they're doing all sorts of crazy stuff. My favorite is that they've actually trained ops people who work on their warehouse floor to use our tool to manually kick off computations and retry them. Because they have people manually entering Google spreadsheets about stuff. And then they want to ingest that. And the data team did some work using Dagster to make it so that they could correct errors in the Google sheets and kickoff pipelines, and then report back to the people, "Hey, you have to fix this." And then rekick it off. And they can do that with no intervention from the data platform team. Nick Schrock: So we're able to enable self-service operations across much broader use cases than I would have anticipated. And I think that's part of, kind of related to that, the wide spectrum of people who use these data platforms in the enterprise is crazy. So this has nothing to do with Dagster, but a story from Netflix. They have an internal notebooking platform based on a technological paper mill. And they actually have, I always need to double check this. I probably will email him, Matt Seal. He's now the CTO of Notable. Because I quote the stat, and I almost don't believe it. But they have something like 15% of all Netflix employees globally have written a notebook and put it into a production workflow. Which is out of this world, right? And so that's what makes these challenges, these data systems so unique is that everyone... How many stakeholders in your company care about data? I mean, everyone- Eric Anderson: In part, everyone's job is to make sense of data, and then show that they validate their work through data. Nick Schrock: Yeah. In terms of software systems I've worked on, there's this very interesting mix of having some of the users required deep technical complexity and a deep engagement with the product, but they also are serving entire wide swaths of other constituencies in the companies who might be less technical, but still need to engage with these systems in some sort of coherent manner, that's not just emailing around Excel spreadsheets or whatever. So the heterogeneity of the populations we serve has also been kind of an interesting takeaway. Eric Anderson: Yeah. Maybe say a few words on that. I think some of us are used to organizations where there's a central team that runs all the production data workflows. And data scientists might generate things, and kind of hand it over to them. Or maybe someone on the BI team might write new queries. But if they want to be scheduled or kind of have some maintenance, we hand them over to the kind of central data team. Is this how things still operate with Dagster, or what did those roles change? Nick Schrock: People use the tools in different ways, but the early kind of cohorts of the user base who it really clicked with were people that describe themselves as data platform engineers, or who in reality act as data platform engineers. And their entire mission of life is to make it so that practitioners can self-serve their own data products effectively. So there's this platform relationship because what you don't want is this old world. We had data scientists, and they would prototype some stuff in notebooks, and then throw it over the wall to data engineers who would then productionize it. Nick Schrock: This is very similar to the artificial distinction 20 years ago between dev and test. Where you'd have developers who had no responsibility for testing their code. Other humans would do that. There'd be this, now in retrospect, totally insane system. And in 20 years, this whole data scientists do something and throw it over the wall to data engineers will also be viewed in the same way. So they're really cutting edge teams that we work with. They're very focused on having a platform team enable end to end workflows for all their stakeholder teams. And that has really been, I think, our sweet spot. Nick Schrock: So those types of people, as well as at what I'll call full stack data, people who one part of their brain has to think in terms of platform, because they're rolling their own infrastructure, and part of their brain has to think about the business logic to create data products. So either the people who really I think embraced Dagster, and they're really getting a lot of value from it, are either people or teams where those two jobs are considered kind of two separate things. But yeah, the world should be moving to empowering stakeholders to own their data products. Nick Schrock: And this is an example of a tool which I think fully embraces this, which is kind of a open source, [inaudible 00:25:04] data is DBT. Which instead of saying, oh, we should dumb down analysts and put them in a tool where they don't have to understand engineering, they said, no, that's not what you do. You take analysts and you put them in a software engineering process with a tool that intuitively makes sense to them. And as a result, one, it's great for those people's careers because they become engineers and they can kind of control their own destiny in a way, but it just makes the systems work better. Nick Schrock: And typically you have a layer of people in a DBT work flow who are owning their data products and data warehouse end to end. And then they're operationalized within the context of a broad data platform. So in a lot of ways, one of our users kind of told us, "Yeah, what DBT did for our SQL, Dagster did for our Python, the users who use our Python." And we're kind of we consider ourselves to have very aligned values with DBT. So we took that as a very strong compliment. Eric Anderson: I think for those who know DBT, that makes a lot more sense and it helps understand the situation. You said something earlier that I've been thinking about since, that these data products, these data workflows become an application. Being that all these processes sometimes are intertwined with other processes throughout an organization, what's the bounds of a Dagster application. Is that the whole organization, or do you find that they're kind of discreet apps within organization? Nick Schrock: Great question. And we're still figuring out the right way to articulate this. So I guess I'll spin test this, but effectively we define a data application as graphs of computation that consume and produce data assets. That's what they do. So we call it a pipeline because it's more familiar to people. But that's what we think of as the application is kind of this limited set of pipelines within a single team that consume and produce data. Nick Schrock: Now, there's other interesting things where there's now interrelationships between teams. Where you might have one team at a different org that depends on data that's produced by a team in a different org. And they don't really want to think of themselves as deploying the same application. They want loose coupling between those things. So we kind of think of a data platform as a graph of data applications. And those themselves are then graphs of kind of more granular compute that people structure. So that's how we kind of think of it. But we don't want to try to redefine every single noun that people know is a data application. It's more approaching this problem as more of an application or software development process than just [inaudible 00:27:30] about a bunch of random scripts, and thinking about it as data cleaning. Eric Anderson: But yet, in many ways, this is how the world has gone with applications. We ran into this when I was at Google Cloud, defining what an application was gets a little tricky today because microservices rely on other services throughout an organization, such that, yeah, you just have kind of a whole slew of interconnected microservices. And I think we ended up just calling them services in the end because applications was a tricky word to use. And so the analogy continues, and reinforces the fact that you're onto something. You're following a similar path as to the application world. Nick Schrock: Yeah. Well, I hope it makes sense to people. Defining terminology is always... When you're in the process of a domain that's rapidly reinventing itself, there's often this kind of Cambrian explosion of terms that can be difficult for both customers and users and the companies themselves to navigate. So it sounds you experienced similar a challenge at Google. Eric Anderson: So Nick, as we kind of near the end of our conversation, take us to where the project is today, and any kind of things that we should be looking forward to, and wrap with how people can get involved if this fits the bill. Nick Schrock: Totally. So if you want to get involved, we're an open source project, so we have a GitHub. You can sign into our Slack, and then we have a really high quality Doc site. So those are kind of the three primary touch points. As we kind of press on, and I would say that one is that this is a business. So at some point we have to [inaudible 00:29:04] commercial product and a hosted service. So although we have nothing to announce there, it's certainly top of mind, shall we say? Nick Schrock: And that's actually been interesting to see as well because what we see increasingly true is that having a hosted product and a commercial solution is increasingly a prerequisite for our adoption, rather than people self-hosting something and pulling teeth to get them to pay a company money to do stuff. Which is an interesting shift in the industry. Three or four years ago, that was not true at all. So that's interesting. Nick Schrock: We are really doubling down. One thing we're really excited about is we're the only orchestrator that has integrated data observability capabilities. And we think this is a really powerful element of the system. So the entire reason why the system exists is to produce data products. And to us, it didn't make sense to not have an orchestrator not be aware of the data products they're producing. And it enables incredibly simple, intuitive, but use cases that you can't do anywhere else. Nick Schrock: So for example, because we have pipelines in the system that are aware that they're producing a specific database table or data lake table somewhere, the people who consume that table generally have no idea what pipeline produces it. They don't know, they don't care. No one cares. But they still need to know who to talk to or what's happening to this thing if they see it go wrong. So we have this simple tool. It's called an asset catalog. You can go to Dagster, you type in the name of your table. It pops up, you can click on it, and you see graphs about it. You can see what pipeline produced it. When it produced it last. You can see the lineage of it, meaning what assets it came from. And that's very straightforward to us to encode because we already have the dependency graph of computations. So it's actually very straightforward to derive the asset lineage graph. Nick Schrock: And this is one of the capabilities that has really enabled less traditional stakeholders to engage in the system. Because even kind of a non-technical ops person gets the idea that like, oh, there's a place in this tool where the thing I care about lives, rather than the thing that I don't care about, understand. They don't know about pipelines. No one knows. No one cares. They care about their assets. So very excited about these metadata capabilities built on this. And we've organized the company actually around kind of the dynamic I told you, which is there's people who are responsible for data assets, and there's people responsible for building the platforms that support those people. So we have kind of a platform team and a practitioner team. And that is their goal and their mission. Eric Anderson: Fantastic. Yeah. You mentioned something there that sparked a thought. I noticed from the beginning of Dagster that you played nice with other tools, which was important because the data landscape, there's so many random things talking to other things. But a lot of the value propositions you're offering, the more things I do in Dagster, or the more metadata I get, the more my assets make sense, the more lineage, and these benefits kind of compound. I imagine that's kind of the growth path as an organization. A team adds you, it compliments the existing things. That team is pretty excited because it works nicely. And then folks discover the more they do in Dagster, the more they get these compounding benefits of metadata, lineage, coherent systems, et cetera. Nick Schrock: Yeah, totally. Yeah. We're still early on the journey, right? There's a lot of stuff in Dagster, and we're always working on kind of what we call the progressive disclosure problem, and introducing these things sequentially in a place that makes sense. I also want to be clear that even though we have capabilities in the asset domain, it's not we're trying to take over that world. We call our asset catalog an operational asset catalog. Meaning it's very specifically the way the assets relate to the orchestrator. We fully expect to integrate with tools like Amundsen and DataHub, which are entire different products, which have way more complex ontologies that we want to support. Likewise, we're aware of data quality, but we have no interest in competing with the likes of Great Expectations or Monte Carlo, et cetera. We want to be able to integrate with these tools. Nick Schrock: So we to think of it that the orchestrator needs to be aware of all these different concepts, but shouldn't try to supplant everything. For example, data quality's interesting, right? Data quality has to play with an orchestrator because you have to schedule the data quality tester in the computation. And there's actually a lot of value in the orchestrator kind of knowing about that. But we also, for example, Great Expectations, which is a tool I know well, has an entire world of they have their own DSL for specifying all these declarative data quality tests, and the SaaS tool that they're working on built on top of that. And yeah, that's way outside the scope of what we want to work on. So we want to plug into that and have a great place for them to notch into and give users a ton of control how they use a tool like Great Expectations. But we want to expose the capabilities, and we think it makes sense to vertically integrate with an orchestration system, but not supplant and take over the entire world. Eric Anderson: No. Makes a lot of sense. Fantastic. Nick, thank you so much for the discussion today. A whirlwind of experience in the last few years since we met. Appreciate you coming on the show. Nick Schrock: Totally. Thanks, man. Great to be on. Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time, I'm Eric Anderson, and this has been Contributor.