Microkernel Architecture

Extensibility is the name of the game
Published on 2024/05/24

For no good reason I haven't covered Architecture Styles in a little while. Today we will touch on the Microkernel Architecture as described by Mark Richards and Neal Ford. To be transparent I never developed or contributed to this type of architecture. As we go through it you will realize, as I did, that A LOT of systems we use regularly adopt this pattern.

Fundamentally this architecture has two types of components:

  1. A core system
  2. Plug-in components

This architecture falls under the monolith paradigm, as the core system is shipped along with its plugins. While you might be used to dedicated services being deployed and scaled independently, this is not the case, and it's usually a single unit. There are plenty of examples of this but before we jump into that, your mental model can represent this as a minimal functioning system that can be extended. The minimal functioning system is the core, the components that allow for this extensibility are the plug-ins.

The most commonly used example is a browser like Firefox. The core is what allows you to use your browser for its original purpose, to surf the web! Thankfully you can extend the core system with plug-ins and extensions which will add functionalities to the core system. Generally, plug-in components are independent from one another and don't have shared dependencies. This makes sense, can you imagine a Firefox or Chrome extension depending on another extension? They should instead be added and removed at will without impacting the overall system or other plugins.

Intuitively the system will need to know which plug-ins are available, this is commonly attained via a registry. If you have 3 plug-ins installed on your browser that need initialization at startup time, a registry might be the place containing the information necessary to tell the browser which extensions need to be bootstrapped (disclaimer, this is just an example, I don't know exactly if this is how browsers accomplish this, let me know if you know!).

The last piece of the puzzle is what I find the most fascinating and also the important "glue". The contract between the core system and the plug-ins needs to be properly designed. This is the most powerful implementation detail, it's what opens the system to extensibility and what plug-ins need to adapt to in order to provide the intended functionality. If you have a mediocre design with the intention to allow anyone to create extensions, it might push away developers from doing so.

Thoughts

Overall the ideas behind the Microkernel Architecture are not particularly complex. As I mentioned in the last paragraph, the challenging part is how you define the contract but, on second thought, it's also what you allow plugins to be able to do. Where you draw the line between what's part of the core system and what's not. I find this an interesting challenge that I haven't faced yet in my career, never say never!

0
← Go Back