MSPs now need automation

In a marketplace where customers will come and go, and each customer’s requirements will change on irregular patterns driven by their own business requirements, managing service delivery will require MSPs to juggle complex interactions of varying demands. In addition, this will need to be achieved at a speed where automation is the only option.

This is one of the key targets for Carl Eberling, Vice President and General Manager of Quest Software’s Virtualisation and Monitoring Business Unit. He is well aware that automation processes – concepts even – have a way to go to overcome many of the issues MSPs will face.

 

One such is the increasingly common occurrence these days where automating a process makes re-engineering it to cope with the rate of changes in technology and business models increasingly difficult. The big danger with the rate of change in cloud service requirements is that automating management processes creates a situation where what has been automated no longer manages what the marketplace is looking for, and can only be changed by `hand crafting’.

 

“This is what we’re aiming at with the Quest Cloud Automation Platform,” Eberling said. “Monitoring the cloud is important but the real piece is understanding the cloud and then adjusting it as the application needs.”

 

Quest answer to this is to use multi-variant equations. “You have to approach automation in a way that lets you understand what are the variables that go in to it,” he said. “For example, if you have two variables, that’s how people have typically approached automation, and called that their solution, instead of building a model that is flexible enough to allow for incremental variables over time. A good example is security. If you look at this as just at who the users are and what they are authorised to do you miss the mark when other variables are introduced, such as location, role change, group policy, or device characteristics. So in order to effectively build automation you need to understand all of this. So the need is to approach automation in a multi-variant way that is flexible enough to cope. Typically people don’t do that.”

 

The Platform is also designed to manage the second most important aspect of this, the ability to change elements of the model in real time. This can either be by direct intervention, or through a policy-driven, rules-based approach. These policies and rules can be centrally managed by an MSP which can then offer customers services analogous to anti-virus tools that update themselves based on data learned by the service provider.

 

“That is why they need an API and therefore any decent automation service has to have an API, and if there isn’t one, then it is not cloud,” according to Quest’s Chief Technology Officer in Europe, Joe Baguley. “Unless there is an ability to programmatically talk to it and update it then it is not cloud, just a badly programmed portal. That level of interaction allows not only applications programmers but also services in a service catalogue to talk to that management environment and modify it themselves. That is really important.”

 

This approach does offer a real service potential for the MSP community. “And that is why we bought Surgient,” Eberling said. “They saw that if IaaS was going to take off it needed the ability to be performance enhanced. It is simple to say, but it’s the secret sauce is of how we bring this together. Once you understand the application, which can range from a simple app in a single executable through to a combinant app that includes multiple server, SOA components and have external calls to other applications, you can intelligently identify factors such as high traffic volume, that the app server space is being hit, and that new app servers should be automatically added. Likewise, if I’ve over provisioned, servers can automatically be taken off-line.”

 

Further down the Platform roadmap are plans for management based on user information. Here, the downstream impact of new users logging on can be predicted from their profile of identity, security level and service demand history, and resources can be adjusted accordingly. Reporting on user activity and service requirements is then fed back into the trouble ticketing system and the ITIL processes.

 

This can also give MSPs the metrics they need to service customer requirements in the form the customers want – business-related Key Performance Indicators (KPIs) rather than technology-related Service Level Agreements (SLAs).

 

 “If I am running something like a help desk I need is to know how many calls each of my agents are handling on a daily basis. If the system starts to slow down it can still be available to the IT department but the productivity slows down and the business stops meeting my business requirements,” Eberling said. “The MSPs are the ones most suited to this because they are in the position to hide the underlying technology from the users and just deliver to them the service components that they need, measured by the KPIs that mean something to them.

 

“The MSPs are far more likely to meet their customers’ needs by engineering down from the end user experience – that should be the basis of the contract between them. On premise IT departments are less likely to do this and simply target technology SLAs.”

 

Eberling also sees such automated management tools being the key to diluting the arguments and misunderstandings about types of cloud, particularly `private’ and `public’. In the long term, of course, all users will have private clouds, whether they reside in obscure on-premise legacy systems, entirely in the `public’ cloud of service provision or any combination in between. The important issue is managing the interactions between the different environments, which in itself could prove to be a crucial selling point for MSPs.

 

“In my last job I ran the IT for a $45m healthcare company in the USA. Though I had three datacentres I also rented space on three other service providers, and I would tie it into the network so it was my stuff. But it was irrelevant where they were,” Eberling said. “The insurance selling arm required a new CRM system, so instead of asking IT, it went to Salesforce. IT learned about when I was asked to integrate the Salesforce system into the other systems being used. What that told me was the standard has been changed about how businesses buy their IT. Their KPI was buy it today and use it tomorrow, and that is what IT now has to be measured against.”

 

Also in the roadmap is disaster recovery and how users can broker payloads between different infrastructures when there is a problem. To start with he is looking to broker cleanly between other pods in an infrastructure. So if an MSP has two or more datacentres they can move users from one to another. Over time he sees that expanding that to cover bursting between clouds. Failover and/or bursting to different technology stacks is the ideal target, but technologically difficult.

 

“The automation will have to be able to drive that, and it will of course depend on what users are trying to do. You won’t be able to take an application built on an Oracle database and running on Websphere and just drop it into a Force.com environment. So bursting will be technology dependent up to a point, and will be driven by standards, he said. “It will certainly depend on standards within the virtual container, but what I would argue is that this depends on an understanding of the application being run. If I understand the apps server and the webserver it becomes easier for me to spin up incremental capacity elsewhere because of the intelligence available about the application.”