By the end of the lesson, you can explain the structure of the microkernel (plug-in) architecture, say when it is advantageous, and what its typical risk is.
Why is it needed?
Some systems are defined by their functions being extensible afterwards, developed separately: an IDE, a browser or an editor works like this. The styles so far cut along business capabilities; the microkernel separates the unchanging core from the changing extensions.
What is it?
The microkernel architecture (also called plug-in architecture) consists of two types of components: a small core, which contains the minimum needed for the system to run, and plug-ins, which provide independent additional functions. The name comes from the well-known structure of operating systems. According to the preview of Mark Richards' book, the core traditionally contains only the functionality needed to run, and a registry often helps find the plug-ins.
flowchart TB
subgraph Core["Core"]
R["Plug-in registry"]
M["Common behaviour"]
end
P1["Plug-in 1"] --> R
P2["Plug-in 2"] --> R
P3["Plug-in 3"] --> R
Plug-ins are typically loaded into the core as libraries, so the system remains one deployment unit; a plug-in can, however, also be a remote service.
By aspect
Aspect
Microkernel
Coupling
Plug-ins connect through the core's contract and do not know about each other
Deployability
A plug-in can be developed separately; deployment depends on how it is loaded
Scaling
The core usually has shared resources; scaling is rarely the main concern
Data management
Shared data, or the plug-in's own data — to be designed
Failure handling
A faulty plug-in can affect the core if it is not isolated
Cost
Low if the extension points are stable
What is its risk?
The core's contract (the extension point) becomes the hardest part of the system to change: if it is modified, every plug-in is affected. A core that is too large or knows too much becomes a bottleneck. A faulty or malicious plug-in is a risk if it runs in the same process.
The microkernel is not a general application structure: it fits where "core + changing extensions" is the natural model.
How does it relate to the others?
The modules of a modulith (2.4) call each other with business operations; the plug-ins of a microkernel use the core and generally do not call each other. Plug-ins may well have a hexagonal internal structure (2.3).
Common misconceptions
Statement
Clarification
"The microkernel exists only in operating systems."
Operating systems gave it its name; applications also use the core–plug-in structure.
"A plug-in is always a separate process."
Typically it is loaded as a library; it can also be remote.
"Plug-ins may freely call each other."
That would couple them; the contract goes through the core.
In short
The microkernel consists of a small core and plug-ins.
Plug-ins connect through the core's contract.
Its advantage is extensibility; its risks are the rigidity of the core's contract and the lack of isolation.
It is not a general business application structure.
Review questions
What is the role of the core and what is the role of the plug-in?
Why is the extension point hard to change?
How does a plug-in differ from a module of a modular monolith?
Microkernel: Core and Plug-ins
Objectives
By the end of the lesson, you can explain the structure of the microkernel (plug-in) architecture, say when it is advantageous, and what its typical risk is.
Why is it needed?
Some systems are defined by their functions being extensible afterwards, developed separately: an IDE, a browser or an editor works like this. The styles so far cut along business capabilities; the microkernel separates the unchanging core from the changing extensions.
What is it?
The microkernel architecture (also called plug-in architecture) consists of two types of components: a small core, which contains the minimum needed for the system to run, and plug-ins, which provide independent additional functions. The name comes from the well-known structure of operating systems. According to the preview of Mark Richards' book, the core traditionally contains only the functionality needed to run, and a registry often helps find the plug-ins.
flowchart TB subgraph Core["Core"] R["Plug-in registry"] M["Common behaviour"] end P1["Plug-in 1"] --> R P2["Plug-in 2"] --> R P3["Plug-in 3"] --> RPlug-ins are typically loaded into the core as libraries, so the system remains one deployment unit; a plug-in can, however, also be a remote service.
By aspect
What is its risk?
The core's contract (the extension point) becomes the hardest part of the system to change: if it is modified, every plug-in is affected. A core that is too large or knows too much becomes a bottleneck. A faulty or malicious plug-in is a risk if it runs in the same process.
The microkernel is not a general application structure: it fits where "core + changing extensions" is the natural model.
How does it relate to the others?
The modules of a modulith (2.4) call each other with business operations; the plug-ins of a microkernel use the core and generally do not call each other. Plug-ins may well have a hexagonal internal structure (2.3).
Common misconceptions
In short
Review questions
Learning resources