View
268
Download
0
Category
Preview:
Citation preview
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
hekonsek@gmail.com
@hekonsek
Thank you!
Dejan Bosanac@dejanb
dbosanac@redhat.com
@dejanb @hekonsek
Recommended