Unit 1: Cloud Computing Fundamentals

1. Cloud Computing Foundations & NIST Architectural Framework

1.1 The Paradigm Shift to Distributed Cloud Computing

Traditional enterprise IT relied upon physical, on-premises datacenters characterized by long procurement lead times, static server capacity, high initial capital expenditure (CapEx), and complex manual hardware lifecycle maintenance. Cloud computing revolutionized this model by transforming compute, storage, memory, and networking into utility-like abstractions provisioned instantly over the Internet.

According to the National Institute of Standards and Technology (NIST Special Publication 800-145), cloud computing is defined as:

"A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

CODECopy Code
+-----------------------------------------------------------------------------------------+
|                                NIST CLOUD ARCHITECTURE                                  |
|                                                                                         |
|  +-----------------------------------------------------------------------------------+  |
|  |                             5 ESSENTIAL CHARACTERISTICS                           |  |
|  |  [On-Demand Self-Service]  [Broad Network Access]  [Multi-Tenant Resource Pooling] |  |
|  |                   [Rapid Elasticity]           [Measured Service]                 |  |
|  +-----------------------------------------+-----------------------------------------+  |
|                                            |                                            |
|                                            v                                            |
|  +-----------------------------------------------------------------------------------+  |
|  |                                3 SERVICE MODELS                                   |  |
|  |       Infrastructure as a Service (IaaS) | Platform as a Service (PaaS)          |  |
|  |                               Software as a Service (SaaS)                        |  |
|  +-----------------------------------------+-----------------------------------------+  |
|                                            |                                            |
|                                            v                                            |
|  +-----------------------------------------------------------------------------------+  |
|  |                              4 DEPLOYMENT MODELS                                  |  |
|  |             Public Cloud  |  Private Cloud  |  Hybrid Cloud  |  Community Cloud    |  |
|  +-----------------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------------+

1.2 Five Essential Characteristics (NIST)

1. On-Demand Self-Service: Consumers can provision computing capabilities (such as CPU time, network bandwidth, disk storage, and virtual server instances) unilaterally and automatically via web consoles, command-line interfaces (CLIs), or REST APIs without human intervention from the service provider.
2. Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (smartphones, tablets, laptops, workstations, headless server containers).
3. Resource Pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a degree of location independence: the customer generally has no control or knowledge over the exact location of the hardware, but may specify location at a higher level of abstraction (country, region, or datacenter).
4. Rapid Elasticity: Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
5. Measured Service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer (Pay-As-You-Go).

2. Cloud Service Models & The Shared Responsibility Matrix

2.1 The Service Model Hierarchy (SPI Framework)

CODECopy Code
+---------------------------------------------------------------------------------------+
|                       SHARED RESPONSIBILITY & SERVICE MODELS                          |
|                                                                                       |
|  STACK LAYER         ON-PREMISES        IaaS             PaaS             SaaS        |
|  -----------------------------------------------------------------------------------  |
|  Applications        [ Customer ]   [ Customer ]     [ Customer ]     [ Provider ]    |
|  Data                [ Customer ]   [ Customer ]     [ Customer ]     [ Provider ]    |
|  Runtime             [ Customer ]   [ Customer ]     [ Provider ]     [ Provider ]    |
|  Middleware          [ Customer ]   [ Customer ]     [ Provider ]     [ Provider ]    |
|  Operating System    [ Customer ]   [ Customer ]     [ Provider ]     [ Provider ]    |
|  Virtualization      [ Customer ]   [ Provider ]     [ Provider ]     [ Provider ]    |
|  Servers (Compute)   [ Customer ]   [ Provider ]     [ Provider ]     [ Provider ]    |
|  Storage             [ Customer ]   [ Provider ]     [ Provider ]     [ Provider ]    |
|  Networking          [ Customer ]   [ Provider ]     [ Provider ]     [ Provider ]    |
+---------------------------------------------------------------------------------------+

Infrastructure as a Service (IaaS)

• Concept: The consumer provisions fundamental computing resources—processing, storage, networks, and other foundational computing resources—where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications.
• Provider Role: Physical facilities, datacenter security, power, HVAC, server hardware, virtualization hypervisor (e.g., KVM, Xen, Nitro).
• Consumer Role: Guest operating system selection, OS patching, runtime environments, middleware installation, application logic, data governance, firewall rules, and network routing.
• Examples: Amazon EC2, Google Compute Engine (GCE), Microsoft Azure Virtual Machines.

Platform as a Service (PaaS)

• Concept: The consumer deploys onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.
• Provider Role: All IaaS layers plus operating system lifecycle, automatic security patching, database engine binaries, runtime environments (e.g., Node.js, Python, JVM, .NET), auto-scaling infrastructure, and container orchestrators.
• Consumer Role: Application source code, application configuration parameters, and application-level data.
• Examples: AWS Elastic Beanstalk, Google App Engine, Heroku, Azure App Services.

Software as a Service (SaaS)

• Concept: The consumer uses the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface (web browser) or a program interface.
• Provider Role: Complete end-to-end management of the entire technology stack—hardware, hypervisor, OS, runtime, application software, bug fixes, database storage, and high availability.
• Consumer Role: User management, role assignment, tenant-specific application settings, and customer data ownership.
• Examples: Google Workspace, Microsoft 365, Salesforce CRM, Workday.

Function as a Service (FaaS / Serverless)

• Concept: Event-driven, ephemeral compute execution model where application logic executes within micro-containers spun up on demand in response to triggers (HTTP requests, message broker events, database table updates).
• Characteristics: Zero idle server cost, sub-second billing, fully automated horizontal scaling, stateless compute units.
• Examples: AWS Lambda, Google Cloud Functions, Azure Functions.

3. Cloud Deployment Models

3.1 Deployment Topologies

1. Public Cloud:
   • The cloud infrastructure is provisioned for open use by the general public.
   • Owned, managed, and operated by a commercial cloud service provider (e.g., AWS, Azure, Google Cloud).
   • Resources exist on the premises of the cloud provider across global availability zones.
   • Benefits: Zero hardware CapEx, massive economies of scale, near-infinite capacity, multi-region geo-redundancy.
2. Private Cloud:
   • The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (business units).
   • May be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
   • Powered by software-defined datacenter platforms such as OpenStack, VMware vSphere/Tanzu, or Microsoft Azure Stack.
   • Benefits: Absolute sovereignty over data location, hardware isolation, strict regulatory compliance, low-latency LAN connectivity.
3. Hybrid Cloud:
   • The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability.
   • Typical Use Case: Cloud Bursting (running baseline transactional workloads on private infrastructure and bursting to public cloud instances during seasonal demand spikes).
4. Community Cloud:
   • The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations).
   • Examples: Government clouds (AWS GovCloud), healthcare federated research clouds, banking cooperative consortia.
5. Multi-Cloud Architecture:
   • Deliberate utilization of multiple distinct public cloud providers (e.g., running core microservices across AWS and Google Cloud) to mitigate single-vendor lock-in, optimize cost per service, and leverage best-of-breed specialized services (e.g., GCP for AI/ML, AWS for enterprise compute).

4. Service-Oriented Architecture (SOA) & Transition to Microservices

4.1 Foundations of SOA

Service-Oriented Architecture (SOA) is an architectural style wherein enterprise software is structured as a collection of modular, autonomous, network-accessible business services. Each service encapsulates a discrete business function (e.g., OrderProcessing, CreditVerification, ShippingQuote) accessible via standardized service contracts.

Core Architectural Roles in SOA

1. Service Provider: Implements the business logic and publishes the service interface contract.
2. Service Consumer: Queries the registry, binds to the provider's endpoint, and invokes the service operations.
3. Service Broker / Registry: Central directory (such as UDDI - Universal Description, Discovery, and Integration) where providers register contracts and consumers discover them.

CODECopy Code
+-----------------------------------------------------------------------------------------+
|                               SOA vs. MICROSERVICES ARCHITECTURE                        |
|                                                                                         |
|       SERVICE-ORIENTED ARCHITECTURE (SOA)               MICROSERVICES ARCHITECTURE      |
|                                                                                         |
|      [Service A]    [Service B]    [Service C]        [Service A]       [Service B]     |
|          |              |              |                   |                 |          |
|          v              v              v                   v                 v          |
|  +--------------------------------------------+    +---------------+ +---------------+  |
|  |   ENTERPRISE SERVICE BUS (ESB)             |    | Dedicated DB  | | Dedicated DB  |  |
|  |   - Complex Message Transformation (XML)   |    +---------------+ +---------------+  |
|  |   - Protocol Translation (SOAP/JMS/MQ)     |            \                 /          |
|  |   - Orchestration & Central Routing        |       Lightweight REST / gRPC / Kafka   |
|  +--------------------------------------------+       ("Smart Endpoints, Dumb Pipes")   |
|                         |                                                               |
|                         v                                                               |
|             [ Monolithic Shared DB ]                                                    |
+-----------------------------------------------------------------------------------------+

4.2 The Enterprise Service Bus (ESB) & Limitations

Traditional SOA heavily relied upon an Enterprise Service Bus (ESB)—a centralized, intelligent middleware platform responsible for:

• Protocol translation (e.g., converting HTTP to JMS or MQSeries).
• Complex message transformations (e.g., XML Schema mapping via XSLT).
• Centralized routing, business process orchestration (WS-BPEL), and policy enforcement.

Limitations of the ESB Pattern:

• Centralized Single Point of Failure (SPOF): If the ESB cluster degrades, the entire enterprise halts.
• Organizational Bottleneck: Adding or altering service interfaces required specialized ESB integration teams, creating deployment backlogs.
• Heavyweight Protocols: Predominantly based on verbose SOAP, XML, and WSDL contracts requiring high CPU serialization overhead.

4.3 SOA vs. Microservices Paradigm

Microservices evolved as a direct refinement of SOA principles designed for modern cloud-native environments:

5. Open-Source Cloud Infrastructure: OpenStack Architecture

5.1 OpenStack Overview

OpenStack is the leading open-source software platform used to build public and private Infrastructure as a Service (IaaS) clouds. It pools physical compute, storage, and networking hardware in a datacenter and provides an abstracted management layer controlled via self-service web dashboards and standardized RESTful APIs.

CODECopy Code
+-----------------------------------------------------------------------------------------+
|                                OPENSTACK ARCHITECTURE                                   |
|                                                                                         |
|       +-------------------------------------------------------------------------+       |
|       |                     HORIZON (Web Dashboard UI)                          |       |
|       +-------------------------------------------------------------------------+       |
|                                            |                                            |
|       +------------------------------------+------------------------------------+       |
|       |                       KEYSTONE (Identity & Service Catalog)             |       |
|       +------------------------------------+------------------------------------+       |
|                           |                |                |                           |
|                           v                v                v                           |
|       +-----------------------+  +-------------------+  +-----------------------+       |
|       |     NOVA (Compute)    |  | NEUTRON (Network) |  |   GLANCE (Image Svc)  |       |
|       |  Manages VM Hypervisor|  | Software-Defined  |  | VM Templates & Raw OS |       |
|       |  Scheduling & Life    |  | SDN, Routers, IPs |  | Boot Images (QCOW2)   |       |
|       +-----------+-----------+  +---------+---------+  +-----------------------+       |
|                   |                        |                                            |
|                   v                        v                                            |
|       +-----------------------+  +----------------------------------------------+       |
|       | CINDER (Block Storage)|  | SWIFT (Object Storage)                       |       |
|       | Persistent VM Volumes |  | Highly Available Blob/Object Store           |       |
|       +-----------------------+  +----------------------------------------------+       |
+-----------------------------------------------------------------------------------------+

5.2 Key OpenStack Subsystems

1. Keystone (Identity Service):
   • Provides central authentication, token issuance, user authorization, and the service catalog.
   • Every API request across any OpenStack module must first validate an authentication token issued by Keystone.
2. Nova (Compute Engine):
   • The fabric controller that manages the lifecycle of virtual machines across physical compute hypervisors (KVM, QEMU, Xen).
   • Features the nova-scheduler, which uses filtering and weighting algorithms to place new instances on optimal physical nodes.
3. Neutron (Software-Defined Networking):
   • Manages virtual networks, subnets, routers, floating IP addresses, VLANs, VXLAN overlays, and security groups.
   • Provides network connectivity to Nova instances via Open vSwitch (OVS) or hardware plugins.
4. Glance (Image Service):
   • Central repository for virtual machine disk images and server metadata.
   • Stores raw disk snapshots (QCOW2, RAW, ISO, VHD) used by Nova to instantiate new compute instances.
5. Cinder (Block Storage):
   • Provides persistent, block-level storage volumes that can be attached, detached, and snapshot-managed for Nova instances (analogous to virtual hard drives).
6. Swift (Object Storage):
   • Distributed, highly available, eventually consistent object storage system designed for unstructured data, backups, and media files.
7. Heat (Orchestration Engine):
   • Template-driven orchestration tool (Heat Orchestration Templates - HOT) that deploys composite cloud applications and auto-scaling infrastructure via declarative code.
8. Horizon (Dashboard):
   • Extensible, web-based graphical user interface allowing administrators and tenant users to provision and monitor resources.

6. Amazon Web Services (AWS) Ecosystem & Core Infrastructure

6.1 AWS Global Infrastructure Hierarchy

Amazon Web Services provides global cloud infrastructure designed for high fault tolerance and low latency:

• AWS Regions: Separate geographic locations around the globe (e.g., us-east-1 in N. Virginia, ap-south-1 in Mumbai). Each Region is completely isolated from other regions to prevent failure propagation.
• Availability Zones (AZs): Distinct datacenters located within a Region, separated by meaningful physical distance (miles) to safeguard against local disasters, but interconnected via high-bandwidth, ultra-low-latency private fiber networking. A Region contains a minimum of three AZs.
• Edge Locations: Globally distributed network points of presence (PoP) hosting Amazon CloudFront (Content Delivery Network - CDN) and AWS Route 53 (DNS) to cache content and terminate SSL/TLS connections close to end users.

6.2 Core AWS Compute & Networking Services

1. Amazon EC2 (Elastic Compute Cloud):
   • Provides resizable virtual compute capacity (instances).
   • Instance Families: General Purpose (t4g, m6i), Compute Optimized (c6g), Memory Optimized (r6g), Accelerated Computing (p4d GPUs).
   • Purchasing Models: On-Demand, Savings Plans, Reserved Instances (RI), and Spot Instances (surplus capacity at up to 90% discount, subject to 2-minute termination notices).
2. Amazon VPC (Virtual Private Cloud):
   • Logically isolated virtual network dedicated to an AWS account.
   • Subnets: Public subnets (associated with an Internet Gateway - IGW) and Private subnets (isolated, routing outbound internet traffic through a NAT Gateway).
   • Security Groups: Stateful virtual firewalls operating at the instance level; return traffic is automatically allowed.
   • Network Access Control Lists (NACLs): Stateless subnet-level firewalls requiring explicit inbound and outbound permit rules.
3. Amazon S3 (Simple Storage Service):
   • Serverless, object-based storage platform providing 99.999999999% (11 9's) of data durability.
   • Stores data as objects (files up to 5 TB) inside uniquely named global containers called Buckets.
   • Storage Classes: S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA (Infrequent Access), S3 Glacier Flexible, S3 Glacier Deep Archive.
4. Amazon EBS (Elastic Block Store):
   • High-performance block-storage volumes designed for persistent file systems attached directly to EC2 instances.
   • Types: General Purpose SSD (gp3), Provisioned IOPS SSD (io2), Throughput Optimized HDD (st1).
5. AWS IAM (Identity and Access Management):
   • Centralized authentication and authorization engine managing Users, User Groups, IAM Roles, and JSON Policy Documents enforcing the Principle of Least Privilege.

6.3 Resilience, Monitoring & Observability

• Elastic Load Balancing (ELB): Automatically distributes incoming application traffic across multiple targets (EC2 instances, containers, IP addresses) across multiple AZs. Includes Application Load Balancer (ALB - Layer 7 HTTP/HTTPS) and Network Load Balancer (NLB - Layer 4 ultra-low latency TCP/UDP).
• Auto Scaling Groups (ASG): Dynamically scales EC2 instance counts outward and inward based on demand metrics (CPU utilization, request count per target) or scheduled timeframes.
• Amazon CloudWatch: Telemetry service that collects metrics, monitors log files, and sets automated alarm actions.
• AWS CloudTrail: Governance and compliance service that continuously records all API calls, administrative actions, and console logins across an AWS account for non-repudiation auditing.