Unit 3: Cloud Architecture and Economics - Subjective Questions

The cloud computing stack is a layered model that organizes cloud resources and services according to the level of abstraction offered to users.

• Infrastructure as a Service (IaaS): Provides virtual machines, storage, networks, and other fundamental computing resources. Customers manage operating systems, applications, and data.
• Platform as a Service (PaaS): Provides operating environments, databases, middleware, development tools, and deployment services. Developers focus on applications without managing the underlying infrastructure.
• Software as a Service (SaaS): Delivers complete applications through a browser or API. The provider manages the application and the entire supporting stack.

Each higher layer depends on services supplied by the layer below it. As abstraction increases from IaaS to SaaS, customer control decreases while provider responsibility increases.

The main trade-off is between control and convenience. IaaS provides the greatest control but requires more administration. SaaS provides the least infrastructure control but minimizes operational effort. PaaS lies between these two models.

Workload distribution is the process of assigning incoming requests, jobs, or data-processing tasks among multiple computing resources so that no resource becomes unnecessarily overloaded.

Important mechanisms include:

• Load balancing: Distributes network requests using methods such as round robin, least connections, or weighted routing.
• Auto-scaling: Adds or removes instances according to demand and performance metrics.
• Task scheduling: Assigns batch or background jobs based on resource availability, deadlines, or priority.
• Geographical routing: Directs users to nearby or less congested regions.
• Replication and partitioning: Distributes data access across replicas or partitions.

Effective workload distribution improves availability, response time, throughput, fault tolerance, and resource utilization. It also prevents individual servers from becoming bottlenecks or single points of failure.

Static workload distribution assigns work according to predefined rules and does not continuously consider the current state of resources.

• It is simple and has low scheduling overhead.
• Examples include fixed partitioning and basic round-robin allocation.
• It is appropriate when workloads and resource capacities are predictable and similar.

Dynamic workload distribution uses current information such as CPU utilization, queue length, latency, or server health when assigning work.

• It adapts to changing workloads and resource failures.
• Examples include least-connections routing and metric-based auto-scaling.
• It is appropriate for variable, unpredictable, or rapidly changing demand.

Static methods are easier to implement, whereas dynamic methods generally achieve better utilization and performance at the cost of monitoring and decision-making overhead.

Capacity planning is the process of estimating and provisioning the computing, storage, and network resources required to satisfy current and future workload demands at an acceptable cost and service level.

Major steps are:

1. Characterize the workload: Measure request rates, concurrency, transaction types, and data volumes.
2. Establish service objectives: Define latency, throughput, availability, and recovery requirements.
3. Collect baseline metrics: Observe CPU, memory, storage, network, and application performance.
4. Forecast demand: Estimate growth, seasonality, peak demand, and exceptional events.
5. Model resource requirements: Translate forecast demand into instance, storage, and bandwidth needs.
6. Include safety margins: Account for forecast errors, failures, and deployment delays.
7. Validate through testing: Conduct load, stress, and endurance tests.
8. Monitor and revise: Compare forecasts with actual usage and continuously update the plan.

Let the average workload be requests per minute and the effective capacity of one instance be requests per minute.

The minimum number of instances is:

With a safety margin, the required workload capacity becomes:

Therefore:

Thus, the service needs a minimum of 5 instances for the average workload and should provision 6 instances when the safety margin is included. This assumes that requests are evenly distributed and instances have identical processing capacity.

Cloud bursting is a hybrid-cloud technique in which an application normally runs on private infrastructure but temporarily uses public-cloud resources when demand exceeds private capacity.

Its operation generally involves:

1. Monitoring private-cloud utilization or application queue length.
2. Detecting that a configured capacity threshold has been reached.
3. Provisioning additional resources in a public cloud.
4. Redirecting overflow workloads to those resources.
5. Releasing the public-cloud resources when demand falls.

Benefits:

• Handles temporary demand peaks without permanent overprovisioning.
• Preserves private infrastructure for normal operations.
• Provides elastic capacity on a pay-per-use basis.

Limitations:

• Data transfer latency and network bandwidth constraints.
• Security, privacy, and regulatory concerns.
• Application and platform compatibility issues.
• Data synchronization complexity.
• Public-cloud usage and data-egress costs.

Cloud bursting is best suited to workloads that can be partitioned and do not require frequent transfer of sensitive or tightly coupled data.

Permanent overprovisioning maintains enough owned or reserved capacity to handle the expected peak workload at all times. It offers predictable performance and avoids dependency on external resources, but much of the capacity may remain idle during normal demand.

Cloud bursting maintains private capacity for the normal workload and obtains public-cloud resources during peaks. It reduces idle capacity and converts some capital expense into operating expense, but introduces network, integration, security, and variable-cost concerns.

Key differences include:

• Cost: Overprovisioning has higher fixed cost; bursting has demand-dependent cost.
• Utilization: Bursting generally provides better average utilization.
• Complexity: Bursting requires hybrid deployment, monitoring, and workload movement.
• Performance: Overprovisioning can offer more predictable local performance.
• Risk: Bursting depends on public-cloud availability, quotas, and connectivity.

The preferred strategy depends on the frequency and duration of peaks. Frequent, sustained peaks may justify reserved capacity, while rare or unpredictable peaks are often better handled through cloud bursting.

Disk provisioning is the process of creating and assigning virtual storage capacity to virtual machines or cloud services.

Thin provisioning:

• Presents a logical disk of a specified size but allocates physical storage only as data is written.
• Improves storage utilization and allows flexible allocation.
• Can lead to overcommitment, where promised logical capacity exceeds available physical storage.
• Requires continuous capacity monitoring.

Thick provisioning:

• Reserves the complete physical storage capacity when the virtual disk is created.
• Provides predictable capacity and may offer more consistent performance.
• Can waste storage when large portions of the disk remain unused.

Some platforms further distinguish between lazy-zeroed thick disks, initialized when blocks are first written, and eager-zeroed thick disks, initialized completely at creation. The choice depends on utilization efficiency, performance requirements, and operational risk.

Thin provisioning improves storage efficiency, but it introduces several management risks:

• Storage exhaustion: Physical capacity may run out when multiple virtual disks grow simultaneously.
• Overcommitment: The total logical capacity may greatly exceed the available physical capacity.
• Performance variation: Disk growth, block allocation, or storage contention can increase latency.
• Snapshot growth: Uncontrolled snapshots may consume substantial storage.
• Failure propagation: Exhaustion of a shared storage pool can affect several virtual machines.

Administrators can control these risks by:

• Monitoring physical consumption and growth rates.
• Configuring warning and critical-capacity thresholds.
• Reserving emergency free space.
• Applying quotas and sensible overcommitment ratios.
• Automatically expanding storage pools where supported.
• Deleting obsolete snapshots and data.
• Forecasting storage demand and testing exhaustion procedures.

Thin provisioning is effective only when logical allocation is supported by disciplined monitoring and capacity management.

Service-Oriented Architecture (SOA) is an architectural approach in which application capabilities are organized as reusable, network-accessible services with well-defined contracts.

Fundamental SOA principles include:

• Loose coupling: Consumers depend on service contracts rather than internal implementations.
• Standardized contracts: Interfaces, operations, messages, and policies are explicitly defined.
• Service abstraction: Internal logic and implementation details are hidden.
• Reusability: Services are designed for use by multiple applications or business processes.
• Autonomy: A service controls its own logic and resources as far as practical.
• Discoverability: Service descriptions make capabilities easier to locate and understand.
• Interoperability: Standard communication formats and protocols support heterogeneous systems.
• Composability: Multiple services can be combined into larger workflows.

SOA improves integration and reuse, although governance, versioning, security, and distributed-system failures must be carefully managed.

SOA supports cloud computing by exposing business capabilities through standardized interfaces that can be remotely accessed, composed, scaled, and managed. Cloud platforms provide elastic infrastructure, service registries, identity management, messaging, monitoring, and deployment facilities that complement SOA.

SOA and microservices share loose coupling, explicit interfaces, independent service boundaries, and network-based communication.

Important differences are:

• Scope: SOA often integrates enterprise-wide systems, while microservices commonly decompose one application or product domain.
• Service size: SOA services may be broad business services; microservices are usually smaller and narrowly focused.
• Communication: Traditional SOA may rely on an enterprise service bus, whereas microservices commonly use lightweight APIs or event streams.
• Deployment: Microservices emphasize independent deployment and decentralized ownership.
• Governance: SOA frequently uses centralized governance; microservices often favor team-level autonomy with shared platform standards.

Microservices can be viewed as a specialized service-oriented style optimized for continuous delivery and cloud-native deployment.

A Service Level Agreement (SLA) is a formal agreement between a service provider and a customer that specifies measurable service commitments, responsibilities, and remedies.

Essential elements include:

• Service scope: The services, regions, features, and users covered by the agreement.
• Service-level indicators: Metrics such as availability, latency, throughput, durability, or support response time.
• Service-level objectives: Target values for the selected metrics.
• Measurement method: Monitoring source, sampling period, exclusions, and calculation formula.
• Responsibilities: Obligations of both provider and customer.
• Security and compliance: Data protection, audit, retention, and incident requirements.
• Support and escalation: Incident priorities, response times, and escalation paths.
• Remedies: Service credits, penalties, or termination rights after violations.
• Exclusions: Scheduled maintenance, customer errors, and specified force-majeure events.

An effective SLA uses precise, measurable terms and avoids ambiguous promises.

Availability is calculated as:

The recorded uptime is minutes out of minutes. Therefore:

The achieved availability is approximately .

The SLA target is , so the service does not satisfy the SLA.

The maximum downtime permitted by the SLA is:

Actual downtime was:

Thus, actual downtime exceeded the permitted downtime by minutes. Any remedy would depend on the SLA's measurement rules, exclusions, and service-credit terms.

The laws of cloudonomics describe economic principles that explain why cloud services can offer value compared with fixed, privately owned infrastructure. Major ideas include:

• Utility services cost less even when they cost more: A cloud resource may have a higher unit price, yet total cost can be lower because users avoid idle capacity and long-term commitments.
• On-demand resources reduce forecasting risk: Capacity can be obtained when needed, reducing the financial effect of inaccurate demand forecasts.
• The peak of the sum is less than the sum of the peaks: Aggregating workloads with peaks at different times reduces the total capacity required.
• Aggregate demand is smoother than individual demand: Providers can obtain high utilization by serving many diverse customers.
• Large providers benefit from economies of scale: Bulk purchasing, automation, specialization, and efficient facilities lower operating costs.
• Geographical distribution creates value: Distributed resources can reduce latency and improve resilience.
• Numerically equal SLAs do not necessarily provide equal value: Architecture, exclusions, support, and failure correlation affect actual business outcomes.

These laws encourage organizations to consider utilization, demand variability, risk transfer, scale, and business agility in addition to the listed price of cloud resources.

For workloads , the principle can be expressed as:

Suppose Application A peaks at virtual machines during business hours, while Application B peaks at virtual machines at night. If each application is provisioned independently for its peak, the organization needs:

If the workloads share a resource pool and their peaks do not occur simultaneously, their combined peak may be only virtual machines. Resource pooling therefore avoids maintaining additional machines.

This principle explains why cloud providers can achieve high utilization by aggregating customers with diverse demand patterns. It also shows why private clouds can gain efficiency by consolidating workloads. The saving is smaller when workloads are highly correlated and peak at the same time.

A comprehensive cloud TCO estimate should include all costs over a defined analysis period.

Direct cloud costs:

• Compute instances, serverless executions, and container services.
• Block, object, archive, snapshot, and backup storage.
• Database, messaging, monitoring, and security services.
• Data transfer, especially internet and cross-region egress.
• Support plans, licenses, and managed-service charges.

Operational and indirect costs:

• Migration, application redesign, testing, and training.
• Cloud administration, security, governance, and compliance work.
• Expected outage losses and business-continuity expenses.
• Contract management and potential exit or repatriation costs.

For a period of years, a discounted TCO model may be written as:

where is the initial migration cost, is the cost in year , and is the discount rate. Estimates should include baseline, expected-growth, and peak-demand scenarios and should be updated using actual billing data.

The monthly on-demand cost is:

The reserved-instance fixed charge is:

The reserved-instance usage charge is:

Therefore, the total reserved-instance cost is:

Monthly saving from the reserved option is:

The reserved option is therefore cheaper per month, assuming all ten instances are continuously required and there are no additional reservation fees or contractual risks. For intermittent or uncertain demand, on-demand pricing could still be preferable because it avoids a fixed commitment.

Capital expenditure (CapEx) involves purchasing long-term assets such as servers, storage devices, networking equipment, and data-center facilities.

• Requires substantial upfront investment.
• Assets are depreciated over time.
• Capacity must often be purchased before demand is known.
• The organization controls the equipment but carries maintenance and obsolescence risks.

Operating expenditure (OpEx) involves paying for services as they are consumed or subscribed to.

• Requires less upfront investment.
• Expenditure can track actual usage more closely.
• Supports faster scaling and experimentation.
• Costs may be variable and require strong financial governance.

Cloud computing commonly shifts spending from CapEx toward OpEx. However, the distinction is not absolute because long-term reservations, committed-use contracts, private clouds, and accounting policies may change the financial treatment. A sound decision should consider cash flow, utilization, flexibility, risk, and TCO rather than relying only on the CapEx-versus-OpEx label.

A suitable economic strategy begins by separating the workload into stable base demand and variable peak demand.

• Run stable, high-utilization workloads on owned private infrastructure or discounted committed cloud capacity when analysis shows a lower long-term unit cost.
• Handle unpredictable seasonal peaks with public-cloud on-demand resources or cloud bursting.
• Use auto-scaling and workload scheduling to prevent idle capacity.
• Purchase reserved or committed capacity only for the demand level that is sufficiently predictable.
• Include networking, data egress, migration, licensing, support, security, and staffing costs in the TCO comparison.
• Evaluate technical constraints such as latency, data gravity, compliance, portability, and workload partitioning.
• Define SLAs and resilience requirements before comparing prices because architectures with different risk levels are not economically equivalent.
• Track unit economics using measures such as cost per transaction, customer, or processed gigabyte.

The likely result is a hybrid strategy: economical fixed capacity serves the base load, while elastic public-cloud capacity absorbs temporary peaks. The organization should periodically recalculate the break-even point because prices, demand patterns, and operational costs change over time.