POSTED ON 19 JUL 2016
READING TIME: 6 MINUTES
Managed Service Providers (MSPs) provide outsourced IT applications and infrastructure monitoring and management services. An MSP’s typical customers are enterprises with a reasonably large or reasonably diverse footprint of IT systems. Examples are found across all industries: retail, health care, manufacturing, e-commerce, and telecommunications.
The reasons for a company to outsource the management or monitoring of some or its entire IT infrastructure are varied. They include: corporate directives which impact all subsidiaries, migration of IT infrastructure to the cloud, merger and acquisition activities which may drive the outsourcing of the monitoring of a subset of the infrastructure, growth of subsets of the IT footprint due to shifting business models, or new markets in divergent time zones.
Managing enterprise applications poses a couple of challenges for both MSP and for the customer.
While many of these issues are important when systems are monitored by internal resources also, there is often an inate domain knowledge that is brought to the table which hides the need to accurately model the impact of specific problems when they occur.
There are of course other issues which should not be under stated, including pre-existing data centre infrastructure, access to sensitive data, interfacing with the internal IT department and (last but not least) knowledge of the enterprise systems.
Even a small enterprise client can be hesitant to move his infrastructure completely to an MSP’s managed environment. This poses a challenge for the MSP to get full visibility of what is going on.
There are a number of approaches to deliver outsourced management. In brief, these are:
Taking each of these in turn:
The requirement here is for VPN-type remote access to the customer’s existing monitoring and management applications by MSP staff. On paper, this is the simplest approach. However, it doesn’t scale well for the MSP.
There is a need for diverse skillsets in its staff - each customer is a new environment (and potentially new toolset) to be learned. It is difficult to achieve economies of scale or leverage any MSP investment in tooling, in root-cause analysis and automated remediation. It’s also likely that the customer will no longer invest in improving the efficacy of its tooling since it’s now the MSP’s problem to monitor the systems and services. The MSP may also find it difficult to measure its own performance (or KPIs), integrate with its own ticketing and workforce systems.
For the customer, this approach can work for a fully outsourced model. However, the customer’s existing toolset may lack good access control or partitioning of the managed resources. The inability to be able to control access to information about sensitive systems may prohibit a partial outsourcing arrangement. The VPN between MSP and customer should offer low latency but bandwidth requirements are low.
Again we rely on VPN connectivity between the MSP and the client, but requiring more configuration on the client side. There is typically a requirement to install an agent on each of the managed entities. However this can be prohibited by the managed system’s vendor’s license conditions. Proactive monitoring (including polling of the managed resources) and remediation activities place greater requirements on firewall configuration between both entities.
For the MSP, there is also a possible requirement to support remote access to the MSP monitoring infrastructure from multiple customers. A self-care portal for the client is a likely requirement. The requirements on the WAN/VPN connection are greater in terms of bandwidth. The dependency on that connection is also absolute, with both customer and MSP flying blind in its absence.
This approach is dependent on the capabilities of the existing management systems (although workarounds are also possible). Depending on the complexity of the managed solutions(s), the alarm propagation may have to be augmented with appropriately configured data exports – data including topology/dependency information and planned outage information. Depending on the abilities of the existing management infrastructure, one may have to filter alerts/alarms before forwarding to the MSP-hosted monitoring system, making the solution partly similar to the federated system described below.
The challenges posed by the previous three approaches can be addressed by a federated architecture. Here, we’re briefly introducing an MSP-owned management system within the client’s management domain which communicates with a centralised MSP-hosted umbrella system. Functionality is distributed across both local and remote management systems. This MSP-owned system can propagate appropriate information (alarms, topology changes …) to a centralised MSP monitoring system for action and remediation actions can be delivered from the local system. The client’s domain can of course cover a mix of own hardware and networking equipment and private and public cloud offerings.
Federated infrastructure and application management (MSP perspective)
In the next post we'll cover federated approach in more details showing, how federated architecture bridges on-site and MSP based management providing flexibility, functionality and value to both MSPs and their customers. However, if you'd like to learn more about federated approach straightaway - sign up for one of our live demonstration sessions where our technical team will guide you thru its basic concepts and demonstrate how you and your clients can simplify and automate IT infrastructure management.