nyssr.net is a real alternative to RESTful microservices

Microservices and nanoservices in nyssr.net are a very good alternative to RESTful microservices. They have an API similar to a RESTful API, but it is easier and more flexible to use. Most importantly, the services offer much more functionality than REST, which is due to the protocol.

But nyssr.net is more than just a server for one microservice. nyssr.net is a mesh of nodes that can provide thousands of services of various types in a distributed manner. The network is a backbone suitable for a complete company, uniting data sources in different countries and continents in one service mesh. Each service can use other services, even if this service is very far away behind firewalls, without any preparation or configuration.

• Node

  nyssr.net consists of one or many nodes. Nodes are small Java micro-kernels that load and execute services via plugin. They are not limited to one or a few services. Nodes usually run many services simultaneously. These services are often much smaller than on RESTful platforms.

  • No web server is required for each service.
  • One node can provide hundreds of services simultaneously.
  • Communication is faster than with RESTful platforms.
  • Communication is not limited to requests.
  • Communication is asynchronous.

  In addition, most services are loaded on multiple nodes at once to take advantage of the scaling and redundancy provided by automatic load balancing.

• For small services as well

  Services offered should be small, universal and reusable so that "the wheel is not reinvented over and over again". Thanks to the high-performance and simple connection, services can be cut smaller than before. And because service discovery is built in without any configuration, it's easy for programmers to use.

  The motto is: make the interface small, and make the service so good that it doesn't need to be touched again.

• Distributed network

  nyssr.net serves as a closed platform for services for enterprise-wide IT. The node network also makes remote and inaccessible services available. Services can be distributed throughout the node network. It does not matter to the programmer where a service is executed, since service resolution and routing to the appropriate node is done automatically by the system.

  Typical applications in nyssr.net often consist of only a first service, which uses further services.

  Even in UI applications, the principle applies. RemoteSkin is a technique where windows, dialogs and parts of them communicate with the user interface completely independently of the current application. Each dialog is then a microservice that independently renders the output on the client. The client UI communicates directly with the service. UI components are created, deployed, and maintained independently of the main program. And they are also used by multiple applications.

• Protocol

  Unlike REST, the protocol is not based on HTTP. Rather, they are object-to-object messages, with multiple support for service resolution and distribution through registries and indexes.

  Messages are transported between nodes over open TCP channels. This eliminates the need to establish a connection with a security handshake. The routing ensures that the fastest connection to the target node is selected. Messages can be prioritized. They natively support compression and encryption. They do not need to be parsed (like JSON or XML), so they are performant. Getter and setter provide convenience. Of course, you can still send anything with it, including JSON, XML, serialized objects, etc., if you need to.

  Messages are automatically sent back from the receiver to the sender after handling (requests), unless the sender omits this (notifications). The central mechanism is the handshake, and not the queue with message persistence. This ensures security in a distributed network. In addition, information about the state of the network is constantly updated and distributed. Each node knows the state of every other node in the network. And services can decide what actions to take when another service is eliminated.

  Objects are completely free to send messages directly to other objects, across the network to distant nodes. No configuration is required for this. This gives the programmer unimagined freedom.

  Then, on top of the protocol, there is everything you need for messaging. Observer, Hooks, Notifications, Nanoservices, Broadcasts, Forwarding, Blocking, Monitoring, Hierarchical State Machines, all available.

• 100% asynchronous

  nyssr.net does not waste resources on waiting. Sending messages is asynchronous, the response will come back at a later time. Since everything happens in parallel, CPUs and cores are also completely utilized. Or the other way around: Even small computers with several cores perform as much as otherwise much larger and more expensive units. In addition, distributed working on small nodes scales much better than monoliths on large machines.

• Scaling

  nyssr.net is a distributed network. Instead of running multiple servers with the same monolith, scaling here is done at the service level. While rarely used services are executed on only one or a few nodes, frequently used services can be distributed across many nodes. Automatic load balancing ensures that the load is handled. And instead of using expensive machines, simple, cheap computers in larger numbers are sufficient here.

• Easy to learn

  All the user code is just a reaction to some message. This makes the code clear (only targets with message handlers). New employees learn to code very quickly and become productive immediately. Small teams work independently of other teams - i.e. also asynchronously. You do not need build pipelines for microservices of nyssr.net. That leaves more time for creativity. And you need less time to launch your software on the market.

• Creativity growth

  The most important thing is to scale your creativity. This is because you don't have to test the entire work every time you make a change, as you do with monoliths. Form small teams to which you assign their own nodes. There you can offer, update and monitor services for a topic area. They avoid the large coordination effort in monoliths. And you avoid the big deployment deadlines because the protocols support different version of APIs. This way, each team can upgrade their software when the time comes.

• Start with one or a few nodes

  The position of microservices in the network is completely variable; it does not change the work. Initially, a single node can load and run all services as plugins. Later, as the network and workload grows, more nodes can be added and services freely distributed among the nodes. This does not require any additional work, because the mechanisms of messaging remain the same.

• Conclusion

  Building a distributed application with multiple web servers is a technique of the past. And putting each service in a container and behind a load balancer doesn't make it any better. Using a dedicated server for service discovery, connecting to that server, and then using a service is cumbersome and much too slow. It's time for a paradigm shift. Distribution and global private networks are the way of the future.