Operating System Development Series (2008)

Once you realize there's not much a difference between Microkernels are the recent microservices architectures, they become interesting again. Then you might want to look in recent advances such as Unikernels or Anykernels.

Here's a good start summarizing lessons in Microkernels learned in the last decades: http://dl.acm.org/citation.cfm?id=2522720

While there might be no reason to build a kernel - most modern ones will let you lock down a process well enough, although it "looks weird" - building good UX around capabilities and objects instead of permissions and files requires starting from the ground up. The vast majority of applications, tools, and workflows that people use right now don't fit within that paradigm.

> "A service" these days means "something that lives on a TCP or UDP port" and URL means HTTP or HTTPD.

A service consists of an administration protocol and a usage protocol. In Linux, the administration protocol is usually some ad-hoc text format and SIGHUP, in Windows it's Powershell, and the usage protocol is almost always ad-hoc over TCP, requiring a library to interact with it.

It's possible to abstract services away from how you communicate with them, provided that you're working within an environment where everyone buys into that abstraction. Communicating with a file on your desktop, a file on a file server, a database server, and your coworker's spreadsheet window all become something you can do without having to find the relevant library which speaks the right protocol, or have ad-hoc mechanisms for sharing each of these things over a network - the relevant services self-describe how to communicate with them, in the same way that you can connect Powershell to an Exchange server and have all the tools for managing Exchange without installing anything.

You get to do away with SSHing into another box with a completely different shell environment, or trying to wrangle your local tools to work over sshfs. You could work on drafting an important email with a coworker as easily as dragging the window into your chat application, with neither the chat application nor the email client having to care how that works - the chat application just needs to be able to transport capabilities, and the window manager needs to be able to create a "window view" capability.

You can also start playing with really fancy things like dynamic constraint-based load balancing across a network, once your services don't care about how they're communicating with each other or where they are - where services get farmed out onto the network automatically when you perform resource-intensive tasks.

Plan 9 gets some of the way there, although I believe a filesystem is not discoverable enough - can I reliably get a lightweight IDE to tell me what "echo swap > /dev/mouse" does, vs "mouse.swapButtons()" where mouse is a typed variable? There's also no formalized way of doing request/response (especially out-of-order), and accessing a certain field of a message requires ad-hoc string parsing which is easy to get wrong.

This needs to be done as an operating system - a complete set of tools which enables a certain way of managing and interacting with resources, both as a developer and a user - because otherwise you keep hitting on the boundary of things you can interact with within the system and things you need to interact with outside the system. If you can interact with your text editor and chat application but not your spreadsheet tool or database server this way, that diminishes its use significantly.

I've been playing with minimal systems which do some of this. It's interesting, but hard work to build entire new user experiences from scratch instead of being able to port a libc to a new kernel and get a bunch of stuff for free.