A completely different platform for nano- and microservices
Nodes have an ID (here moon/planet names).
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
A small network of nodes with plugins
In the
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
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
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
The intention of the design of
A Java application typically consists of a variety of modules and functions that are statically linked in.
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