The microkernel architecture, or plug-in architecture, is a widely used monolithic system design architecture. It is commonly used for product-based applications, which are packaged and available for download and installation as a single, monolithic deployment. The microkernel architecture consists of a core system and multiple plug-in components.
Components
Core System
The core system of a microkernel architecture contains the set of features that offer minimal functionality of the application. It is the general processing flow through the application without any custom processing. This core system is extensible with plug-in components, and the maintenance, complexity, and client-specific customization are passed on to these plug-ins.
The core system can be implemented as a layered architecture or other monolithic architectures, or even split into separately deployable services, where each service has its own plug-in components. In either case, the core system typically shares a common database.
Plug-in Components
The plug-in components are standalone, independent components that contain additional processing and features to the core system of the application. They provide isolation for different components of the system, which increases overall maintainability and testability.
The communication between the core system and the plug-ins is usually point-to-point, meaning each plug-in is invoked through a function call from the core system to the entry-point of the plug-in. Alternatively, communication can be done using REST APIs or message queues, and in this case each plug-in could be a standalone service. Note that this does not change the monolithic nature of this architecture style, because every request must go through the monolithic core system.
Plug-ins can be runtime-based, meaning they can be added or removed at runtime without redeploying the system, or compile-based, meaning they require the entire application to be redeployed if they are added, modified, or removed.
Plug-ins typically do not directly connect to the shared database. Instead, they do so by going through the core system. However, plug-ins may have their own data stores that are only accessible to that specific plug-in. These data stores may be external or embedded in the plug-in as an in-memory or embedded database.
Key Properties
Plug-in Registration
The core system needs to known which plug-in components are available, which means that we need a mechanism to keep a registry of plug-ins. This registry contains information about each plug-in component, such as its name, data contract, and access protocol. The registry can either be an internal map structure owned by the core system or an external registration and discovery tool that is deployed separately.
Contracts
The contracts between the plug-in components and the core system are usually standardized across all plug-ins in a system. This contract includes the input data, output data, and expected behavior of the plug-in components.
Custom contracts can also be found, typically when third-parties develop the plug-ins. In this case, there is usually an adapter between the plug-in contract and the standard contract.
Trade-Offs
Advantages
- As with other monolithic architecture styles, the microkernel architecture is relatively simple and low cost to implement.
- Compared to other monolithic architecture styles (layered architecture and pipeline architecture), the microkernel architecture is more testible, deployable, and reliable. This is because functionality can be better isolated in independent plug-in components.
- Modularity and extensibility are also better in this architecture. Plug-ins can be added, modified, and removed independently.
Disadvantages
- Like other monolithic architecture styles, it is difficult to scale up each plug-in component because they are constrained by the scale of the monolithic core system.
- Fault-tolerance is also low because the core system is a single source of failure.
