BaaS Integration

One of the unique features of OpenFunction is its simple integration with various backend services (BaaS) through Dapr. Currently, OpenFunction supports Dapr pub/sub and bindings building blocks, and more will be added in the future.

In OpenFunction v0.7.0 and versions prior to v0.7.0, OpenFunction integrates with BaaS by injecting a dapr sidecar container into each function instance’s pod, which leads to the following problems:

  • The entire function instance’s launch time is slowed down by the launching of the dapr sidecar container.
  • The dapr sidecar container may consume more resources than the function container itself.

To address the problems above, OpenFunction introduces the Dapr Standalone Mode in v0.8.0.

Dapr Standalone Mode

In Dapr standalone mode, one Dapr Proxy service will be created for each function which is then shared by all instances of this function. This way, there is no need to launch a seperate Dapr sidecar container for each function instance anymore which reduces the function launching time significantly.

BaaS Integration - 图1

Choose the appropriate Dapr Service Mode

So now you’ve 2 options to integrate with BaaS:

  • Dapr Sidecar Mode
  • Dapr Standalone Mode

You can choose the appropriate Dapr Service Mode for your functions. The Dapr Standalone Mode is the recommened and default mode. You can use Dapr Sidecar Mode if your function doesn’t scale frequently or you’ve difficulty to use the Dapr Standalone Mode.

You can control how to integrate with BaaS with 2 flags, both can be set in function’s spec.serving.annotations:

  • openfunction.io/enable-dapr can be set to true or false
  • openfunction.io/dapr-service-mode can be set to standalone or sidecar
  • When openfunction.io/enable-dapr is set to true, users can choose the Dapr Service Mode by setting openfunction.io/dapr-service-mode to standalone or sidecar.
  • When openfunction.io/enable-dapr is set to false, the value of openfunction.io/dapr-service-mode will be ignored and neither Dapr Sidecar nor Dapr Proxy Service will be launched.

There’re default values for both of these two flags if they’re not set.

  • The value of openfunction.io/enable-dapr will be set to true if it’s not defined in spec.serving.annotations and the function definition contains either spec.serving.inputs or spec.serving.outputs. Otherwise it will be set to false.
  • The default value of openfunction.io/dapr-service-mode is standalone if not set.

Below you can find a function example to set these two flags:

  1. apiVersion: core.openfunction.io/v1beta1
  2. kind: Function
  3. metadata:
  4. name: cron-input-kafka-output
  5. spec:
  6. version: "v2.0.0"
  7. image: openfunctiondev/cron-input-kafka-output:v1
  8. imageCredentials:
  9. name: push-secret
  10. build:
  11. builder: openfunction/builder-go:latest
  12. env:
  13. FUNC_NAME: "HandleCronInput"
  14. FUNC_CLEAR_SOURCE: "true"
  15. srcRepo:
  16. url: "https://github.com/OpenFunction/samples.git"
  17. sourceSubPath: "functions/async/bindings/cron-input-kafka-output"
  18. revision: "main"
  19. serving:
  20. annotations:
  21. openfunction.io/enable-dapr: "true"
  22. openfunction.io/dapr-service-mode: "standalone"
  23. template:
  24. containers:
  25. - name: function # DO NOT change this
  26. imagePullPolicy: IfNotPresent
  27. runtime: "async"
  28. inputs:
  29. - name: cron
  30. component: cron
  31. outputs:
  32. - name: sample
  33. component: kafka-server
  34. operation: "create"
  35. bindings:
  36. cron:
  37. type: bindings.cron
  38. version: v1
  39. metadata:
  40. - name: schedule
  41. value: "@every 2s"
  42. kafka-server:
  43. type: bindings.kafka
  44. version: v1
  45. metadata:
  46. - name: brokers
  47. value: "kafka-server-kafka-brokers:9092"
  48. - name: topics
  49. value: "sample-topic"
  50. - name: consumerGroup
  51. value: "bindings-with-output"
  52. - name: publishTopic
  53. value: "sample-topic"
  54. - name: authRequired
  55. value: "false"