The Evolution of Cloud Services and What It Means for ITSM

How decades of cloud transformation have reshaped the risks, responsibilities, and reality of IT Service Management

The shift to cloud has been one of the most significant transformations in the history of enterprise IT, and yet many ITSM practices are still catching up. What began as a cost-saving exercise — shifting workloads off ageing tin in dusty server rooms — has matured into a sprawling, multi-layered ecosystem of services, platforms, and dependencies that fundamentally change how we design, deliver, and support technology. For ITSM professionals, this evolution isn’t just a technical curiosity. It directly affects how we manage incidents, govern change, define service boundaries, and protect the organisations we serve. Here’s a look at how cloud has evolved, the risks it has introduced, and what it all means for modern ITSM.

---

1. A Brief History of Cloud — From Renting Servers to Running Everything

To understand the impact on ITSM, it helps to recognise just how far cloud services have come.

• The early days (mid-2000s): Infrastructure as a Service (IaaS) emerged as a way to rent virtual machines, storage, and networking on demand. AWS EC2 launched in 2006 and effectively created the modern cloud market.
• The platform era (2010s): Platform as a Service (PaaS) abstracted away the underlying infrastructure entirely, letting developers deploy applications without worrying about the operating system or patching schedule.
• The SaaS explosion: Software as a Service became the default consumption model for everything from email and CRM to HR and finance. Suddenly, business units could procure services without involving IT at all.
• Containers and serverless: Docker, Kubernetes, and serverless functions (AWS Lambda, Azure Functions) shifted the unit of deployment from servers to workloads — and then to individual functions.
• The multi-cloud and hybrid present: Most organisations now run a blend of on-premises systems, private cloud, multiple public clouds, and dozens (sometimes hundreds) of SaaS applications. Edge computing and AI-as-a-Service are layering on top.

Each step in this evolution has delivered genuine benefits: speed, scalability, elasticity, and a shift from capital expenditure to operational expenditure. But each step has also chipped away at the traditional boundaries that ITSM was designed around.

---

2. The Disappearing Service Boundary

Classic ITIL® thinking assumed a relatively clear line between what IT owned and what it didn’t. The CMDB held configuration items, change management governed what was deployed, and incident management was triggered when things broke inside that perimeter.

Cloud has blurred — and in some cases erased — that boundary.

• You no longer own the servers, the operating systems, or in many cases the applications themselves.
• The service provider’s outage is now your outage, but their root cause analysis is rarely yours to see.
• SLAs are written by the vendor, not negotiated by you, and credits for downtime rarely reflect the actual business impact.
• Configuration items now include API keys, IAM roles, container images, and ephemeral resources that may exist for minutes rather than years.

In my opinion, this is the single biggest challenge facing ITSM today: we are accountable for service quality across systems we do not control, using data we cannot always access, governed by contracts we did not write.

---

3. The New Risk Landscape

Cloud doesn’t remove risk — it redistributes it. And many of the risks that have emerged are ones traditional ITSM frameworks were never designed to address.

Shadow IT and Procurement Sprawl

SaaS makes it trivially easy for a department to swipe a corporate card and onboard a new tool. Before long, the organisation is running fifteen overlapping productivity apps, none of which are in the CMDB, and none of which have been through a security review. Service desks are then expected to support tools they didn’t know existed.

Vendor Lock-In and Concentration Risk

Whilst the major hyperscalers offer extraordinary capability, their dominance creates concentration risk. A regional outage at one provider can take down a frightening proportion of the global internet — and your business along with it.

Data Sovereignty and Compliance

Where is your data, exactly? Which jurisdictions can compel access to it? GDPR, the Data Protection Act, sector-specific regulations, and emerging AI legislation all impose obligations that are harder to meet when data crosses borders invisibly.

Cost Volatility

The OpEx model is a double-edged sword. A misconfigured auto-scaling rule, a runaway query, or an unmonitored data egress charge can turn a predictable monthly bill into a board-level conversation overnight. FinOps has emerged precisely because cloud cost management has outgrown traditional financial controls.

Security Drift

The shared responsibility model is one of the most misunderstood concepts in cloud. The provider secures the cloud; you secure what’s in it. Misconfigured S3 buckets, over-permissioned IAM roles, and unpatched container images remain among the most common breach vectors — and every one of them is the customer’s responsibility.

Skills and Tooling Gaps

The capabilities required to operate cloud services well — Infrastructure as Code, observability, container orchestration, identity federation — are not the same as those needed to run a traditional data centre. Many service management teams are being asked to govern things they have never built.

---

4. What This Means for Core ITSM Practices

Each major ITSM practice needs rethinking in a cloud-first world. Here’s how I think about it:

Incident Management

• You may not get to perform your own root cause analysis — you’ll be relying on the provider’s status page and post-mortem.
• Incident detection has shifted from monitoring tools you own to telemetry pipelines you stitch together from multiple sources.
• Mean Time to Restore (MTTR) is increasingly dependent on a third party’s responsiveness, not your team’s skill.

Change Enablement

• Infrastructure as Code and CI/CD pipelines deploy changes hundreds of times a day. The traditional CAB cannot keep up — and shouldn’t try to.
• Change management must shift from gatekeeping to guardrails: automated policy checks, pre-approved standard changes, and risk-based assessment.
• The question is no longer “should this change be allowed?” but “is this change safe by design?”

Configuration Management

• The CMDB must accommodate ephemeral, dynamic, tag-based resources rather than static asset records.
• Service mapping needs to extend across vendor boundaries to capture dependencies that span SaaS, IaaS, and on-premises systems.
• Discovery tooling has to integrate with cloud APIs, not just network scans.

Service Level Management

• Vendor SLAs rarely align with business expectations. Bridging that gap requires Experience Level Agreements (XLAs) that measure what users actually feel.
• Composite SLAs — calculated across chains of cloud services — are now the norm rather than the exception.

Supplier Management

• This practice has gone from being a procurement function to being arguably the most important operational discipline in ITSM.
• You now need to manage dozens of vendors as if they were extensions of your own IT department, because in effect, they are.

---

5. Practical Recommendations for ITSM Leaders

If you are leading an ITSM function in this environment, here are the actions I’d prioritise:

• Treat your CMDB as a living service map, not a static inventory. Invest in discovery tooling that understands cloud-native resources.
• Embed FinOps into service management. Cost is now a service quality dimension, not just a finance concern.
• Codify your shared responsibility model. Make it explicit who is accountable for which control, for every cloud service in use.
• Modernise change enablement. Standard changes, automated approvals, and pipeline-based controls should replace the weekly CAB for the vast majority of changes.
• Invest in supplier management as a strategic capability. Track vendor health, SLA adherence, and concentration risk continuously — not just at renewal.
• Develop an XLA framework. If your only measure of success is whether the vendor met their SLA, you are measuring the wrong thing.
• Build cloud literacy across the service desk. Frontline analysts need to understand cloud architecture well enough to triage effectively.

My preference is to think of cloud-era ITSM as a discipline of orchestration rather than ownership. You’re no longer running everything — you’re conducting an ensemble of providers, platforms, and pipelines, and your value lies in making them deliver coherent service to the business.

---

Conclusion

The evolution of cloud services has been transformative, empowering, and at times bewildering. It has delivered genuine benefits — speed, scale, and innovation that simply weren’t possible in the traditional data centre — but it has also redistributed risk in ways many ITSM frameworks haven’t fully caught up with. The boundary between “your IT” and “someone else’s IT” has dissolved, and with it, many of the assumptions that underpin classic service management.

Embracing cloud isn’t just a technology decision — it’s a service management decision. The organisations that thrive will be the ones whose ITSM functions evolve in step with their cloud estate: governing through guardrails rather than gates, measuring experience rather than just availability, and treating suppliers as integral to service delivery rather than external to it.

Hopefully this has been useful to you and I wish you well on your ITSM journey…