Many organizations are interested in running digital business applications in public cloud infrastructure as a service, but lack the necessary expertise. Evaluate managed and professional services offerings that can help bridge the skills gap.
New digital business workloads are often well-suited to public cloud infrastructure as a service (IaaS), but most IT organizations lack sufficient quantities of expert personnel to fully support the growing digital needs of the business on cloud IaaS.
Many cloud-native applications can also take advantage of the platform as a service (PaaS) capabilities within integrated IaaS and PaaS (IaaS+PaaS) offerings from hyperscale cloud providers such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP). However, these offerings are highly complex and feature-rich, and require expertise to use optimally; many IT organizations do not have a sufficiently deep understanding of best practices in cloud-native architecture and DevOps-style operations for these platforms.
A growing ecosystem of managed service providers (MSPs) are offering managed and professional services on top of third-party cloud providers, especially the hyperscale cloud providers. Their capabilities can help bridge the skills gap and add ongoing long-term value in areas such as governance and financial management. However, MSPs vary greatly in expertise, specializations and business model, and must be chosen with care.
Enterprise architects with digital business workloads in cloud IaaS should:
Consider whether managed or professional services will be useful for these workloads.
Choose an MSP that is deeply expert in your particular cloud platform. MSPs need to have cloud-native (and often provider-specific) skills.
Select an MSP that has provider-specific software tools and intellectual property. Cloud IaaS is not a commodity and should not be managed as such.
Choose an MSP that has strong DevOps engineering capabilities. They should assist your organization in developing appropriate processes and tools, and provide skills transfer to your staff. Traditional infrastructure management is suboptimal for cloud IaaS.
New applications, especially digital business applications – such as digital marketing, big data and analytics, mobile applications, and Internet of Things applications – are highly likely to use cloud services. A significant percentage of such applications are deployed into public cloud IaaS. Digital business projects are usually conducted in Mode 2 of Gartner's bimodal IT model – agility, rapid iteration, tight alignment to business objectives, and the ability to experiment are highly prized.
Digital business applications often have very different traits than traditional enterprise applications; they are often customer-facing, have unpredictable capacity needs, require rapid elasticity, and change frequently. Furthermore, Mode 2 infrastructure should not be managed like Mode 1 infrastructure. This is particularly true when the cloud IaaS offering includes PaaS elements as well, as is common for hyperscale IaaS+PaaS providers. This presents challenges for many organizations that are used to traditional IT operations management of on-premises infrastructure.
Many organizations with digital business applications in cloud IaaS can benefit from the use of managed and professional services providers, for short-term projects as well as long-term engagements. To some degree, this business is a natural evolution from, or successor to, the managed hosting market. However, successful delivery of managed and professional services on cloud IaaS demands:
Cloud-native, often cloud-specific, skills
Provider-specific software tools (or provider-specific features within a broader cloud management platform [CMP])
Provider-specific expertise and intellectual property
Most MSPs will provide managed and professional services within the framework of a DevOps philosophy. DevOps is useful for both Mode 1 and Mode 2 applications. Many providers will use ITIL terminology when describing the tasks that they perform and the processes that they follow. Processes and their associated tasks are different in DevOps-oriented environments than they are in traditional IT operations management, but the ITIL framework remains useful for providing common terminology that can be used to describe the service life cycle.
Managed and professional services for public cloud IaaS can be delivered by a broad range of providers, including managed hosters, data center outsourcers, system integrators (SIs), value-added resellers and cloud-native specialized consultancies. These providers serve as cloud service brokerages (CSBs); CSBs are described in "Cloud Services Brokerage Is Dominated by Three Primary Roles."
This research note guides enterprise architects through the evaluation of whether or not managed or professional services will be useful for their digital business applications (and other Mode 2-oriented applications) in cloud IaaS, and, if so, what to look for in an MSP. (For an overview of the Mode 1 use cases for managed and professional services, see "Three Journeys Define Migrating a Data Center to Cloud Infrastructure as a Service.")
This research is scoped specifically for managed and professional services related to infrastructure and operations in the context of cloud IaaS or IaaS+PaaS. It does not include consideration of other professional services useful for developing digital businesses or driving digital transformation; see "Market Guide for Digital Business Consulting Services" for a discussion of such services.
Organizations of all sizes and levels of cloud computing maturity consider the use of professional and managed services in conjunction with cloud IaaS. Such services are often accelerators for digital business, allowing an organization to rapidly gain access to new skills, expand access to hard-to-hire skills, quickly deploy new tools and technologies, become more agile, and obtain assistance with transformation.
Organizations with relatively little experience with cloud IaaS often gain great value from professional services – project-based consulting and implementation services. However, even organizations with a long track record of successful use of cloud IaaS and significant internal expertise often find professional services valuable when doing something they haven't done before – for instance, an application with a new type of architecture that uses a new service or capability from the cloud IaaS provider, that requires significantly greater scale or more dynamic capacity needs, or that has higher security or regulatory compliance requirements.
Many cloud IaaS-related professional services contain a strong element of integration – particularly integration with existing environments (hybrid IT), but potentially also with other cloud environments, including other IaaS, PaaS and SaaS solutions. Network, identity, security and data integration are important to many customers, even when digital business and other Mode 2 applications are otherwise separate from Mode 1 applications.
Table 1 shows common professional services for digital business applications in cloud IaaS, and the reasons you would purchase them. Note: This is not an exhaustive list of professional services. In some cases, these capabilities may be combined with other SI capabilities that are not necessarily cloud-specific.
| Professional Services | Use When … |
|---|---|
| Readiness assessment | You have an existing application that was not built in a cloud-native fashion, and would like a third party to evaluate its suitability for cloud IaaS. |
| Cloud provider selection | You want an independent third party to determine the best and most cost-effective place to host an application. This may include evaluating not only multiple cloud IaaS providers, but also the organization's own on-premises infrastructure solutions and other noncloud solutions. |
| Solution architecture | You want assistance with designing or validating your solution architecture for an application. This may include recommending changes to the application that will make it more reliable, performant, secure, scalable, and cost-effective in the cloud environment. It should also include the design for any necessary integrations. |
| Application refactoring | If the application needs modification in order to work well (or more optimally) in cloud IaaS, the professional services provider may be able to perform this modification, or support an SI partner that can perform such work. |
| Security architecture | You want a third party to help you to design or validate the security of its solution, including assistance in meeting regulatory compliance requirements. This may also include services such as penetration testing and application security testing. |
| Initial deployment | You want a third party to help with the launch of a new application, or assist with migrating your application to cloud IaaS. This will include the initial provisioning and configuration of cloud IaaS components. It may include installing the OS, middleware and application software. It is likely to include securing all elements. It may include development, test and production environments. It may also include assistance with configuring any integrations. |
| Event management | You are anticipating a major one-time event that will drive significant traffic (such as a sports championship), or are concerned about a major upgrade – and want assistance in ensuring that your solution will scale and perform well. You also want that expert assistance to be available during the event itself. This may incorporate capabilities such as load and performance testing. |
| Transformation assistance | You may need to redesign your business processes, IT operations processes or application development life cycle, or restructure your organization for digital business. Such assistance is often not purely technical; it may also require management consulting. In the Mode 2 context, transformation assistance is often specific to just the digital business applications; transformation of the IT organization as a whole is typically a Mode 1 journey. |
Source: Gartner (January 2016)
MSPs typically provide four general categories of managed services for digital business applications in cloud IaaS. See Table 2 for capability categories, the reasons that you would adopt them, and approximate prices (for broad guidance only).
The pricing environment is evolving rapidly. Your individual quoted prices may vary significantly, depending on the mix of services you take from the cloud IaaS provider, the complexity of your environment, your rate of change, your need for proactive versus reactive support, and many other factors. See our Pricing and Buyer's Guides for details.
| Capability Categories | Use When … | Approximate Prices |
|---|---|---|
| CMP as a service | You want CMP functionality as a service; this includes capabilities such as billing management, capacity management, access management, logging, and support for integrating the cloud environment with on-premises infrastructure. The service includes not just the CMP itself, but also ongoing best-practice guidance in using the CMP. These CMP capabilities are usually paired with other managed services. | This service varies in cost based on what capabilities are within the CMP; it may be free in conjunction with other managed services. |
| Guided operations | You want something beyond the scope of the cloud IaaS provider's technical support, but do not need the provider to manage the environment on your behalf. You want assistance and guidance while you manage the environment yourself. | The managed services price is typically $0.10 to $0.15 per dollar of cloud IaaS spend. |
| Frontline operations | You want the MSP to handle frontline operations (monitoring, responding to alerts, incident management and problem management, including collaborating on root-cause analysis). You also want the MSP to assist you with other routine operational tasks, such as configuring the cloud provider's services and managing the OS on virtual machines (VMs). | The managed services price is typically $0.15 to $0.25 per dollar of cloud IaaS spend. |
| Platform operations | You do not want to manage anything other than your own content and application code. You would like the MSP to take care of operating the environment to as great an extent as possible. | The managed services price is typically $0.20 to $0.50 per dollar of cloud IaaS spend, depending on the complexity of each tier of application components. |
Source: Gartner (January 2016)
Many MSPs standardize their managed services into tiers; these tiers will typically resemble the categories given above, but because managed services in this market are still evolving, the tiers are never standard, and some MSPs may offer more or less in a given tier. Many MSPs also offer capabilities beyond the scope of the chosen tier; those capabilities are priced separately and may be offered on a time-and-materials basis. You will usually choose a tier on a per-account basis, so that you can separate development, testing and production environments into different levels of managed services support. Note that any service that must be performed manually will be more expensive than a service that can be automated.
Contracting Benefits
MSPs may offer additional benefits related to contracting for cloud solutions. Cloud IaaS providers often have relatively inflexible contractual terms due to their need to offer a standard service at a standard price. MSPs, by contrast, are often willing to take on greater contractual risk, and may agree to stronger and broader SLAs, higher liability limits, and stronger security guarantees; such guarantees may result in higher costs, however, and the MSP may require a particular architecture or set of operational processes in order to ensure it can deliver the contracted level of service.
MSPs may also be able to offer a discount on the underlying cloud services. They may receive a reseller or volume-based discount from the provider, allowing them to offer lower prices to their customers. They may also take advantage of prepurchase plans from the provider; for instance, an MSP may hold a large pool of Amazon EC2 reserved instances, which usually allows customers to have greater flexibility in choosing reserved instance types, at a price that is lower than the on-demand price but higher than the regular AWS reserved instance price, allowing the MSP to make money on the arbitrage.
Customers that already receive acceptable contract terms from their cloud IaaS provider, and have good volume-based discounts, may not want to use the MSP as a reseller of that cloud provider's services. MSPs may try to pressure customers into purchasing from them, rather than directly from the cloud provider, but it should not be necessary to do so. MSPs should have the tools and capabilities to manage cloud accounts they do not own, and most cloud providers have the ability to recognize channel revenue from a partner MSP without requiring the MSP to resell their service.
How Long Will You Use an MSP?
You should consider what role you want to play in the ultimate outcome, and how long you want to use managed services. This will influence the way you adopt managed services, the depth of the partnership, and the contract terms that you will seek. The greater a role you want to play over the long term, the more important it is for the MSP to be able to help train your staff and collaborate on a sustainable approach to service delivery. There are typically three time frames and associated styles (see Table 3):
| Length of Service | Use When … |
|---|---|
| Short-term staff supplementation | You want to gain the skills to operate this application and the cloud IaaS environment, but want the MSP to ensure that best practices are used from the start. You will typically use the MSP for one to two years. |
| Long-term staff supplementation | You expect to use the MSP over the long term in order to meet 24/7 operations requirements, supplement internal skills or overcome a lack of sufficient internal staffing. You may also value the MSP for CMP capabilities as a service. |
| Long-term outsourcing | You plan to use managed services over the long term. You may have a general preference for outsourcing (and may not have any internal IT operations of your own as a result), not want to build skills internally to manage this application or cloud IaaS in general, believe that performing this function internally won't be cost-effective, or do not want to use internal staff to meet a 24/7 operations requirement. |
Source: Gartner (January 2016)
The actual managed services functions that are performed by the MSP will depend on the style of cloud operations that you want to adopt.
There are three common approaches to operating digital business applications in cloud IaaS:
Rented infrastructure. Cloud IaaS is treated like renting infrastructure, with little or no use of cloud-native capabilities and a traditional approach to IT operations management (rather than DevOps). This results in relatively few management efficiencies; although it may deliver cost-efficiencies for workloads needing variable capacity, it may be potentially more expensive for steady-state workloads that do not inherently benefit from a pay-as-you-go model.
Programmatic infrastructure. Cloud IaaS is treated as programmatic infrastructure – "infrastructure as code." The cloud provider's APIs are used to enable automation as much as possible, and a DevOps style of operations is adopted. Cloud-native capabilities, including PaaS-layer basic middleware components (such as databases and message queues) and management tools (such as monitoring and autoscaling), are used when doing so does not significantly limit long-term application portability. More limited use may be made of capabilities that might create greater lock-in to the provider; this means that the customer needs to either forgo that functionality or obtain it through other means.
Comprehensive adoption. The full spectrum of the provider's IaaS and PaaS capabilities are used to the extent that makes sense for the applications. DevOps tools and processes are integrated with the provider's APIs and management tools. This approach leads to the greatest value, but also the most lock-in.
These three approaches result in different needs for managed and professional services.
The rented-infrastructure approach is more common for Mode 1 applications than it is for Mode 2 applications. While it is suboptimal but acceptable for Mode 1 applications, it is generally inadvisable for Mode 2 applications. This approach is often the result of a Mode 2 application being hastily moved from on-premises or a hosting environment into cloud IaaS, often because the current environment cannot meet new requirements for scaling, or because a colocation or hosting contract is about to expire.
While it is certainly possible to manage cloud IaaS as if it were traditional infrastructure, this is usually the least cost-effective approach due to the use of manual labor rather than automation. Moreover, this approach can lead to greater variability in operational quality, less agility, and thus less value to the business; Mode 2 applications can benefit strongly from cloud IaaS, and this approach steals some of that value.
However, because "rented infrastructure" does not require as many cloud-specific skills, and because more manual labor means more billable hours and higher managed services prices, a very large number of MSPs and consultancies will eagerly deliver managed and professional services for this approach.
When the rented-infrastructure style of operations is used, professional services are typically characterized by:
Readiness assessment and cloud provider selection. This assessment may be heavily focused on a cost analysis of various infrastructure options, including noncloud solutions such as managed hosting on dedicated hardware. A good assessment should also consider the level of effort to adopt one of the other operational styles, since programmatic infrastructure and comprehensive adoption can significantly change the cost analysis.
Solution architecture. This project is likely to focus on a least-effort placement of your application in the chosen cloud provider. This might not reflect a best-practice architecture, especially if you use consultants that are not expert with this particular cloud IaaS provider, or you insist that your cloud environment must resemble your on-premises environment as much as possible.
Application refactoring. Application refactoring is very rare for this operational style, since the point is to move the application unchanged.
Security architecture. Most consultants will recommend using some of the cloud provider's native security capabilities in order to get better defense in depth, even if the customer is reluctant to use proprietary provider capabilities. This will often be combined with traditional on-premises security solutions deployed as virtual appliances or as agents on VM hosts.
Initial deployment. It is rare for consultants to do an initial deployment for a "rented infrastructure" approach. However, this service will normally be offered for free, or at a low price, in conjunction with managed services.
Event management. Most professional services providers will strongly discourage a customer with a critical scale-out event from taking a "rented infrastructure" approach. Load and performance testing are critical to determining how much infrastructure to provision, since this operational style may prevent being able to rapidly and automatically respond to changing capacity demands.
When the rented-infrastructure style of operations is used, managed services are typically characterized by the following:
CMP as a service. You will probably find CMP functionality to be valuable, particularly for cost visibility and cost control. Because you are using very few of the cloud provider's capabilities, you will probably not care about the degree to which the CMP supports cloud-specific functionality.
Guided operations. You are unlikely to adopt this type of managed service, since you are unlikely to be using the cloud provider's capabilities in a complex way that would require more than technical support.
Frontline operations. In addition to monitoring and incident management, the MSP will typically perform cloud IaaS configuration and troubleshooting, OS and patch management, and managed security. You may also want the MSP to perform operational database administration. These tasks are often performed manually by the MSP's system administrators, although they may be augmented by automation.
Platform operations. In addition to all the tasks performed in frontline operations, the MSP will also take care of middleware operations, including patches and upgrades. This also includes performing operational database administration. This may also include operations for common applications and content management platforms, such as Microsoft SharePoint, Adobe Experience Manager and WordPress. These tasks are often performed manually by the MSP's system administrators, although they may be augmented by automation.
The majority of Mode 2 cloud IaaS customers that are targets for managed and professional services will initially prefer a programmatic-infrastructure approach, although as they become more comfortable with the underlying platform they may move on to embrace comprehensive adoption. Even when customers initially think they want more of a rented-infrastructure approach, MSPs and consultancies will normally strongly encourage customers to adopt programmatic infrastructure instead – whether directly through advocacy, or indirectly through the much higher cost of traditional operations management compared to DevOps-style cloud-native management.
Solutions of this sort are typically characterized by:
Scale-out architecture (and, in many cases, cloud-native architecture)
Programmatic provisioning, which may be done via blueprints (whether native to the provider, part of the MSP's CMP, or via a third-party service such as RightScale or Scalr)
Configuration management using a tool such as Ansible, Chef or Puppet, possibly in conjunction with the cloud provider's related services
Autoscaling, via the cloud provider's native capabilities if available, or external services or tools if not
Use of the cloud provider's middleware services when this does not reduce portability, such as database as a service
Integration with continuous integration/continuous deployment (CI/CD) tools such as Jenkins or CircleCI, or the cloud provider's CI/CD service
When the programmatic-infrastructure style of operations is used, professional services are typically characterized by:
Readiness assessment. Consultants determine the level of effort necessary to ensure that your application will run well in the cloud, and the degree to which operations can be automated.
Cloud provider selection. Consultants determine which cloud provider is the best fit for your application, based on cloud provider functionality and a total cost of ownership (TCO) approach that takes into account the degree to which operations can be automated.
Solution and security architecture. Consultants determine how best to architect and operate your application in your chosen cloud provider. Security is an integral part of the overall architecture. This service is often offered for free or at minimal cost, in order to win a managed services deal.
Application refactoring. Applications may need modification to scale cost-effectively in the cloud. It is sometimes also beneficial to directly instrument applications for autoscaling and other automated responses to the environment. Applications may also be modified in order to improve overall resilience, which may include resilience not just to infrastructure failures, but also failures or poor performance of other application components.
Initial deployment. In addition to setting up the environment, an initial deployment typically includes template-building as well as scripting of DevOps automation for that environment. One-time DevOps automation may be sold as a stand-alone professional service. However, this is more commonly performed as part of a managed service, and the initial deployment is often either free or performed for a nominal cost.
Event management. Consultants help to architect and test a scalable solution, which will usually include the use of autoscaling, a content delivery network (CDN), and solutions for "overflow" if your application becomes overwhelmed more quickly than it can be scaled.
When the programmatic-infrastructure style of operations is used, managed services are typically characterized by:
CMP as a service. You are likely to use the MSP's CMP to govern the MSP's access to your cloud environment. You are also likely to use billing and capacity management capabilities. The MSP should provide advice and assistance in "rightsizing" your infrastructure (indeed, ideally the CMP should automate this), use autoscaling where possible, and maximize your ability to take advantage of discounts.
Guided operations. The MSP provides ongoing assistance with best practices for architecture and operations. It maintains a library of templates and DevOps automation for common components and applications, which you can use and modify. The MSP may assist you in adapting their templates and scripts for your environment.
Frontline operations. The MSP provides DevOps engineering (automation of your environment) as well as monitoring, incident management and managed security. They will manage your OS, but rather than performing patch management, they are likely to build new images and reprovision, or otherwise perform updates in an automated fashion, including potentially integrating with your application release automation or CI/CD tools. Many MSPs will encourage use of the cloud provider's database as a service, and will provide support for that service.
Platform operations. In addition to all the tasks performed in frontline operations, the MSP will manage your application stacks, usually via application release automation rather than manual patches and upgrades. Custom DevOps automation will be built for your environment if necessary.
Very few customers begin with comprehensive adoption; rather, many customers begin with programmatic infrastructure, but expand their use of the cloud provider over time, adopting more and more of their capabilities. Eventually, cloud-native capabilities are chosen whenever feasible, and those capabilities are exploited to their fullest. Many MSPs encourage customers to comprehensively adopt a cloud provider, since this often reduces TCO.
Cloud-native, scale-out architecture
Programmatic provisioning, which may be done via blueprints (usually native to the provider, but may be part of the MSP's CMP or a third-party service)
Configuration management via the provider's native service or independent tools
Use of the provider's autoscaling capabilities, if available
Use of the provider's native management capabilities where possible
Use of the provider's middleware services and other components where possible
Integration with CI/CD, whether the provider's native service or independent tools
When the comprehensive-adoption style of operations is used, professional services are typically similar to such services for the programmatic-infrastructure style, with the following changes:
Readiness assessment and cloud provider selection. This assessment will assume that you adopt cloud-native capabilities wherever possible.
Solution and security architecture. The consultants will suggest the use of the cloud provider's native capabilities to the extent that they are feasible and cost-effective for your application.
Application refactoring. Applications may be modified to use cloud-native components where possible. In some cases, application architectures may be entirely redesigned in order to take advantage of new cloud services that deliver unique capabilities. Any dependencies on proprietary APIs should be encapsulated in libraries.
Initial deployment. The DevOps automation that is built as part of the initial deployment may take advantage of the cloud provider's proprietary APIs and capabilities. The DevOps tools themselves may be specific to the cloud provider.
Event management. Consultants may use unique capabilities of the cloud provider in order to ensure that the solution is scalable and performant.
When the programmatic-infrastructure style of operations is used, managed services are typically similar to such services for the programmatic-infrastructure style, with the following changes:
CMP as a service. The CMP is likely to be tightly integrated with a spectrum of the cloud provider's capabilities, and may be entirely provider-specific.
Guided operations. The MSP's templates and DevOps automation will use the cloud provider's native capabilities where possible.
Frontline operations. The MSP will use the cloud provider's management capabilities where possible. You will also be strongly encouraged to use the cloud provider's middleware capabilities whenever possible, rather than running middleware in a VM. If the provider has a specific native solution that fits your requirements, you may be encouraged to use it instead of assembling a solution yourself. In some cases, the MSP will wrap additional automation around those capabilities. The MSP may integrate the cloud provider's native capabilities with third-party services and tools.
Platform operations. When the MSP manages your application stacks, it is likely to do so through a combination of the cloud provider's native capabilities and its own automation.
Cloud IaaS providers are not commodities, and should not be treated as such. IaaS+PaaS providers are especially complex due to their range of services and their depth of functionality. You should expect that a high-quality MSP for an IaaS+PaaS provider should be able to manage not just the infrastructure, but also all of the commonly used PaaS functionality, and also be capable of supporting the provider's native management solutions.
It can be difficult to determine whether or not an MSP or consultancy – a cloud provider partner – has the necessary depth of expertise and experience with a cloud IaaS provider. Factors to consider include those listed in Figure 1.
Source: Gartner (January 2016)
Every cloud IaaS provider's partner program is different. For an example of provider-specific market dynamics, see "Market Guide for Managed Service Providers on Amazon Web Services." For more detail on how to choose an MSP for AWS, Microsoft Azure or GCP, see "How to Choose a Managed Service Provider for a Hyperscale Cloud Provider."
Because cloud IaaS providers are not commodities, and infrastructure should be managed differently for Mode 2 applications than Mode 1 applications, MSPs should have CMPs and other management tools that are specifically designed for DevOps environments. Even if the MSP does not take a DevOps approach for all customers, the MSP should be capable of leveraging the provider's native capabilities and API.
Also, an MSP should not prevent you from adopting the full breadth of the cloud provider's functionality if you wish to do so, although it may decline to provide direct support for all elements. Be aware that you may need to pay the cloud provider directly for technical support if your MSP cannot support all of your solution elements, which may increase the overall solution cost; it would be strongly preferable to use an MSP that can support all of the cloud provider's services that you are using.
Furthermore, the MSP's CMP should not attempt to commoditize the cloud provider's infrastructure, or be limited only to infrastructure elements. It should be able to discover and govern all usage of that cloud provider's services, regardless of whether you provision the services via the CMP or via the provider's self-service portal or API, or whether their usage fluctuates based on automated actions (such as autoscaling).
Some MSPs are able to manage an application that is split across multiple cloud IaaS providers, but this is both a relatively rare architecture and a relatively rare set of MSP skills. MSPs are more likely to be able to manage a multicloud service where each of the services are fairly similar – for instance, if you have files that are spread across multiple cloud object-storage providers for redundancy.
You may need to choose multiple MSPs if you use different cloud IaaS providers for different applications. An MSP that provides a highly expert, high-quality service for one cloud IaaS provider might not be able to do the same for another provider. Moreover, because cloud IaaS offerings are differentiated, providers typically have different target customers and use cases, and thus an MSP may offer different managed services on different providers.
Mode 2 applications – and digital business applications in general – benefit from a DevOps style of management, and DevOps is the most natural and most efficient style of management for cloud IaaS. Managing cloud IaaS should not be like managing traditional infrastructure. "Infrastructure as code" enables a high degree of automation, and more sophisticated cloud IaaS providers offer an array of solutions that substitute automated services for manually managed software running in VMs.
DevOps engineering requires not only a strong operational understanding of infrastructure and the entire application stack, but it requires excellent software engineering skills. DevOps engineers do not just "write some scripts"; they are operationally knowledgeable developers that must create reusable, maintainable code with the same discipline as application software engineers. Moreover, DevOps is fundamentally collaborative. The MSP is likely to need to routinely work with your development organization, especially if you have a high rate of change in your environment.
Unfortunately, many MSPs with roots in traditional infrastructure management services have a core set of skills that is focused on manually installing and administrating vendor-provided hardware and software. Such MSPs may have used open source or commercial IT operations management tools to perform some tasks in an automated fashion, but they have not previously written a lot of software themselves. Consequently, they may not have DevOps skills, or may have only recently built up DevOps competency.
When choosing an MSP, consider the list in Figure 2 when evaluating the MSP's DevOps expertise.
Source: Gartner (January 2016)
You should contractually guarantee that if you choose to leave the MSP, you should able to take all of the DevOps automation code and templates that are specific to your environment – of course, excluding anything that is fully encapsulated within the MSP's proprietary CMP or is otherwise nonportable out of the MSP's environment.
Source: Gartner Research Note G00295689, Lydia Leong, 5 September 2017
Return to Home
© 2009-2017 Copyright by Zhuyun Cloud All rights reserved Terms Of Service Privacy Policy