Hello, referencing to Dimitrys presentation I understand that it's useful to group a set of services in the same osgi container. This will reduce complexity and work while updates, IC and more.
following some ideas to become karaf more kubernetes ready ... - That's currently possible without changes. It's a pure design decision. - What currently is missing is a useful docker image supporting configuration via environment variables, changing user id and supporting sidecars like filebeat or loki promtail. - I already created a docker image with features like this. I can contribute it if wanted. - Even support for tracing collectors like jeager would help to integrate karaf in a kubernetes environment. - I already created a health and readiness check servlet using felix health framework and watching log messages. Maybe this could become part of karaf core. - Maybe it's possible to combine karaf with existing mesh tools to create fast kubernetes configurations with sidecars ect. - A common topic for clustering is a common cache and locking. It's possible with hazelcast. But I was not able use hazelcasts caching service - lots of class loader issues. I was able to use ehcache (no locking) and redis for this features. It's a shame that specially 'java caching api' is not possible in OSGi using hazelcast. It's also not easy with ehcache but I found a workaround. - Also common cron jobs are needed - should be executed only once in a cluster. Maybe it's possible to generate a kubernetes cronjob config instead of using a scheduler (maybe by using annotations). My background: I'm woking for a telecomunication company even for process automatisation. Four years ago we decided to use karaf and JMS to create a decentralised environment. The control center is using vaadin as UI framework. Currently I'm planing to migrate the environment in a kubernetes cloud. I found the presentation of Dimitry very helpful. I will try not to divide each service in a separate container. In this scenario it's also possible to share database entities in the same JVM engine - this will even boost the performance - instead of using it via rest all the time. Also interesting is the support of API gateways. For me a big problem is the service discovery. It's absolutely stupid to configure each service manually in the API gateway. A more comfortable way would be some kind of discovery. Karaf could automatically configure/update the gateway depending on the provided jax rs resources. cu Mike
signature.asc
Description: Message signed with OpenPGP
