I'm confused about how I can use multiple micro services made with spring boot.
When I read about Karaf, they always use Blueprint instead of Spring and I don't get the impression that it's possible to use it with Spring boot.
Then I found Fabric8 but I cannot find any example of micro services made with Spring boot.
All I need is being able to do hot deployment and configuration at runtime like Karaf does but with multiple Spring boot services.
Is it possible?
Could anybody give me documentation or a project sample?
Thank you
Here's a demo video showing how to create a Spring Boot microservice in the Fabric8 Microservices Platform and having a complete Continuous Deployment pipeline get created to do the following:
Any code or configuration change in the git repository kicks off rolling updates automatically - which is a form of hot deployment. e.g. if you are running 3 containers in production; new containers are spun up with the new code and/or config based on the rolling upgrade policy. Typically new containers start; when they are ready old ones are taken down, say 1 at a time (or you can do them all at once if you prefer). The rolling upgrade is included in any service load balancing; so new containers only get invoked when they are ready.
Given your use of OSGi you may want the containers to keep running and just mutate on the fly. Firstly the whole move to immutable infrastructure (e.g. docker images) means software gets simpler and easier to reason about. Rather than rolling new bundles/code/config in/out on the fly you just make a new image and spin that up.
Mutating on the fly leads to multi-threaded code having to stop and restart services on the fly which can cause all kinds of complex hard to reproduce bugs and resource leaks as you have large complex object dependency graphs of services starting/stopping on the fly. On the Fuse team we've wasted many man years fixing bugs in restart logic and I'm sure there's still a zillion bugs hidden there in restarting OSGi services on the fly.
So my preference really is to use a Continuous Deployment pipeline to roll out all changes; whether code or configuration. Sure there's some latency added between the time you make a change and the moment a process is processing a new request with the new code/config - but you have more quality and reliability baked in. Plus its trivial to roll back. You can also easily do rolling upgrades of the change; so you get fast feedback if the change breaks things for a small subset of your users/traffic rather than a big bang.
That being said; if you still really really want production JVMs to reload code and/or config on the fly without testing it first in a big bang approach with no easy rollback; there are still some options available. They are described in the configuration microservices documentation.
Essentially it boils down to using a ConfigMap in Kubernetes or a git repository volume; in both cases the configuration is exposed as volumes (files) - the Java code can then watch the files and reload on the fly. You can do this via OSGi Config Admin or via Spring Boot - whichever development framework you pick really.
Just remember the tradeoff of the benefits in latency from hot-reloading from the reduced quality, increased bugs and operational issues of moving away from immutable infrastructure and Continuous Delivery