With this post we will look deeper into the reusable function definitions, and how they can be used
in your serverless workflow definitions.
The term "function definition" as used within the serverless workflow model refers to defining how our loosely-coupled services that may be deployed onto several different cloud hosting providers can be invoked during workflow execution.
Many different cloud hosting companies exist today, offering bleeding-edge FaaS platforms onto which we can deploy our microservices (serverless functions). Some of the most notable ones include:
Each of these platforms may provide a unique set of ways to invoke the deployed functions which can include direct access to run your code, or many different event/queue-driven services which you can utilize to trigger executions based on different criteria (timers, events, messages, db updates etc).
Now let's take a step back and remember why we are interested in using serverless workflows tobegin with, namely to introduce a clear separation of concerns. Our functions should have the strict focus on dealing with the actual business requirements. Workflows then take on the orchestration aspect which includes defining invocations based on triggers (events), dealing with managing data between function invocations, and defining the overall orchestration control flow logic.
With that in mind then we can see that with the function definition in the serverless workflows model we are defining direct invocation of our serverless functions only. Invocations based on events (triggers) etc can be explicitly defined using workflow event definitions and different workflow states, which will be covered in depth in future posts. This allows you to clearly define the conditions under which our functions should be invoked as well as how they should be invoked in a vendor-neutral way.
Let's take a look at an example on how direct function access can be done in AWS. They use Amazon Resource Names (ARNs) which uniquely identify AWS resources including our functions that may run on AWS Lambda.
An ARN is a string which can look like:
"arn:aws:lambda:us-east-1:123456789012:function:lambda-hello-world"
RESTful API invocations can also be accomplished with simple routing rules, for example you may define in your API gateway:
"GET /hello_world => arn:aws:lambda:us-east-1:123456789012:function:lambda-hello-world"
to expose function invocation via REST.
With Azure Functions for example you can define a http endpoint to trigger function execution, in the form of a string:
"http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>"
In most if not all cases function invocation can be defined with a string value which defines the unique access point (resource) for particular function invocation.
Now lets finally take a look at functions definitions in the Serverless Workflow model :)
The Serverless Workflow JSON Schema defines the top-level functions array as:
Which is an array of specific function definitions described in the schema as:
So finally lets take an example workflow definitions where we have two function invocations definitions that can be then referenced (via its unique name) in workflow state actions:
Since functions can be invoked by many different states during workflow execution, this reusable "functions" array allows workflow states to reference the function invocation resource via the uniquely defined function name. We will get into details on workflow states and state actions in future posts, but for now here is an example state action which references a defined function and passes input parameters to it:
This action references our previously defined "HelloWorldFunction" function and passes a parameter to it which tells it what language to display the greeting in.
The function definition also includes a non-required "type" parameter. This parameter can be used give more information to the runtime implementations what the resource function parameter defines. Some example values of the type parameter can be: "arn", "POST", "kafka-topic", etc. The type parameter does not influence workflow execution logic, it simply gives more information about the function invocation resource.
Thanks for reading, and as always feel free to get your own ideas and expertise into the Serverless Workflow specification by contributing and getting involved.
-- Tihomir Surdilovic --
RESTful API invocations can also be accomplished with simple routing rules, for example you may define in your API gateway:
"GET /hello_world => arn:aws:lambda:us-east-1:123456789012:function:lambda-hello-world"
to expose function invocation via REST.
With Azure Functions for example you can define a http endpoint to trigger function execution, in the form of a string:
"http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>"
In most if not all cases function invocation can be defined with a string value which defines the unique access point (resource) for particular function invocation.
Now lets finally take a look at functions definitions in the Serverless Workflow model :)
The Serverless Workflow JSON Schema defines the top-level functions array as:
Which is an array of specific function definitions described in the schema as:
So finally lets take an example workflow definitions where we have two function invocations definitions that can be then referenced (via its unique name) in workflow state actions:
Since functions can be invoked by many different states during workflow execution, this reusable "functions" array allows workflow states to reference the function invocation resource via the uniquely defined function name. We will get into details on workflow states and state actions in future posts, but for now here is an example state action which references a defined function and passes input parameters to it:
This action references our previously defined "HelloWorldFunction" function and passes a parameter to it which tells it what language to display the greeting in.
The function definition also includes a non-required "type" parameter. This parameter can be used give more information to the runtime implementations what the resource function parameter defines. Some example values of the type parameter can be: "arn", "POST", "kafka-topic", etc. The type parameter does not influence workflow execution logic, it simply gives more information about the function invocation resource.
Thanks for reading, and as always feel free to get your own ideas and expertise into the Serverless Workflow specification by contributing and getting involved.
-- Tihomir Surdilovic --
No comments:
Post a Comment