Number of Neuron Instances - any rules of thumb?

Replies to This Discussion

Permalink Reply by Martin Wasznicky on May 24, 2018 at 7:21am

when using multiple instances, you should probably consider using port sharing on all instances.  that greatly reduces the port conflict issue...in essence, each instance just uses 1 TCP port assignment. 

• ▶ Reply

Permalink Reply by Christian Stærk on May 29, 2018 at 3:58am

Hi André

We have experience with several way to solve this and I think your main options are:

1. Run seperate instances on the same machine with a notion of "Application domains" and perhaps a common instance
2. Run single instances on multiple machines (VMs) and license the host as such.

Regarding 1.

This was the chosen setup at a financial client we had and we ended up with 5 instances.

In short, the setup was to seperate the Neuron instances into application domains and if one application domain needed to communicate with another application domain, this went through a common instance.

This way there was a clear seperation and this helped in parallel development and minimized the need for re-testing. At the same time you have a clear setup for re-using common functionality/endpoints.

This setup also has the benefit that you only need to define and agree on a business wide / common data structure for services in the common instance. Functionality and services in the applicaton domains can more freely use the data structures that make the most sense.

We have good experience with this setup and our client has been using this for the last 3 years. The only downside I can think of, is when you sometimes have to upgrade to a newer Neuron version. If this updates the discovery service then all instances need to be re-installed. Not sure if this is still an issue though.


Regarding 2.

If the different instances do not have to interact, this could also be a way to enable more parallel development.

Basically you license the physical host via a CPU license and the you run VMs on top of this physical host. Then each VM can have its own Neuron installation and the different teams can more freely control their own server.

This is a more clean setup, but the you end up having your integrations scattered across multiple servers. This could be both an advantage or disadvantage.


Some additional thoughts:
Categories: Using categories and the 'Category Filter' is also a great way to limit the number of visible artefacts in the Explorer. If you are using TFS or GIT for version control, parallel development is not really a big issue and then this could be a quick win if the main issue is not to clutter the Neuron Explorer?

Monitoring: It is not our experience that multiple hosts or instances make monitoring much harder. Whether you are monitoring one or more services should not have a big impact. But of course this depends on if you have built anything on top of it. For instance the status of all endpoints can be queried using Neurons built-in REST endpoints. On my current project we have exposed this to SCOM and a SquaredUp dashboard, so I am currently looking at the status on 21 test/qa servers :-)

Ports: As Marty mentions, just use port sharing. And otherwise it is quite easy to define different port ranges which we did on the project above, since the feature was not available at that time.

Just some quick input, hope it helps.

Kind regards,

Christian Staerk

• ▶ Reply

Permalink Reply by André Bach on June 1, 2018 at 6:31am

Thanks for the good responses both Christian and Marty.

• ▶ Reply