Nomirun architecture

1. Non-generic host service architecture

If you do not use a generic host to run your modules, you’re normally building services like this.

Your services or applications contain business logic (in modules or not) and then all the application infrastructure like tracing logs, metrics, health and points, caching, swagger documentation, configuration, service discovery, throttling and similar.

With Nomirun, your application infrastructure is abstracted away in a generic host - Nomirun Host.

On the side, there is a Nomirun CLI to support your workflows and tasks.

What you get with this is not only less boilerplate code for your services, but Nomirun modules and hosts are working hand in hand to give you flexible options to run Nomirun Host as modular monolith or microservice.

2. Nomirun Host as Modular monolith

You can start by building different Nomirun modules that you think might be appropriate for your use cases.

You can always create or split up modules into multiple modules or merge modules depending on the findings of your domain you’re working in.

Once you are happy with your modules, you can bundle them in the modular monolith and run it like this in a single Nomirun host.

After deploying to production, you might see that you want to break things down a bit to lower the memory consumption of your pods. There might be other reasons for you to do that.

3. Nomirun Host as Microservice

If you want to break the module monolith into three separate microservices, you can do this easily by running a Nomirun CLI and Configure three different Nomirun hosts.

No compilation or service changes are needed. You need to configure it differently.

What you do need to change is your deployment scripts, because now you have three services instead of one. But in any case, you’re only changing the configuration, which is a quick job.