On the surface, Puppet and JetPatch have some similar capabilities. Notably, Puppet and JetPatch can both be used to deploy server management tool agents to individual servers. However, IT architects should be aware that there are important differences between these technologies. An explanation of some of these differences can help explain the benefit of integrating JetPatch and Puppet in your organization.
Puppet uses a modular scripting system as an effective way for pushing out server configurations and software packages, and making sure that the configuration is preserved. Typical Puppet usage is based either on downloading open-source modules, such as Linux-centric software from PuppetForge, or on programming custom modules with Puppet’s Ruby-based language. Modules are pushed to each server separately, without particular regard to orchestrating the client and server sides of client-server systems. A command-line tool is the most common way of working with Puppet, and of observing server configuration and events. These are reported by default at 30 minute intervals.
JetPatch uses a proprietary method of pushing out and maintaining server management tool agents, whether the tool is agent-based or is agentless. This capability is tailored specifically for the particular needs of IT operations. Some of the unique capabilities offered by JetPatch are:
- Server management tools typically use a client-server architecture, where the agent acts as a client and reports to a management console server. With a standalone Puppet implementation, users can only automate the agent side, and often still require manual work or scripting hacks to work simultaneously with the console side. JetPatch automates the agent deployment as well as the process of registering and configuring the agent-console relationship. Another critical point is that after the initial deployment, JetPatch keeps agents and consoles in sync across all subsequent agent upgrades, server migrations, and other configuration changes.
- Some management tools, such as hypervisor-based backup products and some monitoring tools, don’t use agents at all. This type of tool has central servers that work and communicate with the managed servers without the need for an agent. JetPatch works with such tools too, continuously configuring them to manage each server according to organizational policy. Using the same framework for working with agent-based and agentless tools gives JetPatch users extra flexibility, helps standardize operational procedures, and avoids vendor lock-in.
- Management agents are notorious for failing at various stages of their lifecycle – with failed installations and updates, crashes during execution, and other issues. On an enterprise scale, with thousands of servers each running a few tools, even a meager 5% weekly fail rate is enough to keep IT in constant firefighting mode. JetPatch runs management agents inside its unique management container, which prevents many of these failures from ever taking place, and automatically fixes most failures that do occur. To address any failures that are not automatically resolved, JetPatch offers centralized, role-based diagnostic access that helps operations teams tackle the issues effortlessly.
- Management agents are also notorious for adversely affecting their hosting servers and applications. For example, an agent bug can cause memory overuse to the point of crashing the entire server, along with the application software that it is running. JetPatch's management container separates agent resources from application resources, establishing clear limits to what agents can do on a server. Application engineers can now be assured that agents are no longer a threat to servers stability.
In addition to adding these unique technical abilities, JetPatch’s focus on making server management tools ‘just work’ allows JetPatch to offer a highly-optimized user experience tailored for enterprise IT operations. For example:
- Highly-functional and easy to use web console interface, with fine-grained role-based access that lets each user view IT operational states, and act on them as allowed by security settings.
- Ready-made packaging of a variety of Linux and Windows. JetPatch can run on older operating systems too, such as Windows 2003 R2 and Red Hat Enterprise Linux 5.5.
- Graphical self-service packaging tool allows users to create and maintain their own set of packaged management tools without the need for scripts.
In short, while Puppet is great for generic server configuration tasks, JetPatch complements it with highly-tailored technical and procedural capabilities that optimize server management. A solid DevOps strategy needs to pursue both of these routes to be successful.