ANSWERS

Note

This document provides the solutions and detailed explanations for the exercises and assessment questions in the TODO.rst file.

Solutions for Part 1: Foundational Exercises

Solution to Exercise 1: Cloud Service Model Recommendation

Company A (StartupFast):

  • Recommendation: Primarily PaaS and SaaS, with some Serverless (FaaS).

  • Justification: The small team needs to move fast and cannot afford to manage infrastructure.

    • PaaS (e.g., AWS Elastic Beanstalk, Azure App Service, or a CaaS like EKS/AKS): Allows developers to deploy code without managing the underlying OS or servers. Perfect for the core application.

    • Serverless/FaaS (e.g., AWS Lambda, Azure Functions): Ideal for event-driven tasks like processing user sign-ups or sending notifications. It scales automatically and has a pay-per-use model, which is great for a limited budget.

    • SaaS (e.g., GitHub, Stripe, Auth0): Offload critical but non-core functions like version control, payments, and user authentication to third-party experts.

  • Key Benefit: Maximum development velocity and minimal operational overhead.

Company B (MegaCorp):

  • Recommendation: A Hybrid Cloud model using IaaS and PaaS.

  • Justification: MegaCorp needs control, compliance, and a way to integrate with existing on-premises systems.

    • IaaS (e.g., AWS EC2, Azure VMs): Provides the control needed for legacy .NET applications that may have specific OS or configuration requirements. It allows the IT department to manage the environment in a way that mirrors their on-premises setup, easing the transition.

    • PaaS (e.g., Azure App Service, AKS): For new application development, PaaS offers a faster path to production while still allowing for significant configuration and security controls to meet compliance needs.

    • Hybrid Connection (e.g., AWS Direct Connect, Azure ExpressRoute): A dedicated network connection is crucial for securely linking their on-premises data centers with the cloud.

  • Key Benefit: Balances control and compliance with the ability to modernize and scale.

Company C (DataInsights LLC):

  • Recommendation: Heavily leverage PaaS and specialized “as a Service” offerings.

  • Justification: The team’s expertise is in data science, not infrastructure. The goal is to provide them with powerful tools, not servers to manage. - PaaS/CaaS (e.g., GCP’s GKE, AWS EKS): A managed Kubernetes service to run their containerized data processing jobs. - Specialized PaaS (e.g., AWS SageMaker, GCP Vertex AI, Azure Machine Learning): These platforms provide end-to-end MLOps capabilities, from data preparation to model training and deployment. This is far more efficient than building it themselves. - DBaaS (e.g., BigQuery, Redshift, Snowflake): A managed data warehouse is essential for handling terabytes of data without administrative overhead.

  • Key Benefit: Empowers data scientists to focus on their core competency by abstracting away complex infrastructure.

Solution to Exercise 2: Scaling Strategy Design

  1. Design Approaches: * Vertical Scaling (Scale-Up): This strategy involves increasing the resources (CPU, RAM) of the existing server. When a traffic spike is detected (e.g., CPU utilization > 80% for 5 minutes), the server instance would be replaced by a larger, more powerful one. When traffic subsides, it would be scaled back down. * Horizontal Scaling (Scale-Out): This strategy involves adding more servers (instances) to a pool behind a load balancer. An auto-scaling group would be configured to add new instances when a metric like average CPU utilization exceeds a threshold (e.g., > 60%) and remove instances when it falls below a threshold (e.g., < 30%).

  2. Comparison Matrix:

    Factor

    Vertical Scaling

    Horizontal Scaling

    Cost

    Can be expensive; you pay for a large instance even if not fully utilized.

    More cost-effective; pay only for what you use. Can use smaller, cheaper instances.

    Response to Spike

    Slower. Requires stopping the current instance and starting a new one, causing downtime.

    Faster. New instances can be spun up in minutes and added to the pool without downtime.

    Complexity

    Simpler to conceptualize, but hard to automate without downtime.

    More complex; requires a load balancer and stateless application design.

    Reliability

    Low. It’s a single point of failure. If the instance goes down, the site is down.

    High. If one instance fails, the load balancer redirects traffic to healthy ones.

  3. Recommendation: Horizontal scaling is the clear winner. For a news website with unpredictable traffic, the ability to scale out quickly without downtime is critical. It provides high availability and is far more cost-efficient than running a massive, underutilized server (vertical scaling) just in case a big story breaks.

Solution to Exercise 3: VM vs. Container Migration Plan

  1. VM-based (IaaS) Migration Plan: * Phase 1 (Lift and Shift): Provision three VMs in the cloud—one for the React frontend (running on a web server like Nginx), one for the Node.js backend, and one for the PostgreSQL database. This closely mimics the on-premises setup. * Phase 2 (Data Migration): Use a database migration service (e.g., AWS DMS) to replicate the on-premises database to the new cloud database VM with minimal downtime. * Phase 3 (Cutover): Update DNS to point to the new cloud-based frontend VM. * Architecture: 3 separate VMs, potentially in a private network, with security groups controlling traffic between them.

  2. Container-based (PaaS/CaaS) Migration Plan: * Phase 1 (Containerize): Create Dockerfile`s for the React frontend and the Node.js backend. * **Phase 2 (Orchestrate):** Write Kubernetes manifests (`Deployment, Service, Ingress) to define how the containers should run. Use a managed Kubernetes service (e.g., EKS, AKS, GKE). * Phase 3 (Database): Migrate the PostgreSQL database to a managed database service (e.g., AWS RDS, Azure Database for PostgreSQL). This is almost always preferable to running a database inside Kubernetes for production workloads. * Phase 4 (Deploy & Cutover): Deploy the applications to the Kubernetes cluster and update DNS to point to the Ingress controller’s load balancer. * Architecture: A Kubernetes cluster running the frontend and backend containers, communicating with a managed database service outside the cluster.

  3. Comparison: * Resource Efficiency: Containers are far more efficient. Multiple containers share a single OS kernel, leading to lower memory and CPU overhead compared to running a full OS for each VM. * Deployment Speed: Containers win. Deploying a new container image is much faster (seconds to minutes) than provisioning and configuring a new VM (minutes to hours). This enables faster CI/CD cycles. * Operational Complexity: The VM approach is initially simpler as it mirrors the old setup. Kubernetes has a steeper learning curve but provides powerful automation (self-healing, auto-scaling) that reduces long-term operational burden. * Cost: The container approach is generally more cost-effective due to better resource density (packing more applications onto a single node) and more granular scaling.

Answers for Part 3: Assessment Questions

Multiple Choice Answers

  1. c) Operating System. In the IaaS model, the cloud provider manages the physical hardware and the virtualization layer. The customer is responsible for everything above that, including the OS, middleware, and application.

  2. b) Cloud Native. This strategy focuses on using managed services to build and iterate quickly, which is ideal for a startup that wants to prioritize feature development over infrastructure management.

  3. c) It increases availability and fault tolerance. By distributing the load across multiple instances, horizontal scaling ensures that the failure of a single instance does not bring down the entire application.

  4. c) Terraform. Terraform is a cloud-agnostic tool designed to work with multiple cloud providers through its provider plugin architecture. The other tools are specific to a single cloud.

  5. b) To provide a single entry point for clients and handle cross-cutting concerns. An API Gateway acts as a reverse proxy, centralizing tasks like authentication, rate limiting, and logging, so that individual microservices don’t have to implement them.

Short Answer Answers

  1. “Cattle vs. Pets”:

  • Pets are servers that are unique, manually managed, and lovingly cared for. If a “pet” server gets sick, you nurse it back to health. This is the traditional IT model.

  • Cattle are servers that are identical and managed as a group. If a “cattle” server gets sick, you terminate it and replace it with a new, healthy one automatically.

  • Relation to Cloud Native: The Cloud Native approach treats all infrastructure as “cattle.” Using containers and orchestrators like Kubernetes, we design systems where individual components are disposable and can be automatically replaced without causing system failure. This leads to resilient, self-healing applications.

  1. Managed DB (RDS) vs. Self-Hosted DB (PostgreSQL on EC2):

  • Managed DB (RDS):

    • Pros: Easy setup, automated backups, automated patching, high availability (Multi-AZ), and scalability with a few clicks. Reduces operational overhead significantly.

    • Cons: Less control over specific configurations, can be more expensive at scale, and potential for vendor lock-in.

  • Self-Hosted DB (on EC2):

    • Pros: Full control over the database configuration and underlying OS, can be cheaper if you manage it efficiently, no vendor lock-in.

    • Cons: You are responsible for everything: installation, patching, backups, replication, scaling, and security. This requires significant expertise and time.

  • Trade-off: You are trading convenience and reliability (managed) for control and potential cost savings (self-hosted). For most teams, the operational safety of a managed service is worth the extra cost.

  1. The “6 Rs” of Cloud Migration:

  • Rehost (Lift and Shift): Moving an application to the cloud with minimal or no changes. Quick but doesn’t take advantage of cloud-native features.

  • Replatform (Lift and Reshape): Making a few cloud-specific optimizations during the migration, such as moving from a self-hosted database to a managed database service (RDS).

  • Repurchase (Drop and Shop): Moving to a different product, typically a SaaS solution (e.g., moving from a self-hosted CRM to Salesforce).

  • Refactor/Rearchitect: Reimagining the application to be fully cloud-native, often by breaking a monolith into microservices. This requires the most effort but yields the greatest benefits.

  • Retire: Decommissioning applications that are no longer needed.

  • Retain: Keeping applications on-premises that are not ready or suitable for migration.