 All right. Welcome everybody. I'm Doug Davis and we have a teamer on the on the call as well And we're here to talk about the CNCF serverless work group now The working group itself really has two main projects that are going on right now Cloud events and the serverless workflow. So what we're going to do in this session is first talk about What's going on the cloud events just very very quick update there And then the bulk of the session will actually be the workflow specifications and stuff And that's that's the more exciting piece for you guys. Okay, so let's go and jump into the cloud events stuff So I'm not going to talk about what cloud events is. I'm going to assume everybody already knows that Instead, I just want to bring you up to date on what's happening with it since the last time we've met Which I guess is last coup con North America since then we've released version 1.0 of the spec and includes not just the Specification but the transport bindings meaning how do you actually map the cloud events metadata to the various protocols? HGP and MTP all the other good stuff Also including the encoding. I'm sorry also included are the encoding formats of how to encode the cloud event metadata into Jason and Avril As well as a primer to give you some basic information about some of the decisions we made Maybe some design or an implementation guidance stuff like that Now we also have a whole bunch of SDKs out there and some of those are very very active So in particular take a look at things like the Java one the goal line one JavaScript very very active C sharp as well Because there's a bit a lot of activity in that space because these SDKs are really the main starting point for people to pick up this stuff Just makes your life a little bit easier for dealing with these cloud event metadata things Okay, now because we've gone one point though. What's next for us? Well, the biggest thing is community feedback or customer feedback, right? We need to hear from other people Who are actually using it to make sure we didn't miss anything get anything wrong and stuff like that And to be honest as of right now, we really haven't heard a whole lot, which is really really good But we're not just sitting back and waiting We're also looking at sort of the next set of pain points related to the cloud events itself So let's go to the next slide and what I want to do is quickly touch on the two bits of work that we're doing related to this now If you understand what cloud events is it's about how to help the producer get the cloud events or the event to the consumer So it's sort of the tail end of the process here So let's talk about the first spec that we're going to be looking at in addition and that is good next slide And that's the discovery API spec and what that's about is the consumer in essence as the name implies discovering Who produces the events of interest to them or what events each producer actually does produce? Okay, that because obviously if you're going to get events you need to know who to subscribe to What events you can get from them and stuff like that and Additionally, you need to figure out how you actually do the subscription itself, right? Do they support ACP maybe a mqp or everything come across Kafka that kind of stuff, right? So you have this discovery step in the whole process Next you then have this the subscription API itself. Okay, and that's how you actually do the subscription Okay, where do you send the description request to how do you tell it? You want the events delivered over ACP versus some other mechanism. What are the format of the messages? How can you filter the messages if they support filtering stuff like that? These are all things that you would naturally expect from a discover and subscription API But they're not really actually written down any place in an interoperable format And so we wanted to try to address those concerns and then finally, of course when you're all done Go to the next slide you end up back at the cloud events spec, right? And you use that to help get the event from the producer to the consumer Okay, and so that's what we're really focusing now in the cloud events group itself Is the discovery spec as well as the subscription specification now these specs are relatively new But we are far enough along. We're actually planning on doing an interop event in the November time frame So if you're interested in either of those specifications and you're in particular interest in actually starting to code these things up Please come and join us and and join the fun Okay. Now with that, let me hand it over to Timor to start talking about the workflow specification All right, thanks Doug so serverless workflow is a CNCF sandbox sandbox project It's part of the serverless working group. So the group that Doug Works with also it's open source and Apache 2.0 license. It's a community project So here you can find some information about our github repo website and the community chat and meeting information The serverless workflow defines a declarative and domain specific workflow language Declarative and it is not expressed in low-level code. However, it defines an abstraction that can be described in both JSON or YAML formats and Domain specific as it targets the domain of orchestration of event driven and distributed services And just to show this as an example on the left-hand side We have two simple requirements written in natural language and these are when for example patient has a bladder infection We want to notify some a doctor specific to his condition and the similar thing is for let's say regular heartbeat We want to notify a cardiologist in this case on the right-hand side You guys see that serverless workflow does not express these requirements in terms of code like if else statements and things like that Neither does it express it Using terminology that does not fit its domain if you look at the bottom right Corner we see that we can translate these requirements straight into things of our domain Which are events such as patient having a bladder infection or irregular heartbeat and Services the need to be invoked in those cases, which is notifying a particular doctor for those conditions Now sorry Serverless workflow is based on standards We use the cloud event specification to define events that can be either produced or consumed During workflow execution and also we define correlations of the many events you might have in your systems using the cloud events format We use the open IPI specification to define Services and in the operations on the services which need to be invoked during workflow execution Finally the serverless workflow provides Workflow patterns or control flow patterns dealing with execution order error handling data management and things like that The overall project goals is to define a language that can be used across multiple different runtime services Which then can be deployed in many different situations some of them being container or cloud platforms Now in order to start utilizing events within your workflows You first have to define them which of many we're interested in for our particular Use case so we want to define an event that are either consumed or being produced And as you can see here with serverless workflow We have a direct one-to-one mapping between how these events are described using the cloud events Specification format and how you define them within your workload definitions and for event correlation We said it was the same thing We again use the cloud events format specifically the context attributes to define correlation between the many different events you might have in your systems Now once we define an event we have to start interacting with it So what can events do within workflows? Events can start workflow instances They can continue existing workflow instances They can be like we said produced or consumed and they can be also used to make logical decisions and the right-hand side We see a very simple definition which just says before we end the workflow We want to produce an event and in this case our event is a type of workflow completed event And then this event which is produced by our workflow execution Then can be consumed by either other workflow orchestration workflows or other different types of services that might be interested Similar is for services in a vocation of services. We want to define The operations that need to be exit on these services They need to be executed during workflow execution in the left-hand side We see a simple open API definition and in this case is just a part of it which defines one Particular operation get inventory, which is one operation of one or many that could be available in this particular service When the right-hand side, we see how we actually define This operation and the service. It's basically we have an operation parameter Which contains the URI or the path to the definition of the service the open API definition And also the unique identifier or the operation idea of the operation that needs to be evoked during workflow execution So you don't have to deal with things like authentication and putting things inside of your workflow definition There is not really related to it the execution of your workflow model that is very specific to the invocation We actually use the open API specification for that as well Now we understand that there is many different types of services And how they're invoked. So with serverless workflow, you can invoke service restful types of services So services that are exposed to some particular endpoint, but you can also Invoke event triggered services or services that are triggered by some particular events The last part of defining your workflow is the control flow logic So here we define the states and the order in which the states are executed And serverless workflow states can be seen like a little black box It receives input either some data or an input event It does its control logic part of what is Particularly needs to be done And then it produces some sort of data output or an output event as the result Of the execution of this particular part of the control flow logic Now serverless workflow we decided to go with explicit control flow, which means you clearly Define What's your building oftentimes in workflows and in control flow logic? We do things on a very granular level, which sometimes becomes some big yes And what I mean by that is it's hard to figure out which part of your control flow fits together And which parts of your control flow are kind of like a unit that perform some particular Piece of the solution of your business problem So in the bottom we see that we have decided to that each state has a type and the type really describes Really the control flow logic that this particular state does if a type is for example event You know that the control flow logic, which isn't Inside of this state deals with events and the payloads and things like that If the type is switch, for example, you know that we're making some sort of either database or event based decisions and things like that Now you can define a whole bunch of different control flow patterns with serverless workflow You can define sequences where you execute one piece of Your workflow orchestration after another you can do looping structure sequential parallel execution Decisions based on like we said your data or events Things like that, but we also deal with a little bit different things like for example human interaction during workflow Execution which is sometimes might be very important in different use cases Now let's take a look at all the different project components of serverless workflow So far we've been talking about this middle piece or the language The serverless workflow language is defined via jason schema Which defines all the rules and things like that to how you actually what you can define within the language Around that we have a set of language extensions. So these extensions do not influence Workflow execution or the control flow logic however enhance it In order for runtime systems to be able to make Some things like overall performance improvements in terms of cost and things like that In addition to that serverless workflow also provides things like sdk's we have them in java and go currently Testing kits in order for runtime implementations to see their compliance level towards the specification And we also have a set of plugins for ide's and things So let's take a quick just to look at for example one of these language extension the kpi or the key performance indicator since extension this allows you to add information about the workflow which are the expected Results during workflow runtime execution and compare them with the actual ones that you Gathered during actual workflow runtimes so this little language extension can help us improve performance of Your workflows the cost effective in cost and effectiveness Let's take a look quick look at the java SDK the features of this are parsing of both jason and yaml serverless workflow language formats He has a fluent api so you can basically Create your workflow definitions using just the programming language includes validation Against the specification and also allows you to generate Diagrams based on either your jason or yaml or your object model represents your workflows And the last thing we look at here is the visual studio code plugin that our project also provides It has code hints and code snippets They're based again on the on the serverless workflow jason schema or the language definition It again provides also validation for both jason and yaml files and it allows you to visually preview Your diagrams as so as you're modeling diagrams and visual studio code You can preview them at the same time So now Done with the introduction part. I wanted to do a a demo It's a very small demo, but I kind of wanted to see I'll show you guys how easy this to get started with workflow orchestration And also of course with with with the serverless workflow itself So For this I just want to set this up a little when you start doing using workflows to orchestrate Things really you're solving business problems. So what you have to do is you have to first understand What is your business problem? And then you want to see what kind of services you have available in your systems that you can utilize In using some sort of control flow logic Given provided to you by the workflow solution in order to solve your business problem So for this simple example to kind of go back in slides Our business problems is patient onboarding So and now let's take a look at what services we have available in order to solve our problem So for this i'm going to exit out of the presentation Sorry And i'm going to have the application running. This is running on local host right now And i'm going to look at my swagger ui. So we Now this application again is running my local host locally for the sake of the demo But these services in real-world scenarios, of course, will be deployed on a container platform or or somewhere Distributed basically but here we see that we have two services We have a patient service the service is responsible To to register a new patient into a system And then we have a scheduling service which then takes this new patient and given their conditions like we discussed before in the slide Assigns the particular doctor that can best treat their condition Of course in a real-world scenario, we would have a much bigger set of services and things like this So for our sake of the demo is just two so to look back at our business Problem which onboarding a patient In order to onboard a patient for our demo, we want to first I invoke the patient service and then we want to invoke the scheduling service to assign a doctor to this particular patient So let's kind of try it all together and do this um, i'm just gonna Go ahead here and open up visual studio code And after i close like 50 million windows like usual Sorry Now this is my application we i have it's a little java application that runs on quarkis You can really use any particular language that they use and they use this a java runtime an open source java runtime of the serverless work implementation So we have two resources here which represent our two services um Now what i wanted to do is to show you how to get started the first thing i'm going to do Is go to my vscode extensions and type in Serverless workflow And i'm going to download this extension now This is the extension that we provide for more serverless workflow project that we talked about earlier Now i already have this installed, but this will be the first step once um I have done this i can go ahead and start Creating my workflow. So pretty much anywhere with java and maven under resources Uh, we want to go and create a new file. So this file is going to represent our workflow. So let's call it uh on boarding And in this case, we're going to just do a jason definition. You can the same thing do yaml So one of the things that once you download that uh, the vscode extension for serverless workflow You get code hints and code snippets in this case We will see that it shows me all the different parameters that I can start using on a top level definition Uh, which are based on of course the jason scheme of the of the underlying language So in this case, I'm going to give my workflow a unique id of onboarding Make sure I spell that right. I'm going to give it a name which let's say we say new patient onboarding I'm going to give it a version. Uh, let's say 1.0 And at this point I want to start defining the different functions that need to be executed What when this workflow is running? So What I'm going to do is I'm going to define a functions array This is real quick And I want to start defining my two functions the first function. I'm going to give a logical name of let's say register new patient And now I have to define how do I actually invoke this function? The only thing I have to do is is create an operation parameter Which then points to my uh open api definition Which I have here and we can take a look at it also visually in VS code, which is kind of cool so In this open api definition I see my patient service and the post which means I want to create a new patient has an operation id of add So let's copy that go back to our workflow So all I have to do is a relative path to slash api slash Open api do Jason, which is my open api definition And I have to give it the unique operation id. So I'm just going to copy that And now we're going to define our second service that we would like to invoke and it's operation Let's say assign doctor to patient And it's the same service but uh open api definition But here we go down to schedule and we see that the one we want to call is has a unique idea of a sign So let's go do this and that's it. So now that I've done I'm done with my service definitions I want to start you creating my control for logic. So for this we have uh an array called states And my I'm going to create a new state. I'm going to give it a name of let's say lights on board And that's it and now I have to give my state a particular type Now the extension is going to list you all the different types that you can Choose here depending on you know, what you want to do the one we're going to use it is a simple operation state It's a state that runs one or many operations in this case invocations of our services Either sequentially or parallel. So I'm just going to give it a type Now I don't I have to say that this is the first state that gets invoked when my workflow instance is created So I have a little star definition With a kind there is different ways to start the workflow. So in this case, we're just going to go ahead and started without any extra information And I want to say my action mode here I want to execute these two services sequentially because we first have to onboard a patient Before we had a doctor do it. Otherwise, there could be some cases where you want to execute in parallel And now I'm just going to define what actions do I want to use and the first action I'm going to use is To evoke my my register new patient service. So for this, I don't have to redefine my services here I just reference them by their logical name And after this I want to Call my assigned doctor service now Yeah, I have to tell the workflow that after the execution of this particular state I want to finish workflow execution So I also have to give it an end definition And again, there is different ways of ending workflows. For example, sending an event killing the entire all the processes running things like that But we just want to simply um End it is this case And I have some Oh, yeah Yeah And Jason get along this one. So you see just with 30 lines of code in yaml That would be probably about 20 of course. We have created a simple workflow. So let's now go ahead and See if I'm going to restart my application. So in addition to the services Is we already have them running on local host if it picks it up and let's see what happens This was a startup in just a second What we wait All right, so that's done now one thing I wanted to show you guys is that workflows are not Some weird thing that you have to use a special way of invoking or It's different than for example how you define your services Workflows are really the same and here we've seen the definition of our two services They were running on our system before we created the service workflow now if I refresh this page You will see an onboarding service and what is this? Well, that is the workflow We have just defined we have basically taken our workflow definition and itself deployed it as a service And that has the advantage now and not only it's a restful service that we can call this endpoint Version 1.0, which is the version of the workflow they defined and onboarding which was the unique id identified by That we put in our workflow we can actually interact with the service orchestration Just like another service that we have defined pretty much anywhere. So and then this is really kind of what we wanted to do We have a local host here. I created a simple page And this first form allow us to enter Some information about a new patient and when we click on board and to show you guys, I'm not making this up We have a little post htp post to our Endpoint which actually will trigger a new workflow instance execution And then on the bottom we will see the results of the workflow orchestration Which should be a patient and also the doctor assigned to the patient given the patient's condition So I just give it simple some name john And this guy has uh, unfortunately a bladder infection And as we see when we clicked on board our serverless workflow was executed it contacted the patient services stored The particular patient you come that they are scheduling services We have defined and assigned doctor elizabeth to this particular patient um So that kind of really guys shows you how easy it is to get started these days with workflows And also how it easy is to get started also with the serverless workflow specification And it's uh, all I have for the demo. Let's go back to um The presentation that you want to do this or should I go for it? You're on a roll All right, so well, uh, thank you guys very much. I hope you enjoyed our talk For more information, of course cloud events Great specification you cloud events that i o for serverless work will we have serverless serverless workflow that i o We hope to see you guys in the community and if you need more health here is the context for a dog and myself Thank you guys very much. Thank you everybody