Eclipse Kapua messaging refactoring proposal
2 likes672 views
Dejan Bosanac and Henryk Konsek propose refactoring the messaging in Eclipse Kapua to make it more scalable and flexible. They plan to extract the messaging into its own layer to allow Kapua to run on any AMQP broker, extract authentication, metrics, and lifecycle handling into libraries, and implement these changes while maintaining backward compatibility. Dejan and Henryk volunteer to lead the refactoring work.
Eclipse Kapua messaging refactoring proposal
- 1. Brought to you by Dejan Bosanac and Henryk Konsek Eclipse Kapua Messaging refactoring proposal
- 2. Dejan Bosanac - Messaging rock star :) @dejanb @hekonsek
- 3. Henryk Konsek - engineer at Red Hat - open source junkie @hekosek@dejanb @hekonsek
- 4. ● Kapua messaging now ● How can we make it better? ● Action plan This presentation @dejanb @hekonsek
- 7. Kapua messaging now @hekonsek - Authentication - Apache Shiro state - Connection metrics - Device lifecycle events All combined into a single ActiveMQ broker uber-plugin. @dejanb @hekonsek
- 8. Implications @hekonsek - Kapua can be run on ActiveMQ only, as it relies on ActiveMQ uber-plugin - You cannot deploy Kapua services as microservices (single VM limitation), as Shiro context is bound to the broker thread @dejanb @hekonsek
- 9. Why is it bad? @hekonsek - Is very challenging to scale Kapua horizontally - Not everybody has to prefer ActiveMQ as messaging layer - Kapua is not PaaS friendly @dejanb @hekonsek
- 10. Benefits of new approach @hekonsek - Kapua running on any AMQP 1.0 compliant messaging middleware - Migration to microservices architecture - Scalability - First step for Eclipse Hono integration - Pluggable authentication support - PaaS-enablement (for example running Kapua in Kubernetes/OpenShift will be very easy) @dejanb @hekonsek
- 11. How can we make it better? @hekonsek@dejanb @hekonsek
- 12. Warning! @hekonsek - Contract of existing MQTT clients (i.e. devices) should be respected - Device should not be aware that it talks to “new” messaging backend - Backward compatibility FTW! @dejanb @hekonsek
- 14. Step #1: Extract messaging @hekonsek - Extract messaging out of the Kapua JVM - Messaging provider must support AMQP, may support MQTT @dejanb @hekonsek
- 15. Authentication @hekonsek - It is messaging layer responsibility to perform authentication if needed - Kapua services should support multiple pluggable strategies to resolve user/tenant from authenticated message - Authentication can be optionally delayed and performed on service level (authentication on message level, not connection level) @dejanb @hekonsek
- 16. Shiro context binding @hekonsek - Services use Camel + Shiro to hold security context - The same way as Kapua does today, but outside the broker threads and JVM @dejanb @hekonsek
- 17. Reference implementation @hekonsek - In reference implementation we can use Artemis broker authentication against KeyCloak (or something else) @dejanb @hekonsek
- 18. Step #2: Extract metrics into library @hekonsek - Extract metrics logic into library - You can use it on the service (Camel) level or… - wrap it into msg middleware plugin (for example Artemis plugin)
- 19. Step #3: Extract lifecycle into library @hekonsek - the same as for metrics library :) - If you messaging middleware doesn’t allow you to wire library into it you need to compensate events logic in services layer
- 21. How can we do it? @hekonsek - I propose to keep existing broker plugin as it is - Work on the alternative approach in parallel - At some point just drop old plugin, switch to the new architecture and celebrate :) @dejanb @hekonsek
- 22. Any volunteers? @hekonsek - Dejan and Henry - We will handle that. Just give us a green light! ;) - Any other volunteers are more than welcome! @dejanb @hekonsek
- 23. Henryk Konsek @hekonsek [email protected] @hekonsek Thank you! Dejan Bosanac @dejanb [email protected] @dejanb @hekonsek