The XP runtime powers XP applications
The runtime uses the OSGi module system to isolate each module (aka bundles) - and controlling the ability to communicate between them. XP Applications essentially work like any other system modules - with their own life cycle and ability to install, start, stop and uninstall.
This is also important from a development perspective. Since the XP runtime is multi-threaded, developers also benefit from a simplified development model, debugging, and the ability to run threaded operations when needed. XP’s task engine for instance runs all tasks as separate threads.
The XP runtime also enables you to run multiple applications in a single runtime. Each application may be built, installed, started and stopped independently - and even cooperate on progressing a single request. This can for instance be seen in the HTTP engines and their execution pipeline. This basically means that most XP apps consume very little resources beyond the actual processing, and that a single runtime may potentially contain many applications - similar to a serverless architectures.
The XP runtime is capable of running in both stateful (using the embedded NoSQL storage) and stateless mode. A single instance deployment will do both, but a clustered deployment may for instance be split into back-end and front-end nodes.
XP can easily be scaled by setting up a cluster of runtime nodes. It can run in virtually any infrastructure, and also be managed by Kubernetes or similar container orchestration engines for automatic scaling and more.
The runtime provides a management API, that amongst others support as installation of apps, dumping and loading data. This is commonly accessed using the Enonic CLI.
Additionally, the runtime also exposes a metrics API, providing access to runtime statistics. Like many other parts of XP, the metrics API may easily be extended with XP apps, and provide additional data as needed.