Why the cloud-native MSPs are the PewDiePies of managed services

by Ned Hallett
As Digital Marketing Manager and JAM’s primary pair of lungs, I provide the JAM-y take on the ever-evolving worlds of DevOps, SaaS, MACH - and acronyms yet to be coined.
Published on May 2020

This is the story of how the MSP market changed, and left behind all the companies who once dominated it. 

It’s a story which has, elsewhere, been interpreted as signs of a market bubble, with investors advised to take money out of managed services, and move it somewhere else.

But this isn’t right.

In reality, the market is going through a technology-driven schism, and though those on the less adaptive side of that schism may indeed become irrelevant, and investment in them prove unwise, those on the more adaptive side, the cloud-native, nimble, specialised MSPs, are poised to quickly cannibalize the market, and suck up the slack left behind by their outmoded cousins.   

In this article, we’ll be looking at 

  1. What has driven this schism between old and new
  2. What separates the non-adaptive, outmoded MSPs from the adaptive ones 
  3. And finally, why on earth the adaptive cloud-native providers are the PewDiePies of managed services

First things first – what has driven this schism: an analogy


At a fundamental level, what’s driving a wedge between the new and old MSPs is the confluence of application and infrastructure. 

Where once infrastructure was a resource like the roads and bridges from which the term derives – simple and static – it has slowly become, with the advent of cloud, something endlessly moldable and adaptable.

If we take the analogy further by saying that applications are the cars that drive on these roads, then the new infrastructure – that’s the vast array of services offered by companies like AWS and Azure – are roads that can make themselves impossibly smooth, can distort their shape to allow tyres to grip into them even better; can, if the vehicle allows, climb to 1000s of feet in the air.

The opportunity then, for the application designers, is the creation of vehicles that make ample use of this broader scope: cars that can support inhabitants at high altitudes, that mold their tyres to correspond to a patterned road – what have you.

The creative dialogue between these two design processes – with one informing the other – is what’s meant by the confluence between application and infrastructure: the increasingly indistinct point where one ends and the other begins.

But we don’t have to rely on analogies, we have examples.

What has driven this schism: examples

  1. DevOps is one site of this confluence. Where previously operations teams, responsible for provisioning infrastructure, were separated from those developing the applications, under the cloud-powered rubric of DevOps, the two are beginning to merge. Increasingly, via practices like IaC (infrastructure as code), development teams are writing the capacity to automatically provision required infrastructure into their applications, making certain operations practices a feature of dev. This is the car that projects fresh tarmac from its bonnet as it drives, to stretch the analogy somewhat.
  2. More complexly, in the move from IaaS (infrastructure as a service)  to PaaS (platform as a service) to SaaS (software as a service), we see computation moving away from the end-user and into the grey zone between them and their provider.

But how has this driven a wedge between the old MSPs and the new?

A fossil

Essentially, this leap in the technology has created two categories of MSPs, the adaptive, who have either fully embraced the possibilities of this new ‘infrastructure’, or, more commonly, those who were simply founded after this new infrastructure’s advent, and those who haven’t. 

But additional to technological redundancy, these legacy-cloud companies are faced with deeper cultural problems, which are best explained by examining their histories. 

When roads were roads

Before AWS, Azure and Google began to transform infrastructure into something mutable and adaptable, it was an uncomplicated resource, acquired and gated via the purchase of millions of pounds worth of data centres.

The hardware contained in these data centres offered a largely undifferentiated service, and the scale at which this hardware was purchased meant that the providers could afford quite narrow margins, as they served an extraordinary number of consumers.

Infrastructure then was a resource much like water: largely the same for the end user, competition being limited among a few giants and  innovation occurring at the production level – aimed at reducing cost per unit, and resulting in huge profits.

Thus, the scale at which these companies operated, and the technology they used, made specialisation and relationship focused support both economically and technically unfeasible.

It would be like United Utilities spending thousands on treating water so that travelled more smoothly through a particular homeowner’s pipes.

But as infrastructure changed, this situation was almost entirely turned on its head, and public cloud meant almost none of the above was true anymore. 

Strange highways 

Elasticity – paying only for the resource you use – eliminated the huge capital barrier to entering the market, reintroducing competition, and by the proliferation of providers, making both specialisation and small client-bases, with whom providers could form personal relationships, a new and attractive reality.

Next, the evolution of the technology described at this article’s beginning provided the platform on which specialisation could occur. 

Suddenly, the stage was set for an entirely new breed of MSP.

Nimble, cloud-native support-and-relationship focused managed service providers

A chess game

Quickly, companies began to make a virtue of all that had been prohibited by the previous set-up.

Smaller client bases received technically personalised service, with providers becoming experts in their clients’ applications and in the businesses themselves.

Moreover, as well as specialising in the verticals, these new MSPs began to specialise in particular aspects of the technology.

Consumers were now able to shop providers who were experts in fintech or legal SaaS; who could construct flawless automation pipelines, design the most efficient use of microservices, or were perfectly placed to bring the advantages of cloud and managed services in healthcare. 

The deepening of these relationships, and the increased complexity of the technical nature of infrastructure, also gave rise to the idea of a support partner: a provider whose role it was to handle all this additional complexity for you; to know this aspect of your business more deeply than you did yourself.

And against this, of course, the old-guard hosting companies began to crumble.

So what’s next 

As we said at the beginning of this piece, this is a split that’s been widely misinterpreted. Those saying the MSP market is declining in value have simply made the error of identifying these legacy cloud providers as the most important players. 

Rather, they should look at the new roles MSPs are playing. Many of which have been overlooked in their analysis.

This pattern of large monopolies being broken up by technology-driven specialists is not unique to managed services, however. A similar thing could be said of broadcast media, with the new creators of YouTube and Twitch creating niche content that it wouldn’t be economical for companies like the BBC to make. 

This is why, the cloud-native providers, those taking advantage of the new playing field, are the PewDiePies of the MSP market. The world-famous YouTuber who’s earned over 100 million subscribers the kinds of gaming videos large broadcast companies would never have thought popular. 

And if the rise of independent content creators tells us anything, it’s that, in a few years, the market could look like nothing we recognise now.



With partners across the USA, Europe and APAC, we provide a truly global service. So wherever you or your clients are based, contact us today to find out what we can do.