Basically, resource pools are nothing bad. They are often used in the service provider area. vCloud Director, for example, uses RP excenssively and vRealize Automation sometimes uses them as well. They can simplify resource management by eliminating VM-level resource micromanagement. On the other hand, they can also make all resource management within a cluster more complex, depending on how far you nest it and there are also some pitfalls. Furthermore, you only profit from RP in some cases.
In my opinion, resource pools are always useful when you have an overcommited cluster with many different workloads with different resource requirements and want to separate them. This doesn't apply to many enterprise setups. Either there are not many VMs running, so that you can configure the resource management (shares, limits, reservations) for single VMs at VM level, or all VMs are equally important, then the default values are sufficient. Or the cluster resources are not overcommited and then you have no advantage from resource management, because each VM always gets the resources it wants. I think for these reasons, there is not much positive information about resource pools. And sometimes they make things more complex. But I'll come to that below.
In your case, using resource pools can be a good idea if you talk about resource conflicts. But I would make 2 resource pools on the same level. One for DEV and one for PROD. With shares, you can control that PROD VMs get more resources when the cluster is busy. But shares are a double-edged sword because they are not really a fixed number. The share value depends on the number of VMs in this RP and is also compared with other RPs on the same level. This is usually overlooked.
For example: If you have set the shares for DEV to 1000 and 10 machines are running there, each VM gets 100 shares. And if you have a PROD RP with 2000 shares and 40 VMs, each of these vm only get half the shares of a DEV vm (50 shares). In reality, you have to adjust the share value every time you power a virtual machine on or off.
This makes the management of resource pools sometimes complex and is one of the reasons why RP are so unpopular.
And in case of resource overcommitment and contention, I'd also consider using reservations. Of course it's uncomfortable if the developers can't work anymore, but usually it's worse if external customers are affected. The only important thing with reservations is that you don't set them too high.
The golden rule is:
Set the reservation value so high (or low) that the VMs can still handle their task and not to a value what they normally consume. The rest of their resource demand is then covered with the higher shares setting. Because if you set the reservations too high, you will lose too much flexibility.
To sum it up:
- Resource pools simplify resource management by eliminating resource micro management at VM level.
- Resource management is only necessary if the cluster is overcommited and resource conflicts occur.
- Reservations can be useful, but should not be set too high.
- If you have multiple RP on the same level, shares on RP are not fixed values but have to be adapted to the number of running VMs to be effective.
- Limits can help to cap the resource consumption.