English:Cloud Computing
Cloud Computing
Introduction
Cloud computing is a way of delivering computing capabilities as network-accessible services rather than requiring every user or organization to own and operate all of the underlying hardware. The influential NIST definition describes a model built around on-demand access to a shared pool of configurable resources that can be provisioned and released rapidly. For university-level study, the important point is not simply that a server is "somewhere on the Internet." Cloud computing combines technical abstraction, automation, resource pooling, metering, distributed systems, security controls, and economic models.
Cloud platforms can provide computing power, storage, networking, databases, analytics, identity services, messaging, machine learning, and complete applications. You interact with these resources through web consoles, command-line interfaces, software development kits, and APIs. A cloud environment may be public, private, community-based, or hybrid, and it may expose infrastructure, development platforms, complete applications, or more specialized managed services.
Learning goals: By the end of this aiMOOC, you should be able to explain the essential characteristics of cloud computing, distinguish service and deployment models, analyze a cloud architecture, compare virtual machines and containers, discuss serverless and cloud-native approaches, apply security and reliability principles, evaluate cost and sustainability trade-offs, and justify an architecture for a realistic university or professional scenario.
Foundations of Cloud Computing
The NIST Model
NIST Special Publication 800-145 remains a useful baseline vocabulary. It identifies five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. These characteristics help you distinguish cloud computing from ordinary remote hosting.
On-demand self-service means that a consumer can provision computing capabilities without waiting for a provider employee to perform each action manually. Broad network access means services are available through standard network mechanisms. Resource pooling means provider resources are shared among multiple consumers and allocated dynamically. Rapid elasticity describes the ability to add or remove capacity quickly in response to demand. Measured service means usage can be monitored and metered, which supports accountability and consumption-based billing.
A virtual machine hosted in a remote data center is therefore not automatically a complete example of cloud computing. If provisioning is slow, capacity is fixed, automation is absent, and usage is not metered, the system may behave more like traditional hosting than a cloud service.
Physical Infrastructure Still Matters
The cloud is built on physical systems: servers, storage devices, network equipment, power distribution, cooling infrastructure, buildings, and interconnection facilities. Virtualization and automation hide much of this complexity from consumers, but they do not remove it.
Cloud providers organize infrastructure into geographic and operational failure domains. Terms such as region, availability zone, data center, and edge location vary somewhat between providers, so you should read a provider's architecture documentation carefully. In general, spreading dependent components across independent failure domains can reduce the risk that one local failure disrupts an entire application.
Latency, legal requirements, data residency, energy sources, service availability, and price can all influence the choice of deployment location.
Service Models
IaaS, PaaS, and SaaS
The classical NIST service models describe different divisions of responsibility between the provider and consumer.
Infrastructure as a Service (IaaS) provides fundamental computing resources such as virtual machines, storage, and networking. You typically control operating systems, applications, many network settings, and data, while the provider operates the physical infrastructure and virtualization layer.
Platform as a Service (PaaS) provides a managed application platform. You deploy code or applications while the provider manages more of the operating system, runtime, scaling mechanisms, and underlying infrastructure. PaaS can increase developer productivity, but it may also introduce platform-specific dependencies.
Software as a Service (SaaS) provides a complete application. You configure and use the software while the provider manages most of the application stack and infrastructure. University examples include web-based collaboration tools, learning platforms, email services, and research administration systems.
Modern cloud catalogs contain many managed services that do not fit neatly into a single classroom label. Managed databases, message queues, analytics platforms, machine-learning services, and identity systems often combine features of infrastructure and platform services. The key analytical question is therefore: Which components do you manage, and which responsibilities are delegated to the provider?
Responsibility Increases as You Move Down the Stack
In SaaS, the provider manages most technical layers, but the customer still has responsibilities such as identity governance, data handling, user permissions, contractual choices, and secure configuration. In IaaS, the customer controls more of the stack and therefore manages more operating-system, application, and network-security tasks.
This is why the shared responsibility model should never be reduced to a slogan. Exact responsibilities depend on the service, provider, configuration, contract, and regulatory context.
Deployment Models
Public, Private, Community, and Hybrid Cloud
A public cloud makes shared provider infrastructure available to multiple customers under standardized services. A private cloud is provisioned for exclusive use by a single organization. A community cloud is provisioned for a specific community of consumers with shared concerns, such as mission or policy requirements. A hybrid cloud combines distinct cloud infrastructures in a coordinated arrangement.
The diagram above illustrates the commonly discussed public, private, and hybrid models. NIST's formal taxonomy also includes the community cloud model. This is a useful reminder that simplified diagrams can omit concepts from formal standards.
A hybrid design is not automatically better than a public or private design. It can support data residency, legacy integration, staged migration, or specialized hardware, but it also adds networking, identity, monitoring, governance, and operational complexity.
Core Cloud Architecture
Compute
Cloud compute can be delivered through virtual machines, containers, managed container platforms, batch services, functions, and specialized accelerators such as GPUs. The right choice depends on workload duration, isolation needs, portability, startup time, operational control, scaling behavior, and cost.
Virtual machines provide strong operating-system-level isolation and flexible software environments. Containers package applications and their dependencies while sharing a host operating-system kernel. Serverless functions abstract much of the server lifecycle and execute code in response to events or requests.
Storage
Three common storage abstractions are object storage, block storage, and file storage. Object storage organizes data as objects addressed through APIs and is well suited to large-scale unstructured data, backups, logs, and data lakes. Block storage exposes volumes that operating systems can treat similarly to disks and is often used for databases and virtual machines. File storage exposes a shared hierarchical file system and is useful when applications require familiar file semantics.
Storage design must consider durability, availability, consistency requirements, throughput, latency, lifecycle policies, encryption, backup, replication, and data-transfer charges. A low storage price does not guarantee a low total cost if retrieval or network egress is expensive.
Networking
Cloud networking usually includes virtual networks, subnets, routing, firewalls, load balancers, DNS, private endpoints, gateways, content-delivery networks, and links to campus or corporate networks. Network boundaries in the cloud are defined largely through software, which makes automation powerful but also makes configuration errors potentially widespread.
A well-designed architecture separates public-facing and internal components, minimizes unnecessary network exposure, uses explicit routing and firewall rules, encrypts sensitive traffic, and monitors flows for anomalies.
Data and Managed Services
Cloud providers offer managed relational databases, key-value stores, document databases, caches, stream-processing systems, warehouses, and analytics platforms. Managed services can reduce operational work such as patching, replication, backup, and failover, but they can also increase dependence on provider-specific APIs or data formats.
When comparing managed and self-managed systems, you should evaluate not only feature lists but also operational effort, portability, performance, availability guarantees, backup behavior, observability, compliance needs, and exit strategy.
Virtualization, Containers, and Orchestration
Hypervisors and Virtual Machines
Virtualization allows multiple isolated virtual machines to share physical hardware. A hypervisor allocates processor, memory, storage, and device access to virtual machines. Type 1 hypervisors run directly on hardware, while Type 2 hypervisors run on top of a host operating system.
Virtual machines are valuable when workloads require different operating systems, strong isolation boundaries, mature management tooling, or legacy software environments. Their trade-offs include larger images, longer startup times, and higher per-instance overhead than many containerized approaches.
Containers
Containers package an application with the user-space dependencies it needs while sharing the host kernel. This often makes containers smaller and faster to start than full virtual machines. Containers are not automatically secure, portable, or stateless; those properties depend on image design, runtime configuration, storage, networking, privileges, and the surrounding platform.
A useful architectural question is not "VMs or containers?" but "Which isolation and deployment abstraction best matches the workload?" Containers frequently run inside virtual machines in public clouds, combining infrastructure isolation with application packaging.
Kubernetes and Orchestration
Container orchestration systems automate deployment, scheduling, service discovery, scaling, and recovery for containerized workloads. Kubernetes is a widely used orchestration platform built around a declarative desired-state model.
Kubernetes introduces powerful abstractions such as pods, deployments, services, configuration objects, and controllers. It can improve portability and automation, but it also adds operational complexity. Using Kubernetes is justified when its orchestration capabilities solve real requirements; a simpler managed platform may be more appropriate for smaller systems.
Serverless and Cloud-Native Design
Serverless Computing
Serverless does not mean that servers disappear. It means that the provider abstracts server provisioning and much of the runtime management from the application developer. In a Functions as a Service model, code is often triggered by events, scales automatically within service limits, and is billed according to execution or resource use.
Serverless architectures can be effective for event processing, APIs, scheduled jobs, automation, and workloads with variable demand. Limitations can include cold-start latency, execution limits, difficult local debugging, distributed tracing complexity, state-management challenges, and provider-specific integration.
Cloud-Native Systems
The Cloud Native Computing Foundation describes cloud-native practice in terms of building and operating scalable workloads in a programmatic and repeatable way, with loosely coupled systems that are secure, resilient, manageable, sustainable, and observable. Technologies may include containers, microservices, immutable infrastructure, declarative APIs, service meshes, and serverless components.
Cloud-native architecture is therefore not a checklist of fashionable tools. The deeper goal is to make systems easier to automate, scale, observe, recover, and evolve. A monolith can still run successfully in the cloud, and microservices can fail badly if organizational and operational complexity is ignored.
Reliability and Performance
Designing for Failure
Cloud infrastructure can fail at many levels: process, virtual machine, host, rack, network path, data center, availability zone, region, identity service, third-party dependency, or human configuration. Resilient design assumes that failures will occur and limits their impact.
Common techniques include redundancy, health checks, load balancing, autoscaling, replication, backups, queues, idempotent operations, circuit breakers, retry policies with backoff, and deployment across independent failure domains. Each technique has costs and can introduce new failure modes.
High availability is not the same as disaster recovery. High availability aims to keep a service operating during expected failures. Disaster recovery focuses on restoring service and data after a major disruption. Two useful planning measures are Recovery Time Objective (RTO), the target time to restore service, and Recovery Point Objective (RPO), the acceptable amount of data loss measured in time.
Scaling and Elasticity
Vertical scaling increases the capacity of one instance. Horizontal scaling adds more instances. Elastic systems adjust capacity according to demand. Autoscaling policies need meaningful signals such as queue depth, request rate, CPU usage, latency, or custom application metrics.
Scaling does not fix every performance problem. A database lock, serial algorithm, external API rate limit, or poorly designed cache can remain a bottleneck even when more application instances are added. Performance engineering therefore requires measurement, load testing, profiling, and end-to-end observability.
Cloud Security
Shared Responsibility and Zero Trust Principles
Cloud security combines provider controls and customer controls. The provider usually protects physical facilities and parts of the underlying platform, while the customer remains responsible for many choices involving identities, data, configuration, application code, access policies, and workload behavior. The exact boundary changes by service model.
Important controls include strong identity and access management, multi-factor authentication, least privilege, secure secrets handling, encryption in transit and at rest, key management, patching, network segmentation, logging, vulnerability management, backups, incident response, and continuous configuration review.
A zero-trust approach does not assume that a request is safe merely because it originates inside a network perimeter. Access decisions should consider authenticated identity, authorization, device or workload context, and the sensitivity of the requested resource.
Common Cloud Risks
Cloud incidents frequently involve misconfiguration, excessive privileges, leaked credentials, insecure APIs, vulnerable software, weak secrets management, exposed storage, supply-chain compromise, insufficient logging, or misunderstood service behavior. Multi-tenancy also requires strong isolation mechanisms, although the provider controls many of the underlying isolation technologies.
Security must be designed into deployment automation. Infrastructure as code can improve consistency and reviewability, but a faulty template can reproduce the same insecure setting at large scale. Policy as code, automated scanning, peer review, and staged deployment can reduce this risk.
Economics, FinOps, and Governance
From Capital Expenditure to Consumption-Based Costs
Cloud computing can reduce the need for large upfront hardware purchases and can align spending more closely with usage. It can also create unpredictable costs because resources are easy to provision and because pricing includes many dimensions such as instance time, storage class, managed-service operations, support, licensing, and data transfer.
A strong cost analysis includes workload demand, utilization, reserved or committed capacity where appropriate, idle resources, architecture efficiency, data-transfer patterns, operational labor, resilience requirements, and the cost of migration or exit.
FinOps is a collaborative practice that connects engineering, finance, and business decision-making so that technology spending is tied to value. The goal is not simply to minimize cost. A more expensive architecture may be justified if it meaningfully improves reliability, performance, security, research output, or user experience.
Governance and Compliance
Cloud governance defines how an organization controls identity, resource creation, data classification, regions, network patterns, logging, tagging, budgets, security baselines, and approved services. Universities may need to coordinate central IT, research groups, faculties, legal teams, data-protection officers, procurement, and external collaborators.
Data residency, privacy law, contractual terms, intellectual property, export controls, research ethics, and sector-specific rules may constrain architecture. Compliance is not achieved merely by choosing a provider that holds certifications. The consuming organization must configure and operate its workloads consistently with its own obligations.
Sustainability and Responsible Cloud Use
Cloud data centers consume electricity, water, construction materials, network equipment, and hardware. Consolidation and high utilization can improve efficiency compared with poorly utilized local infrastructure, but cloud computing is not automatically environmentally preferable.
You should evaluate workload efficiency, hardware utilization, software architecture, data movement, retention policies, geographic electricity mix, cooling methods, hardware lifetime, and provider transparency. Autoscaling can reduce idle capacity, while inefficient code or unnecessary data replication can increase resource consumption.
Responsible cloud engineering therefore connects performance, cost, reliability, and environmental impact. The same design change can affect all four dimensions.
Architecture Case Study: University Research Platform
Imagine that a university research group needs a platform for students and researchers to upload experiment data, process it in parallel, visualize results, and share approved outputs with collaborators.
A possible architecture uses object storage for uploaded datasets, an event queue to decouple ingestion from processing, containerized workers or batch jobs for analysis, a managed database for metadata, an API for application logic, identity federation with the university account system, and a web front end delivered through a content-delivery service. Logs, traces, and metrics support observability.
The research team should decide which data may leave campus, which regions are permitted, how long raw and derived data must be retained, and who can access each dataset. Encryption and least-privilege policies should be applied. Backups and versioning should protect important data, while lifecycle rules can move older data to cheaper storage or delete it according to policy.
For reliability, processing jobs should be idempotent so that a failed job can be retried safely. Queues can buffer demand spikes. For cost control, large compute jobs can scale according to queue depth, and inactive development environments can be shut down automatically. For portability, the team should document provider-specific dependencies and maintain export procedures for critical data.
This case illustrates a central principle of cloud architecture: the best design emerges from requirements and trade-offs, not from maximizing the number of cloud services used.
Reference Frameworks and Further Reading
For a formal baseline, consult NIST Special Publication 800-145, The NIST Definition of Cloud Computing. For modern cloud-native concepts, consult the CNCF Cloud Native Definition. For technology-value and cost-management practice, consult the FinOps Foundation introduction to FinOps.
These frameworks use different scopes. NIST provides a foundational taxonomy, CNCF focuses on cloud-native operational and architectural practice, and FinOps focuses on collaborative technology-value management.
Interactive Tasks
Quiz: Test Your Knowledge
Which NIST characteristic allows consumers to provision resources without provider staff handling each request? (On demand self service) (!Broad network access) (!Community deployment) (!Cold start latency)
Which service model usually gives the customer the most control over operating systems? (Infrastructure as a Service) (!Platform as a Service) (!Software as a Service) (!Content delivery service)
Which deployment model combines distinct cloud infrastructures in a coordinated arrangement? (Hybrid cloud) (!Public cloud) (!Private cloud) (!Community cloud)
What is the main role of a hypervisor? (Manage virtual machines) (!Replace application code) (!Encrypt every database) (!Route all Internet traffic)
What do containers typically share with other containers on the same host? (Host operating system kernel) (!Dedicated physical data center) (!Separate hardware processor) (!Independent power supply)
What is Kubernetes primarily used to orchestrate? (Containerized workloads) (!University admissions) (!Physical building access) (!Spreadsheet formulas)
What does an RPO express in disaster recovery planning? (Acceptable data loss) (!Maximum processor speed) (!Network cable length) (!Number of user accounts)
Which security principle gives identities only the permissions they need? (Least privilege) (!Rapid elasticity) (!Vertical scaling) (!Measured service)
What is a key purpose of FinOps? (Maximize technology value) (!Eliminate all cloud spending) (!Replace application testing) (!Remove all provider contracts)
Why can data egress matter in cloud cost analysis? (Data transfer can incur charges) (!It disables encryption) (!It removes backups) (!It prevents autoscaling)
Memory Game
| Elasticity | Rapidly adjusting capacity to demand |
| Hypervisor | Software layer that manages virtual machines |
| Object storage | API based storage for data objects |
| Least privilege | Granting only necessary permissions |
| Observability | Understanding system state from telemetry |
| FinOps | Collaborative management of technology value and cost |
Drag and Drop
| Match the correct terms. | Topic |
|---|---|
| Infrastructure as a Service | Customer manages operating systems and applications |
| Platform as a Service | Provider manages more of the application runtime |
| Software as a Service | Provider delivers a complete application |
| Hybrid cloud | Coordinated use of distinct cloud infrastructures |
| Serverless computing | Provider abstracts most server provisioning |
...
Crossword Puzzle
| Elasticity | What cloud property describes rapidly adjusting capacity to demand? |
| Hypervisor | What software layer manages virtual machines? |
| Multitenancy | What term describes multiple customers sharing pooled infrastructure with isolation? |
| Kubernetes | What orchestration platform commonly manages containerized workloads? |
| Encryption | What process protects data by transforming it using cryptographic methods? |
| Observability | What capability helps engineers infer system state from logs metrics and traces? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- Cloud Vocabulary Map: Create a one-page concept map connecting elasticity, virtualization, containers, regions, storage, and identity; add one real example for each term.
- Service Model Comparison: Choose one university application and explain how responsibility would change if it were delivered through IaaS, PaaS, and SaaS.
- Data Center Observation: Study a data-center photograph or virtual tour and annotate the physical infrastructure that cloud abstractions depend on.
- Cost Awareness Diary: Design a simple table of cloud actions that could create cost, including compute runtime, storage growth, backups, and data transfer.
Standard
- Architecture Diagram: Design a cloud architecture for a student project with a web front end, API, database, storage, identity, and monitoring; justify every component.
- Container Experiment: Package a small application in a container, record image size and startup behavior, and compare the result with a virtual-machine-based deployment plan.
- Security Interview: Interview a university IT professional or cloud practitioner about identity, logging, backups, and shared responsibility; summarize the main lessons without exposing confidential information.
- Reliability Test: Build or simulate a service with redundant components, deliberately stop one component, and document what continues working, what fails, and why.
Advanced
- Cloud Migration Proposal: Produce a migration plan for a hypothetical university department, including workload classification, dependency analysis, security, data residency, cost, rollback, and exit strategy.
- FinOps Investigation: Analyze a sample cloud bill or public pricing calculator, identify major cost drivers, and propose changes that preserve required performance and reliability.
- Threat Model: Create a structured threat model for a cloud-native research platform and prioritize mitigations for identity abuse, exposed data, insecure APIs, supply-chain risk, and misconfiguration.
- Sustainable Architecture Review: Compare two technically viable cloud architectures and assess energy-related efficiency, resource utilization, data movement, cost, and service quality before recommending one.
Learning Assessment
- Architecture Defense: Given a workload with unpredictable traffic and sensitive research data, choose deployment, compute, storage, and security approaches and defend the trade-offs in a short oral or written presentation.
- Failure Analysis: Analyze a scenario in which one availability zone becomes unavailable and explain which architectural choices would determine whether the application remains usable.
- Responsibility Matrix: Build a responsibility matrix for the same application under IaaS, PaaS, and SaaS, then identify which security duties shift and which remain with the customer.
- Cost Performance Trade-off: Evaluate two scaling strategies using assumed demand patterns and explain when higher spending is justified by latency, resilience, or user experience.
- Portability Review: Inspect a proposed architecture that uses several provider-specific managed services and recommend where abstraction, standards, documentation, or export processes would reduce lock-in risk.
- Governance Transfer: Apply cloud governance principles to a new domain such as a public-sector archive, startup, or scientific collaboration and explain which controls must change.
Evidence of Learning
Important evidence includes knowledge of cloud definitions, service models, deployment models, virtualization, containers, serverless computing, networking, storage, reliability, security, cost, governance, and sustainability.
Skills evidence includes the ability to model architectures, explain responsibility boundaries, analyze failure modes, select services from requirements, estimate major cost drivers, interpret observability data, and communicate technical trade-offs.
Product evidence can include architecture diagrams, containerized applications, threat models, cost analyses, migration plans, experiment reports, interview summaries, and documented prototypes.
Transfer evidence is shown when you can apply the same principles to unfamiliar workloads, recognize when cloud computing is not the best solution, adapt controls to different legal or organizational contexts, and defend a design using evidence rather than product preference.
OERs on the Topic
The English Wikipedia article provides an openly accessible overview of Cloud computing, while the NIST, CNCF, and FinOps sources linked above provide complementary standards and professional frameworks.
Linked Learning Areas
