Question 1: Cloud Service and Deployment Models for a
Startup with Unpredictable Traffic
Available Cloud Service Models:
1.
Infrastructure as a Service (IaaS): Provides raw computing resources (VMs, storage, network).
The startup manages OS, apps, and scaling.
Pros: Full control, flexible.
Cons: Requires more operational effort, scaling manually can be complex.
2.
Platform as a Service (PaaS): Provides runtime environment and managed services
(databases, application servers).
Pros: Developers focus on code; scaling is often built-in.
Cons: Less control over underlying infrastructure; may face vendor lock-in.
3.
Software as a Service (SaaS): Fully managed applications (email, CRM).
Pros: Minimal operational responsibility.
Cons: Not suitable for custom application hosting.
Cloud Deployment Models:
1.
Public Cloud: Resources shared among multiple tenants. Highly scalable, cost-efficient, pay-
as-you-go.
2.
Private Cloud: Dedicated resources. High control and security, but expensive.
3.
Hybrid Cloud: Combination of public and private clouds. Flexible but complex.
Recommended Choice:
PaaS on a Public Cloud (e.g., AWS Elastic Beanstalk, Google App Engine, Azure App Services)
Scalability: Automatic scaling handles unpredictable traffic spikes.
Cost Efficiency: Pay only for resources consumed during peak traffic.
Operational Responsibility: Startup focuses on application code; infrastructure and patching
are managed.
Justification: PaaS provides elastic compute, reduces operational overhead, and is cost-effective
for startups with traffic spikes.
Question 2: Horizontal Scaling & Load Balancing vs
Vertical Scaling
Vertical Scaling (Scale-Up):
Add more CPU, RAM, or storage to a single machine.
Behavior during peak load:
Limited by hardware constraints.
High cost per upgrade.
Single point of failure (downtime if machine fails).
Horizontal Scaling (Scale-Out) with Load Balancing:
Add multiple smaller instances behind a load balancer.
Behavior during peak load:
Traffic distributed evenly across multiple nodes.
High availability: failure of one node does not affect system.
Easier to scale dynamically as demand changes.
Comparison:
Feature Vertical Scaling Horizontal Scaling + Load Balancer
Scalability Limited to single machine Almost unlimited (add more nodes)
Cost Efficiency High hardware cost Incremental cost per node
Fault Tolerance Single point of failure High (distributed nodes)
Peak Workload Handling May bottleneck Handles spikes efficiently
Conclusion: Horizontal scaling with load balancing improves performance, fault tolerance, and
elasticity during unpredictable workloads.
Question 3: Cloud Deployment Models for Healthcare
with Data Residency Requirements
Requirements:
Sensitive health data.
Regulatory compliance (e.g., HIPAA, GDPR).
Elastic compute for variable workloads.
Deployment Models Analysis:
1.
Public Cloud:
Pros: Scalable, cost-efficient.
Cons: Data may be stored in multiple regions; harder to control residency.
2.
Private Cloud:
Pros: Full control, can ensure data stays within legal boundaries.
Cons: Expensive, limited scalability.
3.
Hybrid Cloud:
Pros: Sensitive data on private cloud; non-sensitive workloads on public cloud.
Cons: More complex management.
Recommended Choice: Hybrid Cloud
Sensitive patient records remain in a private cloud within legal jurisdiction.
Compute-intensive analytics or application hosting uses public cloud.
Balances regulatory compliance with elastic compute needs.
Justification: Healthcare organizations need security and compliance without sacrificing
scalability.
Question 4: Limitations of Single Round-Robin Load
Balancer & Cloud-Native Scalability
Limitations of Single Round-Robin Load Balancer:
1.
No awareness of server load or response time; may overload some servers.
2.
Single point of failure; if LB fails, the application becomes inaccessible.
3.
Cannot optimize for geo-distributed users, causing latency for distant regions.
Cloud-Native Scalability Principles to Mitigate Issues:
1.
Multiple Load Balancers across regions (Global Load Balancing).
2.
Auto-scaling groups to dynamically add/remove instances based on demand.
3.
Health checks to avoid routing traffic to failed servers.
4.
CDN (Content Delivery Network) to serve static content closer to users.
Outcome: Latency is reduced, availability improves, and the system can handle regional failures
without downtime.
Question 5: Hypervisors and Containers for OS-
Dependent Legacy Applications
1. Type-1 Hypervisors (Bare Metal)
Description: Runs directly on hardware (e.g., VMware ESXi, Microsoft Hyper-V).
Pros: High performance, strong isolation.
Cons: More setup complexity; migrating legacy apps may require OS compatibility.
2. Type-2 Hypervisors (Hosted)
Description: Runs on top of a host OS (e.g., VirtualBox, VMware Workstation).
Pros: Easy setup, suitable for testing and small-scale deployments.
Cons: Slower performance; OS-dependent apps may experience overhead.
3. Containers
Description: Lightweight virtualization sharing the host OS kernel (e.g., Docker).
Pros: Fast, portable, efficient resource usage.
Cons: Not ideal for apps requiring full OS features; OS-dependent legacy apps may break due
to kernel differences.
Risk Assessment:
Legacy applications that rely on specific OS features or drivers are high risk on containers.
Type-1 hypervisors offer best isolation and compatibility, but cost and complexity are higher.
Type-2 hypervisors are medium risk, suitable for smaller deployments.
Recommendation:
Use Type-1 hypervisors for critical legacy OS-dependent apps to reduce risk.
Containers can be used for modernized or refactored parts of the application.