Cloud Service Models

Cloud Provisioning Models

Cloud computing offers different service models, each providing a different level of abstraction and management. These models define what resources are managed by the provider versus the customer.

Traditional Service Models

Infrastructure as a Service (IaaS)

Definition: Provider provisions processing, storage, network, and other fundamental computing resources where the customer can deploy and run arbitrary software, including operating systems and applications.

Customer manages:

• Operating systems
• Middleware
• Applications
• Data
• Runtime environments

Provider manages:

• Servers and storage
• Networking
• Virtualization
• Data center infrastructure

Key characteristics:

• Most flexible cloud service model
• Customer has maximum control over infrastructure configuration
• Requires the most technical expertise to manage

Examples:

• Amazon EC2
• Google Compute Engine
• Microsoft Azure VMs
• OpenStack

Platform as a Service (PaaS)

Definition: Customer deploys applications onto cloud infrastructure using programming languages, libraries, services, and tools supported by the provider.

Customer manages:

• Applications
• Data
• Some configuration settings

Provider manages:

• Operating systems
• Middleware
• Runtime
• Servers and storage
• Networking
• Data center infrastructure

Key characteristics:

• Reduces complexity of infrastructure management
• Accelerates application deployment
• Often includes development tools and services
• Less control compared to IaaS

Examples:

• Heroku
• Google App Engine
• Microsoft Azure App Service
• AWS Elastic Beanstalk

Software as a Service (SaaS)

Definition: Provider delivers applications running on cloud infrastructure accessible through various client devices, typically via a web browser.

Customer manages:

• Minimal application configuration
• Data (to some extent)

Provider manages:

• Everything including the application itself
• All underlying infrastructure and software

Key characteristics:

• Minimal management required from customer
• Typically subscription-based
• Immediate usability
• Limited customization

Examples:

• Microsoft Office 365
• Google Workspace
• Salesforce
• Dropbox

IaaS in Detail

How IaaS Works

1. Customer requests VMs with specific configurations (CPU, RAM, storage)
2. Provider matches request against available data center machines
3. VMs are provisioned on physical hosts with requested resources
4. Customer accesses and manages VMs through provided interfaces

Resource Allocation

• CPU allocation: Either pinned to specific cores or scheduled by the hypervisor
• Memory allocation: Usually strictly partitioned between VMs
• Storage: Allocated based on requested volume sizes
• Network resources: Shared among VMs with quality of service controls

IaaS APIs

IaaS providers offer APIs for programmatic control of resources:

• Create, start, stop, clone operations
• Monitoring capabilities
• Pricing information access
• Resource management

Benefits:

• Flexibility through code-based infrastructure control
• Automation of provisioning and management
• Integration with other tools and systems

IaaS Pricing Models

Typically based on a combination of:

• VM instance type/size
• Duration of usage (per hour/minute)
• Storage consumption
• Network traffic
• Additional services used

PaaS in Detail

Advantages Over IaaS

• Reduced development and maintenance effort
• No OS patching or middleware configuration
• Higher level of abstraction
• Focus on application development rather than infrastructure

PaaS Components

• Development tools and environments
• Database services
• Integration services
• Application runtimes
• Monitoring and management tools

PaaS Pricing Models

More diverse than IaaS, potentially based on:

• Time-based usage
• Per query (database services)
• Per message (queue services)
• Per CPU usage (request-triggered applications)
• Storage consumption

Example: Amazon DynamoDB

• Key-value store used inside Amazon (powers parts of AWS like S3)
• Designed for high scalability (100-1000 servers)
• Emphasizes availability over consistency
• Uses peer-to-peer approach with no single point of failure
• Nodes can be added/removed at runtime
• Optimized for key-value operations rather than range queries

SaaS in Detail

Business Model

• Provider develops and maintains the application
• Offers it to customers for a subscription fee
• Handles all updates, security, and infrastructure
• Typically multi-tenant, serving many customers on shared infrastructure

Typical SaaS Characteristics

• Web-accessible applications
• Usually based on monthly/annual subscription
• Automatic updates and maintenance
• Limited customization compared to self-hosted solutions
• Reduced IT overhead for customers

Example: Salesforce

• Comprehensive customer relationship management platform
• Replaces spreadsheets, to-do lists, and email with integrated platform
• Backed by elastic cloud services that scale with company growth
• Tiered pricing based on features and user count

Choosing Between Service Models

Factors to consider when selecting a service model:

1. Core competency assessment: What skills exist in your organization?
2. Cost considerations: How much can you spend on each layer?
3. Flexibility requirements: How much control do you need?
4. Regulatory and privacy concerns: Where does your data need to reside?

This decision applies to both individuals and organizations and should align with strategic goals.

Link to original

Serverless Computing

What Is Serverless Computing?

Serverless computing (also known as Function-as-a-Service or FaaS) is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Despite the name “serverless,” servers are still used, but their management is abstracted away from the developer.

Serverless represents an evolution in cloud computing models: IaaS → PaaS → FaaS

Key Characteristics

1. Event-driven architecture

   • Functions execute in response to specific triggers or events
   • No continuous running processes or infrastructure

2. Ephemeral execution

   • Functions are created only when needed
   • No long-running instances waiting for requests

3. Pay-per-execution model

   • Billing based only on actual function execution time and resources used
   • No charges when functions are idle

4. Automatic scaling

   • Providers handle all scaling without developer intervention
   • Scale from zero to peak demand automatically

5. Stateless execution

   • Functions don’t maintain state between invocations
   • External storage required for persistent data

6. Time-limited execution

   • Typically limited to 5-15 minutes maximum execution time
   • Designed for short, focused operations

Serverless Architecture Components

A serverless architecture typically includes:

Core Components

1. Functions

   • Self-contained units of code that perform specific tasks
   • Usually single-purpose with limited scope
   • Can be written in various programming languages

2. Event Sources

   • Triggers that initiate function execution:
     • HTTP requests via API Gateway
     • Database changes
     • File uploads
     • Message queue events
     • Scheduled events/timers

3. Supporting Services

   • API Gateway: Handles HTTP requests, routing to appropriate functions
   • State Management: External databases, cache services, object storage
   • Identity and Access Management: Security and authentication controls

Execution Environment

• Functions deploy as standalone units of code
• Cold starts occur when new container instances are initialized
• Environment is ephemeral with no persistent local storage
• Configuration managed through environment variables or parameter stores

Popular Serverless Platforms

• AWS Lambda: Pioneer in serverless computing, integrated with AWS ecosystem
• Azure Functions: Microsoft’s serverless offering with .NET integration
• Google Cloud Functions: Integrated with Google Cloud services
• Cloudflare Workers: Edge-focused serverless platform
• IBM Cloud Functions: Based on Apache OpenWhisk
• DigitalOcean Functions: Serverless offering for smaller deployments

Use Cases for Serverless

Ideal Use Cases:

1. Event processing

   • Processing uploads, form submissions, or other user-triggered events

2. Scheduled tasks

   • Running periodic jobs like cleanup, reports, or maintenance

3. Asynchronous processing

   • Background tasks that don’t need immediate responses

4. Webhooks and integrations

   • Handling requests from third-party services

5. Microservices backends

   • Building lightweight APIs and service components

6. IoT applications

   • Processing data from connected devices

Example Serverless Workflow

A blog post update scenario:

1. User updates their blog with a new post
2. Updating webpage content triggers a function
3. Function logic:
   • Connect to database
   • Update database records
   • Update search index
   • Trigger other functions (e.g., for ads, analytics, notifications)

Benefits of Serverless Computing

1. Lower costs

   • Precise usage-based billing
   • No paying for idle resources
   • Reduced operational overhead

2. Simplified operations

   • No server management
   • Provider handles patching, scaling, and availability
   • Focus on code rather than infrastructure

3. Enhanced scalability

   • Automatic resource provisioning
   • Scale to zero when not in use
   • Handle unpredictable traffic spikes

4. Faster time to market

   • Reduced deployment complexity
   • Focus on business logic rather than infrastructure
   • Built-in high availability

Challenges of Serverless Computing

1. Cold start latency

   • Initial function invocation can be slow
   • Particularly impacts rarely-used functions

2. Vendor lock-in

   • Functions often rely on provider-specific services and APIs
   • Migration between providers can be difficult

3. Limited execution duration

   • Not suitable for long-running processes
   • Maximum execution times enforced by providers

4. Complex state management

   • No built-in state persistence between invocations
   • External services required for data storage

5. Debugging difficulties

   • Limited visibility into execution environment
   • Complex distributed systems harder to troubleshoot

6. Resource constraints

   • Memory limitations (typically 128MB - 10GB)
   • CPU allocation tied to memory configuration
   • Disk space restrictions

Low/No Code Development

Related to serverless is the emergence of low/no-code development platforms:

• Definition: Visual environments to create applications with minimal or no coding

• Features:

  • Drag-and-drop interfaces
  • Pre-built templates
  • Auto-deployment
  • Built-in integrations

• Examples from major cloud providers:

  • Amazon Honeycode
  • Azure Power Apps
  • Google AppSheet
  • Azure Logic Apps
  • Amazon App Runner
  • Google Vertex AI

• Advantages:

  • Low technical barrier
  • Rapid development
  • Flexible control of data assets

• Disadvantages:

  • Vendor lock-in
  • Limited customization options
  • Platform dependencies

Serverless vs. Traditional Cloud Models

Aspect	Serverless	Traditional (VMs/Containers)
Provisioning	Automatic	Manual or automated scripts
Scaling	Automatic and instant	Manual or auto-scaling groups
State	Stateless by default	Can maintain state
Pricing	Pay per execution	Pay per allocation
Runtime	Limited duration	Indefinite
Deployment	Function-level	Application/container level
Cold starts	Yes	No (for long-running instances)
Resource limits	Fixed by provider	Configurable

Link to original

Cloud Deployment Models

Cloud deployment models define where cloud resources are located, who operates them, and how users access them. Each model offers different tradeoffs in terms of control, flexibility, cost, and security.

Core Deployment Models

Public Cloud

Definition: Third-party service providers offer cloud services over the public internet to the general public or a large industry group.

Characteristics:

• Resources owned and operated by third-party providers
• Multi-tenant environment (shared infrastructure)
• Pay-as-you-go pricing model
• Accessible via internet
• Provider handles all infrastructure management

Advantages:

• Low initial investment
• Rapid provisioning
• No maintenance responsibilities
• Nearly unlimited scalability
• Geographic distribution

Disadvantages:

• Limited control over infrastructure
• Potential security and compliance concerns
• Possible performance variability
• Potential for vendor lock-in

Major providers:

• AWS, Google Cloud Platform, Microsoft Azure
• IBM Cloud, Oracle Cloud
• DigitalOcean, Linode, Vultr

Private Cloud

Definition: Cloud infrastructure provisioned for exclusive use by a single organization, either on-premises or hosted by a third party.

Characteristics:

• Single-tenant environment
• Greater control over resources
• Can be managed internally or by third parties
• Usually requires capital expenditure for on-premises solutions
• Custom security policies and compliance measures

Variations:

• On-premises private cloud: Hosted within organization’s own data center
• Outsourced private cloud: Hosted by third-party but dedicated to one organization

Advantages:

• Enhanced security and privacy
• Greater control over infrastructure
• Customization to specific needs
• Potentially better performance and reliability
• Compliance with strict regulatory requirements

Disadvantages:

• Higher initial investment
• Responsibility for maintenance
• Limited scalability compared to public cloud
• Requires specialized staff expertise

Technologies:

• OpenStack, VMware vSphere/vCloud
• Microsoft Azure Stack
• OpenNebula, Eucalyptus, CloudStack

Community Cloud

Definition: Cloud infrastructure shared by several organizations with common concerns (e.g., mission, security requirements, policy, or compliance considerations).

Characteristics:

• Multi-tenant but limited to specific group
• Shared costs among community members
• Can be managed internally or by third-party
• Designed for organizations with similar requirements

Examples:

• Government clouds
• Healthcare clouds
• Financial services clouds
• Research/academic institutions

Advantages:

• Cost sharing among community members
• Meets specific industry compliance needs
• Collaborative environment for shared goals
• More control than public cloud

Disadvantages:

• Limited to community specifications
• Less flexible than public cloud
• Costs higher than public cloud
• Potential governance challenges

Hybrid Cloud

Definition: Composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities but are bound together by technology enabling data and application portability.

Characteristics:

• Combination of public and private/community clouds
• Data and applications move between environments
• Requires connectivity and integration between clouds
• Workloads distributed based on requirements

Approaches:

• Application-based: Different applications in different clouds
• Workload-based: Same application, different workloads in different clouds
• Data-based: Data storage in one cloud, processing in another

Advantages:

• Flexibility to run workloads in optimal environment
• Cost optimization (use public cloud for variable loads)
• Risk mitigation through distribution
• Easier path to cloud migration
• Balance between control and scalability

Disadvantages:

• Increased complexity of management
• Integration challenges
• Security concerns at connection points
• Potential performance issues with data transfer
• Requires more specialized expertise

Cross-Cloud Computing

Cross-cloud computing refers to the ability to operate seamlessly across multiple cloud environments.

Types of Cross-Cloud Approaches

1. Multi-clouds

   • Using multiple cloud providers independently
   • Different services from different providers
   • No integration between clouds
   • Translation libraries to abstract provider differences

2. Hybrid clouds

   • Integration between private and public clouds
   • Data and applications span environments
   • Common programming models

3. Federated clouds

   • Common APIs across multiple providers
   • Unified management layer
   • Consistent experience across providers

4. Meta-clouds

   • Broker-based approach
   • Intermediary selects optimal cloud provider
   • Abstracts underlying cloud differences

Motivations for Cross-Cloud Computing

• Avoiding vendor lock-in: Independence and portability
• Resilience: Protection against vendor-specific outages
• Service diversity: Leveraging unique capabilities of different providers
• Geographic presence: Using region-specific deployments
• Regulatory compliance: Meeting data sovereignty requirements

Implementation Tools

• Infrastructure as Code tools: Terraform, OpenTofu, Pulumi
• Cloud-agnostic libraries: Libcloud, jclouds
• Multi-cloud platforms: Commercial and academic proposals
• Cloud brokers: Services that manage workloads across clouds

Trade-offs in Cross-Cloud Computing

• Complexity: Additional management overhead
• Abstraction costs: Loss of provider-specific features
• Security challenges: Managing identity across clouds
• Performance implications: Data transfer between clouds
• Cost management: Multiple billing relationships

Deployment Model Selection Factors

When choosing a deployment model, consider:

Cost Factors

• Upfront capital expenditure vs. operational expenses
• Total cost of ownership including management costs
• Skills required to operate the chosen model

Time to Market

• Public cloud offers fastest deployment
• Private cloud requires more setup time
• Hybrid approaches balance speed with control

Security and Compliance

• Regulatory requirements may dictate deployment model
• Data sovereignty considerations
• Industry-specific compliance frameworks

Control Requirements

• Need for physical access to hardware
• Customization requirements
• Performance guarantees

Comparative Matrix

Aspect	Public Cloud	Private (Internally Managed)	Private (Outsourced)
Upfront Cost	Low	High	Medium
Time to Build	Low	High	Medium
Security Risk	Higher	Lower	Medium
Control	Low	High	Medium

Link to original

Data Centre Design

Data centres are the backbone of cloud computing, and their design plays a crucial role in ensuring sustainability, reliability, and efficiency. This note focuses on the infrastructure design aspects that enable dependable and sustainable data centre operations.

Data Centre Infrastructure Basics

A modern data centre consists of several key components:

• Servers: Individual compute units, typically rack-mounted
• Racks: Metal frames housing multiple servers
• Cooling systems: Equipment to remove heat generated by servers
• Power distribution systems: Deliver electricity to all equipment
• Network infrastructure: Connects servers internally and to the outside world
• Physical security systems: Control access to the facility

Designing for Hardware Redundancy

Geographic Redundancy

• Definition: Distributing data centres across multiple geographic regions
• Purpose: Mitigate impact of regional outages (natural disasters, power grid failures)
• Implementation:
  • Multiple data centres in different regions
  • Data replication across regions
  • Load balancing between regions
• Benefit: Ensures continued operation even if an entire region goes offline

Server Redundancy

• Definition: Deploying servers in clusters with automatic failover mechanisms
• Purpose: Ensure service availability despite individual server failures
• Implementation:
  • Server clusters managed by virtualization technology
  • Automatic failover when hardware issues are detected
  • N+1 or N+2 redundancy (extra servers beyond minimum requirements)
• Benefit: Seamless operation during hardware failures

Storage Redundancy

• Definition: Replicating data across multiple storage devices and technologies
• Purpose: Prevent data loss due to disk or storage system failures
• Implementation:
  • RAID configurations to protect against disk failures
  • Replication within and across data centres
  • Multiple storage technologies (SSD, HDD, tape) for different tiers
• Benefit: Data remains accessible and intact despite storage component failures

Network Redundancy

Reliable networking is critical for data centre operations. Redundancy is implemented at multiple levels:

Server-level Network Redundancy

• Redundant Network Interface Cards (NICs) on each server
• Dual or more power supplies to eliminate single points of failure
• Multiple network paths from each server

Network-level Redundancy

• Redundant switches, routers, firewalls, and load balancers
• Multiple connection paths between network devices
• Diverse carrier connections for external connectivity

Link and Path-level Redundancy

• Link aggregation: Multiple physical links between network devices
• Spanning Tree Protocol (STP): Prevents network loops while maintaining redundancy
• Equal-Cost Multi-Path (ECMP): Distributes traffic across multiple paths

Network Topologies for Redundancy

1. Hierarchical/3-tier topology:

   • Access layer (connects to servers)
   • Aggregation layer (connects access switches)
   • Core layer (high-speed backbone)
   • Redundant connections between layers

2. Fat-tree/Clos topology:

   • Non-blocking architecture
   • Multiple equal-cost paths between any two servers
   • Better scalability and fault tolerance than traditional hierarchical designs

Power Redundancy

Data centres require constant and reliable power supply to function:

• Multiple power feeds from different utility substations

• Uninterruptible Power Supplies (UPS) for temporary outages

  • Battery systems that provide immediate power during utility failures
  • Typically designed to support the data centre for minutes to hours

• Backup generators for medium/long-term outages

  • Diesel or natural gas powered
  • Automatically start when utility power fails
  • Sized to power the entire facility for days

• Power Distribution Units (PDUs) with dual power inputs

  • Ensure continuous rack power
  • Allow maintenance of one power path without downtime

Power Redundancy Configurations

• N: Basic capacity with no redundancy
• N+1: Basic capacity plus one additional component
• 2N: Fully redundant, two complete power paths
• 2N+1: Fully redundant with additional backup

Cooling Redundancy

Data centres generate significant heat that must be removed efficiently:

• Heating, Ventilation, and Air Conditioning (HVAC) systems

  • Control temperature, humidity, and air quality
  • Critical for equipment longevity and reliability

• Cooling redundancy measures:

  • N+1 cooling: One extra cooling unit beyond required capacity
  • Multiple cooling technologies to mitigate failure modes
    • Computer Room Air Conditioning (CRAC) units
    • Free cooling (using outside air when temperature permits)
    • In-row cooling (targeted cooling closer to heat sources)
  • Redundant cooling loops – pipes, heat exchangers, pumps
  • Hot/Cold aisle containment – prevents hot and cold air mixing

Advanced Cooling Technologies

• Free cooling: Using outside air when temperature permits
• Liquid cooling: Direct liquid cooling of components
• Immersion cooling: Servers submerged in non-conductive liquid
• Evaporative cooling: Using water evaporation to reduce temperatures

Design Standards and Tiers

The Uptime Institute defines four tiers of data centre reliability:

1. Tier I: Basic Capacity

   • Single path for power and cooling
   • No redundant components
   • 99.671% availability (28.8 hours downtime/year)

2. Tier II: Redundant Components

   • Single path for power and cooling
   • Redundant components
   • 99.741% availability (22.0 hours downtime/year)

3. Tier III: Concurrently Maintainable

   • Multiple paths for power and cooling, only one active
   • Redundant components
   • 99.982% availability (1.6 hours downtime/year)

4. Tier IV: Fault Tolerant

   • Multiple active paths for power and cooling
   • Redundant components
   • 99.995% availability (0.4 hours downtime/year)
   • Can withstand any single equipment failure without impact

Sustainable Design Considerations

Modern data centre design increasingly incorporates sustainability features:

• Energy-efficient equipment selection
• Renewable energy sources (solar, wind, hydroelectric)
• Heat recovery systems to repurpose waste heat
• Water-efficient cooling technologies
• Modular designs for efficient expansion
• Smart monitoring systems to optimize resource usage

Real-world Implementation Challenges

Designing highly redundant data centres faces several challenges:

• Cost vs. reliability tradeoffs
• Physical space constraints
• Regulatory and compliance requirements
• Upgrading existing facilities
• Integrating new technologies with legacy systems
• Balancing performance and sustainability goals

Related: Cloud Sustainability - Carbon Footprint Frameworks, Cloud Sustainability - Measurement Granularities, Cloud System Design - High Availability

Link to original