I have a question on how to choose the correct distributed architecture for devtest. Currently we have one central dashboard server and one central portal and registry server that will serve all teams using devtest. Each team gets its own vse or coordinator/simulator(s) to work with. These components are installed on separate (virtual) servers from the central server that hosts the central dashboard and registry.
The advantage was the simplicity of this approach and the fact we can handle user management from one central location. New users need to login once and user management will assign the correct roles having the correct resource groups/resources assigned to it.
We found that there are some drawbacks. First of all we created a single point of failure, the registry. I am not very happy about that. At the end we will always have the dashboard server as single point of failure. But as far as I can see now that will always be the case (or you could put multiple instances behind a load balancer, or have a cold backup).
The other drawback is that all coordinators that run under a registry communicate with each other. For all this communication we need to add rules to the firewall(s). This also creates a lot of unnecessary communication over the network.
Should we moving to an architecture where each team has its own registry/portal? A drawback from that approach would be we cannot do user management in one single registry/portal.
The customer does not want each team to manage its own users because of the fact there are license restrictions on the Max concurrent users. Giving that away to the individual teams might result in an explosion of users and the need for buying more concurrent users from CA.
I hope that somebody van comment on this. I need to convince the customer to adapt the approach of the multiple registries and I need to have a good explanation why we should do that. Some experiences from other implementations might help.