Is there a best-fit pricing model for public cloud management services? - 1

Adoption of digital technologies, especially cloud, is at an all-time high and businesses are increasingly demanding managed service providers and IT organizations to cater to their dual-speed IT needs. Gartner calls this phenomenon Bimodal IT, others call it dual speed/mode IT, and so on. As usual there are many people for it and against it and I don’t think anyone meant agility at the cost of stability or vice versa. However, the need is loud and clear. Certain sets of workloads demand IT to focus more on stability (stability mode) and another set, the ones with faster time-to-market and faster adaptability requirements, demands IT departments to focus on agility (agility mode). Public cloud infrastructure is at the center of this as it is the foundation to enabling these needs.

While this scenario poses many challenges, one of the key challenges is understanding the pricing for managing IT infrastructure environment on cloud. Did you think there was no infrastructure to be managed on a public cloud? The pace at which organizations are adopting the Infrastructure as a Service (IaaS) model on cloud, using lift and shift migrations and creating shadow ITs all around, there is enough and more to manage, for a few more years to come!

The industry has figured out decent pricing models for the stability mode operations, some are complex and some simple. The prominent pricing models are:

• Fixed price
• Time and Material (T&M)
• Service/ element-based
• Transaction-based
• Output-based
• Outcome-based
• Gain share

Most of the models are about delivering on the agreement/commitment based on a defined scope of work and expected outcomes within the defined parameters, irrespective of the number of people or tools that one uses to deliver.

The advantage of the stability mode is that, it has matured over time with infrastructure environments being standardized and emergence of benchmarks in operations management practices. With this, both providers and customers are able to determine to what it takes in terms of skills, time, effort, and tools to deliver on agreement/commitments.

However, in the agility mode, these standardizations or benchmarks are not available yet, making it very difficult to scope and estimate efforts eventually making it difficult to price the services around it. Many analysts say, more than 50 percent of the providers do not have proper mechanism to price this mode of delivery.

Let us examine a case of managing a customer's public cloud environment where more and more of the agility mode workloads are moved to. A typical public cloud environment of a medium to large-sized enterprise would have:

• Mix of both Dev/Test and Prod workloads:
  • In the agility mode, dev/test and prod environments are more of a continuum and not separate silos
  • Workloads that require mixed SLAs (Eg: Prod and dev/test expect different SLAs – prod is short transactions/uptime-based and dev/test is about build/release, which is longer )
  • Ratio of requests v/s incidents (Eg: Dev/test is more about requests and less about incidents and many times less segregation of requests/incidents)
  • ITIL service management vs DevOps methods (Eg: Dev/test is less of ITIL (change/availability/capacity/SLM, etc.) but more of ALM process (versioning, build, test, release, configuration, etc.)
  • Production toolsets v/s Dev/test/DevOps tool chains (Eg: In Dev/Test the tools are too many and they are expected to be managed as part of the ‘management’ and in Prod it’s different)
  • Skillset required to manage the environments are different – (Eg: Dev/Test management resources need skills on languages, ALM process, tools over and above Infra. Also, in Dev customers prefer single tier support (Eg: someone who can do L1 to L3 activities)

• Mix of IaaS, PaaS components with SaaS integrations
  • Infrastructure as a Service (IaaS) components are limited to VM, storage and network. Plumbing is more and hence prone to more failures at platform level, but you still manage less to a non-cloud world
  • There are a lot of Platform as a Service (PaaS) components you use for IAM, DB, big data, backup, recovery, mobile backend, queues, headless servers, app services, etc. While this required very less management work, there is some plumbing always, but at varying degrees for each
  • The above points mean that VM cannot be the unit for pricing unless large percentage (90?) of the resources in customer’s cloud environment are VMs. There are still caveats based on the application deployment model (think of loosely couples, stateless, auto scaled ones)

• Varying deployment architecture of the resources  
  • In case of a cloud native deployment, there is heavy use of auto scaling, template-based deployment, configuration automation, etc. This means that the environment is variable and not fixed
  • Many workloads use a mix of IaaS and PaaS in a cloud native model. This means that the workload type and its deployment model determine the effort needed to manage
  • Basically, customers do not have a standardized environment and all of the above means work involved on each cloud environment cannot be ‘standardized set of activities’, as yet

• Varying level of management efforts (Layers)
  • Cloud Platform level activities – mostly provisioning, plumbing (new term for integration), sprawl management, continuous automation, IAM administration, cost management, standardization and continuous optimization, etc.
    • The efforts for these are highly variable based on the environment design and the level of automation applied
  • OS level activities – the typical stuff that we do on OS including patching, backup, and so on, but with more automation
    • This is applicable only for IaaS models and I’m sure we have standardized them
    • The efforts for this will be zero to very minimal in case of stateless workloads
  • App platform level activities (running on top of the OS) – Database management , webserver management, app server / middleware management, libraries management, etc
    • Again, applicable for Iaas and we have standardized this as well
  • Tool chains level activities – This gets added when there is a Dev/test/DevOps scenario
    • This highly dependent on the tool chains, dev methods used and release frequencies

This brings us to the end of the first part of our discussion where we discussed about the traditional pricing models and the typical characteristics of public cloud management. In part 2 , I will discuss whether the established models will work and, if they do or not, what could potentially be done to address the situation. Let me know what you think in the comments below!