What Durable Execution Changes

Hey, everyone. I'm Alan Schimmel, CEO, founder, editor-in-chief of Techstrong, and I'm here to introduce you to our newest Techstrong series done in partnership with our friends at Temporal. I think you're going to really like this one.

" And if you don't know what durable execution is, you've come to the right place because that's what we're going to be talking a lot about here today, of what durable execution is and what durable execution changes. But let's start with episode one, and let's start with introducing you to our panel today. We have three speakers in addition to myself.

First of all, we have Tom Wheeler. Tom is the gentleman with glasses. Tom, would you maybe just give folks a little bit about your background, your position, and so forth?

Yeah. I'm Principal Developer Advocate here at Temporal. I joined the company in 2022, and I'd spent 10 years doing technical education at another tech company, and the rest of my career as a software engineer working in a variety of industries, but a lot of them having to do with building scalable distributed systems.

Excellent, and thank you, Tom. Next, we have Sergey Bykov. If I mispronounced Sergey, I apologize.

But Sergey, would you mind introducing yourself? Yeah. I'm Principal Engineer at Temporal.

I joined in 2020. And the main reason I joined was I've always been passionate about helping developers build software in a better way, and this was definitely kind of step function in quality of that experience. So I wanted to help build it.

Absolutely, and thank you for joining us today. And then last but not least, we were lucky to have him. He is joining us from the road, is Maxim Fateev.

Fateev Maxim is the CTO and Co-founder at Temporal. Maxim, welcome. Thank you for having me.

Our pleasure. Maybe a little bit about your-- People always want to know about the co-founders and... Yeah.

Before starting the company, I was engineer all my life. I didn't manage a single person before that, and I worked at Amazon for eight and a half years, couple years at Microsoft, four years at Google, and then before starting the company, four years at Uber. And so the problem which, and this durable execution abstraction, I kind of invented that, but it took over 15 years of iteration to get where we are right now.

Another overnight success. Maxim, over the course-- I've started three or four venture-backed companies myself, co-founded. I have interviewed hundreds of co-founders and founders of companies.

There's always a problem at the heart of every company, right? There's a problem that needs to be solved. Oftentimes, that problem is something the co-founder themselves have experienced in their work, and they realize that it's not just them.

This is a problem everyone has. This is a problem that needs to be solved. This is a problem that somehow will make the world a little better for at least some people.

As a co-founder, you already said you had a problem, and it's taken you guys 15 years to really get to this point where you are today. But let's go back. Let's go back when you were an engineer, and you didn't have anyone reporting to you.

I'm sure you'd like to get back to that point at some point. But what was that problem at the heart of things that led to the passion of founding Temporal? So some background.

I joined Amazon in 2002, and Amazon back then was running on a big monolith. So practically, you could run the whole Amazon website inside of a single developer desktop, which was kind of cool. Like imagine you could put breakpoint on practically any checkout page.

But the little problem was that it was taking over 45 minutes just to relink that binary. It was an Apache module, by the way. And so it was not very sustainable model for development, and Amazon realized that, and they were one of the first companies going on the services big way.

Okay, back then, it wasn't called microservice. It was called service-oriented architecture. But Amazon one of the first companies which did that.

And while doing that, Amazon experienced, kind of had to learn hard way a lot of lessons. And I kind of became tech lead at some point of Amazon messaging platform, platform which was responsible for practically all the pub/sub and asynchronous communication between services. And one of the results of that was the whole platform, and you probably could experience that as a simple queue service because it runs on the engine which I kind of helped to design and implement the first version on, like for messaging.

And as a tech lead for messaging platform, and again, it all existed well before Kafka was even conceived, I was kind of point person for every design review of every new service kind of using those technologies, and obviously, also for every possible problem which you could have with them. And it became pretty clear that orchestration, what people call choreography right now, right? Like when services just publish messages, receive messages, and communicate that way, is just not right way to build large-scale distributed systems So we learned pretty well, like what people call event-driven architectures these days is just not the right abstraction.

It breaks in different levels, at runtime, design time, and so on. And we kind of, as a team, realized that we need to build something else, and we did multiple iterations internally, and third iteration of that product was released as a public AWS service called Amazon Simple Workflow, SWF, and I was tech lead for that. And back then we didn't nail it, because probably most people never heard about that service.

But it was kind of first step in that journey of the durable execution. I love it. And that's such a common fact pattern, that problem that you dealt with, that you had while at Amazon, led to the founding of this company 15 years later, right?

Tom, if you wouldn't mind, I'd like to ask you to expand on what Maxim is talking about and take it from Maxim's own personal pain, right, to the pain we see in the industry around this problem, right? Yeah. So the problems that Maxim's software designed to solve are problems that I faced as an engineer, and I've come to see that a lot of other engineers face them themselves, and that is when an engineer goes to try to make things more resilient, more reliable by building in, for example, retry logic, doing their own state management so that they can withstand a crash or recover from a crash, doing application check pointing, all those sorts of techniques are things that engineers and companies around the world are building for themselves, and they're doing it over and over again.

So the engineer on one team builds it, engineer on the next team builds it, engineer on the next team builds it. m. when you get paged that something is wrong with it.

You find out there's a race condition, you find out something doesn't work properly, and then that's when you have a problem. So what do you do? More complexity.

You do another patch, another if statement. You throw another queue, another cron job in there to try to build reliability. Well, the way you get reliability is not by adding complexity, it's by removing complexity.

It's about simplicity. And that's what Temporal does. It allows you to develop an application as if you're running on a single machine, as if you're making function calls instead of remote procedure calls, so that different parts of the system can fail, and you're insulated from all of that.

It makes the entire system reliable, yet it makes the applications easier to develop. Yeah. And look, in today's world, where things are increasingly complicated for our machines to handle, there's still the issue of cognitive overload, right?

And Sergey, if you wouldn't mind, we didn't give you a chance to talk yet, but as a developer, as a hands-on engineer, talk to us about cognitive overload. So I look at it from kind of a little bit different angle. Maybe I view it as kind of almost like maturity model, right?

Imagine if you were a toddler developer, you build stateless application, you get the request, you make a call, something fails, I return error. I'm done. I'm not responsible.

This is their failure, right? And then as you- It worked on my machine. Yeah.

We've had that before. I got an error, return an error. I'm not responsible for anything else.

Right. As the next step, you're like, "Okay, I'm responsible for something. I'll do retries.

If I got 429, I could back off. " My state is in memory. If something crashes, it's gone.

And then it's kind of like maybe teenager developer, you get into less, "Oh, I'll use queues. " Then I build all this thing which never scales. It always gets into these things that you don't anticipate if you naively approach it.

" One of the big categories of companies or developers that come to us, they built or they use some kind of homegrown, hand-built workflow system because they want to persist a state. They want to know the next step. They want to be able to retry.

They're using durable timers. So all this converges as they take more and more responsibility for reliability. And eventually they decide, like Tom was saying, well, it's complexity that's killing us, that's reducing the reliability.

Can we get rid of it? Can we simplify things to be reliable because it's simple? I love it.

Maxim, if you don't mind, I want to come back to you with that. And usually there's that aha moment, that eureka moment, right? Where we say, "Okay, I know this is a real problem.

" And then there's an insight. And that insight is what we build companies around. It's what we build around.

Do you still remember that aha moment for you with this, and what was it? It's interesting because, if you look at Temporal and the idea of... One thing we understood, we need to do orchestration versus choreography.

And we started to build service around that. But being at Amazon and practically building an AWS service, we thought from the kind of backend point of view, right? So developer experience was kind of afterthought.

So the scalable execution engine was the kind of core idea initially. And then initial API was practically very raw level API, which developers had super hard time working with And then I started to look how to kind of solve that problem, and I ended up doing something which practically everyone does who tries to build similar engine, is come up with our own DSL. So I kind of come up with this, oh, we have this object which represents sequence.

And this object represents a task, this object represents a kind of condition, this object represents a loop, and you get the idea. You kind of compose this abstract syntax tree in memory. I was using Java back then.

And then you kind of can specify your business logic like that, and then you run it. And it worked. And it was much, much better experience than just giving people low-level APIs, which is practically implementing the whole state machine yourself.

One thing I found that I didn't like that experience because it was very verbose, is if you think about it, if you just have business logic, which is like call one function, then make a condition. Like if something, then call another function, else call third function, which can be six lines of code. And then you convert it to this kind of abstract syntax tree syntax.

And I didn't use any external DSL. I didn't use JSON or YAML. It was just pure Java objects, which was actually more concise than probably even shorter than using any other.

I found that it would translate to dozens and dozens of lines of code, which was hard to understand, troubleshoot, and was very verbose. That was kind of bugging me for a long time. So practically, at some point, I've got the idea that can we just write code?

Like code as it is, as I described, like your business logic as failure don't exist. And that it took some time to materialize. The idea is that you can just write the code, but the problem is that you cannot snapshot the state of the code if it's blocked on something.

You cannot call function and then, oh, can I serialize that practically stack trace from Java. You cannot do that. And we wrote first version when everything was asynchronous.

So practically, you had this program which was fully asynchronous. And asynchronous program doesn't tie threads, so there is nothing waiting on a thread. So you could just take and serialize the whole tree of objects after every change.

And I've got an intern implemented that initially and it worked, but it was extremely slow and inefficient. So it kind of proved the concept that you can write a program as asynchronous program, and then serialize it and store it, like kind of checkpoint that state, but it was absolutely inefficient. And then the aha moment was that I was looking into the...

Practically, I've got a bug when this abstract syntax tree approach, which was actually called decider framework, I think, because the core component of the system was called decider, which was making decision what to do next. And it had a bug when two parallel threads, parallel branches were sharing some state, and that state got corrupted. And I realized that the way it was working was incorrect.

Then the only way to actually fix that current state was running, practically replay the whole thing end-to-end in exactly the same state. So that you need to practically have deterministic replay and deterministic execution to recover the state of that, even in this abstract syntax tree. And then aha moment was to combine these two things, deterministic replay and the code to actually make it much more efficient than just serializing the whole state every time.

So practically invent replay kind of logic. And that was the main aha moment. And the next aha moment was when at Uber, we building similar system, is to realize how to do it for synchronous code, not only for asynchronous code.

When was the first time you called it durable execution? That was actually well into the company. We invented that term later.

Initially, it was actually, some history there is, it was called Decide, initially Flow Framework. Initially, it was called Asynchrony. So inside of Amazon, the framework was called Asynchrony, which I liked the name a lot.

But then lawyers figured out that it would violate some trademark somewhere. Right. Trademarks.

And we kind of renamed it to Flow Framework. So if you look AWS Simple Workflow and you search for Flow Framework, that was the official name and still official name I think of that framework at Amazon. But then, co-founder of Temporal, Samar, who worked with me on the Flow Framework, went to Microsoft, and he built a Durable Task Framework there.

And now Microsoft has durable functions, which took that Durable Task Framework and put them inside functions. So the name durable came from there. Ah.

And ideally, one thing I wanted to call Durable Process, when we kind of started that. Problem is Durable Process already has meaning in Linux. It's like if you search Durable Process, you will find a bunch of demon-type processes and a framework around that.

So it wasn't very good as AO. So we kind of end up combining durable with execution, and then Durable Execution was born. Like everything else, marketing got involved, and here we are.

Tom, Maxim gave us, only the insight he can have as the founder. But I'm going to ask you, and Sergey, feel free to jump in here, how do you define durable execution? Is what Maxim said...

I'm sure it's not wrong, but is that how you view it, Sergey? Is that how you view it as well? I think of durable execution as crash-proof execution.

It's giving you the illusion that you have a single machine, and you can write an application for it, and it's able to withstand crashes. If the machine goes down, it goes from being a catastrophe to a very inconsequential issue. And your application's able to recover from that with full state intact and not forget what it's done and not repeat the steps that it's already done.

And so I would say it's kind of like in a network operating system, packets can arrive in different orders. The operating system assembles it, so you, the developer, are unaware of these sort of problems. If there's dropped packets, they get re-requested, they get reassembled.

So as a developer writing, let's say, a web browser, you don't have to think about how packets flow across the network or how they arrive to your machine. You're concentrating on making the request, getting the response, and doing something with it, rendering it to the screen. And so Temporal similarly elevates the way that you do development because it takes failure from being something, and crashes from being something that completely wrecks your application to something you can basically ignore.

And so that's what it's all about. It brings the joy back to programming. I love it.

" That's a quote. Sergey, what about you? Does it bring you joy?

I try to look at it from the end goal, right? So what do we want in the end? What's the experience we want?

And as an engineer, as a developer, I want to write code that just describes what I want to happen, right? I want to do step one. Like if you take one of our young brands like Taco Bell Order or like Snap Stories, I want to process them step by step and write just that logic.

I don't want to write any boilerplate code. I don't want to write any back-off code, because that code is not joy to write. It's usually half incorrect because it's very difficult to test it, right?

And the best code, the most reliable code is the code you've never written, right? Because it doesn't have bugs. So from that perspective, being able to just explain, express what I want to happen as opposed to dealing with all these failures.

Also, don't forget time. We haven't touched on time. " How do I express just this logic without writing a whole bunch of machinery?

That's what durable execution for me is about, is this simplicity and the very clean way of expressing just what I need to happen, not all the boilerplate, all the machinery, all the liability stuff. Tom, I asked you and Sergey to layer on on top of what Maxim said because I wanted to get the point across that in today's world, not all developers, not all of our engineers are at the same level, especially with AI and everything we're talking about. Where are we hiring junior people, newbies?

Where are the newbies? If we don't hire newbies, when the people like us retire, who's going to take our place, right? But something like durable execution and the concepts behind it could mean something different if you are a newcomer to engineering compared to an expert, compared to just your average developer.

But regardless of where you are in that life cycle, the problem is still there, right? And the issue's still there, and the solution, you don't have to be an expert to use the durable execution in Temporal, and I think that's an important thing to talk about. Tom, you're shaking your head.

Yeah. So I think our adoption, the adoption of Temporal to this point has largely been by senior engineers because they recognize the problems that Temporal solves. They've had to solve them for themselves in the past, and so they've built their own mechanisms for doing that.

So when they see Temporal, they immediately recognize that it's a better way of doing things, and so that's where the adoptions come from. But I think Temporal democratizes the ability to create reliable, scalable systems, and it makes it available to everybody so that you don't need a PhD in computer science. You don't need 30 years of experience doing distributed systems.

You can take this software, which is open source, and then be able to build something remarkable in a very short amount of time because it makes you productive. So the benefit to senior developers is obvious. But the ability for a junior developer to do the sort of things that would have previously taken a senior developer, it's there.

And I think if you're a junior developer and you're looking for a way to set yourself apart, absolutely look at Temporal because that's giving you a superpower. Instead of spending your time doing this undifferentiated work of building the reliability that I was talking about, people in every company have to sort of build for themselves in a world where Temporal didn't exist, well, now you have a head start. You have a foundation you can build on, and you can then spend your time developing the parts of the application that customers actually care about, and that's going to set you apart from the competition.

So while the other people are still debugging stuff, you're going to be out there shipping things. You're going to be working on the second version. You're going to be scooping up customers and getting market share.

You're going to be setting yourself apart, and I think Temporal sets developers of all skill levels up for success. Sergey, so I think we've defined it. We've defined the problem.

We've defined here's the solution. But let's talk a little bit about how it works in practice, right? Let's get real now.

" Feel free to jump in, but let's have a group discussion. How does this really work in practice? All right.

Let's make it tangible. Go ahead. Well, I think I just want to make sure that people...

Because we talk about durable execution, and all three of us know very well what it is, but I think people still can be confused what it provides as a developer. Just think about it, imagine use case when you want to do customer subscription, right? You want to do and-Let's say you need to charge them 12 times during the year, once a month, right?

And then send them notification. And try to design that in your head. How would you design a system which just once a month charges credit card, then sends email, right, and then repeats that?

And then you want to do it for like, let's say, 100 million users. And it's a pretty interesting probably exercise for a coding interview to try to design such a system. And then start thinking about failure modes.

What happens if credit card doesn't pass? What happens if a provider is down? What happens if all sort of other system can be, like email is not answering and so on.

And in Temporal, practically, if you use durable execution, what you would do, you would just write the practically normal code. You would say for loop 12 times, sleep 30 days, really like calculate, probably sleep into wherever you to end up in the end of the month, and then charge and send email. And you write such a loop once.

And this is the code you will write. This is kind of most of it. Because durable execution will guarantee you that in presence of any failure or any crash, this code will be resurrected, all state will be preserved, and it will continue running.

Right? And then any API call, for example, if you send, say, charge card and system is down, it will behind the scenes retry it as many times as necessary, even for days. And then, your code will unblock the moment it goes through.

So just think about just how much code and effort you saved. And this is also scales to any number, so you can have billions of those running parallel. So it's absolutely practical to have one of those functions running per customer, even if you are somebody like Facebook, right?

So you can run practically any scale. And it's given you practically out of the box. That is kind of the basic idea.

" And this durability of this code is provided by the underlying system. You know, Maxim, I remember when AWS first came out, right? " Right?

You want the same infrastructure, the same kind of experience that Amazon gives their customers, we offer it to you here with AWS. Of course, not everyone really needed that level of scalability. And now as a CTO co-founder, you know if you're selling to enterprises, even if they don't need that level, they think they do or they want to be able to scale to that.

But you also have customers who realize they're not a jumbo, they're not 100,000 employee or however you want to measure size. But they still need durable. They still need stable.

They still need scalable. Sergey, I wanted to give you a chance to participate a little bit more here. I would add to your list reliable, right?

Yes. Because no matter how many the customers you have, you have some business processes happening, like processing orders or requests, provisioning infrastructure. Like it doesn't matter if it's 100 or 100,000, right?

If 99 out of 100 succeeds and one is stuck, you want to know what, you want to react, you want to figure out what's going on. And so durable execution allows not only you write just kind of intent code, here's what I want to happen, right? But you also get visibility into what exactly each of these execution is currently at, right?

Is it waiting on some service? Is it getting error from some dependency? So it empowers you with this kind of visibility into what used to be hidden within the running process.

You have running process and it spits out logs, and then you can use grep, you can use tail, lexi, trying to figure out what's going on in production. In this case, you have visibility. I have 1,000 customers and I have these orders, 10,000 orders being processed.

I can see that 10 of them failed or are failing, right? That's the superpower you get right away without writing any code for that. Fair.

So let me add one more thing. So, one thing that people- Sure ... don't think is even possible until they learn about durable execution is patching live code.

And this is very absolutely real case where you run your business process, needs to call a API of some dependency, shipping or like a payment processing. And on the other end, they change their API. Now what was optional parameter became required, or they enforce some form.

Your calls are failing that was succeeding just yesterday. What do you do? Like in this case, you can see in this visibility that this is the error code, that you're missing the required parameter.

But you can go and change your code or your application, deploy this new version, and it will continue from this step. Now these calls will start succeeding and your business processes, your orders, that process will complete. That's another example people cannot even think of until they see it.

So guys, I was out in San Francisco last week for the RSA Security Conference. It was all about agentic AI, everything agentic, everything agentic. Maxim, when you first started at Amazon in 2002, I don't know if you were thinking about AI and agentic AI and all of the things that we-- But we find ourselves in such aInteresting place.

It's exciting and scary at the same time, right? There's disruption happening, there's change happening, but there's also opportunity happening. And increasingly, engineering teams, software teams, security teams are being told, "What you used to do isn't going to work, doesn't work going forward.

We need you to adopt new ways of doing it. We need you to go faster. We need you to go deeper.

" Maxim, I'm going to ask you to kick it off, but then Tom and Sergei, please jump in. What happens now if you want to keep... Can we keep doing it the old way in light of the world we're living in?

And how does durable execution help us in this brave new world that we find our... Especially a lot of developers out there, we're all mind-boggling in so many ways. I think from one point of view, AI and the LLMs, they changed everything.

At the same time, they actually increased-- They just made existing problems worse, right? So if you think about it, a lot of development the last 25, 30 years was about increasing number of moving parts, right? Because we have desktop applications, then we started to do multi-tier applications, then we added containers, right?

Then we added sandboxes, Lambdas, and now we added agents. And if you think about it, where we had three parts in the application or five parts, now we can have millions. And we are still in this kind of baby era of MS-DOS or for agents, because most commonly used agents and most popular agents are still running on a single machine in a practically single process.

But we clearly see that they become much more longer running, they're becoming smarter, which means that we'll do more work and communicate to each other, communicate to external systems. And we get a lot, a lot of moving parts. And practically, your systems become more and more distributed.

And this is exactly what kind of durable execution and Temporal solve, is that we solve problem of scaling and running reliably large distributed systems. So practically, from our point of view, it's just Temporal is perfect fit to solve this problem of any agentic system which cannot lose state and fail in the middle, and especially right now, the system actually not only read information, but they also change the world. And you don't want to end up in situation when you change half of the world and the other part is just dropped, right?

So you want to make sure that... And also, there is just tokens thing. You do something like deep research, you do 40 minutes of LLM calls, and then on the last minute, something crashes.

You don't want to lose all this progress. It's just expensive. So this is also other problem which you solve out of the box using something like Temporal.

And durable execution just makes it trivial to implement that. And so that is one part, is running these systems. And another part is generated code.

LLMs are pretty good translating your business requirements to code, which is like corresponds to those business requirements. But the moment you say, "Okay, it's fine that you can call these five APIs to achieve the goal, but now make it fault-tolerant, durable, and make sure that this scales to million parallel items," LLM will not have been able to do that without a lot of guidance. With durable execution, you can practically separate all the complexity and outsource all the complexity to durable execution, and then make LLM generate simple business-level logic, and you get the best of the both worlds.

Excellent. Yeah. To expand on that, I think AI changes the economics of software development, and it means that we're going to have a lot more software in this world because it's less expensive to develop.

And so things that weren't feasible to create before suddenly become possible. You're no longer constrained by the difficulty and the commitment of creating software. But it doesn't change anything about the need for reliability.

Ultimately, this software has to work. It has to deliver results. It has to deliver value.

And so, as what Maxim said, if you have an agent that's taking, let's say, 100 steps to achieve some result, and you get 99 of them right, and it fails on the last one, then you failed. You haven't delivered the value. There's no partial credit here.

Nobody's going to pat you on the back for the 99 that you got right. It's the one that failed in the end that wrecked the entire thing. It's wasted tokens.

It's wasted opportunity. And so you need reliability more than ever before, because ultimately, even if there's agents in the loop doing things, there's a human on the other side that's waiting for these results, and they require that the thing has to work. You've got to make it to production.

You've got to deliver results. You've got to deliver value. And that's what Temporal helps companies do.

I think it's- I think it's- Oh, go ahead. Okay. Sergei, go ahead.

So there's interesting maybe way of looking at that. The more things change, the more they kind of stay the same, just at a different level. One of the reason that was easy for me to join Temporal, because before that, I spent over a decade working on actors, right?

And just isolated things, they hide their state, they exchange messages. And if you think of agents, they're kind of like actors. They're addressable.

They have their stable identities. They hide their state. They send messages to other agents to help them.

What they're missing if you just do it the old way, they're missing the statement durability, like reliability of the execution. And so if you combine these old concepts from the '70s with the new ways of doing managing state You get to this new kind of paradigm, even though it's a kind of combination of all previously discovered tricks, how to build software. And that builds this kind of program model, which program model is how you think, how you model the solution for a problem in your head.

Like how do I visualize in my head what I need to build here? And the simplicity helps with that, with just kind of mapping these agents into something that easy to explain, easy to think about. So guys, we need to wrap up.

But Tom, you said something that is such a term of the times, wasted tokens. Wasted tokens, right? " Well, the worst thing in our time right now is wasted tokens.

Because no one wants to waste tokens on AI that we're not making forward. But guys, we need to wrap up here. We try to keep these at a reasonable length for people to listen to in one sitting.

I think we understand now what we mean by durable execution. We understand how it applies in today's world as much or as more even than when Maxim was working on this problem, solving this problem in Amazon all those years ago. Let's talk about going forward a little bit.

First of all, durable execution is not a tool. It's more of almost a mindset shift. It's a way of looking at how we're going to do things.

It's also an emerging standard. Teams should start exploring it, even if they're not going to use Temporal Durable Execution today. Because this is a question of not if it becomes the standard, it's a question of how soon are you going to start solving this problem.

Because we all have that problem. And this is exactly the kind of things we're going to delve into now going forward. Episode one here is very much a foundational episode.

We laid out a lot of foundation. I'm really excited to see where it goes from here. Maxim, I don't know if you'll be joining us on every episode, but I certainly hope so.

I realize you're busy. Tom and Sergey, thank you for joining us. Thank you for watching this.

By the way, go check out Temporal. Do a Google search if you still do Google search, or ask your AI about durable execution and see what it says. We'll be back probably in the next two weeks with our next episode, so stay tuned for that.

You can watch it here on Techstrong, Techstrong TV, the Techstrong OTT channel, or all your favorite wherever you listen to podcasts, Apple, Spotify, et cetera. It'll be up there. Gentlemen, thank you for joining me.