WEBVTT 00:00.000 --> 00:09.880 Okay, then, good morning, everyone. 00:09.880 --> 00:15.600 We are very happy to see so many of you today at 9 a.m. on the Sunday. 00:15.600 --> 00:21.320 That's brave, especially if you went last night, tasting some Belgian beers. 00:21.320 --> 00:23.880 That's often tradition that was them. 00:23.880 --> 00:27.520 So thank you for being here. 00:27.520 --> 00:33.080 And did you know that 60% of company already adopted automation solution? 00:33.080 --> 00:37.520 And that number is to skyrocket by the end of 2025. 00:37.520 --> 00:39.360 But that brings us a challenge. 00:39.360 --> 00:44.600 How do we manage efficiently and consistently the workflows? 00:44.600 --> 00:47.120 That's what we are here to explore today. 00:47.120 --> 00:51.960 We introduce you to the serverless workflow specification that tackles this challenge and 00:51.960 --> 00:54.160 much more. 00:54.160 --> 00:57.640 But before we start, let us introduce ourselves. 00:57.640 --> 01:00.840 My name is Zomatis Bianchi or J.B. for short. 01:00.840 --> 01:11.840 I'm an active member of the serverless community. 01:11.840 --> 01:18.240 I contribute to projects like the runtime dashboard, the type script SDK, the just 01:18.240 --> 01:22.320 code extension or even the website. 01:22.320 --> 01:23.320 That's for my job. 01:23.320 --> 01:27.840 I'm a full stack developer and co-founder of Niroglia, a business based company. 01:27.840 --> 01:29.320 I run with my associate choice. 01:29.320 --> 01:34.320 Hello, everyone. 01:34.320 --> 01:36.320 Thanks for being here. 01:36.320 --> 01:38.320 Thanks, J.B. 01:38.320 --> 01:43.160 As J.B. said, I'm co-founder of Niroglia, Israel, where we focus on making simple and elegant 01:43.160 --> 01:46.160 solution to complex problems. 01:46.160 --> 01:51.320 I'm also one of the lead maintainers of serverless workflow. 01:51.320 --> 01:56.680 I'm also the author of that net and rest as the case and the creator of Synapse, which is 01:56.680 --> 01:59.480 the serverless workflow workflow management system. 01:59.480 --> 02:02.080 Let me now introduce you. 02:02.080 --> 02:03.080 Ricardo Zanini. 02:03.080 --> 02:04.080 Hello, guys. 02:04.080 --> 02:05.080 How are you? 02:05.080 --> 02:07.080 My name is Ricardo Zanini. 02:07.080 --> 02:11.080 I'm from Brazil, but I'm leaving Canada now. 02:11.080 --> 02:15.440 And I'm also a co-leader of the specification of work with Charles and G.B. and many others 02:15.440 --> 02:17.440 there driving. 02:17.440 --> 02:18.440 Now they back. 02:18.440 --> 02:20.200 My principles of change in here. 02:20.200 --> 02:25.600 I work at Red Hat and we do use the specification on one of our products. 02:25.600 --> 02:27.600 Go ahead. 02:27.600 --> 02:29.600 Thank you, Ricardo. 02:29.600 --> 02:30.600 Thank you, Charles. 02:30.600 --> 02:33.040 So let's kick things off. 02:33.040 --> 02:38.200 Charles, tell me, what is the serverless workflow? 02:38.200 --> 02:45.400 So serverless workflow is a vendor-agnostic open-source free CNCF project. 02:45.400 --> 02:53.560 It's a domain-specific language, a DSL, intended to define and describe workflows in 02:53.560 --> 02:58.360 intuitive, robust and portable way. 02:58.360 --> 03:06.400 It focuses on extensibility, usability, and interoperability, but let's do not make an 03:06.400 --> 03:07.400 mistake. 03:07.400 --> 03:11.080 Serverless workflow is not just a DSL or specification. 03:11.080 --> 03:17.920 It's a whole ecosystem, which is made out of complex SDKs.net, go Java, PHP, Python, 03:17.920 --> 03:24.040 TypeScript, and also of a runtime, which is called Synapse, used to manage and run workflows, 03:24.040 --> 03:26.240 authored with the DSL. 03:26.240 --> 03:31.040 We will showcase Synapse at the end of this presentation. 03:31.040 --> 03:37.080 So it's not just a language, it's a full toolkit for getting your workflows up and running. 03:37.080 --> 03:40.760 But tell me, Charles, why do we need the specification in the first place? 03:40.760 --> 03:43.760 Well, that's a very good question. 03:43.760 --> 03:51.120 And actually, according to me, the answer lies in the term locking, as in technology and 03:51.120 --> 03:53.120 vendor-locking. 03:53.120 --> 03:59.160 As you all know, cloud providers are there, offer a wide range of services to author, run 03:59.160 --> 04:01.280 and manage your workflows. 04:01.280 --> 04:06.560 The problem is that it often comes with their own vendor-specific language and vendor-specific 04:06.560 --> 04:09.520 ecosystem and services. 04:09.520 --> 04:12.400 And that is where serverless workflow kicks in. 04:12.400 --> 04:18.760 As a free open source, vendor-agnostic DSL, it empowers developers to run their workflows 04:18.760 --> 04:22.400 wherever they want, whenever they want and however they want. 04:22.400 --> 04:28.360 It runs on any platforms, any systems, and any cloud providers. 04:28.360 --> 04:35.840 While retaining absolute control of your technology stack, services, and more importantly, 04:35.840 --> 04:40.400 especially in this age of AI data. 04:40.400 --> 04:45.240 Breaking free from vendor-locking, sounds like a game changer indeed. 04:45.240 --> 04:55.040 But besides that, what are the use cases that covers serverless workflow? 04:55.040 --> 05:00.320 Well, good question again, there are a plethora of them, actually. 05:00.320 --> 05:06.640 On top of my mind, I can speak of agentic AI, which is a bit trendy right now. 05:06.640 --> 05:15.760 IoT workflows, CACD pipelines, ETL pipelines, micro-service orchestration, fast orchestration, 05:15.760 --> 05:18.840 and even driven architecture, one of my personal favorite. 05:18.840 --> 05:22.080 But I couldn't ramble on four hours. 05:22.080 --> 05:26.840 Thing is, if you're speaking of a workflow, purchases are serverless workflow, can handle 05:26.840 --> 05:28.840 it. 05:28.840 --> 05:29.840 Great. 05:29.880 --> 05:33.440 But now, maybe let's get a bit more technical. 05:33.440 --> 05:38.640 What are the key components of servers workflow? 05:38.640 --> 05:44.280 So well, your typical workflow is written using YAML, personal favorite of Yusky, 05:44.280 --> 05:48.040 or use a readability, or JSON. 05:48.040 --> 05:58.720 And it is described using a cop like an alpha-dleton of imperative, and actionable keywords. 05:58.760 --> 06:02.400 The first one of them being document, which allows you to describe the metadata of your 06:02.400 --> 06:07.880 workflow, name, version, name, space, tags. 06:07.880 --> 06:11.200 Then we have the input and output key ones. 06:11.200 --> 06:16.920 And those allow you to define, describe, and optionally validate the data that is being 06:16.920 --> 06:19.480 ingested by your workflow. 06:19.480 --> 06:25.520 And the data that is going to be produced as a result of your workflow's execution. 06:25.600 --> 06:31.120 Then we have the schedule, which is used to specify execution timing. 06:31.120 --> 06:39.920 Obviously, if you're not executing it explicitly, we have the use, which intends to define 06:39.920 --> 06:44.960 reusable component that you can reuse within your workflow in order to shorten it. 06:44.960 --> 06:49.520 It's kind of quality of use feature. 06:49.520 --> 06:53.360 Then time out, which is, say, describeable. 06:53.360 --> 07:00.240 When we have the do, which is another list of tags that the workflow has to perform, and 07:00.240 --> 07:03.360 this is about it. 07:03.360 --> 07:10.360 So, what is that do I think that the people here are interested in what kind of tags 07:10.360 --> 07:15.080 the service workforce specification provide? 07:15.080 --> 07:21.560 So it provides a dozen of different tags, which we intended to cover the widest and 07:21.560 --> 07:24.760 bodest range of use cases. 07:24.760 --> 07:30.080 We start with the call function, call task, which is used to call functions in HTTP, 07:30.080 --> 07:33.880 Open API, SNKPI, and GRPC. 07:33.880 --> 07:38.720 Then we have the do-task, which is used to run a subset of task, which is, you can optionally 07:38.720 --> 07:43.520 time out and manage independently from the rest of your tasks. 07:43.520 --> 07:50.680 We have the emit component, which is used to produce an event for the outside one to receive. 07:50.680 --> 07:55.800 We have the font task, which allows you to iterate over a collection of items and conditionally 07:55.800 --> 08:00.240 perform a subset of action for each of those items. 08:00.240 --> 08:07.160 We have the font component, which allows you to run multiple branches of actions in parallel 08:07.160 --> 08:10.360 and optionally concurrently. 08:10.360 --> 08:16.080 The decent task, which is used to consume incoming events and perform complex event processing 08:16.160 --> 08:23.840 and correlation, rates, which is used to produce a domain specific error that you can 08:23.840 --> 08:28.400 bubble up your workflow and potentially catch. 08:28.400 --> 08:34.000 We have one of my personal favorite, the run task, which is used to run containers. 08:34.000 --> 08:38.920 So this covers already a huge range of use cases. 08:38.920 --> 08:47.080 We can run script in both JavaScript and Python, shell commands, and as well subflows. 08:47.080 --> 08:56.640 Then we have the set data task, which is used to modify and set data based on your needs. 08:56.640 --> 09:02.200 Switch, which is a component that is used to conditionally control the flow of the one-flow 09:02.200 --> 09:06.760 you are writing, we fall back conditions. 09:06.760 --> 09:14.760 We have the try, which is used to attempt executing a subset of actions and catching potential 09:14.760 --> 09:18.600 errors that have been raised during that execution. 09:18.600 --> 09:23.760 Upon catching those errors, you have the option to retry those tasks and order to execute 09:23.760 --> 09:26.840 a subset of other tasks. 09:26.840 --> 09:33.560 And finally, we have the weight task, which is used to pose execution for a given amount 09:33.560 --> 09:35.560 of time. 09:35.560 --> 09:37.880 That's a lot of flexibility. 09:37.880 --> 09:42.080 But there is much more to the specification we cannot cover today. 09:42.080 --> 09:48.200 I think you give us a solution for what the specification is and as they say, pictures worth 09:48.200 --> 09:49.200 a thousand worth. 09:49.200 --> 09:54.680 So maybe we can do a quick demo, even if the time is going to be a bit short. 09:54.680 --> 10:02.680 Let's try to speed that up indeed. 10:02.680 --> 10:07.160 So yeah, I have a small geeky case for you guys today. 10:07.160 --> 10:14.120 We were actually thinking of a lot of different potential use case and we didn't want 10:14.120 --> 10:19.240 to bore you with the traditional order management system, so we went up with something 10:19.240 --> 10:20.960 a bit more geeky. 10:20.960 --> 10:28.920 It's Star Wars daunting network application in console, don't expect anything really fancy, 10:28.920 --> 10:35.400 but it will showcase the basic of the specs. 10:35.400 --> 10:38.320 If we can get Docker running. 10:38.320 --> 10:39.320 Yeah. 10:39.320 --> 10:45.680 Well, as he is preparing the demo, everything just to talk about a committee really quickly. 10:45.680 --> 10:49.720 So if you guys are really interested, we have the links after the meeting. 10:49.720 --> 10:55.040 Then we have every Thursday, we have a meeting in the committee, just to discuss about 10:55.080 --> 10:57.600 the specification feature and now. 10:57.600 --> 10:59.800 And the first version just released. 10:59.800 --> 11:05.200 So it's pretty nice if you guys want to take a look in the first version of the specification. 11:05.200 --> 11:16.000 Our SDKs have played in many languages, Java, JavaScript, Python, PHP, .NET, RLC, Utah. 11:16.000 --> 11:22.480 And then you can just grab your favorite language and try modeling your workflows with 11:22.480 --> 11:27.560 the specification and maybe implement on your own or your own types. 11:27.560 --> 11:32.960 So yeah, this is your apoptical galactic daunting network, right? 11:32.960 --> 11:34.480 So I just have to log in. 11:34.480 --> 11:37.600 I will use any kind of key we don't care. 11:37.600 --> 11:41.000 My name is Bob Fett. 11:41.000 --> 11:46.640 And as you can see here, actually an event is being fired and will be intercepted and correlated 11:46.640 --> 11:51.480 by the walkthrough, which you're so starving right here, I'm it fast, right? 11:51.480 --> 11:52.480 Why? 11:52.480 --> 11:56.280 Because if you remember in the presentation, I introduced the schedule component and here 11:56.280 --> 12:01.120 the schedule component is defined to listen on a specific kind of event. 12:01.120 --> 12:04.680 And this is why a workflow started out of the blue. 12:04.680 --> 12:07.440 Here it's waiting for input, as you can see. 12:07.440 --> 12:11.160 So I'm going to just do that, enter. 12:11.160 --> 12:17.920 And as my input will be selected, the Bounties, actually, it will move to an open API call, 12:17.920 --> 12:22.280 which will retone me data in an event driven fashion. 12:22.280 --> 12:24.680 So let's do that. 12:24.680 --> 12:27.960 And maybe it was a bit too fast, but you saw that happening, right? 12:27.960 --> 12:33.040 It moved to process command, which is a switch component. 12:33.040 --> 12:39.560 And on the switch component, we saw that I actually invoked the list Bounty task. 12:39.560 --> 12:44.120 With the list Bounty task, it was actually an open API call, which we handled and then we 12:44.120 --> 12:49.520 returned the command output in an event driven way using a cloud event. 12:49.520 --> 12:52.120 And now we are back in waiting for input. 12:52.120 --> 12:55.560 So let's check my Bounties. 12:55.560 --> 12:56.560 I don't know. 12:56.560 --> 12:58.720 I feel like hitting Jericho Dull today. 12:58.720 --> 13:02.960 So here's some of the info that was returned to me by Open API. 13:02.960 --> 13:05.640 And I'm going to assume that contract. 13:05.640 --> 13:10.240 So doing so, the workflow will move to the take contract task. 13:10.240 --> 13:15.160 And then after once, we'll start back to wait for input and start tracking it, which 13:15.160 --> 13:18.400 is right here. 13:18.400 --> 13:22.840 And so with the track, it's a S&K B. I call, which is SSC. 13:22.840 --> 13:28.320 So it's server-centivance, which will send a lot of simulated updates and in the end, 13:28.320 --> 13:32.560 the workflow will log me out of that system. 13:32.560 --> 13:35.440 So let's take the contract. 13:35.480 --> 13:38.640 So the tracking has started. 13:38.640 --> 13:42.440 Should be started. 13:42.440 --> 13:45.440 Cool. 13:45.440 --> 13:50.440 Let's see, we have last time, but let me restart that again. 13:50.440 --> 13:53.960 Let's add, we don't have time to start really show the workflow. 13:53.960 --> 13:56.640 So the people have a little idea of the syntax. 13:56.640 --> 13:57.640 OK. 13:57.640 --> 13:58.640 OK. 13:58.640 --> 14:04.840 Maybe we just give you, I don't know if you can read or not, but we'll just 14:04.840 --> 14:12.440 give you another view of what's the syntax of this workflow. 14:12.440 --> 14:17.240 Of course, we don't really have time to go in the details, but that gives you an idea of 14:17.240 --> 14:21.240 what kind of tools you are using with them. 14:28.640 --> 14:29.640 So yeah. 14:29.640 --> 14:32.240 As you can see, it's quite user-friendly, right? 14:32.240 --> 14:35.440 It's close to a very natural language. 14:35.440 --> 14:38.440 As you see, even the schedule, which is a bit complex, right? 14:38.440 --> 14:41.240 Because we have chosen to listen to one event. 14:41.240 --> 14:43.840 And we have chosen to correlate it. 14:43.840 --> 14:48.640 Based on the banter ID, which is extracted from the subject context attribute. 14:48.640 --> 14:53.040 OK, we ran out of time, and personally. 14:53.040 --> 14:58.440 Yeah, just let me open the slide with the community links and everything. 14:58.440 --> 15:03.240 So we can take a picture of it and see what we have there. 15:03.240 --> 15:07.640 I know we have free for Q and a side of this stage. 15:07.640 --> 15:15.840 If you guys want to have a few conversations, I'll talk about this project. 15:15.840 --> 15:16.840 Thank you guys. 15:16.840 --> 15:20.840 Thank you so much. 15:21.240 --> 15:26.240 So the way we do this is we put this in the next speaker star. 15:26.240 --> 15:28.240 Because we are back to back. 15:28.240 --> 15:30.240 So you can have time to answer questions. 15:30.240 --> 15:32.240 Yeah, please repeat the question. 15:32.240 --> 15:34.240 I'll have a question. 15:34.240 --> 15:37.240 Do you have any question, sir? 15:37.240 --> 15:38.240 Thank you. 15:38.640 --> 15:47.640 How do you see the solution of what's based system that Jason and Gamma look like? 15:47.640 --> 15:50.040 Do you have things like pay them? 15:50.040 --> 15:53.640 Is there a problem in these kind of like technology solutions? 15:53.640 --> 15:55.440 Like actual programming language. 15:55.440 --> 15:58.040 Do you have any questions? 15:58.040 --> 16:07.040 OK, so to reframe the question, what's the competition, what's the difference? 16:07.040 --> 16:12.040 So the key. 16:12.040 --> 16:18.240 Yeah, so the idea of this specification is actually to be a better walking. 16:18.240 --> 16:24.640 So it is open and it is easy for known technical persons to define workflows. 16:24.640 --> 16:28.040 So we think that EMO is pretty nice in that front. 16:28.040 --> 16:29.440 So that's appealing. 16:29.440 --> 16:36.240 But also you can use the SDKs to create the model of the workflow programmatically. 16:36.240 --> 16:42.440 So you can use Java or Go or Botnet to create your workflows via code as well. 16:42.440 --> 16:47.240 So it is kind of more or less you can do what you have with like paint preferences. 16:47.240 --> 16:53.040 I think that you have an API that you can create your workflows via code. 16:53.040 --> 16:55.840 So you can do the same. 16:55.840 --> 17:02.240 And also we like the flexibility of having workflows defined in EMO or Jason files 17:02.240 --> 17:10.240 that you can like have a authoritarian system that you hide the language from the user. 17:10.240 --> 17:14.640 And now like you're just creating the blocks of the flow. 17:14.640 --> 17:17.440 And behind the scenes, you generate the EMO. 17:17.440 --> 17:24.440 So it's super easy for you know, transform, transform from one not oriental into the other. 17:24.440 --> 17:27.040 And so far, there's a mini-user case for that. 17:27.040 --> 17:32.840 But yeah, I think it is flexible enough to do this in both case. 17:32.840 --> 17:36.440 We did that the technologies that you mentioned are workflows code. 17:36.440 --> 17:42.040 Whereas here we are in a declarative approach, which in my envelope opinion as a developer, 17:42.040 --> 17:46.440 you would expect a preferred workflow approach or workflows code approach. 17:46.440 --> 17:51.640 But it's actually much more flexible to just rely on some YAML asset files that you can part around. 17:51.640 --> 17:59.840 And you know, have no compilation or restriction time involved in executing your workflows. 17:59.840 --> 18:00.840 No worries. 18:00.840 --> 18:04.440 If you have more questions, just begin talking. 18:04.440 --> 18:06.440 Any more questions? 18:06.440 --> 18:08.440 Oh, go ahead. 18:14.440 --> 18:17.440 Yes, so you are asking how the demo was running. 18:17.440 --> 18:22.040 It's actually on synapse, which you can find online on our repository. 18:22.040 --> 18:24.240 I don't know why we had that little bug. 18:24.240 --> 18:26.840 That was the coolest part, by the way. 18:26.840 --> 18:31.840 So the S&KPI is streaming, which is a very important feature of serverless workflow, 18:31.840 --> 18:35.040 that not a lot of workflows actually provide right now. 18:35.040 --> 18:43.440 So to be able to execute a subset of tasks upon consuming events and all S&KPI messages. 18:43.440 --> 18:46.040 But here, it runs on synapse, which is cross-platform upon source. 18:46.040 --> 18:50.240 It's a total, I know guys, it's not so popular around here, it was them. 18:50.240 --> 18:55.040 But the .NET framework runs just fine on any platform. 18:55.040 --> 19:00.040 And you can use both Docker and Kubernetes to spawn up containers. 19:00.040 --> 19:07.040 You invite you to have a look at the architecture, which is vertically and horizontally scalable. 19:07.040 --> 19:10.040 Yeah, I think it's worth the detail. 19:14.040 --> 19:15.640 Thanks a lot for your time. 19:15.640 --> 19:20.640 Thanks a lot to the first demo and all the stuff for hosting these awesome events. 19:20.640 --> 19:24.640 And enjoy the rest of your day and the other nice talk that we'll have. 19:24.640 --> 19:25.640 Thank you.