What Exactly is a Next-Generation AWS Managed Service Provider (MSP)?

By Adrian SanMiguel, Principal Partner Solutions Architect at AWS

Editor’s note: This is the first part of a popular series for AWS MSP Partners. Read Part 2 >> Part 3 >> Part 4

AWS MSP Program-1 The concept of a managed service provider (MSP) isn’t necessarily new, but it is something that can be difficult for organizations to grasp.

What exactly is a managed service provider? What does it take to become a next-generation MSP? How does an organization even begin that process on Amazon Web Services (AWS)?

At a high level, a next-gen AWS MSP is committed to three key tenets:

Educate customers on a proactive, ongoing basis, offering consultative and advisory services. MSPs never hide behind the curtain for the sake of watching the meter run. This enables MSPs to transition from a break/fix relationship to that of a trusted advisor. You want your customers to revere you, not revile you.
.
Lead with AWS Professional Services, just like a systems integrator (SI) would. This is not an after-thought; next-gen AWS MSPs must establish themselves as an expert advisor from the very first interaction. They use in-house talent and sub in third-parties or SIs only when necessary. MSPs use those one-off engagements as training opportunities to further build and train their bench.
.
Advocate to customers the use of and evolution of AWS services. Next-gen AWS MSPs are moving up the stack from the operating system layer and going into application-level services.

In this post, the first in a four-part series for AWS Partner Network (APN) Partners, we’ll explore why you should care about next-generation MSPs and, most importantly, what’s in it for your organization.

Education and Advocacy is the Priority

AWS customers are, by and large, curious. When I was a kid, nothing made me happier than asking questions to learn just a little bit more. Fast forward to today, and the act of asking and answering questions has pushed me towards a position where I have the ability to help others with knowledge I have gained along the way.

If you’re not actively doing this for your customers, you are robbing them of learning opportunities at each engagement. As you experience customers asking the same questions or making the same missteps through their AWS account, you have a choice to make:

Let them continue to make these mistake so they open cases and thus validate their need for your services.
.
– OR –
.
Teach them how to avoid these common pitfalls via a brown bag, hands-on session, or other touch point.

The traditional MSP business model is rapidly evolving. Customers are demanding comprehensive cloud-native solutions that reduce costs, improve business agility, increase security, and empower organizations to focus on their goals.

Next-gen AWS MSPs focus on business outcomes that go beyond the health of individual resources, focusing on four key areas to help customers succeed: Plan and design; Build and migrate; Run and operate; and Optimize.

Learn more about the AWS MSP Partner Program >>

Solving Business Problems vs. Watching the Meter Run

Previously, I served as an AWS Technical Account Manager (TAM), which is responsible for building strategies for our customers, helping solve complex problems proactively, and serving as a trusted advisor and advocate inside of AWS.

A big part of the gig, like with many successful next-gen MSPs, is the ongoing analysis of trends that my customers continually found themselves in. We’d usually ignore the one-offs (unless particularly hairy or interesting) and instead focus on opportunities for improvement.

A particular customer I worked with had a significant spend of $390K per month, and most of this was Microsoft SQL Server running on Amazon Elastic Compute Cloud (Amazon EC2) instances. They had an odd situation where they had no in-house IT staff with cloud experience, so they leveraged a global systems integrator (GSI) as their help desk and cloud support team.

Through no fault of their own, this GSI built instances for their customer on Server 2K3 (issue one) and on MSSQL 2005 (issue two). From my purview, all I could see was giant instances with tons of Amazon Elastic Block Store (Amazon EBS) volumes that repeatedly failed at peak write load.

Each Amazon EBS failure was well within the Annual Failure Rate (AFR), and when a particular instance failed it was an all-hands-on-deck type of situation where the customer was hard down until the instance came back up, passed a chkdsk, corruption was dealt with, and the services were restored.

I went back in time to when the instance was first built and found that, historically, there had been more than 20 failures at a rate of about one per month. Statistically, this made sense considering the number of volumes and the law of averages. Digging in when I could carve out time, however, I noticed this was happening around the end of the month, every month, for the previous six years.

In a recurring cadence call, I asked the million dollar question: How are these instances built? I had no architecture frame of reference, nor did I have a way to see into the instance (no AWS or Amazon employee can look into any instance, in any way, period). We discovered the culprit to be Windows Dynamic Disk, 36 of them, striped in a RAID0.

When I asked, “Why in the name of all that is good?” the answer was, “Because no one told us not to do it this way.” The customer needed IOPS for the DW MSSQL server. At the time, 1TB was the max Amazon EBS volume, and that had a hard cap of IOPS. So, they kept growing it, and the GSI said everything was OK.

When I shared that, for quite some time, the Amazon EBS max size was actually 16TB, all I heard was silence on the other end of the phone. Then the customer became angry. Not at me, and not at the architecture itself, but at the GSI they had employed for years. This customer realized the GSI had simply been watching the meter run.

It turned out the GSI was charging them each and every time the instance went down, billing for Time & Materials (T&M), after-hours escalation (because, of course, the instance ran at night), restoration of the data, and to put the whole thing back together again—metadata and all—just so it could break again in another month.

The customer used these points when addressing renewal with the GSI and came direct to AWS shortly afterwards when they realized the GSI had no interest in fixing things and only sought to keep the status quo in place.

If you’re doing this same thing for your customers, I implore you to stop! You should literally be doing anything but that. Be proactive and start using your recurring touch points, monthly or quarterly account reviews, cadence calls, or whatever mechanism you have to connect with customers.

Review their cases and help them to solve these kinds of issues before they even ask about them. It takes just a few hours a week to dive in and have meaningful conversations with your customers. Often, you’ll discover things they didn’t realize were an issue, or something they have just been living with because it was the norm.

Imagine the impact it would have on your business relationship if you could tell your customers this: “I saw that you keep having this particular issue, so we took a look at things and found a solution. Nightly, your httpd daemon keeps hanging and needs to be manually restarted when you do git pulls, so I updated the logic behind it. It should be fine next time.”

The impact of a proactive approach elevates you over break/fix responses, and gives your customer the sense that you are indeed looking out for them—not just your bottom line.

Building SI Capabilities is a Must

A next-gen AWS MSP’s charter is a capable Professional Services lead-in. As mentioned during my chalk talk at AWS re:Invent 2018—Overcoming the Challenges of Becoming a Next-Generation MSP—the reasoning from a margin benefit alone is compelling.

The global MSP market will be an estimated $53.8 billion by 2020, according to Markets & Market. This capable ProServe lead-in opens the door to competing for 70 percent of this, an estimated $37.9 billion.

Learn more about the global MSP market in a study AWS commissioned from Forrester Consulting, which conducted a Total Economic Impact (TEI) study to examine the business opportunities that next-gen AWS MSPs may realize.

MSP Series-1-1

Figure 1 – Opportunity for next-gen MSPs as stated by Forrester Consulting.

If you don’t have a ProServe bench, does that mean that you can’t be a next-gen AWS MSP? For me, it’s a yes; you cannot be considered a next-gen AWS MSP if you don’t have ProServe capabilities. Without that first-touch lead-in, your customers are statistically less likely to engage you for more complex workloads as time goes on, especially for those coming from your Install Base.

Let’s look at the example below:

Joe Bob has a small business called Joe Bob’s Tires, and he currently hosts with your practice. He has a small digital presence, and his developer, Jimbo, wants to go serverless and use containers to reduce costs so that he can develop on his local machine at home.
.
Joe Bob contacts his account manager to talk about moving to the cloud, and your account manager knows the play well and ropes in an architect or specialist to engage further and gather requirements.
.
Joe Bob’s requirements are set and this proof of concept (POC) is slated for three months on AWS. It will cost $10K to build, including the application refactoring.

One of two things will happen next:

Your ProServe bench has never done application refactoring, and they attempt to futz their way through it. As a result, your deliverables are super late and expensive. Because of this, Joe Bob gets upset and finds another partner to do the application refactoring, or AWS ProServe themselves.
.
Jimbo gets what he wants and is happy. Things are much smoother now, and he can deploy in minutes, not days. Meanwhile, Joe Bob begins wondering why he’s paying you at all, if he hasn’t already been given the recommendation to DIY. Joe Bob leaves and takes his account to another partner.
.
Your ProServe bench has never done application refactoring, and instead of trying to figure it out, opts to bring in a third-party SI. Your ProServe bench carries on.

In this example, the SI is happy to go on your ProServe paper and be your sub-contractor at a higher cost to you, thus reducing your profits. They get the first touch on the customer workload, and they will probably crush it. The project is done a month early, it runs well, and it has reduced costs by 75 percent.

Joe Bob comes to you later and wants to do more, but you know that it will cost you more to leverage the same SI. You opt to call them anyway, and the next 5-6 workloads come through. However, you have to keep calling the SI to do the work for you.

Not only are your profits down, but your bench isn’t learning anything new and your brand isn’t improving on capabilities. Furthermore, your capabilities are visibly missing every time Jimbo calls needing a change made to the environment that he can’t figure out himself. Jimbo asks, “Who did the work?” and the jig is likely up at this point.

What Does the Future Hold for MSPs?

As a next-gen AWS MSP, and just like during any good fishing trip, you want the chance to catch something but also the ability to move on if it’s not the right patch of water. Some of the key tenants of the AWS Cloud are flexibility and elasticity. If you’re using something that’s not working, you can change it.

Ultimately, it’s your customers’ account and they can do what they want. Be there for them and work to evolve and grow as their needs and appetite for new technologies grows, too.

Will your MSP practice potentially lose money as customers like Joe Bob modernize and lower the total amount of infrastructure cost? You must be OK with this and add value to customers via your superpowers.

You should forget about the on-premises days of 80 percent margin on hardware. Those margins will never be seen on the cloud. Instead, pivot your focus into application-level services, such as a managed Hadoop offering, managed backups, disaster recovery as a service, or even managed [insert service name here].

Or, you can build a compelling differentiator that builds on AWS services, like Amazon EC2 or Amazon Relational Database Service (Amazon RDS). These solutions can be something unique that your practice offers to customers.

Application-level offerings are significantly higher margin opportunities than the traditional MSP reseller margin (7 percent versus 28 percent, as seen on the graph above). Odds are, your practice is already doing something like this as a one-off for a large customer that would better serve the rest of your base by offering it there as well.

Conclusion

I recommend you take a hard look at what makes your practice great today (even if you’re not an audited AWS MSP) and build on that foundation. Consider these capabilities your superpowers, and make them the root of everything you do.

Like Joe Bob’s Tires, today these customers may only be using Amazon EC2, Amazon RDS, Amazon Simple Storage Service (Amazon S3), and Amazon Route 53, but in 12 months they’ll probably start exploring containers and other advanced services. To be a next-gen AWS MPS, your organization has to be flexible enough to allow that exploration—and not provide a Type A offer where you get one thing or a Type B offer where you get another thing only.

Guardrails are a good thing, but they can also be a significant hindrance, especially if you want to explore and learn. Most, if not all, of your customers are already doing exploration of advanced services without your knowledge.

If you’re not looking at your own datasets to glean what customers want more of and what they’re struggling with, start on that right away. Shape the next 3-5 years of your customers’ options. Just like a good fishing spot, your customers will remember and go back to it time and again.

Next Steps

These aspects can change your narrative completely, as you’re no longer break/fix or watching the meter run. Now, you’re being proactive and thoughtful on how customers’ problems are causing them grief and working towards solutions in real-time.

Your AWS MSP abilities and offering is in a position to evolve as your customers’ needs and wants evolve, too. With a capable bench of staff, you can set your best foot forward from the onset. And once you start changing the mindset of what your practice is—and what it could be in the future—it becomes significantly easier to justify your monthly charge.

For more, in-depth information, check out our AWS MSP Partner Program, which recognizes leading APN Consulting Partners that are highly skilled at providing full lifecycle solutions to AWS Customers.

Check out these other stories in my series for AWS MSPs:

Part 2: 3 Things You Need to Shape Your Teams into a Next-Gen AWS MSP
Part 3: Building an MSP’s Engineering, Support, and Relationship Management Teams
Part 4: Succeeding with Your Next-Gen AWS MSP Sales, Solutions Architecture, and Marketing Teams

Additional resources for MSPs:

AWS Partner Network (APN) Blog