Eclipse Kapua messaging refactoring proposal

Brought to you by

Dejan Bosanac and Henryk Konsek

Eclipse KapuaMessaging refactoring proposal

Dejan Bosanac

- Messaging rock star :)

@dejanb @hekonsek

Henryk Konsek

- engineer at Red Hat- open source junkie

@hekosek@dejanb @hekonsek

● Kapua messaging now● How can we make it better?● Action plan

This presentation@dejanb @hekonsek

Kapua messaging now

@hekonsek@dejanb @hekonsek

Kapua messaging now@hekonsek@dejanb @hekonsek

Kapua messaging now@hekonsek

- Authentication- Apache Shiro state- Connection metrics- Device lifecycle events

All combined into a single ActiveMQ broker uber-plugin.

@dejanb @hekonsek

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

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

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

How can we make it better?

@hekonsek@dejanb @hekonsek

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

Starting point@hekonsek@dejanb @hekonsek

Step #1: Extract messaging@hekonsek

- Extract messaging out of the Kapua JVM- Messaging provider must support AMQP, may support MQTT

@dejanb @hekonsek

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

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

Reference implementation@hekonsek

- In reference implementation we can use Artemis broker authentication against KeyCloak (or something else)

@dejanb @hekonsek

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)

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

Action plan

@hekonsek@dejanb @hekonsek

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

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

Henryk Konsek@hekonsek

[email protected]

@hekonsek

Thank you!

Dejan Bosanac@dejanb

[email protected]

@dejanb @hekonsek