Clearly, there's a lot of skepticism.

Do microkernels suck? In a nutshell: no, they rock--if they're well designed and implemented. I will elaborate.

Microkernels, first invented around 1970, are based on the idea of moving the operating system's services out of the kernel (the code that runs in the processor's privileged mode) into user-mode servers. Microkernels were en vogue in the 1980s; it seemed as if everyone was building one. And, as with many fashionable technologies, their proponents promised much and delivered little.

Mach, an OS that was widely used as the basis of systems, ran into serious performance problems, and its contemporaries (like Chorus and QNX) weren't much better. There were spectacular failures, none more so than IBM's Workplace OS, which cost the company a cool two gigabucks. Others, like the Mach-based OSF/1 and Next operating systems, ended up moving most OS functionality back into the kernel. This is how Mac OS X functions today; it has given up any pretense of being a microkernel OS.

Needless to say, the experience with Mach and others created a bit of an image problem for microkernels (which didn't stop the GNU Hurd from repeating the mistakes of the past). However, back in 1993, Jochen Liedtke demonstrated that these performance problems weren't inherent in the microkernel concept. His L4 microkernel ran rings around the competition, outperforming Mach and QNX by factors of 5 to 20 in the cost of the critical IPC primitive. In an analysis of Mach, he showed that the poor performance was a result of excessive size (about 300 kernel APIs and 100s kLOC is certainly not "micro").

Liedtke showed that minimality was critical and formulated what is now the accepted definition: a microkernel only contains code that must execute in kernel mode; everything else should run as user-mode programs. He also outlined design principles for flexible, high-performance microkernels.