A completely different platform for nano- and microservices

nyssr.net is a network of interconnected Java nodes using TCP channels to facilitate message exchange. Messages are routed through these channels, avoiding the need to establish new connections dynamically.

Nodes have an ID (here moon/planet names).

A small network of nodes with moon/planet names as ID

A small network of nodes with moon/planet names as ID

Each node is built around a nimble and quick-loading micro-kernel. This micro-kernel loads additional functionalities in the form of plugins during startup. Remarkably, even essential features like TCP or the transport layer are loaded as plugins, alongside various services and applications. The configuration file houses a list of all modules to be loaded, making it the determining factor for a node's capabilities and tasks. This approach ensures that when nodes are executed in containers, all containers remain identical.

A single node has the capability to load hundreds of plugins, making the deployment of new microservices swift and uncomplicated. Gone are the days of setting up new servers for each service; a mere addition to the plugin list suffices. Additionally, the scalability of nyssr.net is incredibly flexible, allowing it to consist of as few as one node or as many as a thousand, tailored to your specific requirements.

A small network of nodes with plugins

A small network of nodes with plugins

In the nyssr.net environment, any piece of code can send messages. However, only registered objects, referred to as "targets," are eligible to receive these messages. Upon registration, each target is assigned a unique address across the entire nyssr.net network. Consequently, messages can be sent to these objects from any location within nyssr.net.

Now, addressing the concern about object addresses needing to be universally configured, there are transport layers that operate atop the object-to-object messaging system. Microservices are registered under simple IDs, such as "database statistics." From this point onward, including this ID as the receiver in a message suffices. The system takes care of ensuring that the intended recipient, whether located on the same node or a distant one, receives the message, alleviating the need for extensive address configuration.

Sending a message with automatic microservice resolution and response

Sending a message with automatic microservice resolution and response

In the event of multiple microservices being registered under the same ID, the registry autonomously selects one instance as the recipient. This seamless load balancing operates throughout the entire nyssr.net ecosystem, eliminating the need for any additional software.

Introducing a new microservice is a straightforward process, achievable through a simple function call or by sending a message. Within a matter of minutes, the new service is ready for use, seamlessly integrated into the nyssr.net environment.

The intention of the design of nyssr.net was not to host a few microservices in a network. Rather, it should be possible to offer large amounts of services without effort and problems with addressing. These services should be much smaller than usual microservices.

A Java application typically consists of a variety of modules and functions that are statically linked in. nyssr.net now offers the possibility of operating these modules and functions as dedicated services so that similar applications in an ecosystem can use them together.

These small services can be written, maintained, and deployed separately from the applications.

The APIs of these services can be extended evolutionarily without necessarily having to update the clients at the same time. Therefore, flexible messages/events are used for communication.

At the same time, all services can be hosted on any nodes without the clients having to be informed of this by a configuration.

Redundancy ensures scalability and fault tolerance.

Neither topics, queues, nor similar things need to be configured.

Each message can be delivered point-to-point to one or more targets without configuration, network-wide. A response can be expected from each message if not otherwise desired.

The programmer thus has maximum freedom.

The system can be easily extended with more and more services without having to compile everything. Service owners can provide, maintain, and renew services independently of other people. The system is designed for fast development and minimal maintenance of its services.

Administrators have the flexibility to optimize nyssr.net through strategic TCP channel arrangements and plugin list configurations. New nodes can be seamlessly integrated at any time, ensuring scalability and adaptability as your needs evolve.