Plus now, the app devs, now all turned devops because talent is scarse and demand is high, get to handle the complexity of concurrency, networking and reliability. This adds to deployment/testing/development setup, and when you change stack or job, the architecture slightly different and you need to learn it all over again.
Funnily enough, we couldn't make the microkernel concept works despite an homogeneous, integrated environment as a basis. But we are fine building frankenstein OS images, hacking multiple graph-shaped systems to make them play together, and call that a success.
Now don't get me wrong, I understand perfectly the benefits of it. But somehow, it feels like we arrived at the right result by the worst possible path, and at a price way higher than it should be.
Most of the people that rail against pure microkernels have zero experience actually building stuff with them. Those that do have that experience have hard proof that systems built in this way are more reliable and easier to build than others. Hypervisors have their own place in the hierarchy, they do not compete effectively with microkernels on their own turf.
The typical problem with microkernels is poor backwards compatibility, mainly due to POSIX. If you add POSIX compatibility, you don't gain any isolation, performance or security benefits of microkernels, and changing your thinking and your programs to gain those benefits requires significant work when they're written against the POSIX API.
Building them that way from scratch is pretty much just as easy as writing programs in UNIX, modulo the lack of tooling that is mostly POSIX-based.
Is there a microkernel API that has more acceptance nowadays? In other words, where should anyone wanting to work on real world / enterprise systems based on microkernel look?
You nailed it: From day 2 or so we imagined to develop Genode as the future common API for the diverse range of microkernels and showcased the approach with all L4 kernels we could get our hands on. The vision is still to provide a replacement for POSIX in the microkernel world ;-)
Regarding POSIX, we don't think that tools and applications developed for this interface do not fit the microkernel world but on the traditional systems level POSIX (and its tools) is not sufficient to make the best of out of the microkernel advantages. For example, we run libcurl, GPG, libarchive, and coreutils in an orchestrated scenario to implement a robust and secure deployment/installation subsystem in the Genode-based Sculpt OS https://genode.org/documentation/articles/sculpt-19-07.
The Okl4 kernel in iPhones is extremely limited in its functionality, you could probably run that code even without an Os. It could also be argued if in its current form it is really a microkernel. Furthermore, sel4 and okl4 are not the same product.
(nothing bad on sel4, I have used it myself and I personally know the people behind the project. But it's not what you think it is)
I've developed for it and I thought it was pretty nice. Sure, the kill command is called slay, and other oddities, but at its core it is a very well-designed system.
Funnily enough, we couldn't make the microkernel concept works despite an homogeneous, integrated environment as a basis. But we are fine building frankenstein OS images, hacking multiple graph-shaped systems to make them play together, and call that a success.
Now don't get me wrong, I understand perfectly the benefits of it. But somehow, it feels like we arrived at the right result by the worst possible path, and at a price way higher than it should be.