Arquitecturas de microkernel y de plug-ins

Definición y origen

Una arquitectura de microkernel, también llamada arquitectura de plug-ins, divide una aplicación en dos tipos de parte: un sistema central (core system) que contiene la funcionalidad mínima y general necesaria para funcionar, y plug-ins que añaden o cambian comportamiento sin que se modifique el núcleo. Los plug-ins se conectan al núcleo solo mediante contratos publicados, y el núcleo los localiza a través de un registro. Mark Richards y Neal Ford la catalogan como uno de los estilos arquitectónicos clásicos en Fundamentals of Software Architecture, y encaja con la descripción de estilo arquitectónico dada en la Sección 5.1: un conjunto con nombre de restricciones sobre los elementos (núcleo, plug-ins) y los conectores (contratos) de un sistema.

La idea nació en el software de producto: herramientas que instalan muchos clientes, cada uno de los cuales quiere algo ligeramente distinto. En lugar de mantener una versión separada para cada cliente, el proveedor distribuye un solo núcleo y deja que los clientes, los socios o los propios equipos del proveedor añadan plug-ins. Los entornos de desarrollo integrados, los navegadores web, los editores gráficos y los paquetes de contabilidad funcionan así. El nombre se toma de los sistemas operativos, donde un microkernel es un núcleo muy pequeño con todo lo demás ejecutándose fuera de él; las dos ideas están relacionadas, pero no deben confundirse, como se explica más adelante.

Una aplicación de microkernel suele ser una única unidad de despliegue, así que pertenece a los estilos monolíticos de este capítulo: una unidad de despliegue, un proceso, un conjunto de inquietudes operativas. Los plug-ins pueden instalarse por separado, pero en tiempo de ejecución viven dentro del núcleo o justo a su lado.

Cómo funciona: núcleo, plug-ins, registro y contratos

El sistema central contiene lo que necesita toda instalación: el flujo de trabajo principal, servicios compartidos como el logging o la configuración, y los puntos de extensión donde se acoplan los plug-ins. Richards y Ford lo describen como el camino feliz a través de la aplicación, con poco o ningún procesamiento personalizado; en el proceso de pago de una plataforma de reparto de comida, eso es poner precio a un carrito, cobrar el pago y confirmar el pedido. Un buen núcleo es deliberadamente aburrido. Cada caso especial que varía según el cliente, el país o la línea de producto es candidato a salir de él.

Los plug-ins son módulos independientes y autocontenidos que contienen procesamiento especializado. Deben depender solo del contrato, no unos de otros ni de las clases internas del núcleo. Cuando un plug-in necesita algo que proporciona otro, esa necesidad debe cubrirla el núcleo (como un servicio que expone a través del contrato) o bien hay que fusionar los dos plug-ins; las dependencias de plug-in a plug-in convierten sin hacer ruido una estrella limpia en una maraña.

El registro anota qué plug-ins están disponibles, cómo se llama cada uno, qué versión es, qué contrato implementa y cómo llegar a él. Puede ser tan sencillo como un diccionario rellenado al arrancar, un directorio en el que el núcleo busca manifiestos, entradas en los metadatos de un paquete (como con los puntos de entrada de Python), una tabla de base de datos o un servicio remoto que lista plug-ins desplegados en otro lugar. El registro es lo que permite al núcleo decir "dame las normas fiscales de Alemania" sin saber que existe una clase llamada GermanTax.

Los contratos definen qué debe proporcionar un plug-in y de qué puede depender: una interfaz con firmas de métodos, las estructuras de datos que la cruzan, el comportamiento ante errores y una versión. En Eclipse, un contrato es un punto de extensión declarado en el manifiesto de un plug-in con un esquema; en Visual Studio Code es la API de extensiones más los puntos de contribución enumerados en el package.json de una extensión; en tu propio código suele ser una interfaz (o un Protocol de Python) en un pequeño paquete propio. Cuando el plug-in procede de otra organización y no puede seguir tu contrato, un adaptador traduce entre ambos, exactamente como en la arquitectura hexagonal.

Los plug-ins pueden conectarse de tres maneras. Las llamadas punto a punto, en proceso son lo habitual: el núcleo llama a un método del objeto plug-in. Los plug-ins en un proceso separado se ejecutan en su propio proceso y hablan con el núcleo mediante mensajes entre procesos, lo que protege al núcleo de los bloqueos. Los plug-ins remotos están detrás de una interfaz HTTP o de mensajería; esto permite plug-ins en otros lenguajes o de otros equipos, pero añade latencia de red y modos de fallo, y el sistema empieza a parecerse a los estilos distribuidos del Capítulo 6.

Ejemplos reales

Eclipse. El IDE Eclipse es el caso de manual. Su núcleo es poco más que un banco de trabajo y un entorno de ejecución de plug-ins (construido sobre Equinox, una implementación de la especificación del framework OSGi). Casi todo lo que ve un desarrollador, desde las herramientas de Java hasta la integración con el control de versiones, es un plug-in. Cada plug-in tiene un manifiesto que declara lo que necesita, qué puntos de extensión ofrece a otros y a qué extensiones se conecta. Los plug-ins se activan de forma diferida, solo cuando algo los necesita de verdad, para que cientos de plug-ins instalados no ralenticen el arranque.

Visual Studio Code. Las extensiones declaran eventos de activación (abrir un archivo Markdown, ejecutar un comando) para cargarse solo cuando hace falta, y aportan comandos, lenguajes, temas y vistas a través de su manifiesto. Las extensiones se ejecutan en un proceso anfitrión de extensiones separado, de modo que una extensión que se comporta mal no puede congelar la interfaz de usuario del editor. Es un buen ejemplo de elegir el aislamiento por procesos para un ecosistema de plug-ins que incluye miles de autores externos.

Navegadores web. Las extensiones de navegador usan un conjunto estándar de API de extensiones y deben declarar en un manifiesto los permisos que necesitan (qué sitios pueden leer, si pueden ver las pestañas o las descargas). El navegador hace cumplir esos permisos, porque por defecto no se puede confiar en los autores de extensiones.

Motores de reglas de negocio. El sistema de siniestros de una aseguradora puede mantener el flujo de trabajo de los siniestros en el núcleo y poner las normas de cada jurisdicción (qué está cubierto, qué documentos se necesitan, los plazos legales) en plug-ins. Los motores fiscales, los sistemas de nóminas y las plataformas de comercio electrónico con plug-ins de métodos de pago siguen el mismo patrón: un proceso estable, con normas o proveedores que varían según el país, el producto o el cliente.

Herramientas para desarrolladores. El framework de pruebas pytest está construido en torno a la biblioteca de plug-ins pluggy; muchas de sus propias funcionalidades están implementadas como plug-ins que usan los mismos hooks que usan terceros. Las herramientas de compilación, los linters y los generadores de sitios estáticos suelen hacer lo mismo.

Aislamiento, versionado y compatibilidad de los plug-ins

Tres preguntas deciden si una arquitectura de plug-ins se mantiene sana con los años: cuán aislados están los plug-ins, cómo evoluciona el contrato y cómo se detecta la incompatibilidad.

Aislamiento. Los plug-ins en proceso comparten la memoria, los hilos y los permisos del núcleo. Eso es rápido y sencillo, pero un plug-in con un bucle infinito, una fuga de memoria o un agujero de seguridad afecta a todo. Las opciones, de menor a mayor aislamiento y costo, son: en proceso con llamadas defensivas (timeouts, captura de excepciones por plug-in, límites de recursos); un proceso o worker separado por plug-in o por grupo de plug-ins; un sandbox, como un entorno de ejecución de WebAssembly o un intérprete restringido, que limita lo que puede tocar el código del plug-in; y un servicio remoto. Elige preguntándote quién escribe los plug-ins. Las normas fiscales de tu propio equipo pueden ejecutarse en proceso; el código arbitrario de un marketplace público no debería.

Versionado. El contrato es una API, y se aplican las reglas de la Sección 0.6 sobre los cambios incompatibles. Versiona el contrato por separado del núcleo, normalmente con versionado semántico: una nueva versión principal para los cambios incompatibles y una versión menor para las incorporaciones compatibles hacia atrás. Deja que cada plug-in declare para qué versión del contrato se construyó, y que el núcleo declare qué versiones admite. El cambio aditivo (campos opcionales nuevos, hooks opcionales nuevos) mantiene funcionando los plug-ins antiguos; cuando un cambio incompatible es inevitable, admite la versión principal antigua y la nueva en paralelo durante un periodo de obsolescencia anunciado.

Comprobaciones de compatibilidad. Comprueba la compatibilidad cuando se cargan los plug-ins, no cuando un cliente los activa por primera vez. Un registro que rechaza un plug-in incompatible al arrancar, con un mensaje de log claro, convierte un error en tiempo de ejecución en un fallo de despliegue. Merece la pena recordar aquí la observación de Hyrum Wright, conocida como ley de Hyrum: con suficientes usuarios, alguien dependerá de cada comportamiento observable de una interfaz, diga lo que diga la documentación. Mantén el contrato pequeño, deja las partes internas del núcleo fuera de alcance (Eclipse marca como internal los paquetes que no son API por esta razón) y trata todo lo que ven los plug-ins como parte del contrato.

Cuándo usarlo y cuándo no

Buenos casos. Software de producto que muchos clientes instalan y personalizan. Sistemas con un flujo de trabajo estable pero muchas variantes de un paso: impuestos y nóminas por país, normas de seguros por jurisdicción, métodos de pago, importadores de formatos de archivo, empresas de transporte. Plataformas que quieren un ecosistema de terceros. Sistemas en los que un regulador o un cliente cambia las normas a menudo y quieres que esos cambios sean lanzamientos pequeños y probados por separado. El estilo también funciona dentro de un sistema mayor: un servicio de una arquitectura distribuida puede ser en sí mismo un microkernel.

Malos casos. Sistemas en los que aún no sabes qué varía. Los puntos de extensión diseñados de antemano para necesidades imaginadas son generalidad especulativa: añaden maquinaria, frenan al equipo y suelen estar en el lugar equivocado cuando llega la necesidad real (consulta el análisis de la reversibilidad en la Sección 1.6). Sistemas que necesitan una escalabilidad o un aislamiento de fallos muy altos, ya que todo escala y falla como una sola unidad. Sistemas en los que los plug-ins tendrían que coordinarse estrechamente entre sí, lo que anula el principal beneficio del estilo.

Una regla práctica: espera a haber construido el mismo tipo de variación dos o tres veces y, entonces, extrae el contrato de los casos reales. Un contrato derivado de tres implementaciones fiscales que funcionan será mucho mejor que uno adivinado antes de la primera.

# package: tax_contract  (version 2.1.0)
from dataclasses import dataclass
from decimal import Decimal
from typing import Protocol

CONTRACT_VERSION = (2, 1)

@dataclass(frozen=True)
class TaxLine:
    sku: str
    category: str      # "hot-food", "cold-food", "alcohol", "delivery-fee"
    net: Decimal       # never float for money

@dataclass(frozen=True)
class TaxResult:
    total_tax: Decimal
    breakdown: dict[str, Decimal]   # label shown on the receipt

class TaxRules(Protocol):
    country: str                    # ISO 3166-1 alpha-2, e.g. "DE"
    requires_contract: tuple[int, int]
    def calculate(self, lines: list[TaxLine], region: str | None) -> TaxResult: ...

from importlib.metadata import entry_points
from tax_contract import CONTRACT_VERSION

class UnsupportedCountry(Exception): pass

class TaxRegistry:
    def __init__(self, log):
        self._by_country = {}
        for ep in entry_points(group="fooddelivery.tax_rules"):
            plugin = ep.load()()
            major, minor = plugin.requires_contract
            if major != CONTRACT_VERSION[0] or minor > CONTRACT_VERSION[1]:
                log.warning("skipping %s: needs contract %s", ep.name, plugin.requires_contract)
                continue
            self._by_country[plugin.country] = plugin

    def for_country(self, country):
        if country not in self._by_country:
            raise UnsupportedCountry(country)   # fail loudly, never guess a rate
        return self._by_country[country]

Hacer cumplir el estilo en el código

Una arquitectura de plug-ins solo sigue siéndolo si sus reglas se comprueban automáticamente. La estructura que funciona en la mayoría de los lenguajes tiene tres tipos de paquete: un pequeño paquete de contrato, solo con interfaces y tipos de datos; el núcleo, que depende del contrato; y un paquete por cada plug-in, que depende del contrato y de nada más de lo tuyo.

Después, haz cumplir las reglas de dependencia con herramientas como las que se tratan en la Sección 3.4: en Python, import-linter puede prohibir que el núcleo importe cualquier paquete de plug-in y que los plug-ins se importen entre sí o importen el núcleo; en Java, las pruebas de ArchUnit o los sistemas de módulos (JPMS, OSGi) pueden hacer lo mismo. Haz fallar la compilación cuando se incumpla una regla.

Añade un conjunto de pruebas de contrato: un conjunto de pruebas escritas una sola vez contra el contrato y ejecutadas contra cada plug-in en el pipeline propio de ese plug-in. Comprueba el comportamiento que promete el contrato (redondeo, entrada vacía, tipos de error), no la ley fiscal de cada país, que cubren las pruebas propias del plug-in. Por último, añade una comprobación al arrancar o una prueba de humo del despliegue que cargue cada plug-in instalado y verifique su versión de contrato, para detectar las incompatibilidades antes de que las encuentren los usuarios.