Cloud Operating Models and Emerging Developments

Introduction

Cloud deployment is no longer only a technical activity performed by infrastructure teams. Organisations increasingly treat cloud as an operating model: a coordinated way of designing platforms, delivering software, managing reliability, controlling risk, and allocating costs. AWS, Google Cloud Platform (GCP), and other providers supply highly programmable infrastructure, but the benefits of cloud depend on how people, processes, governance, and automation are organised.

This chapter examines six connected developments. CloudOps manages cloud environments as continuously operated services. Site Reliability Engineering (SRE) applies software engineering and quantitative service objectives to operations. Platform engineering creates reusable internal platforms for development teams. Internal developer platforms (IDPs) provide self-service capabilities through approved workflows. GitOps uses version-controlled desired state as the operational source of truth. Multi-cloud and sovereign cloud address strategic, regulatory, resilience, and jurisdictional concerns. Finally, AIOps and generative artificial intelligence (AI) are changing monitoring, deployment, incident response, and infrastructure development, while introducing significant requirements for human oversight, security, and responsible governance.

The central professional question is not whether an organisation should adopt every new practice. It is how to select and combine operating models that improve delivery and reliability without creating excessive complexity, vendor dependence, uncontrolled automation, or governance gaps.

Learning Objectives

By the end of this chapter, students should be able to:

• explain CloudOps, SRE, platform engineering, IDPs, and GitOps;
• distinguish responsibilities among developers, platform teams, SRE teams, and governance functions;
• evaluate multi-cloud and sovereign-cloud strategies;
• describe how AIOps and generative AI can support deployment and operations;
• identify risks involving security, privacy, resilience, accountability, and AI governance;
• recommend an operating model for a realistic cloud deployment scenario.

1. Cloud as an Operating Model

A cloud operating model defines how an organisation plans, builds, deploys, operates, secures, and improves cloud services. It includes:

1. People and responsibilities — team structures, ownership, escalation, and skills.
2. Processes — change management, incident response, disaster recovery, compliance, and financial control.
3. Technology — cloud accounts or projects, networks, identity systems, observability, automation, and developer tools.
4. Governance — policies, risk controls, audit evidence, standards, and decision rights.
5. Measures — reliability, delivery performance, security posture, user experience, and cost.

Traditional operations often relied on manually configured servers and separate development and operations departments. Cloud changes the economics and speed of delivery: infrastructure can be created through APIs, environments can be reproduced from code, and services can scale dynamically. However, speed without controls can produce configuration drift, excessive privilege, uncontrolled spending, and fragile dependencies.

A mature model therefore treats infrastructure and operations as products. Teams define users, service expectations, interfaces, support arrangements, and improvement road maps. The cloud provider manages some layers, but the customer remains responsible for correct configuration, identity, data protection, workload security, and business continuity according to the selected service model.

2. CloudOps

CloudOps is the operational discipline of managing cloud resources and services across their lifecycle. It extends conventional IT operations to highly automated, API-driven, distributed environments.

Typical CloudOps capabilities include:

• account, project, subscription, and resource organisation;
• identity and access management;
• network and connectivity management;
• infrastructure as code (IaC);
• patching and vulnerability management;
• monitoring, logging, tracing, and alerting;
• backup, recovery, and resilience testing;
• cost management and resource optimisation;
• policy enforcement and compliance evidence;
• incident, problem, and change management.

CloudOps is not simply “running virtual machines in the cloud.” It must manage ephemeral resources, managed services, serverless functions, containers, data services, regional dependencies, and provider quotas. An operational design should make ownership explicit. For example, a team may own an application service while a central platform team owns the Kubernetes control plane or landing-zone policies.

CloudOps operating practices

A practical CloudOps lifecycle is:

Figure: CloudOps as a continuous lifecycle supported by governance.

CloudOps teams should prefer automation that is observable, reversible, and tested. A change that cannot be inspected or rolled back is an operational risk, even if it saves time during initial deployment.

3. Site Reliability Engineering

Site Reliability Engineering (SRE) originated as an approach to applying software engineering to operations. Its purpose is not to eliminate failure—distributed systems inevitably fail—but to manage reliability as an explicit engineering and business concern.

Service level concepts

• A service level indicator (SLI) is a measurement of service behaviour, such as successful request proportion, latency, or availability.
• A service level objective (SLO) is a target for an SLI over a defined time window.
• A service level agreement (SLA) is a formal commitment, often involving customer remedies or financial consequences.
• An error budget is the permitted amount of unreliability implied by an SLO.

If availability is measured as the proportion of valid time in which a service is available, then:

The time quantities must use the same unit and the measurement method must define exclusions, maintenance windows, and the treatment of partial failures. For a 30-day month with 99.9% availability, the nominal error budget is:

This is an illustrative calculation, not a universal SLA interpretation. Providers and organisations may measure availability differently, and an SLO may use request-based rather than time-based availability.

An error budget supports a balance between innovation and stability. If a service consumes its budget rapidly, the team may pause risky feature releases and prioritise reliability work. If substantial budget remains, the team may accept measured operational risk to deliver business value. This is a decision framework, not permission to ignore security or legal obligations.

SRE practices

Important SRE practices include automation of repetitive work, capacity planning, production readiness reviews, blameless post-incident learning, tested recovery procedures, and carefully designed alerts. An alert should normally identify an actionable condition rather than merely report an interesting metric. Excessive alerts create fatigue and increase the likelihood that a genuine failure is missed.

SRE does not mean that every organisation needs a separate SRE department. In a small organisation, developers and operations specialists may share SRE responsibilities. The essential features are measurable objectives, engineering-based improvement, and explicit ownership.

4. Platform Engineering and Internal Developer Platforms

Platform engineering is the design and operation of an internal platform that enables application teams to deliver software efficiently and safely. The platform is a product for internal users, not a collection of tools imposed without user research.

An internal developer platform (IDP) is the usable product surface through which developers access platform capabilities. It may include a service catalogue, templates, command-line tools, portals, APIs, CI/CD pipelines, secrets integration, environment provisioning, observability defaults, and policy checks.

The distinction is useful:

A good IDP provides a golden path: a well-supported, opinionated route for common tasks such as creating a service, deploying to a test environment, enabling logging, and requesting production access. Golden paths should not become inflexible “golden cages.” Teams need documented escape routes for legitimate specialist requirements.

Platform teams should measure outcomes such as onboarding time, deployment lead time, platform reliability, adoption, developer satisfaction, and the percentage of workloads using secure defaults. They should avoid measuring success only by the number of tools installed.

5. GitOps

GitOps uses a version-controlled repository to declare the desired state of infrastructure or applications. An automated controller compares desired state with observed state and reconciles differences. In this model, Git provides history, review, and change traceability, while the controller performs deployment or correction.

A simplified reconciliation relationship is:

The principle is broader than “put scripts in Git.” A robust GitOps implementation normally includes declarative configuration, automated reconciliation, peer review, protected branches, secret-management controls, audit logs, and a recovery process.

Benefits include repeatability, reviewable changes, easier rollback, and reduced manual configuration drift. Limitations include repository compromise risk, difficulties with resources that are inherently imperative, secrets accidentally committed to source control, and the danger of an automated controller repeatedly applying an incorrect configuration. GitOps therefore requires validation, policy checks, least privilege, and safe failure modes.

A practical workflow is:

1. A developer proposes a change to application or infrastructure configuration.
2. Automated tests, security checks, policy checks, and previews run.
3. An authorised reviewer approves the change.
4. The controller applies the desired state to the target environment.
5. Monitoring verifies health and reports drift or failure.
6. A tested revert or corrective change restores service when necessary.

6. Multi-Cloud and Sovereign Cloud

Multi-cloud means using services from two or more cloud providers. It may be deliberate—such as using AWS for one capability and GCP for another—or arise through acquisitions, regional constraints, or independent team decisions. Hybrid cloud generally combines cloud services with privately operated infrastructure; an organisation can be both hybrid and multi-cloud.

Potential reasons for multi-cloud include regulatory requirements, geographic availability, bargaining position, access to specialised services, resilience objectives, and avoidance of dependence on one provider. Costs include duplicated skills, duplicated tooling, inconsistent security controls, data-transfer charges, more complex identity, fragmented observability, and a larger failure surface.

Multi-cloud does not automatically provide resilience. If both deployments depend on the same identity provider, DNS service, network carrier, data source, or operational team, a common dependency may still cause a shared outage. Resilience must be demonstrated through dependency analysis and realistic testing.

Sovereign cloud refers to cloud arrangements designed to satisfy requirements concerning jurisdiction, data residency, operational control, legal authority, and sometimes national ownership or personnel restrictions. The exact meaning varies by jurisdiction and contract. Data stored in a country may still be subject to foreign legal access if the provider or controlling entity is subject to another jurisdiction. Therefore, sovereignty analysis must examine provider ownership, support access, encryption-key control, subcontractors, metadata, operational location, and applicable law—not only the physical data centre.

A decision matrix can support evaluation:

Portability should be selective. Attempting to use only the lowest common denominator of every provider can reduce capability and increase engineering effort. A more practical approach is to classify workloads by portability requirement and document provider-specific dependencies.

7. AIOps and Generative AI in Operations

AIOps applies machine learning, analytics, correlation, and automation to operational data such as logs, metrics, traces, events, tickets, and topology. Common uses include alert deduplication, anomaly detection, event correlation, probable-cause suggestions, capacity forecasting, and incident summarisation.

AIOps is valuable when data is sufficiently complete, labelled, timely, and representative. It is not a substitute for instrumentation or sound service design. Poorly configured monitoring can cause an AIOps system to automate noise at greater speed.

Generative AI can assist with:

• explaining unfamiliar configuration or error messages;
• drafting infrastructure-as-code and deployment manifests;
• generating runbook steps and test cases;
• summarising incidents and identifying timelines;
• translating operational questions into queries;
• proposing remediation options;
• documenting architecture and post-incident findings.

These are assistance functions. Generated code may contain insecure permissions, incorrect provider syntax, hidden assumptions, or destructive commands. Generated explanations may sound confident while being wrong. AI tools should therefore operate within a controlled workflow:

1. define an authorised task and data boundary;
2. provide relevant, verified context;
3. generate a proposal rather than immediate unrestricted action;
4. run tests, static analysis, policy checks, and security scanning;
5. require human approval for material changes;
6. execute with least privilege and bounded blast radius;
7. monitor the outcome and record evidence;
8. review errors and improve prompts, data, and controls.

Human oversight and autonomy levels

A useful governance scale is:

Production deletion, privilege escalation, changes to encryption, and modifications affecting regulated data should normally require explicit human authorisation. Emergency automation may be justified, but its scope, expiry, audit trail, and post-event review must be defined.

AI risks and responsible governance

Key risks include confidential data disclosure to an AI service, prompt injection through logs or tickets, insecure generated code, model bias, unreliable explanations, excessive dependence on one model provider, intellectual-property uncertainty, and inability to explain a consequential decision. Controls include data classification, approved tools, retention restrictions, redaction, access controls, output validation, model and prompt versioning, audit logs, separation of duties, and incident procedures for AI failures.

AI governance should assign accountability to people and teams. “The model made the decision” is not an adequate operational or legal explanation. Organisations should document intended use, prohibited use, evaluation methods, known limitations, approval authority, monitoring indicators, and methods for human override.

8. Security, Governance, and FinOps Across Operating Models

Operating models must integrate security rather than attach it at the end. Important controls include central identity federation, multifactor authentication, least privilege, workload identity, network segmentation, encryption in transit and at rest, key-management processes, vulnerability management, immutable or protected backups, and continuous policy evaluation.

Governance should distinguish guardrails from gates. A guardrail prevents or detects dangerous configurations automatically; a gate requires an explicit review before a change proceeds. Excessive gates slow delivery and encourage bypasses, whereas absent guardrails permit preventable failures. Risk-based controls are preferable.

FinOps connects engineering decisions to economic outcomes. Teams should allocate costs to products or services, monitor usage, set budgets, identify idle resources, select suitable purchasing commitments, and include data-transfer costs in architecture decisions. Cost optimisation must not undermine reliability, security, or compliance. For example, deleting backups may reduce a bill while increasing recovery risk.

Useful operational metrics include:

• availability and latency against SLOs;
• change failure rate and deployment frequency;
• time to restore service;
• vulnerability age and policy violations;
• recovery-point and recovery-time test results;
• cost per transaction or service unit;
• developer platform adoption and satisfaction.

Metrics should guide learning rather than punish teams. A single metric can be gamed or misinterpreted; a balanced set is more informative.

9. Applied Case: Northstar Retail Cloud Transformation

The following is an illustrative case, not a report of a real organisation.

Background

Northstar Retail operates an online store and several warehouse systems. It has moved its customer-facing application to AWS while its analytics group uses GCP. Development teams deploy at different speeds, operations staff receive thousands of alerts, and finance cannot reliably associate cloud expenditure with products.

Problem

A production incident occurred after a manually edited security-group rule blocked access to a dependent service. Recovery took four hours because the actual configuration differed from the documented configuration. A later review found long-lived administrator credentials, unencrypted development data, and no consistent SLOs. Management proposed “using multi-cloud for resilience” and purchasing a generative-AI operations tool.

Analysis

The problem is not simply provider selection. It includes configuration drift, weak identity controls, unclear service ownership, inadequate observability, and untested recovery. Adding another provider without solving these issues would increase complexity. AI would also be unreliable if event data and service topology were incomplete.

Approach and solution

Northstar adopts the following model:

• a platform team owns landing zones, identity integration, network patterns, approved deployment templates, and central observability;
• product teams own their services and define SLOs with support from an SRE capability;
• Terraform and Git-based workflows manage infrastructure changes, with policy checks for public exposure, encryption, and excessive privilege;
• an IDP provides templates for new services, secure defaults, deployment pipelines, dashboards, and cost tags;
• workload identities replace shared administrator credentials, and privileged access is time-limited;
• AWS remains the primary platform for the retail application, while GCP is retained for selected analytics workloads based on capability and contractual considerations—not as an untested failover copy;
• AIOps initially performs alert grouping and incident summarisation only;
• generative AI may draft runbook steps, but production changes require human approval and automated validation;
• quarterly recovery exercises test backups, dependencies, DNS, identity, and communication procedures.

Northstar defines an availability SLO for the checkout service and measures request success, latency, and dependency health. It introduces cost allocation by product and environment. The platform team publishes an escape process for exceptional requirements and reviews its templates using developer feedback.

Outcome

After implementation, configuration changes become reviewable and reproducible, alert volume falls because duplicate events are correlated, and teams can create compliant test environments more quickly. The organisation does not claim automatic multi-cloud resilience; instead, it documents which failures are covered and which are not. AI is used as an assistant with auditable boundaries rather than as an uncontrolled production operator.

Learning points

1. An operating model must address people, process, technology, and governance together.
2. Multi-cloud is a strategic choice with measurable trade-offs, not a guarantee of resilience.
3. Platform engineering succeeds when the platform is treated as an internal product.
4. SLOs and error budgets make reliability decisions explicit.
5. AI value depends on trustworthy data, constrained authority, and human accountability.

10. Challenges and Limitations

These operating models introduce their own difficulties. Platform teams can become bottlenecks or create unsuitable abstractions. SRE practices can be misunderstood as a separate “reliability department” that owns all operational quality. GitOps can spread incorrect configuration rapidly. Multi-cloud can produce duplicated controls and skills shortages. Sovereign-cloud claims may be unclear unless contracts and legal dependencies are examined. AIOps can generate false confidence when training data is incomplete. Generative AI can accelerate both good and bad engineering.

Organisations should begin with a small number of high-value services, establish ownership and baseline measurements, automate repeatable controls, and expand through evidence. Architecture decisions should record assumptions, dependencies, exit criteria, and residual risks. Periodic exercises—security tests, failure injection where appropriate, restore tests, access reviews, and AI evaluation—are more reliable than policy documents alone.

Best-Practice Checklist

• Define service ownership and operational responsibilities.
• Establish meaningful SLIs, SLOs, and alert thresholds.
• Use IaC and version control for repeatability.
• Apply least privilege, strong identity, and protected secrets.
• Build secure defaults into the IDP and deployment pipelines.
• Validate GitOps changes before reconciliation.
• Analyse common dependencies before claiming multi-cloud resilience.
• Treat sovereignty as a legal, operational, and technical question.
• Classify data before sending it to AI services.
• Keep high-impact AI actions subject to human approval.
• Measure reliability, delivery, security, developer experience, and cost together.
• Test recovery and review incidents for system improvements rather than blame.

Chapter Summary

Cloud operating models determine how cloud technology becomes a dependable organisational capability. CloudOps provides lifecycle management for programmable cloud environments. SRE introduces measurable reliability objectives, error budgets, automation, and learning from incidents. Platform engineering and internal developer platforms create reusable, self-service pathways that reduce cognitive load while preserving governance. GitOps makes desired state reviewable and reconciled through automation.

Multi-cloud can support capability, resilience, or regulatory goals, but it also adds cost and complexity and does not guarantee independence from shared failures. Sovereign cloud requires analysis of jurisdiction, provider control, support access, data location, and legal authority. AIOps can correlate events and support operational decisions, while generative AI can assist with code, documentation, diagnosis, and runbooks. Both require trustworthy data, bounded permissions, validation, security controls, auditability, and human accountability.

The most effective contemporary model is not maximal automation or maximal provider diversity. It is a measured combination of product-oriented platforms, explicit reliability objectives, secure automation, transparent governance, and continuous improvement.

Key Terms

CloudOps: The discipline of operating and governing cloud resources and services throughout their lifecycle.

Site Reliability Engineering (SRE): An approach that applies software engineering methods to reliability and operations.

Service Level Indicator (SLI): A quantitative measurement of service behaviour.

Service Level Objective (SLO): A target value or range for an SLI over a specified period.

Service Level Agreement (SLA): A formal service commitment, often including remedies.

Error budget: The permitted unreliability implied by an SLO.

Platform engineering: Engineering an internal platform that enables teams to deliver software safely and efficiently.

Internal developer platform (IDP): A self-service set of tools, workflows, and capabilities for internal developers.

Golden path: A supported, opinionated route for completing a common engineering task.

GitOps: An operational model using version-controlled desired state and automated reconciliation.

Configuration drift: Difference between intended configuration and actual deployed configuration.

Multi-cloud: Use of services from two or more cloud providers.

Hybrid cloud: Combination of cloud services with privately operated infrastructure.

Sovereign cloud: A cloud arrangement designed to satisfy jurisdictional, operational-control, and data-sovereignty requirements.

AIOps: Use of analytics, machine learning, and automation for IT operations.

Generative AI: AI that produces new content such as text, code, configurations, or summaries.

Guardrail: An automated control that prevents or detects risky behaviour.

FinOps: Collaborative practice for managing and optimising cloud economics.

Human-in-the-loop: A design in which a person reviews, approves, or can override an automated decision.

Review Questions

Short Answer Questions

1. What is the principal purpose of CloudOps?
2. Distinguish an SLI, an SLO, and an SLA.
3. What problem does an internal developer platform address?
4. How does GitOps reduce configuration drift?
5. Why does multi-cloud not automatically guarantee resilience?

Long Answer Questions

1. Compare CloudOps and SRE in terms of purpose, responsibilities, practices, and measures.
2. Explain how platform engineering and IDPs can improve developer productivity without weakening governance.
3. Discuss the benefits and limitations of a GitOps operating model.
4. Analyse the technical and legal dimensions that should be examined before adopting sovereign cloud.
5. Explain appropriate uses, risks, and governance controls for generative AI in cloud operations.

Analytical / Application Questions

1. A company has frequent production incidents caused by manual changes, but its developers complain that the operations team is a bottleneck. Design an operating model using platform engineering, GitOps, and SRE principles. Identify ownership, controls, and success measures.
2. An organisation proposes copying every workload to two cloud providers to achieve resilience. Evaluate the proposal, identify shared dependencies and costs, and recommend a more defensible resilience strategy.
3. An AI operations assistant proposes automatically increasing database privileges during incidents. Decide whether and under what conditions this should be permitted. Address least privilege, human approval, auditability, rollback, and emergency procedures.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an SLO?

A. A measurement of service behaviour

B. A target for a service measurement over a defined period

C. A contract that always includes financial compensation

D. A list of cloud-provider products

Correct Answer: B. A target for a service measurement over a defined period

Question 2

A 30-day month with a 99.9% availability target has a nominal error budget of approximately:

A. 4.32 minutes

B. 14.4 minutes

C. 43.2 minutes

D. 432 minutes

Correct Answer: C. 43.2 minutes

Question 3

What is the central operational idea in GitOps?

A. Manual production changes by senior administrators

B. Desired state stored in version control and reconciled automatically

C. Using Git only for application source code

D. Replacing monitoring with code review

Correct Answer: B. Desired state stored in version control and reconciled automatically

Question 4

Which capability is most characteristic of an internal developer platform?

A. A self-service workflow with secure deployment defaults

B. A policy prohibiting all developer automation

C. A second public cloud provider used without governance

D. A collection of unrelated monitoring alerts

Correct Answer: A. A self-service workflow with secure deployment defaults

Question 5

Why may multi-cloud fail to provide resilience?

A. Cloud providers cannot host redundant workloads

B. All cloud services use identical hardware

C. Both environments may depend on the same identity, DNS, or network service

D. Multi-cloud prevents infrastructure automation

Correct Answer: C. Both environments may depend on the same identity, DNS, or network service

Question 6

Which statement about sovereign cloud is most accurate?

A. Data-centre location alone proves sovereignty

B. Sovereignty concerns can include jurisdiction, operational control, and support access

C. Sovereign cloud removes the need for encryption

D. Sovereign cloud always means using two providers

Correct Answer: B. Sovereignty concerns can include jurisdiction, operational control, and support access

Question 7

Which is an appropriate initial use of AIOps?

A. Unrestricted deletion of production resources

B. Alert correlation and incident summarisation

C. Automatic disabling of all security controls

D. Replacing service instrumentation

Correct Answer: B. Alert correlation and incident summarisation

Question 8

Why should generative-AI output for infrastructure be validated?

A. Generated code is always syntactically invalid

B. AI cannot process technical information

C. It may contain insecure permissions, incorrect assumptions, or destructive actions

D. Validation prevents all automation

Correct Answer: C. It may contain insecure permissions, incorrect assumptions, or destructive actions

Question 9

What does an error budget primarily help a team decide?

A. Whether to balance feature delivery against reliability work

B. Which cloud provider has the largest data centre

C. How to encrypt a database mathematically

D. Whether source control is necessary

Correct Answer: A. Whether to balance feature delivery against reliability work

Question 10

Which control is most appropriate for a high-impact AI production action?

A. No logging, to protect model privacy

B. Human approval, least privilege, validation, monitoring, and rollback

C. Permanent administrator access for the AI system

D. Automatic execution based only on the model's confidence score

Correct Answer: B. Human approval, least privilege, validation, monitoring, and rollback