 Hello and welcome to this lightning talk for FOSSAsia 2022. I am Dominic Torno. I am a principal engineer at Temporal. How can you develop always available systems while also enjoying a delightful developer experience? In this talk, we will learn about the important role of core abstractions, a key ingredient in answering this question. Core abstractions are the fundamental building blocks of your system. A core abstraction mitigates a set of challenges on a platform level while it entirely eliminates that set of challenges on an application level. Let's look at two examples. First, we will look at a well established core abstraction in the context of database systems. And next, we will look at a recent core abstraction in the context of distributed systems. First up, database systems. The database community faces many significant challenges. Here, I will focus on two, the presence of failure and the presence of load. If a database system experiences failure, some operations may have taken effect already, while other operations may not have taken effect yet. An anomaly known as partial application. If a database experiences load, some operations may interfere with each other. An anomaly known as a race condition. Obviously, these challenges threaten your system's consistency. It's correctness. However, for the past 45 years, the database community has enjoyed an unparalleled developer experience. These challenges do not seem to be on anybody's mind. Why? Because the database community introduced a core abstraction. Database transactions. A database transaction is a sequence of read and write commands that terminate with exactly one abort or exactly one commit. In case a transaction terminates with an abort, the database system guarantees that the resulting state of the database is equivalent to a state where the transaction did not happen at all. In case the transaction terminates with a commit, the database system guarantees that the resulting state of the database is equivalent to the state where the transaction happened exactly once and in isolation. In summary, a database transaction guarantees that the resulting state of the database is equivalent to the state where the transaction didn't happen at all or where the transaction happened exactly once. So a database transaction mitigates failure and load on a platform level, entirely eliminating failure and load on an application level. As a database developer, I develop my application as if failure and load do not even exist. And as a database developer, because transactions are a well-established abstraction, I take this developer experience for granted. But not every community is so fortunate. Case in point. Next up, distributed systems. The distributed systems community too faces many challenges. And once again, I will focus on two. The presence of failure and the presence of time limits. As previously, if a distributed system experiences failure, some operations may have taken effect already, while other operations may not have taken effect yet. Again, the anomaly of partial application. If a distributed system approaches a time limit, operations may be terminated, an anomaly known as a timeout, which in turn may result in partial application. Again, these challenges threaten your system's consistency. It's correctness. Unfortunately though, the distributed systems community does not enjoy a developer experience similar to the database community. These challenges are on everybody's mind all the time. Why? Because we have not established a core abstraction. We are unable to mitigate failure, unable to mitigate time limits on a platform level. We mitigate on an application level. Our application code is painfully aware of failure, painfully aware of time limits. We break up our computation into chunks, wrap those chunks into retries in order to mitigate failure, and then stitch those retrying chunks back together via databases queues and crone jobs in order to mitigate time limits. Let's face it, our application code is just a hot mess. However, recently we are witnessing the advent of a new core abstraction. The distributed systems community is introducing the concept of a workflow. A workflow is to distribute the systems where the transaction is to databases. A workflow is a sequence of commands. A workflow guarantees that the resulting state of a distributed system after executing a workflow is equivalent to the workflow executing exactly once and to completion. Now once again, workflows mitigate failure and time limits on a platform level, entirely eliminating failure and time limits on an application level. With the core abstraction of a workflow, it is both trivial and delightful to build correct systems. One example of a popular workflow system is Temporal. Temporal is an open source workflow as code workflow system. Workflow is code refers to the fact that you can author your workflows in code, for example in Java, in Golang, in JavaScript, TypeScript, PHP, any language that Temporal has an SDK for. Temporal lifts a regular function into a workflow. In other words, a workflow is a regular function but with additional execution guarantees. Check out this example. This snippet illustrates a workflow that loops forever until it hits an exit condition, sleeping one month in between iterations as if failure and time limits do not even exist. Curious? Learn more about workflows and workflow systems at Temporal.io. Thank you very much for watching and enjoy the rest of the conference.