Our website relies on funding from our readers, and we may receive a commission when you make a purchase through the links on our site.
Comparing & Evaluating NPM Deployment Models
As environments become larger and more complex, the options for managing and monitoring performance across the full breadth of your infrastructure are improving in tandem. Multiple vendors have developed solutions for more or less managing physical and virtual servers, storage, network and applications all through a consolidated management interface. That’s wonderful, but if a performance management solution isn’t deployed easily or completely throughout the environment, those capabilities and benefits can be lost, reducing the value of the entire investment.
Deployment model is an often-overlooked criterion in evaluating performance management platforms from the different vendors. The deployment model utilized by different vendors can vary greatly from solution to solution and each model has nuances that can affect how quickly and completely they can start delivering on their initial platform promises. Often, we tend to think of ‘deployment’ as just the initial install, discovery and configure, but there are other important considerations at play. The deployment model of the performance management platform you go with can have longer term impacts that need to be considered up front.
Beyond just install, discovery and configuration time and complexity, other factors impacted by the deployment model of the vendor you’ve selected can include:
- Speed of deployment/time to operation
- Scalability
- Speed of reporting
- Impact on your existing infrastructure
- Security
- Up-front Cost
- Lifetime cost of ownership
Importance of Deployment Model
Let’s dive deeper into the various deployment models and have a look at the various considerations at play:
| Characteristic | Description, Value & Considerations |
|---|---|
| Speed of Deployment/ Time to Operation | How quickly can the solution be deployed and come to operation after decision? 1. Need to purchase hardware to support NPM software 2. Need for in-house resources or vendor to physically set up 3. Need for in-house resources or vendor to configure NPM software 4. Need to deploy agents |
| Scalability | The ability to grow the coverage of monitored and managed devices/objects. Scalability may less frequently imply the ability to reduce monitoring. 1. Need to purchase new equipment at discrete increments 2. Impacted by the number of Appliances/devices required to implement NPM needs (e.g. separate devices for SNMP and NetFlow) 3. Location and interconnection of hardware may affect scaling performance 4. Location of software may affect scaling performance 5. Impacted by need for agent deployment 6. Impacted by ability to connect (network resource availability) 7. Limited hardware capacity 8. Limited software capacity |
| Speed of Reporting | How quickly, from query to displayed result, the status and associated data of monitored devices/objects is presented. Generally considering a challenging query because speed will depend on type of information queried and number of devices/objects queried. 1. Generally inversely proportional to scalability 2. Facilitated by local (on-premise) implementation 3. Significantly impacted by if using central reporting resource in scaled solution 4. Significantly impacted though use of agents 5. Enhanced through database replication techniques 6. Impacted by need to poll and compile at one (or more) location and report to another |
| Customer Resources | The customer resources, other than price paid directly to NPM vendor, required to implement the NPM solution. 1. Need for capital equipment purchases and timing 2. Need for IT personnel to install and configure 3. Need for IT personnel to maintain and upgrade (not perform NPM) 4. Need for IT personnel for database administration |
| Security | All issues of security including physical security, data security, data sovereignty, system integrity and disaster recovery. 1. Physical equipment and data security 2. Backup data security 3. Data sovereignty impacted by data center location(s) and policies 4. Disaster recovery impacted by data center location(s) 5. Impacted by ability to decline, elect or roll-back solution upgrades |
| Up-front Cost | Factors relating to the initial costs to deploy and operate the NPM solution. The up-front cost is closely related to vendor cost model, types of which are explained elsewhere in this article. Up-front cost is not as valuable a measure as lifetime cost of ownership. 1. Impacted by cost model 2. Impacted by need for capital equipment purchases 3. Impacted by need for IT personnel additions to implement |
| Lifetime Cost of Ownership | Lifetime cost of ownership highlights considerations beyond initial cost to deploy. This provides a levelized – with respect to deployment model – view of cost, independent of vendor cost model. These factors do not reflect a vendor’s business efficiency or profit motives in lifetime cost of ownership. 1. Impacted by need for capital equipment purchases 2. Impacted by need for IT personnel to maintain and upgrade software and agents 3. Benefitted by depreciation benefits 4. Impacted by need for capital equipment upgrades 5. Impacted by unplanned service price increases by vendor 6. Impacted by inventory carrying costs 7. Impacted by data center costs (footprint, power, cooling) |
Performance Management Deployment Models
So, with these factors firmly in mind, let’s consider some of the most common vendor deployment models out there right now:
- Traditional On-premise
- All-in-one On-Premise Appliance
- Software as a Service (SaaS)
- Virtual Appliance
Traditional On-premise
The traditional on-premise deployment approach combines customer-owned equipment with vendor provided NPM software. Generally, the customer equipment is dedicated to the operation of the NPM solution. With the traditional on-premise model, the customer maintains and upgrades application software, as well as managing security, availability and performance.
All-in-one On-premise Appliance
The all-in-one on-premise appliance model comprises a vendor-provided appliance pre-loaded with NPM software. Often, the appliance is preconfigured by the vendor for use by the customer. There may be a significant caveat to the value of that pre-configuration if the vendor requires the deployment and use of agents for its solution.
“All-in-one” presumes the basic concept to be that all NPM functions – such as poller/collection engine, database, and analytics engine reside on a single appliance. The most complete solutions also include complete support for metric and flow technologies (e.g. SNMP, WMI, IPSLA, NetFlow, etc.) while other solutions provide these as optional modules. Variations do exist with these functions separated, with each individual appliance being “all-in-one” for a defined role. For example, an all-in-one appliance for SNMP and a second all-in-one appliance for NetFlow.
With the all-in-one on-premise appliance model, the cost model determines which party, vendor or customer, maintains and upgrades application software, manages security, availability and performance.
Software as a Service (SaaS)
Software as a service (SaaS) is an NPM delivery method whereby the application software resides and runs on the vendor’s hardware at a vendor location and is accessed and configured by the customer over the Internet (or private network connection to the vendor). As a service, the SaaS vendor maintains and upgrades application software, as well as managing security, availability and performance, generally seamlessly for customer use.
Virtual Appliance
The Virtual Appliance deployment model has characteristics of the other deployment models. The vendor provides software for operation as a virtual machine on customer equipment, generally requiring only partial resources on that equipment. Virtual Appliance deployment is only suited to small NPM needs and must be replaced by another deployment model if the solution needs to scale. However, there can be significant value to starting with a virtual appliance if the vendor has seamless scaling to another solution.
Cost Models
Cost models for network performance management are important to understand as the model offered can affect factors related to an NPM deployment model.
The major cost models offered for NPM solutions are matrixed on two axes denoted by License Type and Ownership Type. Ownership Type is closely related to deployment type, relating to the ownership and use of NPM equipment, whereas License Type relates to term of NPM software license and how it is managed by or for the customer.
Ownership Types
The most significant aspect of Ownership type is the software type because it implies that the customer is supporting capital equipment and IT resources to manage the NPM solution, irrespective of license type. The service ownership type is the opposite, implying essentially no customer resources (beyond NPM operations) are required.
The appliance ownership type provides the best of both the software and service ownership types depending on customer needs. An appliance can be outright sold (with software license) to a customer, equating to the software ownership type, or the vendor can deliver, install and manage the appliance for the customer essentially matching the service ownership type. The appliance ownership type also enables a middle ground enabling the customer to manage the appliance within their network but with the vendor managing all aspects of the NPM software as a service.
License Types
Objects, as used here, could mean devices, device interfaces, agents, or other identifiable element in a user system. Often when the Object license type is used, multiple types of objects are priced. For example there may be a charge per device and a charge per type of agent used on the device.
The subscription license type suggests a software or appliance license for a specific time period rather than perpetual license. While a subscription could be limited to a finite number of objects, it is assumed here to be an unlimited object license. It then becomes possible to have a hybrid subscription/object license as part of a cost model.
Level of Automation and Deployment Model
Deployment models can also vary significantly in terms of the amount of (or lack of) automation options, particularly during the discovery process of the deployment. Some models rely heavily on the deployment of agents across the environment. This requires significant planning during the deployment process to ensure all elements that require management and monitoring are discovered and effectively covered during deployment. Basically, you need to find what you want to monitor and deploy agents to in order to ensure everything is properly covered. If this ends up being a manual process, you’re looking at a significant increase in the amount of time and planning needed to start deriving value from your NPM solution. The more automation here the better in terms of reducing manual workloads.
Comparison of Deployment Models
The table below provides a summary view of the relative benefits and challenges of the major NPM deployment models. The table also summarizes each characteristic to highlight key points and to provide relevant examples of industry solutions.
Key: — Poor • √ Good • √√ Better • √√√ Best
| Traditional On-premise | All-in-one On-premise Appliance | SaaS | Summary & Notes | |
|---|---|---|---|---|
| Speed of Deployment/Time to Operation | √ | √√√ | √√√ | All-in-one On-premise Appliance provides the best overall speed of deployment and time to operation. SaaS is a close second but is compromised by the need to deploy agents. |
| Scalability | √√ | √√ | √ | Scalability is largely vendor dependent based on the number of appliance/device instances which must be added to increase capacity. Scalability has general implications for cost and speed of reporting. Scalability is also impacted by the need to deploy agents. |
| Speed of Reporting | √√ | √√√ | √ | All-in-one On-premise Appliance offers the most integrated architecture for reporting. Speed of reporting is generally limited by a central reporting “node” in a scaled solution which creates a bottleneck for report information which becomes more restrictive as the solution scales. SaaS solutions are challenged by inherently more complicated routing due to off-premise service locations. |
| Customer Resources | -- | √√ | √√√ | SaaS deployment requires the fewest customer resources, essentially requiring only an NPM manager. All-in-one on-premise solutions are equivalent to SaaS when using a cost model with maintenance and upgrades provided. All-in-one, on-premise can be heavy on customer resource use (much like traditional on-premise) without inclusion of services. |
| Security | √√ | √√ | √ | Security has enough variables that its value with deployment model is determined by the customer. For example: On-premise provides the best physical security. SaaS likely provides good disaster recovery but offers no physical security to the customer and may have data sovereignty issues. |
| Up-front Cost | -- | √√ [1] | √√√ | SaaS solutions will share, if not own, the award for least up-front cost. All-in-one, on-premise solutions can be equivalent in up-front costs when using subscription or per-object licensing. |
| Lifetime Cost of Ownership | √ | √√ | √√ | Lifetime cost of ownership, with respect to deployment model and not vendor efficiency or profit motive, is likely similar across all-in-one on-premise appliance deployments and SaaS solutions. From a lifetime cost perspective, SaaS is essentially an all-in-one off-premise deployment with hardware, operation and management costs amortized across subscription fees. Traditional on-premise has a more expensive lifetime cost of ownership due to the external needs for capital equipment, personnel, and other non-optimized expenses. |
[1] The rating reflects an average across cost model options.
Performance Management Vendor Deployment Models
So what are some of the common deployment models used by top vendors in the NPM world? Here’s some detail:
| On-premise Software | All-in-one On-Premise Appliance | SaaS | Virtual Appliance | |
|---|---|---|---|---|
| CA Nimsoft | ||||
| HP | ||||
| InfoVista | ||||
| NetScout | ||||
| Open Source | ||||
| Riverbed | ||||
| SevOne | ||||
| Solarwinds | ||||
| WhatsUpGold |
[1] Requires multiple appliances for basic NPM (“basic NPM” defined here as SNMP+IPSLA+traffic flows)
[2] Requires agents
Conclusion
There are pros and cons for all deployment models and your situation may dictate which solution works best for your company. For those without a unique set of criteria to fill, the All-in-one On-premise model offers the most flexibility in the broadest range of scenarios. And, with proper vendor support and cost model, equals the lowest lifetime cost of ownership.
SaaS solutions need to move beyond reliance on agents to help drive the implied benefits of the ‘cloud’. Challenges with scalability, discovery, planning and reporting speed can hold back the potential net benefits of offloading the heavy lifting to the cloud. Traditional and Virtual Appliance on-premise installations perform well, but require additional time to maintain and upgrade, particularly with regard to testing and pushing updates to the NPM application itself. Obviously, hardware costs and OS licensing costs are borne by the customer in the Traditional On-premise model as well.
Automated discovery as part of a rapid deployment has improved significantly with the virtual and all-in-one appliance vendors discussed here (SevOne for example). This improved agent-less discovery results in quicker and more thorough deployment of the NPM solution as most administrators discover there are devices ‘out there’ that need management that weren’t previously accounted for. Having better visibility into what needs to be managed increases the likelihood that NPM can deliver the value it was selected for.
How to glean meaningful, actionable data from what’s been discovered on deployment is another matter however. Ensuring a ‘single pane of glass’ view from any location helps considerably. The all-in-one approach facilitates a single pane of glass portal by requiring only one appliance from which to pull data, but other deployment models can offer similar views by funneling data to a reporting appliance. Ensuring speed of reporting is another means to gleaning actionable data. On-premise can’t be beat by an offsite cloud from a reporting speed perspective and specialized database architectures in all-in-one on-premise solutions like SevOne act to maintain that speed as solutions are scaled.
In the final analysis, while the cloud shows promise on paper, ‘drop-it-in-and-go’, appliance-based solutions like SevOne represent the most compelling deployment model advantages in the current NPM environment.