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 JetPatch 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 JetPatch 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 JetPatch 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.
Please sign in to leave a comment.