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

5. Kapua messaging now
@hekonsek@dejanb
@hekonsek

6. Kapua messaging now
@hekonsek@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

13. Starting point
@hekonsek@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

20. Action plan
@hekonsek@dejanb
@hekonsek

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
hekonsek@gmail.com
@hekonsek
Thank you!
Dejan Bosanac
@dejanb
dbosanac@redhat.com
@dejanb
@hekonsek