The traditional managed services provider (MSP) model is broken and needs disruption. The next-generation managed services model is about guiding customers in a self-service manner.
The key drivers causing customers to seek cloud providers like Amazon Web Services (AWS) include the agility and cost efficiencies they afford. The agility helps customers be more responsive to their users. At the same time, this same agility delivered by cloud providers can also result in customers being overwhelmed in determining best practices and patterns for deploying and operating on the cloud. Moreover, as more companies realize how software is a strategic asset for their business, they often don’t want to simply outsource all their IT needs to yet another provider. They want speed and agility, but not by being at the mercy of an IT provider. They want to leverage best practices while gaining the autonomy in obtaining these capabilities in a self-service manner.
In this post, I contrast the traditional MSP to a next-generation MSP driven by DevOps and automation. In learning how MSP features can help increase agility when delivered from a new model, you should be able to better choose providers who align best with your business outcomes.
The Traditional MSP
To begin, let’s have a look at the typical capabilities of an MSP. They include:
- Access Management – Creating user accounts and permissions to infrastructure resources
- Change Management – Ensure changes are applied in a controlled manner
- Continuity Management – Prevent loss via disaster recovery techniques such as backups, high availability, and restoration
- Incident Management – Get support to fix problems
- Patch Management – Keep infrastructure up to date and compliant
- Provisioning Management – Provision and configure infrastructure
- Reporting – Get access to metrics, logs, and recommendations for improvement
- Security Management – Ensure infrastructure is secure
With a traditional MSP, these types of services are typically provided through an opaque model in which customers are reliant on the MSP to perform remedial actions to fix most problems. This is because the MSP often has the credentials and knowledge to make changes to a largely manually-provisioned infrastructure or a hodgepodge of “automated” scripts that are not provided as a system to customers.
Next-Generation MSP on AWS
A next-gen MSP provides customers capabilities in a self-service manner enabling them to get up and running quickly with a fully-automated infrastructure while benefiting from the expert guidance provided by the MSP. This means customers don’t need someone on the MSP’s support team to – say – restart a server or perform a backup. This is because these services are provided to customers through self-service means. Instead, the reason a customer might need a next-gen MSP is for their best practices expertise in architecture and automation to help more quickly guide them to better solutions.
What Does Next-Gen Look Like?
What do each of the capabilities described in the first section look like in a next-generation MSP model? At their core, they’re self service. Customers of the MSP might have a team from the MSP get their infrastructure up and running but there should be nothing preventing the customer from provisioning everything themselves either. Furthermore, there should be a way for customers to get their applications running on the infrastructure using repeatable frameworks as well.
Let’s have a look at the types of capabilities a next-gen MSP on AWS might offer:
- Access Management? – A customer interfaces with an API and/or console provided by the MSP that automates the provisioning of AWS Organizations, AWS Accounts, and IAM users and permissions. Possible Tools: AWS Organizations, AWS IAM, AWS Service Catalog, and automation through AWS CloudFormation and other tools.
- Change Management – Customers interface with the API/Console to manage how changes are deployed on their infrastructure. For example, they might want to modify RDS database configuration settings or the AMI the EC2 instances use. Customers can make a request to the MSP to apply or schedule these changes or they can apply the changes themselves using frameworks provided by the MSP. These changes flow through an approval process configured by the customer. Possible Tools: AWS Service Catalog, AWS CloudFormation, AWS CloudWatch Dashboards, Configuration Management Tools, and custom automation.
- Continuity Management – Customers can schedule disaster recovery processes and scenarios through an API/Console. This includes scheduling data, storage, and source backups. It might also include the ability to schedule disaster recovery drills with experts from the MSP. Moreover, the automation provided in the DevOps frameworks provided by the MSP should support resilient, high availability solutions that can maintain the necessary infrastructure even when parts of it fails so that users do not experience errors when parts of the underlying infrastructure fails. Possible Tools: Amazon EC2 Systems Manager, AWS CodeCommit, AWS Shield, Custom Reports, Amazon Glacier, AWS Service Catalog, AWS Auto Scaling, AWS CloudFormation, and Configuration Management Tools might be used. Also, tools for automation of backing up EBS volumes, RDS database snapshots, etc.
- Incident Management – Customers can contact MSP support experts at any time of day to help guide them to solutions through various mechanisms including real-time chat, chatbots, online systems, and the phone. However, the MSP should never be required to be present to fix an infrastructure error. This is because the MSP should provide the customer access to authorized individuals who are capable of making infrastructure changes in a governed manner – if they choose to do so. The MSP can also handle daily activities of investigating and resolving alarms or incidents. Possible Tools: Amazon Connect, AWS Step Functions, Amazon Polly, Amazon Lex, Amazon CloudWatch – Logs, Events, and Monitoring, AWS CloudTrail, New Relic (App & Performance Monitoring), AWS Config (and Config Rules), and AWS EC2 Systems Manager
- Patch Management – The MSP can manage all customer OS patching activities to help keep infrastructure resources current and secure. This would include applying updates or patches that are released from OS vendors? in a timely and consistent manner to minimize the impact on the customers’ business. Critical security patches are applied as needed, while others are applied based on the patch schedule when customers make the request. The customer can also apply these changes through governance mechanisms provided by the MSP. Possible Tools: AWS EC2 Systems Manager, AWS Service Catalog
- Provisioning Management – The MSP launches and manages infrastructure stacks via a framework that provisions these stacks as code that builds users, security infrastructure, networks, environments, services, and deployment pipelines. The MSP should provide these same capabilities to customers as well so that they are capable of making these changes with or without the MSP. Possible Tools: AWS CloudFormation, Configuration Management Tools, and custom automation.
- Reporting – Customers get access to the data using to manage your infrastructure, including Amazon S3 logs, CloudTrail logs, instance logs, and real-time data from the AWS Managed Services APIs. Customer can also get real-time advice through automated systems provide by the MSP. The MSP should also walk customers through metrics, their impact, as well as recommendations to optimize platform usage. Possible Tools: Amazon CloudWatch Dashboards, AWS Trusted Advisor, custom automation, and web portals
- Security Management – The next-gen MSP provides customers information protection of assets and keeps the infrastructure secure by providing anti-malware protection, intrusion detection, and intrusion prevention systems. Possible Tools: Amazon VPC, AWS Parameter Store, AWS WAF, Amazon Inspector, AWS Shield, AWS Config and Config Rules, AWS CloudTrail, and Security Monitoring as a Service
The overarching goal of the next-generation delivery model is to provide the capability of 100% self-service capabilities for customers as part of a shared responsibility model. Alternatively, the customer might choose for the MSP to manage everything for them. In this case, the customer should be able to take over the management of the infrastructure at any time if the MSP is not meeting its needs. Customer-centric MSPs will do this by creating fully automated, continuous, and autonomic services.
Scenario: Deployment Pipeline Management
Here’s an example scenario in how a next-generation MSP might provide a deployment pipeline monitoring and guidance service to customers.
The MSP uses an open-source framework that provisions all the necessary AWS environment, deployment pipeline, and application resources to run a highly-available, secure application on AWS. Each deployment pipeline is configured to send AWS CodePipeline statistics via AWS CloudWatch Events. These events are configured to submit notifications through Amazon SNS and AWS Lambda so that all necessary parties are informed via email and Slack. What’s more, the CodePipeline statistics are aggregated and made available through Amazon CloudWatch Dashboards. All of this is configured through configuration files that are versioned in the customer’s version-control repository and automated via the open-source framework.
Once the MSP DevOps Engineers receive failure alerts through Slack, email, or the Dashboard, they help guide the customers’ engineers in resolving errors in AWS 
What’s Next?
Going forward, we expect customers to demand more self-service capabilities from their providers. Providers will enable these self-service capabilities through systematic automation and a focus on the user experience in how these features are provided to IT consumers.
Additional Resources
- AWS Managed Services
- Stelligent mu – Open-source DevOps on AWS framework
|
Stelligent Amazon Pollycast
 |
