Hello and welcome to this session. We’re really excited to have you here today. What we want to provide is really a basic foundational understanding of Temporal, the technology, and how it’s used with bi-developers across lots of leading organizations all over the whole planet.
I’m joined today; my name is Jim Walker. I’m the VP of product marketing here at Temporal, and I’m joined today by two of my esteemed colleagues. I’m going to let them introduce themselves, so Max, let’s start with you.
I’m Maxim; I’m a co-founder of the Temporal project and now I’m the CEO of the company. That’s right, my ultimate boss.
Uh, I’m Rylan Goldstein. I’m the head of product here at Temporal and I’m an early employee of the company.
Yeah, I mean, how long have you been at Temporal, Ryland?
Uh, like three and a half years—a lifetime, a lifetime in Temporal terms for sure. So between the two of you, I think we have more knowledge than almost anyone on the planet around Temporal. Well, there’s a couple of other people that have a lot of really great knowledge.
What we’d like to do is just run through a baseline understanding of kind of where it fits. We’ll talk a little bit about the history of the project and how Max started doing all this work and then a little bit about some customers.
Um, so just to get started, as application architects and as developers, we draw pictures, and often these pictures are very, very generic. On this slide, you’ll see a very generic understanding of a system. This is just a simple order flow diagram.
Um, and what happens is we design the system and then ultimately, developers, operators, and architects have to go out and implement these things. We’ll take this, cut it down into microservices, we’ll use queues, we’ll use timers and databases. What ultimately gets delivered in production is fairly complex.
And it may seem simple at its surface layer, but ultimately inside what we’re building, the complexities really start to compound. Honestly, as you add more features, they get exponentially more complex. Right?
So while these new architectures, these modern architectures kind of promise efficiency and ease and a simple way forward to implement these applications, they often present a lot of different problems because what can go wrong will. A database can fail, a service can go down. I mean, I’ve spent years in the Kubernetes space, you know, with pods coming up and down all the time. Queues can back up, and ultimately, you know, APIs time out all the time.
And how do you deal with these things as a developer? I think in a pure state where none of these things go wrong, things are pretty simple to deal with. But when things go wrong, we’re set dealing with rollback or retry policies and these sort of things.
I think people struggle with this sort of stuff, and ultimately it detracts away from doing what we really want to do, which is basically deliver the business logic that we’ve been asked to deliver. Even when things go right, we still have problems in these complex architectures. How do you share state across various different things?
Maybe not everybody thinks about state, but where am I? Do I have insight into this overall process for each person that’s being executed across this complex flow? Can I perform transactions to a single database across multiple different services? Maybe you want to do that.
Um, you know, how do you implement long-running timers? How do you wait a month for something to happen, let alone a month—maybe even three hours for that matter—or even 10 minutes, or even a minute?
Um, are we just putting pauses in code? You can’t really pause code, so these things get really complex even when everything is working well.
I think ultimately, as you add more features, as you add complexity to the application, as the architecture expands, it gets even more difficult and even more complex. If you think about retries and rollbacks across three services, what happens when it’s 15 or 20 or 30? The complexity just really compounds.
As you scale and you get more customers, reliability can suffer as well because there are just more components that can go down. Ultimately, I think developers are left dealing with this; they get caught holding the bag because they’re the ones who have to develop all this stuff, and they lose productivity.
It gets more difficult to deliver features faster. The reliability of our systems, as we mentioned, kind of goes down, and again I’ll come back to this really important point: it’s really, really difficult to get this kind of end-to-end insight across all the process flows that are going on in whatever the system is and the application that you’re in.
Sure, we may have some observability and some tracing across the services, but what’s really going inside that service, and how do we know what’s actually happening end to end?
Ultimately, over the past couple of years, I’ve seen this happen. Anybody could go to microservices.io and look at some development patterns on how people are actually doing these things.
Development patterns are interesting, and I think it’s the natural inclination of developers to share and figure out how to do this over and over again. Some of these patterns, like a dead letter box and a saga pattern, they’re fantastic, but often they’ll serve only one part of the problem.
I think even further complicating the issue is that we leave it to humans and each developer to implement them in their own way, so they’re also prone to errors or complexity. As we move on, I think ultimately there is a better way to do this beyond just kind of development patterns, beyond just kind of manually coding all these things.
One of the reasons I joined Temporal was exactly this. I think this is a problem that I was aware of when I was a developer, but I never knew there was going to be a way to actually figure this out. In fact, I think I stopped being a developer because I hated doing all this chaos—the stuff that I didn’t want to do. I wanted to focus on business logic.
When I think about Temporal, I think about it as a way for developers to build for the single positive state that they want. What is the way I want people to actually flow through my application and not worry about the retries, the rollbacks, the queues, the timers?
Temporal really abstracts away all of that. Um, we allow developers to code in whatever language—well, not whatever language, but we have SDKs across Go, PHP, TypeScript, Java, Python. Guys, correct me if I miss one in the end there, but .NET, that’s coming soon. That’s right.
Um, you know, we allow you to code in your language, define this workflow, which is this end-to-end kind of positive state that you want in your language, and then instrument your code using an SDK to interact with Temporal.
So it’s really about abstracting away this complexity so you can focus on what matters, and it has a fundamental impact on the way that we think about applications. I like to think of it as almost a paradigm shift because I think, you know, the developers I know that have used Temporal, it’s like once they see it, they can’t unsee it.
It is really a different way of thinking about your application. I think it’s an incredibly interesting way to approach software development.
Um, but I’m joined by—you know that’s my own understanding of it. I’ve been at the company and introduced to Temporal about eight months ago, but I’m sitting with the person who actually created the project.
Max, this is not your first incarnation of this approach, is it? I mean, there’s a history here of you doing this for quite some time, right?
Uh, yes. It took us probably 15 years to get where we are. It’s a long time. So where did it start? I mean, how long ago was it 15 years, as you told me? But where did it start for you?
I started probably—I joined Amazon in 2002. Yeah, and back then Amazon was I think one of the first companies which decided to kind of break the big monolith into smaller pieces, which they called services. Now we call them microservices. Back then it was all services.
The reason they did it was not because of some kind of abstract desires or architectural principles; it just was taking 45 minutes just to re-link the binary of the Amazon website back then. So imagine the developer experience.
And I think the clean build of that binary was 18 hours. Wow! So the reasonable solution was to break it into pieces, and then these pieces had to talk to each other. I was part of the infra team, which was responsible for all the messaging between those microservices on the back end.
At the end, I was checked out for the service—the storage for queues—and later it was adopted, actually, as a simple queue service. AWS SQS uses that as a back end. As somebody who was responsible for practically talking to every team that was adopting our technology, I ended up getting exposure to a lot of use cases.
It became pretty clear that queues are actually not a good way to link services together if you have complex transactions. Amazon Fulfillment flow is non-trivial. Even back then it was non-trivial. I cannot imagine what it is right now.
So we actually kind of started to think about how to solve that, and orchestration became a pretty clear answer to that. Amazon had multiple iterations on that, which resulted in Amazon Simple Workflow Service (SWF), which is still publicly the best service.
But we had two internal versions of that before, and then later, I co-founded Temporal with Samer, who worked with me on a simple workflow at Microsoft. Long story short, Microsoft has Azure Durable Functions which are based on the same idea, and later we came to Uber.
One of the projects we started was Cadence, which grew from zero to 100 use cases within three years. It was open source from the beginning, and it started to get popular—like adoption outside of Uber. We started a company three and a half years ago, and we created the Temporal team as a continuation of a fork of Cadence.
We added a lot of new features, and now we have… Sorry, but I lost track there. How many different incarnations were there?
There were five different incarnations. There were some others in between, and also, it’s not only about back-end services, it was also about client-side experiences.
Yeah, and we built at least probably four different frameworks for client-side. The first ones were kind of more traditional, like creating this DSL and instantiating objects with a syntax tree of things. You have a sequence; you have split and join; you have all kinds of… There are like a million incarnations of those.
It worked, but I quickly realized it was not a very good developer experience because it was much harder to understand and troubleshoot and so on. So we ended up implementing what we call the AWS Flow Framework, which was the first idea, kind of similar to what Temporal does. You just specify your logic and code directly without any intermediate representation. It didn’t… We didn’t nail the developer experience. 707.7 - 4.4: experience probably not many people know about simple workflow but later Microsoft Samara did I think an awesome job with dotnet I think framework like a weight I think and a tuber we did go SDK which was actually synchronous and I think we kind of nailed the developer experience while doing that well.
It’s interesting I think it’s the kind of the core principles that when it is Step functions as well and I think there’s this you know it’s by my experience as far as I talked to you know people users of this and I think there’s been more than just the five or six that you and Samara have done I think everybody’s trying to solve this problem in some form or fashion I think you know once you see what the problem is it’s like oh gosh how do I how do I deal with this you know I think what you all did at Uber was amazing and you know creating the Cadence project and open source m T license and then starting a company.
What makes it right this time? Um you know like this incarnation of temporal by the way I’m an absolute believer as well right so what why is it right this time around can I try to answer it for you first that’d be great it’s right this time because it wasn’t right all the other times interesting that’s good I like the one most constant message that I’ve heard from him is that like when people are asking you know like why should we just assume you know all this stuff and you made all these right decisions he’s like well I didn’t initially that’s right first time I made the wrong decision and now I have this long list of decisions that I should make correctly the next time I have to make them.
Yeah so that’s at least what it seems like for me. Yeah I think the idea is that it’s not like we dreamed this overnight it was just a lot of iterations and a lot of different mistakes and certain things we took us for up to five or six years just to come up with the right abstraction and I think just as a project why I think we’ve got to try it is that first we’ve got developer experience I think correctly and it was a big deal at the same time we built a lot of projects like that they focus on developer experience and forget about the back end right but because we built simple workflow service before as AWS service so we built this as open source project as a highly scalable practically cloud-based architecture from the beginning and it was practically so far we couldn’t find the point when it breaks.
Yeah it can saturate almost any store practically any storage we oriented with 300 Cassandra clusters we have our custom storage which is even more performant and we always able to create a new database to 100 and then and the third thing was because we built a tuber as an open source project and uh initially we didn’t get like huge adoption but we were running hundreds of use cases high frequency is a tuber uh so practically we kind of nailed the operational uh excellence yeah because we had to run it for Mission critical use cases and so it means that we kind of got developer experience we got it as open source and we run it at scale at the large company and then uh we’ve got adoption from external companies which was amazing because like one of the first users were companies like Coinbase, Airbnb, Box, uh like DoorDash and uh these companies uh certain HashiCorp and these are not like companies which would take these things lightly but they trusted us because again because all of these reasons.
Yeah I think it’s really interesting and I you know I I concur on the developer experience for this is just fantastic you know being able to do this across multiple different languages you know polyglot applications that we have it’s right and I think if you’re going to change the model you kind of have to do it across all you couldn’t do this in a single language you know what I mean and I think the operational kind of getting it to a point where it’s great.
Um this is all amazing uh do you want to show us the technology Max? I mean you want to give a quick demo okay yeah let’s do it. I I’ve been in very few companies where I just asked the CEO to do a demo uh but that’s our best demo person right there because he built it uh so first we run the temporal Service uh which kind of beckoned and usually it’s a large-scale distributed system but you can run it as a single binary with an in-memory database for developing purposes.
How can someone get that binary if they wanted it? Yeah you just to do Brew install temporal and if you’re on Mac and in automatic there’s a release on the GitHub and you can curl it and install it like a normal Linux package. So I want to demo a very simple uh money transfer use case so practically we have two operations we want to withdraw and we want to deposit money back and if you want to write that like the business logic of that is just two lines of code right so we call this draw and we call deposit.
Uh obviously nobody writes code like this uh in normal life like at least in production because obviously if something fails in the middle here uh your process crashes and you lose money which is actually not a good idea probably if you’re a bank. So the interesting thing that you actually can write like production code like this with Steam portal so the whole idea is that temporal guarantee is completion of this code we call it durable execution uh of workflow kind of interchangeably just for kind of Legacy reasons but any workflow code is guaranteed to complete and keep running in presence of any failure.
So it means that for example if a failure happens a process crashes after line 35 here that uh temporal will automatically move this state of this particular manual transfer to a different machine and recover that and it will keep running so as engineer you don’t even notice uh in like as a programmer that there was a failure so it’s very powerful because you practically do need a huge class of issues that disappears you don’t even need to think about process crashes.
Other things if you call this draw service and this service is not reliable uh temporal will automatically retry that as long as necessary so there is no limitation of duration of retries unless you specify it explicitly in the configuration options and all this retries are fully configurable it’s exponential retries and so on and there are a lot of features like rate limiting flow control and so on which I don’t have time to spend on.
So uh if you want to do this money transfer how would you initiate that? So this is actually workflow code and it implements an interface in this case transfer interface you see I’m in Java uh as we said we have uh SDKs and a bunch of other languages but for Java you would not take a workflow is this workflow interface and Main Muffler method with workflow method otherwise it’s just normal Java code.
So do we implement this in a way that was meant to be very adhering to temporal or did we try to marry this to the actual idiomatic way that like a Java developer would implement something in a framework themselves? No this is just normal Java right but it’s nothing magical but you can use all the Java constructs.
So for example if you want to say okay what happens if withdrawal succeeds and deposit fails and in them I didn’t do that but then it will just use normal uh exception handling from Java right and you would run compensation here like let’s say put in money back on the original account or you can implement Saga full Saga pattern here if you want to.
So uh but this is like just normal Java code if you want to have a loop if you want to have if like it just you can use all object and design you can move with another method to even class so just there is no limitation what you can do here there are some rules but like you have the full power of Java when implementing this code.
So let’s just try to run it and so uh the idea is that there is this backend service which I just started before uh kind of we have it running in this window but and also uh when you start the workflow you actually call into that service uh so the only requirement is that temporal services run when you’re starting that the way you would start it you’ll connect to this service all this kind of code is just to connect to the service and then you will uh just call uh start on that transfer method which we just described here.
And when it will start is accepted uh this process will exit and transfer will continue so let’s request the transfer. It will take some time mostly because it will try to recompile also grade always not the fastest thing in the world.
Okay we request a transfer we can see that it printed uh okay we don’t even want to see what printed imagine it’s a distributed system with thousands of processes running uh temporal provides UI so we can uh this is again uh this local binary which I was running or includes UI it just hit it on the localhost and we can see that there is an instance of this workflow running by the way this workflow ID is assigned by you so it’s usually a business level identifier and you can use NV granting uniqueness it’s a fully consistent system so you’ll be guaranteed uniqueness of workflows by ID so things like idempotency and uniqueness it’s easy to guarantee because you don’t want to transfer with the same ID going at the same time right.
And do users have any control over that behavior in terms of the ID usage and reusage policy? So you cannot have two workflows open at the same time to save ID ever it’s guaranteed but after it’s closed you can choose they want to run workflow again with the same ID or they want to run only if it failed or never run it so you can say never allow running again if it completed or failed for example.
So here we will see that workflow we have some workflow with this ID which we started and we can see input arguments of that so these are arguments I passed as parameters uh there is no result because it’s not completed yet and it will say there is no walk around why because in temporal temporal doesn’t run your code even workflow code it’s a citizen external process and you deploy this process anyway you want to just part of your service it’s like the way you would for example have your process talks to a database and this is your process talked with temporal backend and workflow code is not running this way this workflow is not making progress more like queued up in the system.
So let’s run the walker. So I have kind of uh and also in temporal we have a separation between workflows and activities so workflow would be the code which is uh as I said durable execution is fault tolerant survives failures and activities just code which talks to external services and it can fail anytime and we just usually retry it the work focus is doing the orchestrating whereas the activities are the tasks yes it’s a workflow it’s orchestrator right it orchestrates those.
So we started to run a walker so we can refresh and also just wanted to clarify it makes it sound like what you’re saying is that temporal server itself is never running your actual code this is always taking place on the worker and just events are transparently communicated back and forth on your backend. Yes it’s a temporal services more like middleware right it’s kind of it’s kind of encompasses queues and databases and all of that so from your point of view your application runs both workflow and activity code and connects to the backend server for State Management and queuing and also durable times and so on.
So now we see what happened is that we have a deposit pending activity, and it means like how this draw activity probably completed, and we see that it’s already executed five times and there is a failure going on, so we can go and check on that failure and help an account implementation line 36, and let’s find account implementation line 36. Yes, and there is an exception here. I actually put this exception just for the demo purposes, but we can see that this activity has been retried and deposit, so let’s fix this in real life.
You would just probably fix the bug in your code and always fix this service because maybe there is some other issue and redeploy. In this case, we just restart the account activity worker. Yeah, here it is.
Let’s just restart this process. I use a new code, and let’s go back to our UI and see what happens. So, at this point, temporal server has statefully and durably tracked the position where my code is executing in the workflow, and essentially it’s just trying to execute this activity right now, and the activity is obviously failing. So, what you’re trying to do right now is just fix that activity implementation, so the next time it retries, it’ll complete. Yeah, and also, obviously I can also kill the workflow worker, which holds the workflow code, so we can restart that and we will see that it will recover to exactly the same state it was, so it will adjust. It will, like both local doesn’t even need to know it was restarted, right? So we were at the workflow with the line uh, uh, 38, and right now probably it will just come already completed because it retried the activity. Yeah, so yeah, the workflow is completed and we can go back and check. Okay, we executed this activity.
Uh, first activity withdrawal. It was scheduled at this time. These arguments of this activity, it was started by this process. So you see everything which happens with what happened. Then we’ve got activity uh, deposit scheduled, and this activity was executed eight times. It failed seven times. This is stack trace and exception why it was failing, and then it completed at some time, right? And then the workflow completed. So, think about it. I do need to restart workflow. I didn’t have to do anything. I just fixed my bug and the system just recovered itself and he just won. But if you have like a million of those running at the same time, it’s pretty cool that you don’t need to do anything. It just code recovers automatically in the presence of process crashes and so on. You don’t need to do anything. As we saw, that quote doesn’t contain any, it doesn’t need to contain any error logic related to intermittent failures or outages. This area located here only happens if you have business level failure, right? For example, deposit is not possible because the account doesn’t exist. But at the same time you don’t need to handle a situation when process crashed because it just handled automatically. I don’t want to spend too much time on that. But for example, we also have a unit testing framework, and it means that you can test these workflows even if you have long grinding. For example, you can absolutely write production code, which is workflow.sleep and say something like duration of this, right? And sleep like for three days here, and it’s a blocking call. So, it’s okay for the process to, for example, sleep for three days and then continue. And then you can unit test it in milliseconds because we automatically skip time. For example, okay, so just to review that you can write normal code, and you have full visibility into this code processing, and everything is recorded, and you see all input and arguments, and this code recovers automatically after any intermittent and deployment or failure.
Very, very short introduction. It’s a short introduction, but it’s very powerful as well. Max, and I think you know some of the things. It’s like, yeah, there’s retries, rollbacks, we’ve saw a bunch of stuff. I mean even timers were in there at the end, right? I mean, I think schedules are interesting. Why are people dealing with cron today? Like, you use temporal to run things like that, and this was just money movement, right? This was like a bank transfer, which you know I think is one of those ways in which people use temporal today. You know, high-end transactions where like a bank, like you said, like that can’t fail. Man, it’s money, right? Like you, it’s got to work right. It’s got to be reliable. It’s got to be durable, I think, is the word that we like to use around temporal a fair amount. Um, you know, but like this kind of durable transactions is kind of one thing I think people use it for. Like, say, you know, business processes. I don’t know. I’ll ask you. I know Rylan’s one of his favorite use cases is more of a business process. You know, people use it for like inventory management or, uh, you know, you just, just understanding things and having insight into things. I’ve even seen, you know, I think one of the common use cases is like infrastructure deployment. Um, you know, I’ve seen people end to end, you know, bring software or, you know, bring hardware up, run software, bring the hardware down. Like it’s incredible, like some of the things that people are doing with temporal. Um, Rylan, you’ve been on the front edge of a lot of, uh, people using temporal, and you’ve collected a fair amount of user stories. What’s your favorite user story? I think it’s impossible to probably just choose one. I will say that one thing I want to just make sure I don’t, uh, forget for, you know, what Max is kind of showing there is that like temporal itself almost does a disservice to its own technology by making things look so easy and so much more simple than they actually are. And so even just something basic like, like implementing, you know, retry statefully, that’s an immense amount of code. Like any developer has had to do that, no, that’s daunting. And like that’s just something that’s implicit in the demo that you just saw. And so I just wanted to make sure that that was highlighted there in terms of the users. I’ll choose like a couple. Um, I think, you know, some of them are very exciting because they’re products that I use, and the fact that they’re a user of ours is just cool in itself. And so like, um, one example in that, uh, area is Yum Brands. They’re the company behind, you know, a lot of major fast food establishments that probably almost everyone has eaten at once or twice in their life. And I’m someone who eats like, hey man, tacos, pizza, and chicken. I’m in, exactly right? And so it’s uh, it’s hard not to say that they’re, you know, an amazing customer just on that basis as someone who spends a lot of money at their establishments. Um, so I think, you know, the other part I love about that is kind of going back to this idea that things can look very simple or sound very simple, but in reality, not be that way. You might think that a process like ordering food or having it delivered isn’t that much stuff. There isn’t that much work there, but it’s clear from, you know, the presentations that people have given, like Matt from brands, that there’s an immense amount of complexity there. You could spend days just talking about the complexity of delivering someone’s food that orders, you know, a Taco Bell.
And so I think that, you know, the fact that we took something that’s so meaningful to a lot of people’s lives and we were able to, you know, make it deliverable at such a high scale and with such a great developer experience, that’s super great and exciting for me to see. I think another type of customer that’s so, so exciting is one where I’m like a very strong user of their products or, you know, I really like the brand they’ve created, like Datadog. Um, who for like a lot of developers is like a really representative company of modern cloud development, modern cloud trends. Uh, and so, you know, Datadog is unique because they’re not just going in on temporal for one use case. At this point, they are probably one of the most aggressive users of temporal. Um, even beating us out in a lot of ways in terms of how they adopt and use the technology. And so, you know, it’s amazing when you have users that actually are teaching you about your own product on like a regular basis, and you know, not just teaching us, but contributing and you know, helping us deliver things like the temporal CLI experience and all of that. And so I think Datadog has been like a wonderful partner, but also like one of the most exemplary users and contributors to everything we’re doing here at Temporal.
Yeah, and the taco, I’m sorry, but I got to go back to Yum Brands. The taco one is the one that actually sold me on temporal in the very beginning. It’s very simple to understand because I think everybody’s gone through that experience. You walk into a store, you go to a kiosk, you hit the thing, you order something, the funds get held for a second. Your credit card doesn’t get charged until you get that product, right? So that happens. It goes to the cloud, somewhere a central server, it goes back to the store. A chef picks it up, pushes a button, makes the taco, pushes a button when they’re done, puts it on a window. The guy up front grabs it, puts it to the front, they push a button, and then your number comes up, and Ryan goes and grabs his taco. And then you get charged. The amount of complexity in that small little—what was that, ten seconds—is intense. And all of the things that can go wrong in that equation is incredible. You know, that’s just one time. Do it a million times. Do it a million times. And like if you think about like the Taco Bells, like they’re in all in cities with amazing Wi-Fi. Like a store can be completely offline. And when we talk about durable execution, right, this ability to kind of withstand pressure or damage and whatever that is, and your system continues no matter what.
It’s incredible, an incredible use case for them because I mean, okay, maybe they’re making 50 cents a taco. I don’t know what it is, but like that’s money in the end, right? And so that’s the one use case, by the way, that sold me on temporal. I think that that talk from our conference last year, our replay conference, was really, really just amazing.
Um, when I really think about temporal, I think about kind of like what we can do. That word durable becomes really, really important. And you know, at temporal we define this as durable execution because of exactly that. It can withstand pressure.
Um, you know, this is a framework that allows you to survive damage of these complex systems that you’re building. But ultimately when we look at that, you know, it really helps you kind of deliver more features faster. Um, I always like to use words. It allows you to kind of more elegantly fail. You know, you might still fail, but it’s going to be very elegant. And you don’t have the code for all those kind of situations. And then, you know, maintaining the integrity of your data and having insight end to end to all your processes, I think is just, you know, truly incredible. And I think don’t any fails when you want it to fail. That’s right, because it fails on business problem failures but not on the infrastructure errors, intermittent failures, deployments, and all these other things. That’s right. It’s truly amazing. And Max, kudos, like I’m honored—I really think it’s changing the way that developers think and really changing the way that people kind of approach problems. I’ve seen it happen time and time again. I don’t know, Rylan, what is the best way to get started with temporal? So I think some of the, some of them you saw demoed. You know, even with what Max did, I think you know, starting with our temporal CLI and just having a very good local development experience.
Um, I think like, you know, philosophically, I would say go and watch the presentations from, you know, amazing people like Matt McDole from Yum Brands, uh, and you know, uh, Drew Hoskins from Stripe and Jacob up from Datadog. These are all people who are really, really amazing at representing the problems that they solved with the technology and how it transformed not just their lives but all the developers’ lives that they work with. And so that’s at least for me what kind of has the biggest impact. And quite honestly, all it’s open source, so you can go and start to use temporal today. We talked a little bit about Datadog, their temporal CLI.
Um, you know, and if you want to deploy on the cloud, we make it real easy for you to run it as a managed service as well. Uh, but you know, join the conversation. Our team is, uh, ever present including Max in Slack and support and all the various different places, so you can interact with us. We’re more than happy to work with you to get you started if you have any questions. But Max, Rylan, thank you for doing this today. I hope you enjoyed it. Did you enjoy this, Max? Absolutely awesome. Blast. Awesome, buddy. I appreciate it. I like talking to you guys anyway. So, yeah, um, ah, thanks, buddy. Thank you, everybody.