Feedback for IBM Cloud Functions

[csantanapr]

Feedback for document: https://github.com/Stacksenseio/Data/blob/master/Serverless/FaaS%20Evaluation/IBMCloudFunctions.yaml

Language Support : Node.js, Swift, Java, Go, PHP, Python

We support docker actions in two ways:

1. (wsk action create foo foo.sh|foo.zip--native) user can re-use the default docker action image and can upload a script (bash, shell, perl) or a zip with an executable inside (from any language c++, golang cobol, rust, etc..)
2. (wsk action create foo myuser/mydockerimage) user can specify any docker image form docker hub and it will be use as a docker action.

Function Code Input Options : {UI, Github, IBM Cloud Object Storage, Docker}

Currently we don't have "IBM Cloud Object Storage" You can deploy with a CLI or REST API.

Event Sources : {Cloudant, Cloud Object Storage, Push Notifications, Message Hub, IBM Watson, The Weather Company. Slack, GitHub}

Update to: Event Sources : {Cloudant, Mobile Push Notifications, Message Hub (Apache Kafka), GitHub, WebHook}

Dependencies : npm

User can upload a zip and this can include any dependencies, for compiled languages then they can use standard dependencies. Java (gradle, maven), Swift (Swift package manager), Python (virtualenv)

• High Availabilty : False

This should be True I think, your functions will always find a node where to run on.

• List of Metrics : {CPU, Memory, Time, Error, Cold Start}

We don't currently provide out of the box what was the max cpu or memory consumed by the function run. The user can do this within the function and record the cpu and memory and send it to a metrics api for collection or just log it to stdout.

• Supported Cloud Services : {Slack, IBM Watson, IBM Cloudant, Weather, IBM Mobile Push, IBM Cloud Storage}

I guess you can add at the end of the list "Any Service with an API", any of the IBM services or outside the IBM cloud can be consume from the function.

• Cloud Provider IAM Support : True

We currently do not integrate with IBM Cloud IAM, but is on the roadmap. currently security is via API Key for the IBM Functions service.

• Virtual Private Network Support : False

This should be True, we offer a secure gateway service that you can VPN to a on-premise server from your function, but we also allow any custom VPN to be use by the user from their functions.

[mbehrendt]

Language Support : Node.js, Swift, Java, Go, PHP, Python

along the lines of @csantanapr 's feedback -- I think any language should be added here.

Environment Variables : False

I think this should be true . While we don't support OS-level environment variables, we support the declarative definition of parameters, so you can run a function with different parameters while not having to modify the code. You can find this in the "Setting default parameters" section on this page: https://console.bluemix.net/docs/openwhisk/openwhisk_actions.html#openwhisk_actions

Built-In Versioning : False

Depending on the semantics of this item, it could be set to true. Whenever you update a function/action, the version counter for that action is automatically increased. You can see that, when -- after updating an action - you run bx wsk action get <actionname> .

High Availabilty : False

As @csantanapr mentioned, I also think this should be true.

Warm Start Support : False

We're doing warm starts under the cover, so depending on the semantics of this item, I think it should be set to true.

[krishnan]

@csantanapr I have covered the support for additional languages through Docker in the language extensibility. This list is about out of box languages. I will update the rest as you suggested. As far as High Availability, I agree functions will run on any node that is available but this is about fault tolerance across availability zones which AWS Lambda uses. As far as "Any service with an API", that is covered under Third party integrations out of the box. But let me think if I should have this as a standalone feature. Thanks for the feedback.

@mbehrendt I will fix the Environment Variable. As far as versioning, I was looking to see if the resource ID (which you point out actually increases) can be used to work across different versions as the code traverses the pipeline towards production. It was not clear in the docs. Without this ability, it just becomes a label and not helping in the context I am looking. As far as High Availability, it is about functions running in two availability zones as in the case of AWS Lambda. I didn't see it in any of the services but one could do it with Azure if their functions is used under App Services plan. I checked out the warm starts work under cover. It is more of a hack than say a configuration value where I should be able to set it on for certain functions and it should stay warm. ie, giving users a way to decide if they want to keep a function warm or not.

Thanks for the suggestions. I will incorporate you suggestions

[krishnan]

Added your suggestions. For the rest, see my explanation above. Re-open the issue if needed.

[mbehrendt]

I agree functions will run on any node that is available but this is about fault tolerance across availability zones which AWS Lambda uses.

@krishnan while this might not be explicitly documented, we're running in a multi-AZ mode. Did you come across any documentation which would express the opposite? (if so, I think we should fix that)

[krishnan]

No. I didn't come across any documentation that says otherwise. i searched the documentation to see if they run across multiple availability zones and couldn't find anything to support that. I will update it based on this information. Maybe, you should update the documentation too

[mbehrendt]

thank you, that is a good finding. We'll update our docs accordingly