Eric Anderson: Hey Contributors! We have a new Slack channel for all things open-source, where you can talk directly to the project founders and maintainers on this show. Check it out at contributor.fyi/slack. Dominik Tornow: The core conflict of software engineering is to build reliable systems from unreliable components, but it's much easier if you are able to build reliable systems from reliable components. And Temporal's core obstruction, the workflow, is that reliable component that you can build reliable systems from. Eric Anderson: Today, we are discussing Temporal, an open source project to help people build cloud-native applications. And we're going to get into more of how Temporal works, but before we do, let's acknowledge that this is the second time we're covering Temporal on the show. Maxim Fateev, who is here with us today, joined us almost two years ago. The project's come a long way and we're excited to get an update. And we're also joined by Dominic Tornow, who's a principal engineer at Temporal. Maxim, Dominic, thanks for coming. Maxim Fateev: Thank you for inviting. By the way, we kind of had a big discussion about that, and now we call it Temporal. We had choice between Temporal and Temporal and we decided to standardize on Temporal. Eric Anderson: Temporal is not the name. It is Temporal. Maxim Fateev: Correct. Eric Anderson: Fantastic. Maxim, Dominic, you've been busy. So much has happened since we discussed, usage is up, you've had some big announcements. Maybe you can just give us a couple of the highlights on some of the recent press around Temporal. Maxim Fateev: I don't remember exactly the moment we talked, but I think if it was two years ago, we actually didn't have Temporal as a product you could use. I think we were working on the fork of cadence and then, later that year, we announced actually we won release, which we blessed for production use. And I think the most progress around that happened is that, actually right, now very large number of companies and projects used Temporal in production. The other big part which happened is that we started to work what we call Temporal Cloud, which is offering. And we, right now, have quite a few paying customers running on our cloud. It's still not JA, we are targeting JA later this year. And the way we define JA is that we will practically unblock anyone who wants to use our cloud to participate. Right now, there is a very long wait list, that is kind of the main progress we made from the business point of view. Maxim Fateev: The other thing which happened is that we closed our B round in December, and we've got over a hundred million dollars with a 1.5 billion valuation. So that certainly helps us to keep growing as fast as possible sustainably and making sure that this project and the cloud offering, also whatever is in front of us in terms of economy. Eric Anderson: Yes, I think you couldn't ask for a better two years since our conversation. A bunch of new users, a bunch of new capital and a lot of progress on the product. That's a great update. To give the listeners some background, normally we cover the history on a project and we won't go into that a lot today. You can go listen to the prior episode and there you would learn that Maxine was once at Uber, where he created Cadence and some of the innovation there, also sends as far back as Amazon and Microsoft, where Maxim and Samar had both worked and developed similar predecessor technology. So this was a decade or more in the making. And now it's on the world stage after a big fundraise and a lot of growth on the product. Eric Anderson: Today, I wanted to talk about maybe a little bit more on how Temporal works and then a little bit of how users are using Temporal in the wild, and how you communicate the value of Temporal to people. So, maybe we can start with hearing a bit from Dominic, as he's new to the show, on how Temporal works. Dominik Tornow: Temporal. Interesting challenge about Temporal itself is to explain what Temporal is, what Temporal does and what Temporal does for you, because Temporal is actually a brand-new programing paradigm, a brand new developer paradigm. So, it was pretty hard for us, it's still pretty hard for us to draw parallels or analogies, so that we can easily explain what Temporal is. However, we have found one analogy that works pretty well. And, we found that analogy in the database community. Dominik Tornow: The database community, for the last 40 years, has enjoyed an unparalleled developer experience. So, a database let's you write an application as if failure or concurrency doesn't even exist, and it does so with a fantastic developer experience. The database community created a core abstraction of transactions. So, you have database transactions. And database transactions mitigate these adverse effects like failure or concurrent access on a platform level, making it entirely invisible on an application level. So, whenever you see your transaction, a set of SQL statements, you do not see that set of SQL statements dealing with failure. There is no if then else failure condition. All you see there is application logic. Dominik Tornow: And, we did not enjoy, up to this point, a similar developer experience in the context of distributed systems. But, Temporal actually provides that developer experience that is similar to transactions. So, our analogous would be the Temporal workflow. And the Temporal workflow addresses adverse effects, for example, failure or time limits on a platform level. Making it entirely invisible on the application level. Dominik Tornow: You can literally write your function code as if failures and time limits do not even exist. In short, you can say that a Temporal workflow execution is a normal function execution, and that is actually the developer experience that we give you, but with additional execution guaranties. And that execution guarantee is that your function will run to completion, and in distributed systems at any moment a set of nodes can crash on you. That is actually a fantastic guaranty. And with that, a lot of problems become trivial. Dominik Tornow: The core conflict of software engineering is to build reliable systems from unreliable components. But, it's much easier if you are able to build reliable systems from reliable components. And, Temporal's core obstruction, the workflow, is that reliable component that you can build reliable systems from. Eric Anderson: Got it. It is quite helpful. And you're building on the heritage, it sounds like, of other distributed systems. I want to say that one of the kind of early, popular, open-source distributing systems was Hadoop or Googles MapReduce, and if I recall correctly, one of the core tenants of Hadoop is that we can handle machines failing at any point in time and the process continues, or at least, we'd be able to report that the computation is accurate or not at the end of it. Eric Anderson: But, that's for one kind of singular data operation. And, I think what you're describing is that this could span any kind of workflow back-end process, ensuring that something gets executed correctly without having to go through the imperative declarations of if this, then do that, try this, if it fails, handle this situation. I just ask it to happen and it's ensured that it will eventually happen? Dominik Tornow: You know, by definition, we could argue that as developers, the best we can ask for is a happy path. And if you have a whiteboard session and you sketch out an algorithm, on that whiteboard, you'll draw out the happy path. So, it's like you basically assume that failure doesn't exist. Nodes do not go down. You do not lose packages. You just write down your core algorithm to communicate the idea. Dominik Tornow: With Temporal, the developer experience we give you is that you actually follow that happy path. When you write the workflow, you are writing the function. And you can ignore a wealth of failure scenarios like lost packages or machines going down, machines coming back up. Temporal will guaranty that the workflow execution runs to execution. Dominik Tornow: Now, there is an impossibility result in distributed systems. And that is you cannot have exactly once. You have to settle for at least once or at most once. However, in case you can ensure that your side effects are item potent, we can give you the best next thing, and that is effectively once. And, seeing that your side effects are item potent, we can guaranty that no matter what, no matter the failures, no matter the package loss, we can guaranty that your workflow execution executes observably equivalent to exactly once. And that is a stunning guarantee. Eric Anderson: No, that is the ultimate guarantee. Very good. Dominik Tornow: That is as good as it gets. Maxim Fateev: Just to make it a bit more practical, is that when we say function, we actually do mean function in the programing language. And we mapped to a mouthful of programing languages like we have, it's the case in Java, Go, Typescript, Javascript, PHP right now, and we're working on Python and .net and Ruby, right now. So, you just write normal Java code, or GO code or Typescript code. So, you say something like call this separation, and this separation can take five days, and it's still a blocking call. This is what we mean by the function. Maxim Fateev: It's because this process is not linked to a specific machine, so it's okay to wait for five days on that block and call. And then, five days later, when this call returns or fails, or just because of timeout, because you specified timeout, how long you're willing to wait, and then you can handle that. Or you can pull something like sleep for 15 days, and then, for example, you can have a loop. Normal programing loop in Java, and for loop and say, for 12 months, and every month just sleep for 15 days, or whatever next period of time. And then, charge customer, and then send email. Maxim Fateev: And this code is normal production code. You may be trying to do something like that out of the components you have now. You have a durable timer, you need to deal with re-tries, you need to make sure that you keep states somewhere when you build the state machine. This 10 lines of code become very complex state machine, there's a bunch of callbacks. That is kind of exactly what we mean when we have a function which is actually the great thing that it executes and it doesn't care about time. You can absolutely block on anything for as long as necessary. Eric Anderson: Got it. Maybe you can tell us a little bit about the execution environment, where it runs. Because I'm imagining, like you described, this can't run on a single machine, presumably, in the case that machine were to fail. Maxim Fateev: This service was designed as a cloud service from the beginning. The main assumption is that we don't run your code. It's like the same way if you're using a database, you have a database driver, you write your application, and database run somewhere else, usually on a different machine, at least in production. Maxim Fateev: And, the same thing is Temporal. So, Temporal has a pretty evolved distributed system-like cluster we call Temporal Cluster. Which internally has multiple components, but it's all kind of just given to you, and then sits on top of an existing database. So, we have bindings to different databases. Right now we support MySQL, Postgres and Cassandra, but you can write more bindings if you want to. Maxim Fateev: And then, the code itself is part of your servers. So, Temporal is an open-source project. Even if you use our cloud offering, we don't run your code. It's not functions, for example. You can run it anyway you want. You can run it on your laptop, you can run in Docker, you can run in Bare Metal. It doesn't matter because it's just code which you run. You use Temporal as the key library in the appropriate language, and all it needs is practically GPC connection, being able to connect to the Temporal backend service. Maxim Fateev: So, your code is kind of a bunch of stateless, what we call worker processes. They sit there and they just wait for tasks to come from Temporal for long pose. Then when you need to open ports or something, they'll always connect to the back end service. And then you will actually, for example, start a new transaction for the mining transfer. You don't quote to the back end service, say start this, use this arguments, and so on. And then it will dispatch tasks to your worker process, which hosts your code. Maxim Fateev: So, it means that we don't run your code, it's just part of your servers. You just link it to this appropriate library, and then there is a back end service which takes... It's more on the same ways in the queueing system, there is back end broker, and there is your application talking to that. So, they're kind of a similar paradigm. Maxim Fateev: It makes a lot of things actually awesome from a security point of view because think about it, none of these processes need to open any ports. At least inbound ones. They don't listen to any events. They always do outgoing connection to the JPC service, which can be obviously secured with MTLS, and other properties. Maxim Fateev: Also, because you run the code, you can for example, encrypt the payloads there. So, in the back end service now receives an encrypted payload, so it makes a lot of security things much simpler. So, it is pretty powerful. Maxim Fateev: And then, you just scale things out. If you need more capacity, you bring a larger database, or you just bring Temporal service instances, or you just bring more of your worker processes if you need to scale out. So, the system scales out very linearly. So far, we've been able to practice saturating the database, which we tried to run on. I think we ran up to 200 Cassandra nodes on Bare Metal, pretty large machines, and we were able to saturate the cluster 200%. Eric Anderson: So, if I were to kind of fit you in an application diagram, and people generally have an idea of what a traditional application looks like, maybe there's a database, and there's some kind of front-end, and maybe there's load balancers. And, where I have background processes, or back end processes, or workflows, that all goes to Temporal now, and that's where you might fit in the application architecture diagram? Maxim Fateev: Yes. Practically, every time you go beyond a single request reply. And you have some state between requests, or you need to manage some state, or lifecycle, or you need to wait on durable time, Temporal is a good fit. Maxim Fateev: For example, as I said, my new transfer is a very good example. You don't have transactions across two services, so you need to make sure that you do withdrawal and deposit. And you guaranty that it eventually happen in the presence of failures. It's important to write two lines of code. Again, I'm simplifying because at some point, you want to deal with these unrecoverable errors, you need to do compensations. But, again, as you try to cage block around the second line, and you can just do compensations using normal Java error handling logic. And you can do a lot of those kind of things. Maxim Fateev: Or you can do lifecycle. You can have workflow function always running, at least main method, and listening to look for external events, and aggregating their data or doing something around them. For example, you want to care for, I don't know, airline points. You're an airline, you want to implement this system of given points or promotions based on your trips. So, it can have object per customer, millions of them. They will listen to events, for example, the completion of your trip events, and then accumulate those points inside of the workflow code in their variables. Then you need to talk to database explicitly, and then take actions like once a month based on what are your custom services, promote a customer to the next level, for example, or send them an email saying "Thank you. You had that penny trips." Maxim Fateev: So, this can be modeled as practically just one piece of code, and then Temporal will take it and it and can run millions and hundreds of millions of those in parallel. And then you implement that logic like a library. Maxim Fateev: We use word workflow, which confuses people, because they kind of think about sequence of steps, but in our case, it is more like full to an actor. And, again, actor has a little bit different connotation, but you can think of this... Some people think about actors, you can think it this way as well. That is like actor is not linked to a specific machine, this survives practically any outages, and still has all its state preserved all the time. Eric Anderson: And this is now coming full circle for me to Dominic's explanation earlier, that you're creating an abstraction that's similar to a database transaction, where I just send you data with an expectation of what you're going to do with it, and you ensure it gets done. But, in your case, in a database transaction, there's simply persisting the data where you're allowing for multiple steps to happen, some of those steps are long-running, some of those steps have dependencies on other steps, and all of that will just kind of happen in the way I would expect without concern for failure, re-tries, and all that logic. Maxim Fateev: Good way to describe that. Eric Anderson: Shifting gears a bit, last time when we talked, you were kind of still new on the stage for a lot of people, and you were trying to figure out how to describe what Temporal is. And, I think we called it ourselves workflow orchestrator in our last conversation, and you came up with some additional terms for this. This is still an open question, how you kind of encapsulate such a broadly useful thing in just a few sentences for people. Maxim Fateev: Yeah, I think the problem is it's practically a new category of software. Every company claims to have a new category of software, but the reality is that's how our users tell us. That's why it's hard, because new category needs a new name, and then we need to educate people what this new name means. Imagine, 10 years ago, I came to you and said I do container orchestration, for example. It would be meaningless to anyone. Now, we just know what it means. Maxim Fateev: The same thing here. I think one way Dominic describes it is actually coded workflow. So, it's coded, but it's actually workflow. But, again, workflow has connotations which get some people confused. But, this lifecycle-type object I described, people would never associate it to workflow. It is a new way to build a distributed system, if you need reliability. So, that's why we still didn't come up with the right name for that abstraction, so we are thinking about it. Eric Anderson: Yeah. Dominik Tornow: The interesting thing is that Temporal, you can describe Temporal as a new pair of glasses, that lets you see the world actually differently. And, there is also why it comes and merges that even so, we are basically using the word actor which has more of an object connotation, or we're using the word workflow, which has more of a process connotation. But, this new abstraction that Temporal provides is actually able to capture both of these aspects. Dominik Tornow: And, that seems to align very well with the real world and with people's mental models, because if you take anything in the real world, for example an order in an e-commerce system. An order definitely has object characteristics. It has an identity, it has an integrity. Is this order, is an object. But it's not just an object, right? It has a state, it is in this step, then it's in the next step, now we're doing this step. So, there's also a process characteristic to it. Dominik Tornow: And, usually, because we are lacking an appropriate abstraction, what are we doing, we're basically separating this out in two different things. On the one side, you have a role in the database, and that hopefully captures enough of the object characteristics. And on the other side, how are we going to do processes around that thing? Well, there is one long-running process where we can't run it in the long-term, so we have to chunk it up, then wrap the individual chunks into re-tries, and then stitch the re-trying chunks back together, we have database's queues, and chrome jobs in order to make this process aspect work again. Dominik Tornow: Yet, we are lacking the integrity of the entire thing, that entire entity. And, Tempura does away with all of that. So, with Tempura, you can actually capture both the object and the process aspect in one abstraction. And that is why, when I talk a lot to our user ecosystem, and they start adopting Tempura, and within a half an hour conversation, you can see them moving on from incremental improvements of what they have today, to massive improvements by re-structuring, re-thinking their system. Massive improvements. Of course, only conceptually, but massive improvements within half an hour. Eric Anderson: There's a couple categories on your website that I looked at before we met, that I thought brought clarity to me. One was kind of business transactions, and then business process applications. And we've kind of already spoke to these, but the business transactions make sense. We mentioned similar to database transactions, but in some cases you're expecting more things to happen that is just encapsulated in the database. Like, you want to ensure that a driver is given directions on an order, or that a know your customer regulation requirement is met before a money transfer can complete. Eric Anderson: Tell me a bit about the business process applications. Maybe this goes, Dominic, to the workflows you were describing where a single request that Temporal can span several asynchronous steps. Dominik Tornow: There's interesting driving forces. The Temporal, think of the workflow execution as a function execution but with additional guarantee to execute to completion. That is applicable to a wide range of applications. So, some of the business applications we can argue that Temporal workflow executions are used for short-lived, whatever short-lived means, but for short-lived executions like, for example, as Maxim already said, money transfer. Dominik Tornow: This shall happen quickly, within a few milliseconds, at most a few seconds. But it most happen reliably. If I withdraw money from one account, I have to deposit it to the other account. Or, to long-lived, for whatever long-lived means here, in terms of all time, is that you have a business process that may actually span multiple minutes, multiple hours, multiple days, up to may you say, what servicing a mortgage for 30 years is exactly one business process, and you could actually capture that business process as one Temporal workflow execution. And that would execute reliably over the course of the 30 years, collecting payments, and eventually closing out the mortgage. Dominik Tornow: So, depending on the driver, what is the driver? Often times the driver is a short-lived, but must happen reliably, or sometimes often the driver is a really long-lived with lots of sleep time in between, mortgage isn't active all the time, once a month, if you stick to the payment plan and be good. And, yet, also, reliably. So, these are basically the driving forces that make you reach for Temporal workflow execution and make you reach for Temporal workflow. Dominik Tornow: Even so on the surface, this looks very, very different, it actually boils down to the exact same thing. Function execution that executes exactly once and to completion. Eric Anderson: It is like a new pair of glasses, maybe, if I understand you correctly. Your mortgage example, I think an alternative would be to run a process that every month scans all the mortgages in your database and checks which ones need to be billed this month. But, you're kind of describing a different world in which each mortgage is its kind of own function, and it gets deployed in Temporal. And, normally, I wouldn't do it that way, because I would be like, "I can't have 30 year running jobs, it's just not something." But, Temporal allows me to imagine that that were possible, and ensures that it does. Dominik Tornow: That is exactly it. And this is a blockade that once that it's lifter, Temporal is used not just for an incremental improvement. Temporal is used for a massive improvement that you re-structure, re-construct your system. Because, as you said, there is no such thing as a 30 year running function execution, right? But, with Temporal, there actually is, and we call it a workflow execution. And it will reliably run for 30 years. Maxim Fateev: One thing to add is just that we say function for simplicity. But, this function can have, for example, language like Java or Go in multiple threads. So, it can span its own threads. It's more like a main method. So, it can actually have multiple parallel things going on. You can listen to asynchronous external events, react to them. So, it's not just a sequence of steps. It absolutely can be as complex as you want. Can be fully asynchronous, can be synchronous, semi synchronous, and so on. Maxim Fateev: And obviously, in language like type script, we use a way to sync, we don't use threads, but you still get the same capabilities. So, we are kind of doing it in an appropriate way for every language. .net and type script use a weight, but Java uses threads, and Go uses Go routines. Eric Anderson: I'm liking my new Temporal glasses where I can now fashion the world, my data model becomes a bunch of Temporal state machines, or objects that exist as functions. And, if I need to cancel that mortgage, the application logic is written such that they could accept a cancellation event, and process it accordingly. Maxim Fateev: Absolutely. Yes. Dominik Tornow: I, basically threw out everything that I learned in the last 15 years about software engineering because obviously, how would we service mortgages just the way that you described? We have a database, in that database the mortgages are all listed. We have a daily job that iterates over it. All of us would do it like that. And we wouldn't even question why we do that because every one of our function executions is short-lived. Every one of our function executions is boarded by one request-response pair, probably in front of a web server, and that web server cuts it off after 30 seconds, to begin with. So, you have to chunk it up into 30 seconds re-tries via chrome jobs. And so on and so forth. Dominik Tornow: And, none of us would ever spend a split second to question our decision. And then, somebody puts a Temporal workflow execution in front of you, and then you start questioning all of it. And it's like, wait, yeah, that actually runs reliably no matter what, durable no matter what. Why is a mortgage not just one function that runs for 30 years? That makes actually a lot of sense. Sleep 30 days, charge, for 30 years, end of story. Of course, is a very simple mortgage progress, so you'd probably have to throw in some edge cases, and that's why Temporal also has things like signals and queues. Now that our function runs 30 years, you'd probably want to interact with it. If a function runs for 30 seconds, you don't have to interact with it, you can just wait it out. If a function runs for 30 years, you can't wait it out, you may have to interact with it. You may have to want to cancel it, send in a cancel request, send in a termination request, or send it any signal in application level signal, for example, to adjust your monthly payment rate. Dominik Tornow: So, we have signals and queues as first class citizens, so that you can interact with these workflow executions and you re-structure your system entirely differently. Maxim Fateev: I think one thing to add is not only about how you write code and how you design systems, we're focusing on that right now, but there's huge part of operating these types of systems, like how, in production, when something goes wrong, how do I troubleshoot that? How do I get visibility in what's going on? How do I make sure that I can page my code if there is a bug there in the middle of executing that function? Things like that. Maxim Fateev: And, Temporal has support for the whole lifecycle. It wasn't build just as a toy, it was built as a production system from the beginning, this experience of free previous production systems at life scale cloud providers. So, this is why we cover the whole lifecycle, and it's very important. People like it, not only because it simplifies the design and implementation, but because it's much more simple to iterate. And, visibility and what's going on, because we caught almost every invocation of, for example, external functions, whatever. You see all arguments, you see everything which happen, you see all failures. So, there is a lot of visibility, and ability to operate things. Which is another big selling point. Maxim Fateev: Okay, selling is probably a bad word, because it's an open-source project, but it's something which our users really want. Dominik Tornow: Okay, I want to add to that because, if the last 15 years made me lose all my hair, now it starts to grow back, because there are amazing capabilities in that system that makes your life so much easier that all the stress just goes away. Dominik Tornow: Let's imagine you have 100,000 workflow executions. These workflow executions, they run for half a year, and the all have been started already, they are four months in. And now, unfortunately, we realize that in testing, it slipped us, there is an edge case, a certain combination of parameters, we're going to run into another point or reception. Now, what? Are like 20,000 workflow executions lost? Are they gone? They're already four months old. How am I going to catch up to that? Dominik Tornow: Actually, they're not. So, with Temporal, the workflow execution is durable, reliable and scalable, and it guarantees to execute exactly once, or observably equivalent to exactly once. If you hit that other point of reception, the workflow execution obviously cannot make progress, but it doesn't just cease to exist. It sits there and waits there. So, it sits there and waits there, and then somebody eventually, obviously is going to catch that, and say what's happening to our 20,000 workflow executions? Why are they not making any progress? Let me look in the code, and a nod point of reception. What are you going to do? Fix the node point of reception, deploy the new code and all of the 20,000 workflow executions that were currently in danger, just take the next step and keep on going. Eric Anderson: Wow. I'm now trying to fit this new paradigm into the rest of my brain. In a world of microservices, you kind of hide everything behind APIs, and I'm not an expert at this, but I assume these kind of rest APIs, do some of that go away? If everything is kind of a function that I can deploy with Temporal, maybe I don't need all these rest interfaces? Maxim Fateev: Exactly. You can think that function signature as a service. We obviously support what we call chart workflows. It means that you can call these function as a block and call if you want, asynchronous if you want to, from any other function. You can treat them as package services. Your signature, and there's a way to route request to separate processes. And Temporal, it can actually route it across specific machine if necessary. Maxim Fateev: But, in this case you say, okay, this is my service, my team owns that, this is my functions workflows I expose. And then, other team can go and practically call them and use them as practical service call. And there is a PC, but it's all internal to Temporal. From your point of view, just making the call to this function can take 10 days or five months, it still is block and call. And all the other things about availability, making sure things are out to obviously process will go up and down all the time in the meantime. But, you as a developer don't care about that. You just make a call, call happens, and this call can be owned by other team. Maxim Fateev: So, it is kind of, I think of it more like service mesh for asynchronous request, which can take long time. And guaranty to execute, at least to be deliberate. Obviously, you can always reach on failure, but it's your application logic failure, not the intermittent failure because some process went down. Eric Anderson: Yeah. So, I would describe in my application rather than creating a bunch of different rest endpoints, I would create first, maybe a bunch of Temporal workflows I describe as functions that depend on one another, and they get deployed to Temporal. And now, my application works, and then, if I want to expose elements of those to developers, I could stand up rest end points that also speak to different parts of my... Maxim Fateev: No, you don't need to. If you want to... Yes, if you want to expose it to somebody outside of Temporal, then you do a rest end point. And, for example, very standard thing, you have web application or mobile application. They talk to your end point, and end point will start workflow, send signals to those workflow events, created those workflows. So, there is actually the block post, a series of block posts where you describe for them how to use Temporal to implement a shopping cart. Maxim Fateev: Every time you add an item to the shopping cart, it just stores it in the local list, practically, of the items inside of the workflow accord, and then you create it so the shopping cart, you just create its workflow and it jumps that list. So, not only did the... But, then you can do things like "Oh, your shopping cart was abandoned for one day", just sleep for one day and then send notification to the user, "Why did you abandoned your shopping cart?" And then, it recounts five lines of code, but if you're doing it the traditional way, it will be accompanied with different subsystems to build that. Eric Anderson: And, do I make fewer database calls because now the state of my world exists in Temporal functions as opposed to in a database where I continue to log this is where this shopping cart is at? Maxim Fateev: I would say you'd do less database calls, but Temporal is heavily... We do more rights. Because, for example, every time you send something, we record that. Every time some task completes, we would record that result, so you can see them. Not only for troubleshoot, but recovery. We have the right heading. But, because we catch those points in memory, and if they're actively being worked on, we're not loading them every time. They because very efficient. Maxim Fateev: So, if it's practically hard point in the memory, your operation is very, very fast because all you're doing is a single database right in the middle of cases, versus loading from database update it and saving back. And we aren't saving the whole state, we are saving only advance. We kind of use advance sourcing paradigm, but internally in our service. We don't expose it to developers as an outsourcing. Eric Anderson: Yep. Maxim Fateev: We just give you high level abstraction, but internally, these events sourcing. So, every event is recorded, you can use it for... Again, troubleshooting, and also to file the core features. Dominik Tornow: You are correct so that an application level you have less database calls. Maxim Fateev: Oh, yeah. You don't have any in most cases. Dominik Tornow: You don't have any. Eric Anderson: And in effect, you're making the database calls for me as an app developer, I just talk to Temporal. Yep. Maxim Fateev: And again, one thing we should mentioned, just to make sure you said. Deploy app to Temporal. You don't deploy app to Temporal. You are using your deployment system to your own deployment, whatever you use, Kubernetes or Bare Metal, or whatever. And all it needs to do to connect Temporal cluster. And then you build your application, you link Temporal library. But, Temporal doesn't run your code, you run your code usual way. Eric Anderson: I see. Maxim Fateev: You can even take an existing service and just make small part of your service, for example, distribute chrome job. You can start small. One thing important about Temporal is not about all or nothing. "Oh, now all my services use Temporal." You can have a single small chrome job which runs once a day as your starter application. And then, you can grow it into the millions of chromes, and then you can grow it to whatever else. Maxim Fateev: So, there is no need to do all these big migration, you can always do it piecemeal. And most companies are doing it that way, because nobody will go and change 50 or 100 services in one day to use Temporal. Eric Anderson: If we had more time, we'd go to so many other places. Let me make sure, Maxim and Dominic, we covered what you'd like to, and I'll ask maybe five minutes here. But, I can't help but think that this paradigm, the new glasses people have to put on, applies to a lot more than I expected. I was kind of imagining you were mostly kind of backend data processing, or other kind of engineers, but really, the application developers need to put on these glasses as well, I assume. How do you bring people around? I imagine there's a lot of open-source project founders, creators, who had the same predicament. Where they need people to kind of see the world in a new way in order to use their tools. And I'm curious what you can teach them. Maxim Fateev: I want to say we aren't perfect in terms of teaching that. I think most of our adoption is actually word of mouth. For example, we started at Uber. Uber is a large company, and a lot of people move around. And we hear almost every week that somebody from Uber comes to other companies and says, "Okay, how do I use your technology in the new place?" So, because it's a mind shift, you start thinking about building applications differently, so it's very hard to go back. Maxim Fateev: People, when they move around, they always tend to bring it with them. We see it multiple times. We actually had people resign because a company decided not to use, for example, Temporal, for whatever their reasons. And, moving to another company to work on the technology. We've seen that. Maxim Fateev: And, this is I think they are largest part of our adoption is that people just talking and communication, and in general, most of our users are extremely happy about the usage. And you can go to a select channel, like go Temporal.io and there is a link to a select channel where there is a link to a forum post you can just talk to the community, everything is very open. You don't need to take my word on that. Maxim Fateev: Actually, just to give you some finding stories that we're closing... Our partner [inaudible 00:36:32] from Sequoia, he practically, all he did, he just went to our forum and pinged everyone. Practically they are saying can I talk to you about this company? And people where pinging him back, like why is he asking us? And then, he got such a positive feedback, and people are very open about that type of companies, because most companies don't go public about their usage of Temporal, because these huge enterprises, they're not very comfortable about talking about small startups. But, in private, people can sometimes say that. Maxim Fateev: And the VCs look at that, "Oh, wow. This is the actual usage", and they are planning to use more, and they're super happy about it, and it was no brainer. I think, from their point of view, is why to close us. Even just from the user's point of view. Maxim Fateev: So, I think everyone is welcome there, talk to our users, talk to us and learn it. I think, for us, it's most important things people to learn about this. You don't have to use it. But, at least understand this new concept, understand what's possible. And then, yeah, you make a decision. If you want to go with database, you can do it. But, I think at least people make a conscious choice. Right now, this abstraction is still not very well known. Eric Anderson: Certainly. I have been through an interview with you already, and I don't think I fully understood it. And what's next for the company? You've had quite a couple years, what are you looking forward to this year? Maxim Fateev: Our goal is adoption, because we think having a strong open-source project is most important achievement we can have. We don't believe we can build business around non popular open-source project. One of the things which we are going to have this year is a conference. First time Temporal conference. It's one day only, at this point. But, it will be August 26th. Please visit our website and we'll have information there, how to join. Maxim Fateev: And the other thing which we are focusing on is making sure that we will have GA of our cloud offering, so we go and unblock anyone who wants to use it, and don't want to host Temporal service themselves. And, otherwise, we're just growing our company. We want to make sure that both cloud offering and open-source project get enough love from us. And we also want to build more open-source community, we want more contributions. That is another goal we have. Have meaningful contributions from outside of Temporal as a company, because it's important for an open-source project, I think, longevity. Eric Anderson: Great. Listeners can find details in the show notes, or you can go straight to the Temporal website, I'm sure they'll find everything you need there. Dominik Tornow: To add to that. The Temporal community is super welcoming. So, if you join the Temporal slack, it's not only like a Temporal team, it's also the community that's going to go ahead and answer questions. And, I want to say that I meet a lot with our users, so, if you join the slack, you can just reach out to me and then I meet a lot with our users. Usually it's anywhere from half an hour to an hour. Dominik Tornow: And then, we look at your use cases, and your requirements, your architecture, and usually within half an hour, it's very obvious whether Temporal is a good fit. And then, also, how to approach your particular problem with Temporal as a solution. So, there is a one-to-one aspect that we're still doing, but as Max said, we also need to do a good job, a better job in explaining the core concepts, and then also the mechanic of the core concepts without that one-on-one aspect. But, I just want to throw it out there. Eric Anderson: Fantastic. No, that was a fun anecdote on how somebody gets a project going, and bringing people around on their point of view. Eric Anderson: Maxim, Dominic, this has been a wonderful time together. I hope, in a couple years, we can do this again and get the latest update. Maxim Fateev: Oh, that'd be awesome. Thank you. Dominik Tornow: Thank you. Eric Anderson: You can subscribe to the podcast, and check out our community Slack at contributor.fyi. If you like the show, please leave a rating and a review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson, and this has been Contributor.