You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in #712 we want to have a single generic component which can be instantiated multiple times to fulfill the different EAI Patterns. We plan that the generic component interfaces with Kafka and takes care of the message de/serialization. The business logic on how to split/route/transform/aggregate the message or its payload is provided via functions hosted on a FaaS solution. As a result of that, we need a means to wire the instances of the generic component with functions. I think there are at least the following possibilities (the order does not indicate any prioritization):
Environment variables: Save the gateways addresses and the necessary details like the name of the functions in environment variables while deploying an instance of the generic component. MICO already supports environment variables and we probably need a way to configure the components (Kafka Topic settings etc) anyway.
Function registry: Implement a function registry component inside MICO. At startup time an instance fetches the necessary information from there. We could evaluate if Apache Zookeeper or etcd fits this purpose.
Control Topic: We already use Kafka so we could follow the dynamic router pattern and use a control channel(topic) to configure the instances. This topic could use the compaction feature to always retain the last known configuration for each message key.
Function composition: Don't implement the generic component as a separate component but as a function. There is a Kafka connector for OpenFaaS. Then compose the functions with a composer like this or follow the workflow techniques described in the OpenFaaS documentation.
The text was updated successfully, but these errors were encountered:
As described in #712 we want to have a single generic component which can be instantiated multiple times to fulfill the different EAI Patterns. We plan that the generic component interfaces with Kafka and takes care of the message de/serialization. The business logic on how to split/route/transform/aggregate the message or its payload is provided via functions hosted on a FaaS solution. As a result of that, we need a means to wire the instances of the generic component with functions. I think there are at least the following possibilities (the order does not indicate any prioritization):
Environment variables: Save the gateways addresses and the necessary details like the name of the functions in environment variables while deploying an instance of the generic component. MICO already supports environment variables and we probably need a way to configure the components (Kafka Topic settings etc) anyway.
Function registry: Implement a function registry component inside MICO. At startup time an instance fetches the necessary information from there. We could evaluate if Apache Zookeeper or etcd fits this purpose.
Control Topic: We already use Kafka so we could follow the dynamic router pattern and use a control channel(topic) to configure the instances. This topic could use the compaction feature to always retain the last known configuration for each message key.
Function composition: Don't implement the generic component as a separate component but as a function. There is a Kafka connector for OpenFaaS. Then compose the functions with a composer like this or follow the workflow techniques described in the OpenFaaS documentation.
The text was updated successfully, but these errors were encountered: