In Approach 1, the choice of management services to be deployed to each server is managed through Puppet. The advantage in this approach is that server automation teams can control both the server configuration and the selection of management tools through the Puppet master server. But as other users, such as tools experts and operations teams, still rely on the Intigua console to define, test, and troubleshoot management services, this approach may end up causing significant overhead. With this approach, operations such as tuning agent resource limits or testing a new management service require switching back and forth between using Intigua and Puppet. In choosing this approach, make sure that tools experts and operations teams will have this level of access to Puppet.
In Approach 2, there is a much more well-defined separation of roles and responsibilities, as Puppet handles the server configuration and Intigua handles server management tools based on Puppet-controlled metadata. The advantage in this approach is that each IT user can use the best suited console for the task, with all actions and configurations visible to other authorized users. This is important when you consider the large array of potential tools, server roles, and configuration states that are required across physical, virtual, and cloud-based infrastructures. Separating server configuration from tool configuration simplifies the overall number of possible class combinations, and thus minimizes the daily workload of both server-oriented and operations-oriented teams.