5. Compute, Storage, Databases and Managed Services

Introduction and Context

Cloud platforms are not merely collections of virtual machines. They provide a portfolio of infrastructure and managed services from which organisations assemble application platforms. The central architectural task is to match a workload’s technical and business requirements with an appropriate combination of compute, storage, database, communication, and operational services.

This choice is consequential. A virtual machine may offer control and compatibility but impose patching and capacity-management responsibilities. Object storage may provide exceptional durability and low cost but is unsuitable for low-latency transactional updates. A relational database offers strong integrity and expressive queries, whereas a NoSQL system may scale particular access patterns more effectively. Managed services reduce operational labour, but they also introduce provider dependencies, service limits, pricing complexity, and governance questions.

For DevOps professionals, service selection is therefore an engineering and managerial decision. It must consider performance, availability, consistency, durability, security, cost, portability, observability, and the operational burden carried by the organisation. This chapter develops a comparative framework for making those decisions across AWS, Google Cloud, and Microsoft Azure. Product names differ, but the underlying architectural principles are broadly shared.

Learning Objectives

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

1. Distinguish among virtual machines, containers, serverless compute, and managed platform services.

2. Explain autoscaling, elasticity, high availability, and capacity planning.

3. Select object, block, or file storage for appropriate workload characteristics.

4. Compare relational, NoSQL, analytical, and in-memory data services.

5. Evaluate messaging, caching, and managed integration services.

6. Analyse trade-offs involving performance, consistency, availability, cost, and operational effort.

7. Design a service composition for a realistic cloud workload.

8. Identify security, governance, resilience, and vendor-dependence risks.

A Decision Model for Cloud Service Selection

A useful starting point is to describe a workload before selecting a product. The description should include the shape of demand, data characteristics, failure tolerance, and operational constraints. Important questions include:

• Is demand steady, seasonal, bursty, or unpredictable?
• Is the workload stateful or stateless?
• What latency and throughput are required?
• How large are the data objects, and how frequently are they read or modified?
• Is immediate consistency required, or can the application tolerate delayed convergence?
• What are the recovery-point objective (RPO) and recovery-time objective (RTO)?
• Does the organisation possess the skills to operate the service?
• Are regulatory location, encryption, retention, or audit requirements applicable?

These questions expose a significant distinction between technical capability and service suitability. Almost every major provider can support a web application, but the most suitable architecture depends on access patterns and constraints rather than on a provider’s feature list.

One practical evaluation framework is the PACS-O model:

• Performance: latency, throughput, concurrency, and scaling speed.
• Availability: service continuity, redundancy, failover, and dependency health.
• Consistency and correctness: ordering, isolation, durability, and acceptable staleness.
• Security and governance: identity, encryption, network controls, auditability, and compliance.
• Operational burden: patching, upgrades, monitoring, backup, recovery, and incident response.

Cost should be evaluated across all five dimensions rather than as a unit price alone. Total cost of ownership includes compute charges, storage, requests, data transfer, support, engineering time, downtime exposure, and the cost of maintaining specialised expertise.

Compute: From Virtual Machines to Managed Execution

Virtual machines

A virtual machine (VM) is an isolated software-defined computer running on a physical host through a hypervisor. Cloud VMs generally provide configurable virtual CPUs, memory, disks, networking, operating-system images, and security controls. AWS EC2, Google Compute Engine, and Azure Virtual Machines are representative services.

VMs are appropriate when an organisation requires operating-system control, legacy software compatibility, specialised agents, custom networking, or predictable long-running capacity. They are also useful when migrating an existing data centre application with minimal redesign. Their disadvantages are equally important: customers typically remain responsible for operating-system patching, hardening, capacity planning, backup strategy, monitoring, and application runtime maintenance.

VM selection involves more than choosing a CPU count. Instance families may be general-purpose, compute-optimised, memory-optimised, storage-optimised, or accelerator-equipped. Workload benchmarking should measure the limiting resource, because increasing CPU will not resolve a memory, disk-I/O, network, or lock-contention bottleneck.

Containers and orchestration

Containers package an application and its dependencies while sharing the host operating-system kernel. They usually start more quickly and provide greater deployment consistency than full VMs. Container orchestration platforms schedule containers, restart failed instances, expose services, manage configuration, and support rolling deployment. Kubernetes is the dominant open-source example; cloud providers offer managed Kubernetes services such as Amazon EKS, Google Kubernetes Engine, and Azure Kubernetes Service.

Containers improve portability and deployment automation, but they do not eliminate complexity. Teams must still manage images, vulnerabilities, resource requests and limits, cluster upgrades, networking, secrets, observability, and workload scheduling. Managed Kubernetes reduces control-plane administration but does not remove responsibility for application reliability or cluster configuration.

Serverless and platform services

Serverless compute executes code without requiring the customer to administer servers. Functions are commonly triggered by HTTP requests, messages, schedules, or storage events. Examples include AWS Lambda, Google Cloud Run functions, and Azure Functions. Container-based serverless platforms, such as Cloud Run or Azure Container Apps, allow teams to deploy containers while delegating much of the infrastructure management.

Serverless is attractive for event-driven, intermittent, or rapidly varying workloads. It can reduce idle capacity and accelerate delivery. However, execution limits, cold starts, concurrency behaviour, statelessness, platform-specific triggers, and detailed pricing must be considered. Long-running, highly specialised, or consistently saturated workloads may be more economical on VMs or containers.

Autoscaling and elasticity

Autoscaling adjusts capacity in response to demand or policy. Horizontal scaling adds instances; vertical scaling increases the resources of existing instances. Horizontal scaling is generally preferred for resilient stateless services because it distributes load and permits failure of individual instances. Vertical scaling may be simpler for databases or tightly coupled applications, although it has limits and may require interruption.

Autoscaling policies can use CPU utilisation, memory, request rate, queue depth, latency, or custom business metrics. Queue depth is often a better signal for asynchronous workers than CPU utilisation. Scaling must also account for startup time, warm-up effects, downstream capacity, and scale-in protection. An application that scales web servers rapidly while its database remains fixed may simply move the bottleneck.

Autoscaling is not a substitute for capacity engineering. Poorly chosen thresholds can cause oscillation, delayed response, or runaway cost. A sound design combines load testing, minimum and maximum capacity, health checks, graceful termination, rate limiting, and alerts for saturation.

Storage as a Set of Access Semantics

Storage should be classified by how applications access data rather than by marketing terminology. The principal cloud storage models are object, block, and file storage.

Object storage

Object storage stores immutable or replaceable objects within logical containers called buckets. Each object consists of data, metadata, and a key. Amazon S3, Google Cloud Storage, and Azure Blob Storage are examples. Object storage is highly suitable for backups, media, log archives, software packages, data lakes, and static website assets.

Its strengths include high durability, broad scalability, lifecycle policies, versioning, encryption, and relatively low cost. It is accessed through APIs rather than as a conventional disk. Consequently, applications should not assume POSIX file semantics, in-place updates, or arbitrary low-latency operations. A design that repeatedly rewrites small portions of a large object may be inefficient.

Storage classes allow frequently accessed data to be separated from infrequently accessed or archival data. Lifecycle rules can transition objects between classes and delete expired data. Such automation must be designed carefully: retrieval charges, minimum storage periods, replication costs, and legal retention requirements can alter the apparent savings.

Block storage

Block storage presents virtual volumes to compute instances as persistent disks. The operating system formats and mounts the volume, making it appropriate for VM boot disks, transactional databases, and applications requiring low-latency random reads and writes. Examples include Amazon Elastic Block Store, Google Persistent Disk, and Azure Managed Disks.

Block storage performance is commonly expressed through input/output operations per second (IOPS), throughput, and latency. These dimensions are not interchangeable. A database performing many small random operations needs sufficient IOPS, while sequential analytics may need high throughput. Snapshots provide point-in-time copies, but a snapshot alone is not necessarily a complete application-consistent backup; database-aware coordination may be required.

File storage

File storage provides a shared hierarchical namespace and file-system semantics. It is useful for shared application content, home directories, content management systems, and legacy applications that expect mounted filesystems. Examples include Amazon EFS, Google Filestore, and Azure Files.

The convenience of shared files comes with coordination and performance considerations. Concurrent writes, locking, metadata operations, network latency, and throughput limits can become bottlenecks. File storage should not automatically be selected merely because an application uses files; object storage is often more scalable for unstructured data when application changes are possible.

Durability, availability, and backup

Durability describes the probability that stored data will not be lost; availability describes the probability that it can be accessed when requested. A highly durable object may temporarily be unavailable, and a highly available service may not protect against accidental deletion or logical corruption. Backup, replication, versioning, immutability, and tested restoration address different risks.

A robust storage plan defines retention, deletion protection, encryption-key management, cross-zone or cross-region replication, restoration procedures, and recovery testing. The relevant question is not “Is the provider’s storage durable?” but “Can the organisation recover the right data within its required time and compliance boundaries?”

Databases: Matching Data Models to Workloads

Relational databases

Relational database management systems organise data into tables with defined schemas and relationships. SQL supports expressive queries, joins, constraints, transactions, and reporting. Managed relational services such as Amazon RDS and Aurora, Google Cloud SQL and AlloyDB, and Azure SQL Database and Database for PostgreSQL delegate much of provisioning, patching, backup, and failover.

Relational systems are particularly suitable for financial records, order processing, inventory, identity, and other domains where integrity and multi-record transactions matter. Their constraints are valuable: a foreign key or uniqueness rule prevents classes of application errors. Scaling reads through replicas is common, but replicas may lag. Scaling writes may require larger instances, partitioning, sharding, or a different architecture.

A transaction’s isolation level affects the balance between concurrency and consistency. Stronger isolation can reduce anomalies but increase locking and contention. Cloud availability options may span zones, and failover can introduce a brief interruption. Applications must use connection pooling, retry policies that respect transaction semantics, and schema migration practices that avoid incompatible releases.

NoSQL databases

NoSQL is a broad category rather than one data model. Key-value stores retrieve records by keys; document databases store flexible, nested records; wide-column systems support partitioned access patterns; graph databases represent relationships and traversals. Managed examples include DynamoDB, Firestore, Cosmos DB, and Bigtable, although their capabilities differ substantially.

NoSQL systems often achieve scale by partitioning data across nodes. This makes data modelling inseparable from query design. A team should begin with the required access patterns, identify partition keys, estimate item distribution, and determine how hot partitions, secondary indexes, transactions, and cross-partition queries will be handled. Flexible schemas do not mean absence of design; they shift design emphasis from normalisation and joins toward aggregates, denormalisation, partitioning, and controlled duplication.

Consistency models range from strong to eventual, with some systems offering bounded staleness or per-operation choices. Eventual consistency can improve availability and reduce latency when temporary divergence is acceptable, such as social feeds or product recommendations. It is unsuitable for every operation involving money, stock, or access control.

Analytical and specialised data services

Operational databases are not always appropriate for large-scale analytical queries. Columnar data warehouses separate analytical workloads from transactional systems and optimise scans, aggregation, and parallel processing. Data lakes use object storage as a foundation for varied structured and unstructured data, often with catalogues and governance layers. Search engines optimise text and relevance queries; time-series databases optimise timestamped measurements; graph stores optimise relationship traversal.

The principle is workload isolation. Running analytical queries directly against a production transactional database can create contention and unpredictable latency. Replication, change-data capture, streaming pipelines, or scheduled extracts can provide a controlled analytical path, but they introduce freshness, schema, and governance issues.

Caching and Messaging as Architectural Control Points

Caching

A cache stores data closer to the consumer or in a faster system to reduce latency and protect the primary service. Caches may exist in browsers, content delivery networks, application memory, distributed key-value systems, or database query layers. Managed Redis- or Memcached-compatible services are commonly used for sessions, frequently read objects, rate limiting, and ephemeral coordination.

Caching creates a second copy of data and therefore a consistency problem. Common strategies include cache-aside, read-through, write-through, and write-behind. Cache-aside is flexible: the application reads from cache, retrieves from the database on a miss, and populates the cache. It must handle expiration, invalidation, stampedes, stale values, and failures. A cache should not be treated as the sole durable copy unless its service explicitly provides that guarantee and the design accepts the consequences.

Messaging and eventing

Messaging decouples producers from consumers. A queue holds work until a consumer processes it, while a publish-subscribe system distributes an event to multiple subscribers. Streaming platforms retain ordered event records for a period and support multiple consumers. Cloud examples include Amazon SQS and SNS, Google Pub/Sub, and Azure Service Bus and Event Grid.

Queues support load smoothing, retry, failure isolation, and asynchronous processing. They require explicit decisions about acknowledgement, visibility timeout, duplicate delivery, dead-letter handling, ordering, and idempotency. “Exactly once” is difficult to guarantee across distributed systems; consumers should generally be designed to tolerate duplicates by using idempotency keys or transactional state transitions.

Events describe something that happened, whereas commands request an action. Confusing the two can produce tightly coupled systems or unintended repeated operations. Event schemas should be versioned, documented, and governed. Messaging improves resilience but can make tracing, debugging, and business-process visibility more difficult.

Managed Services and the Shared Responsibility Boundary

A managed service transfers selected infrastructure responsibilities to the provider. It does not transfer accountability for data, identity, configuration, architecture, or business outcomes. The exact boundary differs by service. For example, a provider may patch the database engine while the customer remains responsible for access controls, network exposure, query design, backup retention, and data classification.

Managed services reduce undifferentiated operational work and can provide built-in replication, monitoring, upgrades, and integration. They also create constraints: quotas, supported versions, proprietary APIs, maintenance windows, regional availability, and provider-specific failure modes. The correct comparison is not “managed versus unmanaged,” but “which responsibilities are delegated, and are they delegated acceptably?”

Service selection should be recorded in an architecture decision record. It should state the requirements, alternatives considered, assumptions, expected costs, exit strategy, and operational ownership. This practice makes decisions reviewable rather than dependent on informal preference.

Illustrative Case: An Online Retail Platform

Background

The fictional company Northstar Retail operates an online store with a product catalogue, customer accounts, checkout, payment integration, order tracking, and sales analytics. Demand is moderate on ordinary days but rises sharply during promotional campaigns. The company has a small platform team and must protect customer and payment-related data.

Situation and problem

The original application runs on two manually managed VMs. Product images are stored on local disks, orders and catalogue data share one database, and email notifications are sent synchronously during checkout. During a campaign, CPU saturation increases response times; a failed VM causes image loss; and reporting queries interfere with order processing.

Analysis

The workload contains several distinct patterns. Web requests are stateless and bursty. Product images are large objects with infrequent modification. Orders require relational transactions and strong correctness. Notifications can be asynchronous. Analytics requires scans that should not compete with checkout. Frequently viewed catalogue data is a candidate for caching, but prices and stock quantities require carefully controlled freshness.

Approach

Northstar adopts a managed container or VM autoscaling group for the web tier, with health checks and a load balancer. Product images move to object storage, delivered through a content delivery network. The order system uses a managed relational database deployed for zone-level resilience, with automated backups and tested restoration. A separate read replica or controlled data pipeline supports reporting.

Checkout writes an order transaction and publishes an order-created message after the transaction reaches the appropriate state. A worker consumes the message to send email and update downstream systems. The worker uses an idempotency key so that retrying a message cannot send multiple business actions unintentionally. A managed cache stores catalogue information with short, policy-based expiration, while authoritative price and inventory checks remain transactional.

Autoscaling uses request latency and queue depth rather than CPU alone. Monitoring tracks database connections, replica lag, cache hit rate, object-storage errors, queue age, failed payments, and checkout success. Infrastructure is defined as code, and deployment uses a gradual rollout with automatic rollback criteria.

Outcome

The redesigned architecture separates durable data, transient acceleration, asynchronous work, and analytical processing. It reduces manual server administration and isolates several failure modes. It does not make the system failure-proof: database failover, message duplication, stale cache entries, quota exhaustion, and regional disruption remain possible and are addressed through testing and operational procedures.

Learning points

The central lesson is decomposition by workload semantics. The team did not select a single “best” service. It selected different services for stateless compute, durable media, transactional records, asynchronous work, caching, and analytics. It also treated consistency, recovery, observability, and operational ownership as design requirements rather than afterthoughts.

Risks, Governance, and Common Mistakes

A frequent mistake is choosing services by popularity rather than by access pattern. Other mistakes include placing state on autoscaled instances, assuming replication equals backup, ignoring cross-region data-transfer charges, allowing unrestricted autoscaling, and using eventual consistency where business correctness requires stronger guarantees.

Security requires least-privilege identities, private network paths where appropriate, encryption in transit and at rest, managed key controls, secret rotation, audit logs, and restrictions on public storage access. Database snapshots and object versions may contain sensitive information and must receive the same governance attention as primary data.

Data residency, retention, deletion rights, auditability, and sector-specific regulation can constrain service regions and replication. Organisations should classify data, define ownership, document processing purposes, and establish deletion and legal-hold procedures. Automated infrastructure is not automatically compliant; policy must be encoded, monitored, and periodically reviewed.

Operationally, teams should test restore procedures, failover, scaling limits, dependency outages, expired credentials, full disks, poison messages, and cache failures. Observability should connect infrastructure metrics to user outcomes. A low CPU graph does not prove that checkout is healthy.

Current Developments and Professional Practice

Cloud platforms increasingly provide serverless containers, managed distributed databases, global routing, confidential-computing options, policy automation, and integrated observability. AI-assisted operations can help classify incidents, detect anomalies, recommend rightsizing, and generate queries or infrastructure templates. Such tools remain advisory: recommendations require validation because false positives, hidden dependencies, and unsafe automated changes can create outages or governance violations.

FinOps practices are becoming essential. Teams use budgets, tagging, unit-cost metrics, rightsizing, committed-use analysis, storage lifecycle automation, and anomaly detection. A meaningful measure may be cost per order, cost per active user, or cost per processed event rather than total monthly spend alone.

Best practice is to maintain a small set of reusable architectural patterns, but not to impose them mechanically. Each pattern should specify assumptions, service limits, security controls, observability requirements, recovery objectives, and estimated cost. Regular architectural reviews should examine whether the workload has changed enough to justify migration, consolidation, or a different service model.

Chapter Summary

Cloud compute ranges from customer-controlled virtual machines to containers, serverless functions, and managed application platforms. The trade-off is primarily between control, portability, scaling behaviour, and operational effort. Autoscaling improves elasticity only when metrics, limits, startup behaviour, and downstream dependencies are understood.

Object, block, and file storage provide different access semantics. Object storage suits durable unstructured data, block storage suits mounted low-latency volumes, and file storage suits shared hierarchical access. Durability, availability, backup, and recoverability must be evaluated separately.

Relational databases provide schemas, joins, constraints, and strong transactional models. NoSQL systems can scale particular access patterns but require deliberate partition and consistency design. Analytical and specialised stores should isolate workloads from transactional systems. Caches reduce latency but create invalidation and staleness concerns; queues and event streams improve decoupling but require idempotency, ordering, retry, and schema discipline.

Managed services reduce infrastructure administration but do not remove customer accountability. Sound decisions evaluate performance, availability, consistency, security, cost, portability, and operational burden together. The most reliable architecture is usually a carefully governed composition of services, validated through testing, observability, and explicit recovery procedures.

Key Terms

Virtual machine: A software-defined computer with virtualised compute, memory, storage, and networking resources.

Container: An isolated application package that shares the host operating-system kernel.

Serverless computing: An execution model in which the provider manages much of the underlying server capacity and customers pay for or configure application execution.

Autoscaling: Automatic adjustment of service capacity in response to demand or policy.

Elasticity: The ability to add or remove resources in response to changing workload requirements.

Object storage: API-based storage of objects identified by keys, generally suited to unstructured and archival data.

Block storage: Persistent virtual disk storage presented to a compute instance as a block device.

File storage: Shared hierarchical storage providing file-system semantics over a network.

Durability: The probability that stored data remains intact over time.

Availability: The probability that a service or resource is accessible when required.

Relational database: A database organised into related tables and queried primarily through SQL.

NoSQL database: A non-relational database category including key-value, document, wide-column, and graph models.

Consistency: The degree to which reads observe the intended and current state of data.

Replication: Maintaining copies of data or service components across resources or locations.

Cache: A faster, temporary copy of data used to reduce latency or primary-system load.

Message queue: A buffer that stores work until a consumer processes it.

Idempotency: The property that repeating an operation produces the same intended business result as performing it once.

RPO: Recovery-point objective, or the maximum acceptable amount of data loss measured in time.

RTO: Recovery-time objective, or the maximum acceptable time to restore service.

Managed service: A provider-operated service in which selected infrastructure responsibilities are delegated from the customer.

Review Questions

Short Answer Questions

1. Why is a virtual machine not equivalent to a managed database service in operational responsibility?

2. Distinguish durability from availability in cloud storage.

3. What is the principal architectural purpose of autoscaling?

4. Why can eventual consistency be unsuitable for inventory management?

5. What problem does a dead-letter queue address?

Long Answer Questions

1. Compare object, block, and file storage, including access semantics, suitable workloads, and operational concerns.

2. Explain how relational and NoSQL databases differ in data modelling, scaling, consistency, and application design.

3. Discuss the benefits and limitations of managed services using the shared responsibility model.

4. Explain how caching and messaging influence performance, resilience, and consistency.

5. Develop a decision framework for selecting compute services for a bursty web workload.

Analytical / Application Questions

1. A university admissions system requires transactional seat allocation, document uploads, asynchronous notifications, and annual reporting. Propose suitable cloud services and justify each selection using performance, consistency, cost, and operational burden.

2. A team proposes placing user sessions on local disks of autoscaled VMs and storing backups only as database snapshots. Critically evaluate the design and recommend improvements.

3. An online retailer experiences high cache hit rates but incorrect stock displays during promotions. Analyse the likely consistency problem and design a caching and transaction strategy that protects inventory correctness.

22. Multiple Choice Questions with Answers

Question 1

A workload stores large media files that are rarely modified and should be accessed through APIs with lifecycle-based archival. Which storage model is most appropriate?

A. Block storage

B. Object storage

C. Shared file storage

D. Ephemeral local storage

Correct Answer: B. Object storage

Question 2

Which metric is often more suitable than CPU utilisation for autoscaling asynchronous workers?

A. Queue depth

B. Disk capacity only

C. Number of database tables

D. Object size

Correct Answer: A. Queue depth

Question 3

Why should an application using a NoSQL database design its partition key carefully?

A. It determines the programming language

B. It prevents all forms of replication

C. It influences distribution, scalability, and hot partitions

D. It converts eventual consistency into transactions

Correct Answer: C. It influences distribution, scalability, and hot partitions

Question 4

Which requirement most strongly favours a relational database?

A. Flexible documents with independent key-based access

B. Transactional integrity across related records

C. High-volume media archiving

D. Temporary response caching

Correct Answer: B. Transactional integrity across related records

Question 5

What is a principal risk introduced by caching?

A. The database schema becomes normalised automatically

B. Cached data may become stale or difficult to invalidate

C. All requests become synchronous

D. Object storage loses durability

Correct Answer: B. Cached data may become stale or difficult to invalidate

Question 6

A message may be delivered twice because a consumer fails after processing but before acknowledgement. What design property reduces the business impact?

A. Idempotency

B. Vertical scaling

C. Data compression

D. Longer object names

Correct Answer: A. Idempotency

Question 7

Which statement best distinguishes durability from availability?

A. Durability concerns protection from loss; availability concerns accessibility

B. Durability concerns latency; availability concerns encryption

C. Durability and availability are identical measures

D. Availability applies only to archived data

Correct Answer: A. Durability concerns protection from loss; availability concerns accessibility

Question 8

In the retail case, why were analytical queries separated from the transactional order database?

A. To eliminate the need for backups

B. To prevent reporting workloads from causing checkout contention

C. To make all data eventually consistent

D. To avoid using object storage

Correct Answer: B. To prevent reporting workloads from causing checkout contention

Question 9

Which responsibility generally remains with the customer when using a managed database?

A. Manufacturing physical servers

B. Designing access controls and appropriate data governance

C. Replacing failed provider disks manually

D. Operating the provider’s hypervisor

Correct Answer: B. Designing access controls and appropriate data governance

Question 10

A service scales web instances rapidly, but response time remains high because the database has reached its connection limit. What does this illustrate?

A. Autoscaling always removes bottlenecks

B. A downstream dependency can limit the benefit of scaling

C. Object storage is unsuitable for images

D. Strong consistency eliminates capacity planning

Correct Answer: B. A downstream dependency can limit the benefit of scaling