What is a ‘managed service’ anyway?

I was asked to talk about this at work but it seems worth sharing more widely…

Eduserv have traditionally offered managed services on our own cloud platforms. These have been VMware-based and therefore relatively static in terms of functionality and features. We have tended to refer to ourselves as a managed cloud service provider (MCSP).

In the main, we have managed our customers’ estates up to the OS level. We have looked after OS patching, anti-virus, backups and DR. We have designed solutions for our customers based on the building blocks available from the platform — compute, storage networking, firewalls — coupled with stuff around the edges — VPN, WAF, DDoS protection, protective monitoring, etc. In some cases we have deployed and managed our customers’ databases — by which I mean that we deployed one or more VMs and then installed and managed an RDBMS stack for them on those VMs. In others, though somewhat more rarely, we have looked after our customers’ applications, particularly so where the application the customer wanted us to manage was a CMS.

So far, so straight-forward. There have been lots of players in this space and the kind of managed service I’m describing will be familiar to most people.

Enter AWS and Azure.

Things changed.

Firstly, the breadth of services on offer is huge and the rate of change of associated functionality and features has been growing, and continues to grow, exponentially.

Secondly, AWS and Azure have generally been moving up the stack — IaaS to PaaS to SaaS — effectively eating our lunch as they go. If our customers are making use of services delivered on a PaaS or SaaS basis, there is no infrastructure (in an historical sense) for us to be managing. No VMs to patch! No a/v to deploy. AWS and Azure increasingly do that for us.

That leaves us with a problem…

For customers that we help to take advantage of those features, why wouldn’t they then choose to go direct to AWS and Azure and cut us out of the equation?

Why? Because we are better at keeping pace with the rate of change of AWS and Azure than our customers are typically able to be and therefore better at exploiting those platforms for the benefit of our customers’ customers.

To do that we have to think and act rather differently from how we have thought and acted in the past.

Historically, there has been a focus on maintaining the status quo. A bad day in the office, for us, was a day when a customer’s service wasn’t performing the same as it had been the day before. We managed our customers’ estates largely to keep them performing as they did the day we designed and deployed them.

In the new world, a combination of the PaaS/SaaS shift described above, coupled with increasingly intelligent automation, means that much of the ‘maintaining the status quo’ type work is done for us by AWS and Azure.

What our customers need is something quite different.

What our customers need is for us to be maintaining a watching brief on the features and functionality on offer, applying them pro-actively to meet their evolving needs. Sometimes that will mean responding to needs that our customers already know they have. Sometimes it will drive a change in their thinking — just because the art of the possible has moved on. In a perfect world, it will be a combination of both.

“AWS RDS now has feature X, how about we work together to re-architect your existing solution to take advantage of it?”

“Azure have just announced a new service called Y. Why don’t we get rid of that group of VMs and use Y instead?”

Increasingly, that is the space that we need to be playing in. Those are the kinds of conversations we need to be having with our customers.

Whether that falls under what we have traditionally called a ‘managed service’ is something of a moot point. In many ways it is more like a rolling professional services or advisory engagement. But who cares what it is called? The important point is that, increasingly, that needs to be the kind of function we provide to our customers.