APACHE OPENWHISK - PLUGGABLE EVENT PROVIDERS APACHE OPENWHISK TRIGGER FEED PROVIDERS ➤ API Gateway ➤ Apache Kafka ➤ Apache CouchDB ➤ Cron Alarm ➤ Github ➤ ... APACHE OPENWHISK TRIGGER FEED PROVIDERS Why don’t we have more? Lots of community contributions for runtimes Not so much for feed providers... APACHE OPENWHISK TRIGGER FEED PROVIDERS Why don’t we have more? Trigger feeds are not that simple to implement. Documentation is not great. APACHE OPENWHISK TRIGGER FEED PROVIDERS Was asked internally to produce an S3 compatible feed provider. Use polling to check bucket file etags for file changes. HOW OPENWHISK TRIGGER FEEDS WORK wsk trigger create periodic \ --feed /whisk.system/alarms/alarm \ --param cron "*/2 * * * *" \ --param trigger_payload “{...}” \ --param startDate "2019-01-01T00:00:00.000Z" \ --param stopDate "2019-01-31T23:59:00.000Z" feed parameter refers to a normal action action invoked with the trigger details by cli TRIGGER FEED API custom feed provider is supposed to manage listening to event source and firing triggers on events EXISTING TRIGGER FEED PROVIDERS ARCHITECTURE - ADDING TRIGGER Feed Action Web Action Trigger Database Event Provider Event Source User Trigger wsk CLI - User creates trigger with feed with wsk CLI tool - CLI calls feed action with trigger & auth details - Feed action calls web action (?) - Web action writes to Trigger management database EXISTING TRIGGER FEED PROVIDERS ARCHITECTURE - EVENT PROVIDER Feed Action Web Action Trigger Database Event Provider Event Source User Trigger wsk CLI - Event provider follows DB updates - Uses trigger details to start listening to external event source - Web action writes to Trigger management database EXISTING TRIGGER FEED PROVIDERS ARCHITECTURE - EVENTS OCCUR Feed Action Web Action Trigger Database Event Provider Event Source User Trigger wsk CLI - Provider fires trigger with event details when they occur. APACHE OPENWHISK TRIGGER FEED PROVIDERS Looking at the different feed providers, most of the code is not specific to the event source. 90% of code base = generic trigger management “ Can we build a generic event provider with a plugin architecture? - Easier to contribute event sources - Easier to maintain feed provider GENERIC TRIGGER FEED PROVIDERS ARCHITECTURE Feed Action Web Action Trigger Database Generic Event Provider Custom Event Source - Plugin handles custom event source integration - Trigger management handled by generic provider Custom Event Source Plugin Is this interesting to others? Possible next steps... - Open-source code on Github? - Write more event provider plugins? - Donate to Apache (eventually)?