Plugin / Microkernel Architecture

The idea in one minute

A microkernel or plug-in architecture has two kinds of component: a core system that contains only the minimal functionality needed to run, and plug-in modules that add specialised behaviour. Plug-ins must stay independent of each other. The core finds them through a registry and talks to them through contracts, and Mark Richards advises deciding a contract versioning strategy at the start.^[1]

The name comes from operating systems, where microkernels such as Mach, L4, QNX and MINIX 3 run drivers and file systems outside the kernel so a crashed service can be restarted without a reboot.^[24] In application design the same shape appears as Fowler’s Plugin pattern: implementations linked at run time through configuration rather than at compile time.^[25]

When it fits

Richards rates the style high on agility, deployment, testability and performance, and low on scalability and ease of development.^[1]

The design decisions

Contract and versioning

• Separate contracts package. Microsoft’s plugin tutorial puts the interface in its own library so it can be published as a package.^[2]
• Semantic version ranges. OSGi distinguishes consumers from providers: a provider of an API should import it with a narrower range than a consumer.^[18]
• API stability markers and verification. IntelliJ marks internal, experimental and scheduled-for-removal APIs and ships a Plugin Verifier that checks binary compatibility across IDE versions.^[16]
• Compatibility declared up front. VS Code requires an engines field;^[9] IntelliJ uses since and until build ranges.^[15]

Discovery

Plug-ins describe themselves in a manifest that the core reads before loading any code. Eclipse plug-ins declare contributions to named extension points;^[17] IntelliJ does the same in plugin.xml;^[13] VS Code uses package.json with contribution points and activation events;^[9] .NET’s MEF scans a directory and matches parts to imports by contract.^[5]

Loading and isolation

• .NET: one AssemblyLoadContext per plug-in, with a dependency resolver that reads the plug-in’s own dependency file, so plug-ins can carry conflicting versions of libraries.^[2]
• Share the contract, or types will not match. The contracts assembly must load once, from the default context; otherwise the same type loaded twice is two different types.^[3]
• A load context is not a security boundary. Untrusted code cannot be safely loaded into a trusted .NET process.^[2]
• Unloading is cooperative. A collectible context stays alive while anything still references it.^[4] IntelliJ’s dynamic plugins have the same constraint: one leaked reference forces a restart.^[14]
• Process isolation for anything risky. VS Code moved its extension host into a separate process so misbehaving extensions do not affect the editor.^[6][7]

Lifecycle and activation

OSGi bundles move through installed, resolved, starting, active and stopping states, and can activate lazily on first use.^[19] VS Code activates extensions on events (a command, a file type, a workspace pattern) and discourages activating on startup.^[8] Lazy activation keeps start-up fast when dozens of plug-ins are installed.

Trust

VS Code states that extensions run with the same permissions as the editor itself, and relies on marketplace scanning, signing and publisher trust.^[11] In engineering tools, signed plug-in manifests serve the same purpose: EB tresos plug-ins ship signature manifests in META-INF.^[23]

Data, not code, for UI

VS Code’s settings contributions are declared as schema-like data that the editor renders without running extension code.^[10] For a configuration tool this is the model to copy: plug-ins declare parameter definitions; the core renders the editor.

Worked example: a configuration tool

An illustrative C# sketch for device families delivered as plug-ins.

// Contracts package: shared, loaded once from the default context
public interface IDeviceFamilyPlugin
{
    string FamilyId { get; }                                         // "acme.ecu.bms"
    IReadOnlyList<ParameterDefinition> GetParameters(DeviceVariant variant);
    IEnumerable<ValidationIssue> Validate(IConfigurationSnapshot config);
    IDeviceTransport CreateTransport(TransportOptions options);       // a port, as in hexagonal
}

public sealed record ParameterDefinition(
    string Key, string DisplayName, ParamType Type,
    object? Default, object? Min, object? Max, IReadOnlyList<string>? Choices, string Group);

// Host: one load context per plug-in, contracts forced to the shared copy
sealed class PluginLoadContext(string pluginPath) : AssemblyLoadContext(isCollectible: true)
{
    private readonly AssemblyDependencyResolver _resolver = new(pluginPath);

    protected override Assembly? Load(AssemblyName name) =>
        name.Name == "Acme.Configurator.Contracts" ? null      // use the host's contracts
        : _resolver.ResolveAssemblyToPath(name) is { } path ? LoadFromAssemblyPath(path)
        : null;
}

{
  "id": "acme.ecu.bms",
  "version": "2.3.0",
  "entryAssembly": "Acme.Bms.Plugin.dll",
  "contract": ">=3.1 <4.0",
  "families": ["BMS-G2", "BMS-G3"],
  "activation": ["onDeviceDetected:0x1A2B", "onProjectContains:*.bmscfg"]
}

The core reads the manifest, rejects incompatible contract ranges before loading anything, and activates the plug-in only when a matching device or project appears. A plug-in that wraps a native vendor driver runs in a helper process and talks to the core over IPC instead.

Where it is used in practice

• EB tresos Studio (AUTOSAR ECU configuration) is built on Eclipse and extended with plug-ins.^[22] Texas Instruments ships its microcontroller drivers’ configuration as tresos plug-ins: parameter definitions, presets, code-generation templates, signature manifests and a plugin.xml, copied into the tool’s plugins folder.^[23] This is the same pattern applied to exactly the kind of tool this article is about.
• Eclipse describes plug-ins as structured bundles that contribute functionality at well-defined extension points.^[17]
• VS Code combines a separate extension host process, activation events and signed marketplace packages.^[6][11]
• IntelliJ Platform offers extension points, dynamic loading and automated compatibility verification.^[13][16]

How it relates to other styles

• Hexagonal / Clean. Any device that follows a port’s protocol can be plugged into it;^[20] frameworks and drivers are outer-ring details.^[21] A plug-in is an adapter that ships separately and loads at run time. The difference: hexagonal adapters usually face infrastructure, while plug-ins usually carry domain variability, so their contract sits at the domain boundary and must be designed as a public API.
• Modular monolith. Both are one deployable with internal parts. Modules are compiled in and versioned together; plug-ins are discovered at run time, versioned independently and may come from third parties.

Gains and costs

How it goes wrong

1. Contract designed too early. The variability axis was not understood, so the contract changes with every new family.
2. Plug-ins depending on plug-ins. Independence breaks and load order starts to matter.
3. The core as a god object. Everything that does not fit a contract lands in the core, which becomes a service locator for everything.
4. In-process vendor code. A crash or leak in one native driver takes down the whole tool or blocks unloading.^[4]
5. Eager activation. Every plug-in starts at launch and start-up time grows with each family.^[8]
6. No compatibility checks. Old plug-ins load against a new core and fail at run time instead of being rejected up front.

Testing a plug-in system

Origins

• Operating systems: microkernels moved drivers and services out of the kernel; the architectural style borrows the name and the idea.^[24]
• 2002: Fowler documents the Plugin pattern in Patterns of Enterprise Application Architecture.^[25]
• 2000s: Eclipse builds a whole IDE platform on plug-ins and OSGi bundles, later the basis of engineering tools such as EB tresos Studio.^[17][22]
• 2015: Richards describes the microkernel as one of five core architecture patterns.^[1]
• 2022: VS Code completes the move of extensions into a separate process for stability.^[7]