JB, Thanks for the feedback. I'll check out the blog and look at where you've been going.
This is sort of on track for what I'm thinking about. One has to read between the lines a bit because the example is using VirtualBox and Docker but OSv is the microkernel being used. In reality, what I'd be after is the microkernel - OSv or Mirage or whatever - directly running on the hypervisor. Which is what OSv and other ukernels are really designed for. What I wasn't sure about until I read this is one of the microkernels running Java. Obviously once one has a JVM running then putting Karaf/Felix on it is possible. https://github.com/solo-io/unik/blob/master/docs/getting_started_java.md >From what I understand microkernels generally only permit a single process to be booted. That can be a big challenge for many applications and architectures. Karaf has long worked in a way that when it runs on a VM you really don't have to log into the VM itself because all the tools are built in. That makes it ideal for use in a microkernel because I don't believe most microkernels provide command lines or log ins. Think about a compare and contrast of Karaf running on OSv versus Spring Boot. Karaf would run on the JVM and you could SSH in or go to Hawtio or interact with it and its file system in many different manners. With Spring Boot, once you've run it on the microkernel that's it. You can't log into it or look at its file system or tweak configurations for the running instance. Hypervisor->OSv ukernel->JVM->Karaf Very fast start up. Low overhead. JVM running in kernel mode with privileged acess and low latency. Karaf console/SSH, Maven deployment of artifacts, etc. While I understand Docker and Kubernetes, I've always thought of it as an "elegant hack". Virtual machines are big and slow and resource hungry so how do we get around that problem? Hack security barriers into the virtual machine to partition it and then create management technologies. It seems to solve the problem at the wrong level of abstraction and with Java that creates a problem - the JVM isn't shared across Docker images. So we end up with a way to share the resources of a virtual machine with multiple Docker images but if they are JVM based, each JVM is going to grab its own chunk of threads, memory and so on. Of course, if you're running Spring Boot instance then each of those instances loads a large number of identical classes and bytecode - even if it is just the JDK. That problem persists even if you run Spring Boot on a microkernel. Running Karaf on a microkernel is another matter. If I structure my features along functional lines I can install them all in one Karaf container or if I want to break them out later I can run them in separate containers in their own microkernel instance. Obviously that's not unique to microkernels as you can do that today in Docker images if you desired. But Karaf in Docker doesn't make a lot of sense to me. But let's get to the original problem - VMs are big and slow and take a lot of resources to boot up an operating system that lets your run your applications. Docker partitions the VM to make it a little more parsimonious and faster. Kubernetes manages the resources for you. Now, let's get rid of the VM, Docker and Kubernetes and run a microkernel directly on the hypervisor which spins up a JVM and Karaf. Fast. Streamlined. Managing my Java applications on that stack is no different than interacting with it running on my desktop or on a server or on a VM or in a Docker image running in a VM. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
