Okay, then, good morning, everyone.
We are very happy to see so many of you today at 9 a.m. on the Sunday.
That's brave, especially if you went last night, tasting some Belgian beers.
That's often tradition that was them.
So thank you for being here.
And did you know that 60% of company already adopted automation solution?
And that number is to skyrocket by the end of 2025.
But that brings us a challenge.
How do we manage efficiently and consistently the workflows?
That's what we are here to explore today.
We introduce you to the serverless workflow specification that tackles this challenge and
much more.
But before we start, let us introduce ourselves.
My name is Zomatis Bianchi or J.B. for short.
I'm an active member of the serverless community.
I contribute to projects like the runtime dashboard, the type script SDK, the just
code extension or even the website.
That's for my job.
I'm a full stack developer and co-founder of Niroglia, a business based company.
I run with my associate choice.
Hello, everyone.
Thanks for being here.
Thanks, J.B.
As J.B. said, I'm co-founder of Niroglia, Israel, where we focus on making simple and elegant
solution to complex problems.
I'm also one of the lead maintainers of serverless workflow.
I'm also the author of that net and rest as the case and the creator of Synapse, which is
the serverless workflow workflow management system.
Let me now introduce you.
Ricardo Zanini.
Hello, guys.
How are you?
My name is Ricardo Zanini.
I'm from Brazil, but I'm leaving Canada now.
And I'm also a co-leader of the specification of work with Charles and G.B. and many others
there driving.
Now they back.
My principles of change in here.
I work at Red Hat and we do use the specification on one of our products.
Go ahead.
Thank you, Ricardo.
Thank you, Charles.
So let's kick things off.
Charles, tell me, what is the serverless workflow?
So serverless workflow is a vendor-agnostic open-source free CNCF project.
It's a domain-specific language, a DSL, intended to define and describe workflows in
intuitive, robust and portable way.
It focuses on extensibility, usability, and interoperability, but let's do not make an
mistake.
Serverless workflow is not just a DSL or specification.
It's a whole ecosystem, which is made out of complex SDKs.net, go Java, PHP, Python,
TypeScript, and also of a runtime, which is called Synapse, used to manage and run workflows,
authored with the DSL.
We will showcase Synapse at the end of this presentation.
So it's not just a language, it's a full toolkit for getting your workflows up and running.
But tell me, Charles, why do we need the specification in the first place?
Well, that's a very good question.
And actually, according to me, the answer lies in the term locking, as in technology and
vendor-locking.
As you all know, cloud providers are there, offer a wide range of services to author, run
and manage your workflows.
The problem is that it often comes with their own vendor-specific language and vendor-specific
ecosystem and services.
And that is where serverless workflow kicks in.
As a free open source, vendor-agnostic DSL, it empowers developers to run their workflows
wherever they want, whenever they want and however they want.
It runs on any platforms, any systems, and any cloud providers.
While retaining absolute control of your technology stack, services, and more importantly,
especially in this age of AI data.
Breaking free from vendor-locking, sounds like a game changer indeed.
But besides that, what are the use cases that covers serverless workflow?
Well, good question again, there are a plethora of them, actually.
On top of my mind, I can speak of agentic AI, which is a bit trendy right now.
IoT workflows, CACD pipelines, ETL pipelines, micro-service orchestration, fast orchestration,
and even driven architecture, one of my personal favorite.
But I couldn't ramble on four hours.
Thing is, if you're speaking of a workflow, purchases are serverless workflow, can handle
it.
Great.
But now, maybe let's get a bit more technical.
What are the key components of servers workflow?
So well, your typical workflow is written using YAML, personal favorite of Yusky,
or use a readability, or JSON.
And it is described using a cop like an alpha-dleton of imperative, and actionable keywords.
The first one of them being document, which allows you to describe the metadata of your
workflow, name, version, name, space, tags.
Then we have the input and output key ones.
And those allow you to define, describe, and optionally validate the data that is being
ingested by your workflow.
And the data that is going to be produced as a result of your workflow's execution.
Then we have the schedule, which is used to specify execution timing.
Obviously, if you're not executing it explicitly, we have the use, which intends to define
reusable component that you can reuse within your workflow in order to shorten it.
It's kind of quality of use feature.
Then time out, which is, say, describeable.
When we have the do, which is another list of tags that the workflow has to perform, and
this is about it.
So, what is that do I think that the people here are interested in what kind of tags
the service workforce specification provide?
So it provides a dozen of different tags, which we intended to cover the widest and
bodest range of use cases.
We start with the call function, call task, which is used to call functions in HTTP,
Open API, SNKPI, and GRPC.
Then we have the do-task, which is used to run a subset of task, which is, you can optionally
time out and manage independently from the rest of your tasks.
We have the emit component, which is used to produce an event for the outside one to receive.
We have the font task, which allows you to iterate over a collection of items and conditionally
perform a subset of action for each of those items.
We have the font component, which allows you to run multiple branches of actions in parallel
and optionally concurrently.
The decent task, which is used to consume incoming events and perform complex event processing
and correlation, rates, which is used to produce a domain specific error that you can
bubble up your workflow and potentially catch.
We have one of my personal favorite, the run task, which is used to run containers.
So this covers already a huge range of use cases.
We can run script in both JavaScript and Python, shell commands, and as well subflows.
Then we have the set data task, which is used to modify and set data based on your needs.
Switch, which is a component that is used to conditionally control the flow of the one-flow
you are writing, we fall back conditions.
We have the try, which is used to attempt executing a subset of actions and catching potential
errors that have been raised during that execution.
Upon catching those errors, you have the option to retry those tasks and order to execute
a subset of other tasks.
And finally, we have the weight task, which is used to pose execution for a given amount
of time.
That's a lot of flexibility.
But there is much more to the specification we cannot cover today.
I think you give us a solution for what the specification is and as they say, pictures worth
a thousand worth.
So maybe we can do a quick demo, even if the time is going to be a bit short.
Let's try to speed that up indeed.
So yeah, I have a small geeky case for you guys today.
We were actually thinking of a lot of different potential use case and we didn't want
to bore you with the traditional order management system, so we went up with something
a bit more geeky.
It's Star Wars daunting network application in console, don't expect anything really fancy,
but it will showcase the basic of the specs.
If we can get Docker running.
Yeah.
Well, as he is preparing the demo, everything just to talk about a committee really quickly.
So if you guys are really interested, we have the links after the meeting.
Then we have every Thursday, we have a meeting in the committee, just to discuss about
the specification feature and now.
And the first version just released.
So it's pretty nice if you guys want to take a look in the first version of the specification.
Our SDKs have played in many languages, Java, JavaScript, Python, PHP, .NET, RLC, Utah.
And then you can just grab your favorite language and try modeling your workflows with
the specification and maybe implement on your own or your own types.
So yeah, this is your apoptical galactic daunting network, right?
So I just have to log in.
I will use any kind of key we don't care.
My name is Bob Fett.
And as you can see here, actually an event is being fired and will be intercepted and correlated
by the walkthrough, which you're so starving right here, I'm it fast, right?
Why?
Because if you remember in the presentation, I introduced the schedule component and here
the schedule component is defined to listen on a specific kind of event.
And this is why a workflow started out of the blue.
Here it's waiting for input, as you can see.
So I'm going to just do that, enter.
And as my input will be selected, the Bounties, actually, it will move to an open API call,
which will retone me data in an event driven fashion.
So let's do that.
And maybe it was a bit too fast, but you saw that happening, right?
It moved to process command, which is a switch component.
And on the switch component, we saw that I actually invoked the list Bounty task.
With the list Bounty task, it was actually an open API call, which we handled and then we
returned the command output in an event driven way using a cloud event.
And now we are back in waiting for input.
So let's check my Bounties.
I don't know.
I feel like hitting Jericho Dull today.
So here's some of the info that was returned to me by Open API.
And I'm going to assume that contract.
So doing so, the workflow will move to the take contract task.
And then after once, we'll start back to wait for input and start tracking it, which
is right here.
And so with the track, it's a S&K B. I call, which is SSC.
So it's server-centivance, which will send a lot of simulated updates and in the end,
the workflow will log me out of that system.
So let's take the contract.
So the tracking has started.
Should be started.
Cool.
Let's see, we have last time, but let me restart that again.
Let's add, we don't have time to start really show the workflow.
So the people have a little idea of the syntax.
OK.
Maybe we just give you, I don't know if you can read or not, but we'll just
give you another view of what's the syntax of this workflow.
Of course, we don't really have time to go in the details, but that gives you an idea of
what kind of tools you are using with them.
So yeah.
As you can see, it's quite user-friendly, right?
It's close to a very natural language.
As you see, even the schedule, which is a bit complex, right?
Because we have chosen to listen to one event.
And we have chosen to correlate it.
Based on the banter ID, which is extracted from the subject context attribute.
OK, we ran out of time, and personally.
Yeah, just let me open the slide with the community links and everything.
So we can take a picture of it and see what we have there.
I know we have free for Q and a side of this stage.
If you guys want to have a few conversations, I'll talk about this project.
Thank you guys.
Thank you so much.
So the way we do this is we put this in the next speaker star.
Because we are back to back.
So you can have time to answer questions.
Yeah, please repeat the question.
I'll have a question.
Do you have any question, sir?
Thank you.
How do you see the solution of what's based system that Jason and Gamma look like?
Do you have things like pay them?
Is there a problem in these kind of like technology solutions?
Like actual programming language.
Do you have any questions?
OK, so to reframe the question, what's the competition, what's the difference?
So the key.
Yeah, so the idea of this specification is actually to be a better walking.
So it is open and it is easy for known technical persons to define workflows.
So we think that EMO is pretty nice in that front.
So that's appealing.
But also you can use the SDKs to create the model of the workflow programmatically.
So you can use Java or Go or Botnet to create your workflows via code as well.
So it is kind of more or less you can do what you have with like paint preferences.
I think that you have an API that you can create your workflows via code.
So you can do the same.
And also we like the flexibility of having workflows defined in EMO or Jason files
that you can like have a authoritarian system that you hide the language from the user.
And now like you're just creating the blocks of the flow.
And behind the scenes, you generate the EMO.
So it's super easy for you know, transform, transform from one not oriental into the other.
And so far, there's a mini-user case for that.
But yeah, I think it is flexible enough to do this in both case.
We did that the technologies that you mentioned are workflows code.
Whereas here we are in a declarative approach, which in my envelope opinion as a developer,
you would expect a preferred workflow approach or workflows code approach.
But it's actually much more flexible to just rely on some YAML asset files that you can part around.
And you know, have no compilation or restriction time involved in executing your workflows.
No worries.
If you have more questions, just begin talking.
Any more questions?
Oh, go ahead.
Yes, so you are asking how the demo was running.
It's actually on synapse, which you can find online on our repository.
I don't know why we had that little bug.
That was the coolest part, by the way.
So the S&KPI is streaming, which is a very important feature of serverless workflow,
that not a lot of workflows actually provide right now.
So to be able to execute a subset of tasks upon consuming events and all S&KPI messages.
But here, it runs on synapse, which is cross-platform upon source.
It's a total, I know guys, it's not so popular around here, it was them.
But the .NET framework runs just fine on any platform.
And you can use both Docker and Kubernetes to spawn up containers.
You invite you to have a look at the architecture, which is vertically and horizontally scalable.
Yeah, I think it's worth the detail.
Thanks a lot for your time.
Thanks a lot to the first demo and all the stuff for hosting these awesome events.
And enjoy the rest of your day and the other nice talk that we'll have.
Thank you.