Cloud-Based Managed Services – The Current Reality of a Digital Transformation

As personal experience of recent years shows, beautiful words like “digitalization”, “digital transformation” and other popular phrases that are supposed to emphasize the incredible “advancement” of a company on its way to new heights of cloud business – very often they are just a beautiful signboard, which hides the level of 20-year old business and the sluggishness of management, who after “20 years of success” are no longer able to think differently, just the criteria of that very “digital transformation”… No, this article will not be about different personal-psychological practices of “how to adopt new things” and “read more and think innovatively”.

This article will be more practical – I will try to formulate my own vision of what is truly “transformed” Managed Services for Cloud (in my case it will be about Azure and based on my personal experience of creating and managing the respective department) as opposed to “traditional” Managed Services, to which “dinosaurs” continue to gravitate under the sign of “digitalization”.

So, how should organizations that provide modern Azure Managed Services differ from those with “traditional” Managed Services and how should the latter go about providing truly modern Managed Services for clouds rather than a Level 1 call to “we’re not running a virtualization – please overload”?

Clouds are a significant change in management as they add a new level of flexibility to Managed Services not previously achievable through their notification, monitoring, automation, automated health and security services on top of cloud capabilities such as elasticity, scalability and resilience. Accordingly, Azure Managed Services customers expect the service provider to use all of these tools to ensure that their business services and business processes as a whole, rather than individual virtual machines, are running uninterrupted and the “oops, my virtual machine isn’t working” conversation simply cannot happen within cloud Managed Services. Customers also expect Azure Managed Services providers to have their Operational Excellence methodologies and approach transformed and adapted to the cloud environment too, where not only reactive decision health and SLA monitoring and automation tools are used, but also services to automatically improve business service infrastructure based on analytics, anomaly and predictive capabilities through cloud services like Log Analytics or Sentinel. And of course – customers expect help in migrating to the cloud and further adapting their traditional “terrestrial” solutions – this aspect is not even discussed – and if the migration itself has already taken place – most often the option of migrating existing “terrestrial” services as Azure IaaS virtual machines – customers expect the Azure Managed Services provider to take further steps in transforming such infrastructure into native Azure services.

And here’s the first huge difference between traditional and cloud-based Managed Services – the customer sees the Azure Managed Services provider as not just “outsourced hands” to be used to perform routine operations like “reloading a virtual machine”, but rather as a trusted person, who primarily provides the expertise to ‘move to the cloud’, with the customer expecting to be able to communicate with a top-notch SME (Subject-Matter Expert) on the full range of Azure services that are outlined in the contract, and the communication between the customer and the service provider will be in the style of the famous dialogue:

  • Now here’s a suggestion: what if
  • We shouldn’t.
  • I see. Then maybe we should.
  • Don’t need to.
  • I see. Allow at least
  • Try this one.

I will probably repeat myself on this point because many managers of “traditional” Managed Services hear this point like a diplodocus with a very long neck – in the case of a public cloud like Azure, the customer can do a lot of basic operations themselves – good thing Azure greatly simplifies many administrative routines and provides excellent management tools – whether it is Azure portal or Azure PowerShell and others – and not those local “clouds” with trivial virtual machines, that have proliferated over the past 10-15 years without becoming a true cloud and are unable to provide a decent management toolset for the customers and then all the “dancing around” each virtual machine has to be done solely by the Managed Services provider’s personnel. With Azure, the customer doesn’t need the dense, locked-down cloud infrastructure that only the traditional Managed Services provider’s staff can access this creates a middle ground in solution deployment and significantly slows down the process – in sharp contrast to the goal of clouds to accelerate business by rapidly adapting and deploying IT services. But Azure continues to be difficult enough for customer engineers, whose responsibility it is to the business services, not how they are delivered in Azure – hence it is the expert services provided by the Azure Managed Services provider which is the main differentiator of the “new” provider of modern cloud Managed Services.

The second differentiator for an Azure Managed Services provider is the SLA. No, not the SLA that Managed Services providers like to write about in their contracts – guaranteed response and recovery time, that’s all anyone cares about in the cloud – Azure cloud is a lot more stable than all those “local clouds” – but actual, proven SLA of specific business services. That’s right – the customer makes the SLA requests for their critical services and the Managed Services provider delivers. And that’s where the first point comes in – the Azure Managed Services provider provides “heads” rather than “hands” whose job it is, among other things, to improve the customer’s infrastructure (within the Managed Services contract) to achieve the required SLA level of a specific critical business service. The next step is purely technical and financial – the challenge of reaching the required SLA – whether this is technically feasible within Azure and the customer’s specific business application and whether the customer is ready to pay for all the “wants” to reach such an SLA. Azure can be “tricked out” to achieve high availability, reliability, disaster tolerance, and recovery for a particular solution – so it’s doable for a “real” support specialist (not L1 who “has to overload a VM”) without too much trouble. But the most interesting thing in this case with SLA is if the “legacy” application itself is not adapted to work with the scalability and high-reliability tools in Azure and a modification or even a total change of the solution architecture is required. That’s where the third, and by far the most important, differentiating feature of a modern cloud Managed Services provider, as opposed to “traditional” Managed Services.

So, the third difference is that today’s Managed Services cloud providers do the basic work for customers, not as part of a “ticket” to “overload VMs” or “resize VMs”, but as part of a continuous adaptation and optimization of customer services in the cloud. Think of it as an ongoing ongoing ongoing phased project of upgrading, implementing new components, optimizing existing ones, etc. No legacy business models where the contract specifies the number of virtual machines, networks and other things to maintain and everything new is a separate “planning and deployment project” done by Professional Services. In the case of Azure Managed Services cloud, all infrastructure development in the cloud, perhaps with plans for a year or even several years, is the task and responsibility of the Azure Managed Services team. Does it look very demanding? Maybe, but we’re not talking about ‘rewriting’ applications (although such services are offered by some cloud Managed Services providers), but consulting with the customer’s developers and recommending changes to the application code or architecture according to Microsoft’s best practices for Azure. In fact, the experts of the Azure Managed Services team are both problem setters for developers (together with the customer) and SMEs for the solution architecture, because one of the areas of responsibility of an Azure Managed Services provider is the SLA of the applications and services and their architecture has to be planned for meeting the agreed SLA. And what about planning and implementing new services in the cloud for the customer – and this is also the job of the Azure Managed Services team. Firstly, because any cloud infrastructure is first and foremost about following best practices and they are talking about building HUB-SPOKE type virtual data centre solutions and after building the central hub all additional services are connected by type projects, as spoke – and there is no need to “grow” anything serious, involving “Professional Services” at all. Secondly, it is Managed Services team that has all actual information about client infrastructure, possible additional limitations or requirements, plans for the deployment of other services and much other information – therefore, in fact, a project of such improvements or will be associated with a long process of knowledge transfer between Managed Services team and Professional Services “architecture” team with the subsequent approval of results, etc. – which makes such project significantly cumbersome and expensive, or it can be done by Managed Services team with involvement of necessary SMEs for some specific solutions just from Professional Services team. Although, as experience shows – L2 Azure Managed Services engineer after a year of active work in a large corporate customer environment will give a big head start to Professional Services “architect” in planning and implementing solutions in the served environment – because he has the practical experience and much deeper understanding of the specific environment – so in reality, in my personal experience – SME involvement from “Professional Services” was not required at all – all planning and implementing new solutions and upgrading existing to meet SLA was done only by L2 engineers and L3 architects.

And here’s where another difference comes in – normal customer interaction requires an ongoing technical dialogue where plans and projects are discussed, and the customer can ask relevant technical questions like “Can we do this?” to the very same Azure SME who has a full understanding of the customer’s infrastructure. And this dialogue needs to be ongoing, regular and proactive on the part of the Azure Managed Services provider, i.e. – the Azure Managed Services team that works with a particular customer needs to have someone on board who will act as a notional “Technical Account Manager” (TAM) for the customer. Practice shows that it is the L3 support Azure Architect who does a great job of regular technical communications with customers and is the primary SME for Azure, the single point of contact for all technical issues and participates in all infrastructure planning and development meetings/meetings, and of course – the Azure Managed Services team leader for a specific customer. This notional TAM must have full knowledge of the customer’s infrastructure, be aware of infrastructure development plans, allocate and plan team resources for future projects and lead ongoing projects from a technical expertise and management perspective. And, again – as practice shows – the persona of such a TAM has a major impact on the success of work with a particular customer, his satisfaction with the service and much more. So regular phone calls a couple of times a week and proactive work (all this Operational Excellence – about this – in the next part) are very much required from TAM.

Another difference between cloud Managed Services and ‘traditional’ is the ‘cost of issue’ – moving away from ‘counting by head’, i.e. by the number of virtual machines maintained with a fixed price per VM, to a percentage of the cloud’s disposal price. You should agree that counting the cost of cloud services by “heads” of VMs, while one of the objectives of modern Azure Managed Services – infrastructure optimization, ensuring SLA for business services and applications – requires upgrading applications “embedded” in VMs in IaaS environments to PaaS services and which automatically removes VMs in the future – is extremely strange. Plus Azure has a lot of services that need to be managed and can’t be counted “by head”. Therefore – only a percentage of disposal. Again – depending on the set of services provided within the Managed Services, the percentage may vary from 10% to 30% of the cost of Azure resources themselves. This, in turn, makes it easier for Managed Services team to pay close attention to infrastructure cost and optimization issues (which also makes it easier for Managed Services team to implement SLA’s), and Managed Services is interested in continuous infrastructure development and driving migration of customer services from on-premises infrastructure to the cloud. And the recycling growth metric (and thus the Azure Managed Services cost growth) is a great KPI for the new cloud team (along with the updated SLA KPI – just not the one representing “obscure response tickets”, but the customer business application SLA).

And so about the KPIs and other steps a service provider needs to take (like implementing a cloud-based Operational Excellence variant) to transform “traditional locked-in” Managed Services into modern cloud-based/Azure Managed Services – we’ll talk in our next article on this topic.