 All right. Let's see. This doesn't look right. I think. Let's see if I can. Do you guys see the presentation right or is something going on? Yeah, we can see this line. All right. Let's go. Sorry. Let's go ahead and get started. First of all, thanks. Thank you guys for having me present here. In this talk, I'm going to talk about Temporal, which is an open source, reliable, scalable microservice registration platform. And hopefully, but the end of this talk, you will see the parts of the reliable and scalable and stuff like that. And why does that matter and how Temporal solves those particular issues? My name is Tijku Mishordilovic. I'm a developer advocate at Temporal. Most of the project lead at CNCF Serverless Workflow Specification. Here's my tag if you want to follow or say hello. About Temporal, just a couple of links. If you're interested or after this talk, you want to learn more about it. Here's some notable links like the website, of course, docs, the meetups. We have monthly meetups. So if you want to meet the team or meet the rest of the team from Temporal and ask any questions, you're more than welcome to do that too. For any questions that you might not want, you know, kind of private or whatever if you have, you can always email that product at Temporal.io as well. In addition to, you know, kind of like things that I'm going to talk about today, you can see a bunch of different case studies by different companies who are using Temporal in production and you can go to the website and access them and read how, you know, the different use cases and how different companies are utilizing Temporal. Now, when we talk about Temporal, it's really two things. We talk about the server and the different SD case. The server itself is just a goal and binary. There is nothing to it. And you can deploy this binary on Kubernetes. You can deploy it on Docker. You can deploy it really in any infrastructure that you currently have available. In addition to that, Temporal provides a cloud platform where, you know, if you don't want to deploy it yourself and you can deploy it on the Temporal cloud and run, you know, use that for your applications as well. As far as the SDKs goes, Temporal currently has four SDKs go PHP, Java and Node. And it's just like the same thing. Since you're using a programming language approach to write your business applications, you can deploy them still on any framework that you currently have existing or tested and employed on any infrastructure you currently have available. So Temporal is not restricting you in that way in any sort of way. So we talked about the Temporal server, what it is kind of on the high level, but let's kind of like take a little bit look inside. So the server is composed of five different services. They're independent services that communicate with each other to the front-end service and we'll talk about what each one does. But the basic idea is that you have full control of your server's scalability in terms of horizontal scaling by deploying your server on multiple nodes, for example. And you also have horizontal scale, vertical scaling by being able to replicate, for example, each of the internal services of the server and that way achieve scalability of your applications as well. So let's just quickly look at each parts of the service of the front-end services, basically exposes a GRPC API that your application that you run actually can communicate with the server. So all inbound calls from your client application from the microservices you're developing can communicate with this front-end service. So the history service deals with things like workflow or your business logic state transitions. So here, the state of your current execution of your different application is stored and things like that. You have a matching service. That is the service that actually controls the execution of parts of your business logic applications. So this will be more clear here in a minute. And basically parts of your application communicate with this as well. And then we have the internal worker service which does some background processes, replication, and blah, blah, blah. As far as the database goes, Temporal supports Cassandra, MySQL and PostgreSQL for persistence. And the database stores a lot of different things like your workflow task, like what's currently happening, what should happen, what has happened so far. The data that is local to your business logic or the data of your different executions, the events that are happening during the execution of your applications, and also stores a bunch of different visibility data that we'll take a look at as well. The scaling of the database part of the Temporal server really depends on which database you use. So it's going to be a different scaling factors if you, for example, use Cassandra versus MySQL. As far as observability goes, that's always important. The Temporal server itself emits, and as well as the SDKs emit a ton of different metrics out of the box. So there's nothing really that you have to set up on the server and on the SDK side, since those are your applications, you just have to say which metrics you want to actually use or not. And these metrics, of course, especially for the server side, you can easily scrape with Prometheus and also define the different dashboards with Grafana, for example, your favorite metrics systems. In addition to metrics, out of the box when you do your work with the Temporal SDKs, you get tracing, so you can trace your execution of your applications on things like Yeager and stuff like that. Now, let's take a look, I'd like to take your approach and let's see what Temporal server really looks at from a different perspective or user perspective. So if you are a developer and you really want to focus only on writing your business logic or implement the requirements that you have to do for your application that whatever company you work at, the Temporal server really looks something like, okay, I don't have to worry about things like event handling, dealing with timers, dealing with actually storing anything in my application, transaction management, the Temporal server is fully transactional and things like that. I don't have to deal with, for example, if I'm calling multiple services in my applications, I don't have to deal with any queueing systems. And also like we saw, we don't have to really worry when we write our code about things like analytics and metrics that come out of the box for you. Now, Temporal server is not kind of like a joke and because of the scaling factor which can happen in both the server and then of course also in your application and you're actually able to execute hundreds of millions of these business logics or these workflows currently. So this is kind of like a very interesting approach that you have something so powerful that you can really write your applications and scale them on a very high level. Now, the Temporal server itself does not execute your code directly. It more like guides your execution of your code but there's still code is executing on your servers and on your deployments. The Temporal server then tracks and managements your application and also its state. Now, at the same time, if we look at, for example, the SDKs, as a developer when you write your logic, you can still use your programming language. You can still write your apps in Go, PHP, Node, Java or if you have Polyglot type of applications, you can use multiple of these languages. The SDKs with Temporal provides you, of course you have the capability of programming language but in addition to that, you have a very easy approach. We'll take a look in a second for development, testing and also writing your client applications that need to interact with your services and things that you have. Now, from developer perspective, and the reason why I showed it really is a lot of times when you're developing or adopting some sort of workflow solutions, you're a lot of times bound to the overall development environment and things of that workflow runtime. With Temporal, it's not really the case. You can still use your favorite ID in case this is IntelliJ but whatever you're using, you don't have to get out of that environment. And you're really concerned about writing three things. The first one is of course workflows, which is deterministic implementation so your business logic. You have to think about orchestration. So during your business logic, you're orchestrating for example, invocations of different services, which we'll see are called activities within Temporal. And you can write fully fault-tolerant control for logic. So he has full support of course of the programming language constructs, object-oriented constructs, but in addition for things like automatic retries, cron and time-out execution, based execution, compensation, fully sync and fully async invocations as well as of course parallel invocations of your services. Like we said, you can use all the OO features or your programming language that you're using and you also have for example, database conditional weights and sleeps and stuff like that all built in without you actually having to worry about how that happens behind the scenes. Now as far as the activities goes or the parts of your application, they're supposed to do things like file access, invocation of third-party services and stuff like that. There you can really have non-deterministic or really any code type of approach. This is your, we have people integration of temporal with different frameworks and right-headed, it's a big Java shop. So things like Spring Boot or Quarks event and stuff like that. And again, you have full sync and async approach, depending on of course your programming language used and stuff like that. The third thing is of course your workers. These are processes that host your workflows and activities that communicate to the temporal server, GRPC of course, using long polling and they provide full data privacy. So even if you have a temporal server, your application has some privacy or private information that you don't wanna secure information that you wanna share, you can encrypt it on your end. So the temporal server when it saves your state or your application and stuff like that, there is nothing there that is stored that you don't want to. Now, as far as from the app development perspective, you have a web UI where, you know, this kind of typical for anything where you can use to monitor what's going on what workflows or applications are running which ones are not. You can look their full histories as far as events would happen. You can see the stack traces and stuff like that. And also even more powerful is a CLI that you get also for free, it's all open source. And you can actually do everything that you can do in the web UI even more like execute batch commands and stuff like that as well. Now, as far as app testing and debugging, which is very important in any workflow system, this is probably the one thing that is probably, you know, differs a lot between different implementations. As far as temporal go, since again, you're using a programming language approach, you have full support to use your favorite IDs, your favorite debuggers, your favorite testing frameworks and things like that. And again, workflows can be tested, they can be mocked and temporal is the case also provide a testing API where you can test your workflows where they're mocked without actually a server running, but it has an internal built-in capability so you can even run your tests offline. Same thing for activities that can be tested independently different, you can test different timeout options and stuff like that. So we saw this from the development perspective, what about some sort of architect perspective? Or, you know, I know now developers really do everything but still kind of like this approach of thinking about building some frameworks or higher level concepts to build your applications. So the first thing we probably wanna think about, hey, can I use my existing frameworks that I use? And this is especially true if you already have an existing application and you want to start introducing temporal or as a technology into your system. And the answer is yes, because of the way that temporal is again a programming language approach, you can use it in any framework that you currently have. There's no problem with that. The second thing, hey, can I still use my existing programming language? It's a lot of workflow solutions force you to kind of do develop in a way that you're not currently doing it. Then you have to basically adopt a whole new development model in order to start utilizing these runtimes and their services. So for as far as temporal goes as an architect, you can continue using your existing programming languages or if you're thinking about new applications, you can really write them in the way that makes more sense to you given the development team that you have currently available. As far as the dev environment, hey, can I still use my IDs? Can I still deploy to Kubernetes? Can I still deploy my applications to test them on the frameworks that I currently have going on? And again, the answer is yes. There is no restrictions that a portal imposes onto anybody really in order to adopt it and start using it. And so again, of course, testing, can I still use JUnit? Can I use Testify? Can I use PHPUnit? Things like that. And the answer is again, yes. You can test the applications using a favoring testing framework in the bucket inside of your IDs as we saw earlier. So as far as adopting any technology into something that you haven't written yet or something that you knew is fairly easy, but the problem always becomes, hey, I have existing applications. And this is kind of not like how every application is, but overall is you have some sort of data models on the left in this circle, some sort of eventing platform where you're getting events from internally, you have your object model or the representation of your business requirements and the thing that actually makes your applications take or work or what they actually do that is your knowledge of your company. And then of course your code wants to communicate with some third party services, UIs and stuff like that. So from the perspective of adopting temporal into an existing applications, really all you have to worry about which parts of your applications that want to turn into workflows or the core orchestration of your business logic that it does and which parts of your applications you want to turn into activities or as we said, parts of your applications which are responsible to communicate with third party systems, UIs, file access, database access and stuff like that. So now that we've seen all this now, what's still the core value proposition of temporal? And the core value proposition is really as if you're a developer, if you're an architect, whoever, it doesn't really matter, it's all really mixed, we want to write our application service services the way we want to write, right? And the value proposition of temporal is that by using temporal, you can have your services or applications that you run fully durable, fault tolerant, they can, even if you have some outages for five minutes or five months, you can still restore your applications to the state where the failure happened and continue their execution. You have fully distributed way of writing services without even thinking about it. You don't have five frameworks and whatever, you can choose what you want, you still have fully distributed applications. You can scale your applications, like we said, to execute millions of workflows concurrently, so it's very high scale. And of course you can write your services polyglot and the reason I put that is again, a lot of run tests restrict your single way of developing the single way of a single programming language or approach but polyglot, we saw it temporally, it can use currently for and I'm sure in the future, there'll be even more programming languages that will be supported. Now, again, let's take a look a little bit about how this works. So on the left-hand side, we have some sort of business class, this could be any classes, again Java, it could be a game go or PHP or whatever, where I have some my customer class and this is my current code that having my application, it needs to update some account and we have a get customer method which returns, so some sort of way to return some information and we have some exit method here, which it typically could be triggered by a signal, for example, from some sort of messaging service. Now, we have some, of course in Java, but this will be a little different in Go, for example, we have some sort of interface, again, this is our code that we currently have, there's nothing to do with them, portal that describes the methods of our business class that we have. So basically, first thing we have to do is we want to turn this into a workflow interface. So just with a couple of annotations at workflow interface, at workflow method, query method, for example, the get customer that returns could become a query method where, and also we have a signal method, meaning that our exit method can receive signals from different sources. And just with that, we've turned really our my customer class on the left into a temporal workflow. Now, of course, we have to still think about what did we gain with that? Well, with just this little small changes, our my customer class now can be long running, it can run for years, without really thinking about much resources, especially on our side, it is fully stateful, so all the local information, local variables, our pieces persisted without us really thinking about database becomes fault tolerant completely. So if something breaks during the middle of execution, you can easily replay the state and continue its execution, it can be invoke sync or async without us even thinking about using some sort of frameworks for that, can be fully versioned and also fully tested. But of course, we still have to say, okay, how do I interact with this thing once I have my workflow? And how can I actually write my business logic so it's deterministic? And we'll talk about the deterministic factor of the portal here in a minute as well. Now, the next thing, okay, now I've written my workflows, how can I actually interact with them? On the left-hand side, we have like a box to represent our client application. Our client application wants to start some workflow, stop and interact with them. On the right-hand side, we have the temporal server. So the temporal SDKs provide APIs to send commands to the temporal server. That can be, for example, start command, there is a bunch of other different commands and there is many, many more. So let's say through the code, we have here workflow kind of start, so we want to start a particular execution of the workflow. This command is sent to the server, which is then going to schedule actually the execution of our workflow by placing on the right-hand side, a little dot task onto the task queue. Now, on the bottom right, we see our application code, which again is a combination of your workflows and activities and your workers. Our worker is going through a long poll for this task, wait for it when he receives it, is going to get any information out of this task and he's going to then determine what to do, should we execute a workflow, should we schedule an activity, should we just go ahead and do nothing? If we have a long sleep or a wait in our workflow execution and things like that. Now, once this task has been completed on your application code, your application can send again commands to the server. The server figures out if it needs to, for example, create timers, if it needs to persist, things, whatever it needs to do, make it put another task onto the task queue, which is then again consumed by the worker and then continues the execution of your workflows and activities. Now, on the right-hand side, we see kind of like the continuation of the previous slide. So let's say a task arrives, our worker has pulled the task queue, has received a new task onto whatever task queue it's listening to. Now, important thing here is that temporal is a fully distributed system. So this particular app code could be something completely different. Or in case, let's say your application code crashed and you redeployed somewhere completely different, again, this application and the worker can still listen to the queue when it comes back up and receive the workflow task from the server and continue execution of your workflows. So the workflow task itself includes things like, okay, what are we supposed to do next? As far as the execution where application goes, but also includes information about past events and what has happened so far. And especially these past events allow us to replay our current execution to the point of where it either needs to proceed further. Or for example, in case of failure where it has crashed and now we have fully preserved the workflow state, let's say on the left-hand side, we see customer activities update customer account. This is kind of either where we need to continue execution or let's say in case of failure, we recovered from it and want to continue execution as well. So the replay really allows us to preserve what has happened so far without re-executing everything twice. So temporal provides at most once execution of your activities, for example. So the replay doesn't call your services five times and you have unexpected results. But anyway, so if so far the past events match the execution of your workflow execution so far, the workflow is deterministic, which means everything that happens so far matches with the event history of what happened and the workflow can continue execution according to the what's next information. If it's non-deterministic, that means you either introduce some change and things like that and the workflow is going to fail in this case. So what about microservice orchestration? Well, this is kind of like the typical part where how do we write our microservices? Well, I'd say we have a food delivery service in the top left part, which again can be polygonal completely and our application orchestrates third-party services that we don't really control, such as dispatch, restaurant, payment and blah, blah, blah. And the typical, this is kind of like the typical way of writing things. Well, you can still use this with temporal and you still have the ability out of the box to deal with intermittent failure with, for example, automatic retries of your activities. So let's say dispatch service has an intermediate error. It's down, you'll get automatic retries. You can also configure those retries and stuff like that and retry until the dispatch service comes back up. You can also deal with continuing failure. Let's say our payment service is down for weeks and we just can't recover from it. You can easily configure things like some sort of saga patterns or something to compensate. The work that has been done so far. Another thing that temporal allows you to do, which is really key is rate limiting. So for example, you don't want to write your food delivery service to bomb, let's say the payment service or the dispatch service. You can easily configure rate limiting, which can also save you, for example, cost in the long run if you don't wanna hit some service over some amount of time per, numbers of times over some period of time. Now where temporal really shines is a microservice orchestration where multiple microservices that you write are connected to the temporal server and using the temporal server. In this case, we have on the left-hand side our food delivery service, which has a workflow and its worker, sorry, talks to the temporal server. On the right-hand side, we have a dispatch service. Now dispatch service can be written by different company, it can be different department in your company, whatever. It's a completely separate team, for example, the rights to dispatch service, but they can together using temporal and its SDKs communicate with a single server. And what that allows you to do is again, you can, for example, rate limit each service individually rather than, as we've seen before, your food delivery service having to deal with rate limiting third-party services. You have full error handling and propagation between, for example, the dispatch service and the food delivery service. We'll take a look at that in the next slide. And again, the polygon aspect, you can write one application or the food delivery service in Go, you can write the dispatch service in Node.js if that's what your teams are working on and you can still communicate with each other without any issues. Now, one thing about error propagation chain in cross-polygal microservices, this is super hard to do, typically. You usually, when you have polygal services, you have to deal with either some sort of JSON or you have to deal with error messages being in some sort of string format and communicate with that with temporal. It's not really like that. Let's say we have a food delivery service again on the top left, which is written in Go, and our workflow, let's say, invokes an activity. And this activity, of course, through the temporal server invokes no restaurant service workflow, which is written in Node.js. That thing calls its activity and then again invokes just an activity of our payment service, which is written in PHP. Now, what happens actually when the payment service goes down or it has an error? Well, at this point, what do you do typically in your applications right now? The temporal, especially if all of them are using a temporal SDKs and communicating with a temporal server, you can easily propagate these errors back. So for example, the activity in our restaurant service can catch this exception in the PHP workflow. You can add some data to it, then you can propagate it back to the restaurant service workflow execution. This can propagate back, again, this is Node.js now that we're talking about, back to the activity of the food delivery service. And finally, our initial workflow which started the orchestration of this particular microservice, different microservice who can get the error. And when it gets the error, it's not like a four or four. It's not like service not available. It's a full error that has the payment service error includes things like the original error from the PHP payment service, the account information from the restaurant service, the amount paid from the restaurant service and things like that. And it can, you basically, you have full control at this point with this error, what you can do. And then again, this is polyglot across different microservices as well. So that's kind of it for what I have. I have also a short demo but I don't know if you're out of time or not. I apologize if we are moderators, please let me know. And for more information about Temporal, if you're interested, go to docs.temporal.io and get in touch again on the community side and Ruma if you're interested in meeting the team and then joining the monthly meetings. I do have a demo, but again, moderators, let me know. Yeah, so the time slot is up but I don't think we have any other talks in this track at 10 a.m. So if you want, you can go ahead with the demo and if people want to attend a different talk, they might head off. Before you do that, do you want to answer some of the questions? Yeah, are they all in chat? Sorry, I'm trying to. Yeah, I can just read out to you. So our question is, are workflows meant to supersede web frameworks? That is instead of writing application code in a web framework like Laravel, PHP, I read a workflow that runs some business logic. If I understand the, no, the workflows are really just the core implementation of your business logic. You can still use a web framework to expose them to your customers. So a lot of times when you use things like some web frameworks, whatever the web framework would be, you can still use it. You can define REST endpoints that make sense to your application that you expose to end users. And when they hit that endpoint, they can actually invoke different workflows or the core implementation of your business logic. And again, with Temporal, if you have some sort of web framework where you just get some requests from a customer and run some code, you have that still, but also with Temporal, you have full fault tolerance. You can deal, again, like we show with being completely resilient. And even if your web request fails, you can do automatic retries and recovery and stuff like that. And then finally be able to respond back to your web framework to your users. Does that answer your question? All right. You mean yes, they don't say anything in the chat. So they also have another question, which is how does Temporal fit with container orchestration or management tools like Kubernetes? All right, thank you for the question. That was very nice. It, as we said, the Temporal server does not really restrict the frameworks that you use. Temporal does have out-of-the-box Helm charts support for the community so you can deploy your servers on Kubernetes if you wish to. And you can also, of course, deploy your applications with your workflows and everything on Kubernetes too. It is one way of deploying it. I think most of the companies that we have seen that they use Temporal yet, they probably deployed on Kubernetes or some other sort of system that is similar. All right, and I think the last question is, can we able to do a micro front-end app structure using Kubernetes? I have to be honest, I don't really know what the micro front-end app structure using Kubernetes is, but again, with Temporal, your applications or your applications, as we said, you deploy them any way you want to. The only thing you have to do is make sure that you can, of course, communicate with the portal server or cluster of Temporal servers that allow you to have all these benefits of using it. So I just see another question come in. I'm not sure if this is gonna be something related to temporal, but why does Windows have issues with Kubernetes? In handling load balancing pods? I'm not really sure. That's probably a Kubernetes question more than Temporal question. I'm not really sure how to answer that one. That's fine, that's fine. And just a clarifying question. So workflows are more like task runners, is that correct? The workers more than anything. So basically, like we said, Temporal server does not execute your code. Your applications are still executing the code. So what happens is, let's say you have a weight in your business logic. So let's say what you wait for a week, right? Your worker is going to make sure that the timer is actually created on the server and it's going to hold the execution of your workflow or your business logic for as long time as you specified, of course, in your code, in the end. During that time, there is not going to be any resource utilization. So this is kind of like this whole Kubernetes and scaling to zero thing. While let's say your workflow and your applications, again, waits on something, perform some sort of timer work where you either wait for an event for a certain number of time or there is just simply no execution for a long running workflow, there is nothing going to be utilized under your application resource set. So that's kind of like, hopefully answers your question. So in a way, yeah, it would be kind of like a task runner, but that's more of the part of your worker part. And again, you can scale your workers any way you want in your applications. And we see that all the time where it's scalability is not only on the server, Temporal server side, but for example, you can have a whole fleet of workers for the same application. And you can really say, okay, I want this workflow to run and this worker, these workflows and activities of this worker, and you can scale your applications and a very high level in order to utilize or have high performance or throughput for your customers. All right, I think that was all the questions. Thank you so much for answering. And yeah, if you want to go ahead with the demo, I think we can do it, but there is a keynote starting at 10.30. So, what I'll do then, I apologize, but what I will do, and I'll do the demo next time, apologize, I didn't know and thank you again for allowing me to talk over the time. I did want to show you, the demo is basically that I wanted to show is a polyglot application using the Temporal, Java, Go, and PHP as the case. And it's just a game. I like to do kind of... Sure, sure. When I do things. But it is on GitHub, you can go to this URL here on the GitHub. We cannot see anything on the screen, by the way. Sorry to interrupt. Oh, am I not sharing it? Let me try to share it, yeah. I'll put it in the chat. Is that okay? Yeah, that's perfect, yeah. So here you go for anybody interested. This is GitHub repo for the demo, and it has clear instructions. And also if you go to the Temporal YouTube channel, I do have a video that shows the demo off as well. So you guys will not missing anything. So yeah, thank you so much. Appreciate it having me. I'm happy to be here again. And yeah, if you have any questions, let me know if not, have a great day and great rest of the conference. Yeah, thank you so much.