Pre-proposal for a WG: Multi-modal dev services

[holly-cummins]

I don't think this is ready for a working group, not least because #49 is still going, but I want to get a few thoughts down in a place where we can add to them.

The problem

For users in restricted environments, such as banks, most dev services just don't work. A container runtime isn't allowed, which means any dev service that uses containers can't run. The only dev services that can work are ones which don't rely on containers, such as H2 and Amazon Lambda. This is a real shame, because dev services are fantastic.

We offer some workarounds to missing container runtimes, such as using Testcontainers cloud instead of a local container runtime, but no generalised solution.

The inverse problem that also turns out to be a problem

We also occasionally get requests to allow dev services that don't run in containers to run in containers. For example, sometimes it's desirable to have the AWS Lambda dev service run in a container so that it can access the docker shared network

Ideas for solutions

At the moment, every dev service has to be either "container" or "not-container," each of which has drawbacks. What if a dev service could provide multiple implementations, and the Quarkus runtime would select the most suitable one for the environment? For example, an extension's processor could return a prioritised list, with attached conditions for each option (isContainerRuntimeAvailable(), etc).

Here are are some possible implementations:

• Java (internal or external process). Some services, such as H2 and Lambda, run this way at the moment. It's performant and robust but only a few services have Java implementations.
• Container. Obviously, this is great when it's available. It's easy to customise the image, it's robust, it's portable.
• Compose script. Some services do better with a compose script rather than a container so that configuration can be richer. At the moment we have some support for prioritised selecting between those two.
• Shell script (external process). This is tricky to get right, and non-portable, but it could be a fallback for the most popular services, such as postgresql. A service's availability would have to be declared per operating system and architecture, rather than as a global statement.
• WASM. @andreaTP has done some really cool things using the Chicory WASM runtime to run the SQLite database as an embedded process in Java. WASM provides a secure sandbox, and Chicory allows that sandbox to be embedded in Java. This model could be extended (with work!) to build WASM versions of other services. For example, there are WASM implementations of postgresql and MySQL. There is a performance penalty for running in a WASM sandbox, but that's probably acceptable if it's the difference between "working' and "not-working".

It's worth noting that we also have a related problem, "should this dev service start a new container or re-use a compose container or or re-use an external service?" We've solved this on an ad-hoc basis per service by doing discovery and chaining, but that implementation could fit neatly into a the "prioritised list of suppliers + metadata" solution.

cc @cescoffier @ozangunalp

[andreaTP]

Great write up @holly-cummins !

Regarding WebAssembly (WASM), yes, it’s definitely feasible, though the complexity and trade‑offs depend on the service in question. Take running PostgreSQL, for example: porting it to WASI is ongoing and involves some effort .

For completeness, it is possible to run containers via WASM using projects like container2wasm.
However, this approach is experimental. On my machine, booting an Ubuntu container takes around 30 seconds, potentially acceptable for CI pipelines but too slow for local development (as of today).

Happy to help and support this great initiative.