Microkernel #
Communism. Share resources among consumers.
Known as: Microkernel [POSA1, POSA4 but not SAP and FSA].
Aspects:
Variants:
- Operating System,
- Software Framework,
- Virtualizer / Hypervisor / Container Orchestrator [DDS] / Distributed Runtime,
- Interpreter [GoF] / Script / Domain-Specific Language (DSL),
- Configurator / Configuration File,
- Saga Engine,
- AUTOSAR Classic Platform.
Structure: A layer of Orchestrators over a Middleware over a layer of Services.
Type: Implementation.
| Benefits | Drawbacks |
|---|---|
| The system’s complexity is evenly distributed among the components | The API and SPIs are very hard to change |
| Polymorphism of the resource providers | Performance is suboptimal |
| The components can have independent qualities | Latency is often unpredictable |
| A resource provider can be implemented and tested in isolation | |
| Each application is sandboxed by the microkernel | |
| The system is platform-independent |
References: Microkernel pattern in [POSA1].
While vanilla Plugins and Hexagonal Architecture keep the business logic in the monolithic core component, Microkernel treats the core as a thin Middleware (called microkernel) that connects user-facing applications (external services) to resource providers (internal services). The resource in question can be anything ranging from CPU time or RAM to business functions. The external services communicate with the microkernel through its API while the internal services implement the microkernel’s service provider interfaces (SPIs) (usually there is a kind of internal service and an SPI per resource type).
On one hand, the pattern is very specific and feels esoteric. On the other – it is indispensable in many domains, with many more real-life occurrences than would be expected. Microkernel finds its place where there are a variety of applications that need to use multiple shared resources, with each resource being independent of others and requiring complex management.
Performance #
The microkernel, being an extra layer of indirection, degrades performance. The actual extent varies from a few percent for OSes and virtualizers to an order of magnitude for scripts. A more grievous aspect of performance is that latency becomes unpredictable as soon as the system runs short of one of the shared resources: memory, disk space, CPU time, or even storage for deleted objects. That is why real-time systems rely on minimalistic real-time OSes or even run on bare metal.
It is common to see system components communicate directly via shared memory or sockets bypassing the microkernel to alleviate the performance penalty it introduces.
Dependencies #
The applications depend on the API of the microkernel while the providers depend on its SPIs. On one hand, that isolates the applications and providers from each other, letting them develop independently. On the other hand, the microkernel’s API and SPIs should be very stable to support older versions of the components which the microkernel integrates.
Applicability #
Microkernel is applicable in:
- System programming. You manage system resources and services which will be used by untrusted client applications. Hide the real resources behind a trusted proxy layer. Be ready to change the hardware platform without affecting existing client code.
- Frameworks that integrate several subdomains. The microkernel component coordinates multiple specialized libraries. Its API is a Facade [GoF] for the managed functionality.
- Scripting or DSLs. The microkernel is an Interpreter [GoF] which lets your clients’ code manage the underlying system.
Microkernel does not fit:
- Coupled domains. Any degree of coupling between the resource providers complicates the microkernel and its SPIs and is likely to degrade performance which, however, may be salvaged by introducing direct communication channels between the providers.
Relations #
Microkernel:
- Is a specialization of Plugins.
- Is related to Backends for Frontends, which is a layer of Orchestrators over a layer of Services; Microkernel adds a Middleware in between.
- Is a kind of 2-layered SOA with an ESB.
- The microkernel layer serves as (implements) a Middleware for the upper (external) Services and often makes an Orchestrator for the lower (internal) Services.
- May be implemented by Mesh.
Variants #
Microkernel can appear in many forms:
Operating System #
The original inspiration for Microkernel, namely operating systems, provides an almost perfect example of the pattern, even though their kernels are not that “micro-” (unless you are running MINIX or QNX). Device drivers (internal services) encapsulate available hardware resources and make them accessible to user-space applications (external services) via an OS kernel. Drivers for a given kind of subsystem (e.g. network adapter or disk drive) are polymorphic towards the kernel and match the hardware installed.
Software Framework #
The microkernel is a Facade [GoF] that integrates a set of libraries and exposes a user-friendly high-level interface. PAM looks like a reasonably good example.
Virtualizer, Hypervisor, Container Orchestrator, Distributed Runtime #
Hypervisors (Xen), PaaS and FaaS, container orchestrators (Kubernetes) [DDS], and distributed actor frameworks (Akka, Erlang/Elixir/OTP) use resources of the underlying computer(s) to run guest applications. A hypervisor virtualizes the resources of a single computer while a distributed runtime manages those of multiple servers – in the last case there are several instances of the same kind of an internal server which abstracts a host system.
Interpreter, Script, Domain-Specific Language (DSL) #
User-provided scripts are run by an Interpreter [GoF] which also allows them to access a set of installed libraries. The Interpreter is a microkernel, and the syntax of the script or DSL it interprets is the microkernel’s API.
Configurator, Configuration File #
Configuration files may be regarded as short-lived scripts that configure the underlying modules at the start of the system. The parser of the configuration file is a transient microkernel.
Saga Engine #
A Saga [MP] orchestrates distributed transactions. It may be written in a DSL which requires a compiler or interpreter, which is a microkernel, to execute.
AUTOSAR Classic Platform #
The notorious automotive standard, though promoted as SOA, is structured as a distributed / virtualized Microkernel. The application layer comprises a network of software components spread out over hundreds of chips which are, for some secret reason, called electronic control units (ECUs). The communication paths between the software components and much of the code are static (auto-generated at compilation time). A software component may access hardware of its ECU via standard interfaces.
The microkernel shows up as Virtual Functional Bus (VFB) which, as a distributed Middleware, provides communication between the applications by virtualizing multiple Runtime Environments (RTEs) – the local system interfaces.
Summary #
Microkernel is a ubiquitous approach to sharing resources among consumers, where both resource providers and consumers may be written by external companies.