Microkernel

An architectural metapattern

This is a chapter from my book Architectural Metapatterns. Any feedback is warmly welcome. The book is free (CC BY license) and available for download (PDF and ePub) from GitHub.

Communism. Share resources among consumers.

Known as: Microkernel [POSA1, POSA4].

Variants:

• Operating System,
• Software Framework,
• Virtualizer / Hypervisor / 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.

References: Microkernel pattern in [POSA1].

While vanilla Plugins and Hexagonal Architecture keep their business logic in the monolithic core component, Microkernel treats the core as a thin middleware (“microkernel”) that connects user-facing applications (“external services”) to resource providers (“internal services”). The resource in question can be anything 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 Programming 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 is used when 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 hard drive space for deleted objects. That is why real-time systems rely on “real-time OS”es with rudimentary features 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 to:

• 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 the existing client code.
• Frameworks that integrate multiple 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 internal services complicates the microkernel and SPIs and is likely to degrade performance. The performance may often be salvaged by introducing direct communication channels between the services.

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 as an orchestrator for the lower (internal) services.
• May be implemented by Mesh.

Variants

Microkernel appears as many a species:

Operating System

The original inspiration for Microkernel, operating systems provide a nearly perfect example of the pattern, even though their kernels are not that “micro-”. Device drivers (internal services) encapsulate available hardware resources and make them accessible to user-space applications (external services) via an OS kernel. The drivers for the same kind of subsystem (e.g. network adapter or disk drive) are polymorphic and need to match the installed hardware.

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 / Distributed Runtime

Hypervisors (Xen), PaaS and FaaS, cluster managers (Kubernetes) and distributed actor frameworks (Akka, Erlang/Elixir/OTP) use resources of the underlying computer(s) to run guest applications. A hypervisor virtualizes resources of a single computer while a distributed runtime manages those of multiple servers — in that case there are several instances of the same kind of an internal server which abstracts a host system.

Interpreter [GoF] / 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, 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 over hundreds of chips for some reason called electronic control units (ECUs). The communication paths between the software components and much of the code are static and auto-generated. 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.

References

[GoF] Design Patterns: Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Addison-Wesley (1994).

[MP] Microservices Patterns: With Examples in Java. Chris Richardson. Manning Publications (2018).

[POSA1] Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal. John Wiley & Sons, Inc. (1996).

[POSA4] Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. Frank Buschmann, Kevlin Henney, Douglas C. Schmidt. John Wiley & Sons, Ltd. (2007).