Chapter 5: Cloud-Based Software Study Guide
Architecture & Cloud Engineering
1 The Foundation: Virtual Servers and Dependencies
Before we discuss the mechanics, you must understand the problem we are solving. When
you write code—whether it is a [Link] backend or a complex C++ application—your soft-
ware relies on external dependencies like interpreters, compilers, and specific libraries. If you
deploy that code to a server missing those exact versions, your application breaks.
A virtual server solves this by acting as a stand-alone system with absolutely no exter-
nal dependencies. You bundle your software with all required libraries, bypassing the host
machine’s configuration entirely.
There are two primary ways to implement these virtual servers: Virtual Machines and
Containers.
1.1 Virtual Machines (The Heavyweight Approach)
Virtual Machines (VMs) provide a complete simulation of a physical computer.
• A software layer called a hypervisor emulates the underlying physical hardware.
• Multiple hardware emulators share the same physical server and run in parallel.
• You must install a complete, distinct operating system (the Guest OS) on top of each
emulator.
Figure 1: Implementinga virtual server as a virtual machine
1
VM Trade-offs
The Advantage: Because the hardware is emulated, you can run completely different
operating systems (like Windows and Linux Mint) concurrently on the same physical
machine.
The Drawback: Loading and booting a massive, complex operating system for every
virtual server takes gigabytes of space and several minutes to start. You cannot react
instantly to sudden spikes in user traffic.
1.2 Containers (The Lightweight Approach)
If your entire architecture runs on Linux, booting a separate OS for every single application
is a tremendous waste of resources. Containers are an operating system-level virtualization
technology that allows multiple isolated servers to share a single underlying host operating
system.
• Because containers do not boot an entire OS, they are remarkably efficient.
• They are megabytes in size rather than gigabytes.
• They start in mere seconds.
Figure 2: Using containers to provide isolated services over a shared Host OS.
2
1.3 Architectural Comparison: VMs vs. Containers
Feature Virtual Machines (VMs) Containers
Architecture Emulates physical hardware via a Shares the Host OS via a Con-
Hypervisor. tainer Manager.
Operating System Requires a full Guest OS for each All containers share the single
machine. Host OS.
Resource Footprint Massive (Gigabytes in size). Highly compact (Megabytes in
size).
Startup Speed Slow (2 to 5 minutes to boot the Near-instantaneous (A few sec-
OS). onds).
Best Use Case Large, continuous shared Stand-alone services, microser-
databases or varying OS needs. vices, and rapid scaling.
Table 1: Architectural differences between VMs and Containers
2 Docker: The Industry Standard for Containers
Docker revolutionized container management by standardizing how we define and run them.
You must be familiar with its core ecosystem:
Figure 3: The Docker Architecture: Client, Daemon, and Registries.
• Docker Daemon: The background process on the host server that builds, starts, stops,
and monitors your containers.
• Docker Client: The interface you use to issue commands to the daemon.
• Dockerfiles: Script files containing a series of setup commands that define precisely
what software goes into your container.
• Image: A compiled set of directories containing your runnable software and data, gen-
erated from the Dockerfile.
• Docker Hub: A centralized registry where built images are stored, shared, and pulled.
3
• Containers: The actual, executing instance of an image.
Crucial Concept: The Union Filesystem
Docker images are uniquely fast because they use a layered union filesystem. Instead
of duplicating entire filesystems, an image starts with a base layer and only saves the
specific files that have been changed or added on top of it.
When you update an application, you are only shipping the tiny fraction of altered files,
making deployment highly efficient. When a container runs, the image is locked as
read-only, and the daemon adds a temporary read-write layer on top for execution.
2.1 The Four Strategic Benefits of Containers
Deploying cloud software via containers gives an engineering team four distinct advantages:
1. Dependency Elimination: Your code ships perfectly packaged with its exact libraries,
completely neutralizing the “it works on my machine” problem.
2. Absolute Portability: A Docker container will execute identically on any cloud provider
or local machine running the Docker daemon.
3. SOA Facilitation: They are the perfect mechanism for breaking large systems down
into Service-Oriented Architectures (microservices).
4. DevOps Simplification: They bridge the gap between development and operations, as
the same container format is used in both environments.
3 The Three Main Tiers of Cloud Services
Figure 4: Everything as a Service (EaaS): The architectural stack.
3.1 1. Infrastructure as a Service (IaaS)
This is the foundational layer. The cloud vendor provides the raw, basic compute, network,
and storage services.
• The Engineering Reality: You are essentially renting empty virtual servers. You avoid
buying physical hardware, and you can rapidly scale out by adding more servers via a
control panel.
4
• The Burden: You are entirely responsible for installing the operating system, setting up
the databases, managing system security, and deploying the application.
3.2 2. Platform as a Service (PaaS)
This is the intermediate layer. Here, the cloud provider gives you the underlying infrastruc-
ture plus the libraries, frameworks, and database management systems (like SQL or NoSQL)
needed to build your application.
• The Engineering Reality: This level natively supports auto-scaling; you write the code,
and the platform automatically adds compute and storage resources as your user load
increases.
• The Burden: You devolve the heavy lifting of managing the database, system software,
and security infrastructure to the cloud provider. You only focus on writing and managing
the application code.
3.3 3. Software as a Service (SaaS)
This is the top layer, representing the finished product. The software runs entirely on the cloud
and the end-user accesses it via a web browser or a mobile app.
• The Engineering Reality: Familiar systems like Gmail, Twitter, and Office 365 operate
here.
• The Burden: The software vendor (you, the developer) manages the application logic,
while the cloud provider manages absolutely everything else underneath.
3.4 Architectural Comparison: The Delegation of Responsibility
Figure 5: Management responsibilities across SaaS, IaaS, and PaaS.
5
Component IaaS PaaS
Software Application (SaaS) Managed by Software Managed by Software
Provider. Provider.
Application Services (Databases) Managed by Software Managed by Cloud Ven-
Provider. dor.
Cloud Management Services Managed by Software Managed by Cloud Ven-
Provider. dor.
Basic Compute/Storage Managed by Cloud Ven- Managed by Cloud Ven-
dor. dor.
Table 2: Responsibility Delegation in Cloud Services
Note: In the modern era, the strict boundaries between IaaS and PaaS have blurred, with
almost all major IaaS providers now offering PaaS capabilities.
3.5 The Evolution: Function as a Service (FaaS)
A highly relevant architectural development is Function as a Service (FaaS), commonly
known as serverless computing (e.g., Amazon Lambda).
Instead of renting a server that sits idle waiting for traffic, you simply upload your code (the
function). The cloud provider automatically spins up a server to execute that specific function
the millisecond it is invoked, and shuts it down the moment it finishes.
The Strategic Advantages of FaaS
• Zero Server Management: The cloud provider assumes 100% responsibility for
the underlying server.
• Micro-Billing: You do not pay monthly rent for a server; you pay strictly for the
fractions of a second that your function is actively executing. This creates massive
cost savings for unpredictable or intermittent workloads.
4 The SaaS Model: Business and Architecture
Historically, software was a physical product installed locally on a customer’s machine. This
created an engineering nightmare: customers ran different versions on different OSs, forcing
software companies to maintain multiple legacy codebases simultaneously.
SaaS eliminates this. You run the software on your remote servers, and the customer
accesses it via a web browser or mobile app, paying a recurring subscription.
4.1 1. The Provider’s Perspective (Why We Build SaaS)
From the perspective of a software product company, SaaS is highly advantageous.
6
Benefit Engineering & Business Explanation
Steady Cash Flow Subscriptions provide predictable, year-round revenue, avoiding
the "feast or famine" cycle.
Unified Codebase You control the updates. Everyone gets the update simultane-
ously, eliminating support for legacy versions.
Continuous Deployment You can push bug fixes and new features daily without waiting for
user-initiated updates.
Data-Driven Iteration You can harvest usage telemetry to see exactly how users inter-
act with your product, driving better design.
Table 3: SaaS Benefits for the Software Provider
4.2 2. The Customer’s Perspective (The Double-Edged Sword)
SaaS offers immense benefits to customers but introduces severe enterprise-level risks.
Category The Advantages The Disadvantages & Risks
Financial & Setup • No Upfront Costs. • Perpetual Payment (never own
• Zero local IT management. it).
• Loss of internal self-host exper-
tise.
Access & Workflow • Ubiquity (access anywhere). • Forced updates can break work-
• Immediate updates. flows.
• Strict network dependency.
Data & Security None explicitly provided by the • Third-party security breaches.
SaaS model inherently. • Regulatory/Privacy law conflicts.
• Data Silos (hard to integrate).
Table 4: SaaS Trade-offs for the Customer
4.3 3. Core SaaS Design Issues
When architecting a SaaS application, you are building a system accessed by unknown de-
vices across unknown networks. You must resolve four critical design issues:
1. Local vs. Remote Processing: Pushing logic to the client’s browser makes the app
feel faster and saves bandwidth, but drains mobile battery life. Strike a balance.
2. Authentication Protocols: Individual users prefer OAuth (Google/Facebook), but cor-
porate users demand "federated authentication" for internal credentials.
3. Information Leakage: Your highest security risk. A single bug could expose Company
A’s data to Company B.
4. Database Architecture: Do you put everyone’s data in one massive shared database
(Multi-tenant), or an isolated database for every customer (Multi-instance)?
7
5 Multi-Tenant vs. Multi-Instance Database Architectures
5.1 1. Multi-Tenant Systems (The Shared Paradigm)
In a multi-tenant system, a single instance of the software and a single database schema are
shared by all customers (tenants). Logical isolation is achieved by tagging every database
row with a specific tenant identifier (e.g., Company ID).
The Engineering Challenge: Customization and Extensibility
Corporate clients demand custom data fields and rules. If everyone shares the exact
same database schema, how do you allow customization?
• Additional Columns (The Sparse Strategy): Add numerous generic columns
(e.g., Ext1, Ext2). Flaw: Wasted space and data-typing nightmares.
• Extension Tables (The Relational Strategy): Maintain separate tables defining
custom fields linked back via tenant ID. Flaw: Heavy JOIN operations add severe
complexity.
Security in Multi-Tenancy:
• Multilevel Access Control: Queries must filter first by tenant ID, and second by user
permissions.
• Encryption: Encrypt sensitive data to protect against leaks, despite the performance
hit.
5.2 2. Multi-Instance Systems (The Isolated Paradigm)
Each customer gets their own completely separate copy of the software and isolated database.
It bypasses cross-tenant data leakage entirely.
• VM-Based: Each customer system runs on a dedicated VM. Expensive but excellent
for heavy corporate use.
• Container-Based: Each user gets an isolated version via containers. Highly cost-
effective as they start instantly and don’t need to run 24/7.
8
5.3 The Master Comparison
Architectural Factor Multi-Tenant (Shared) Multi-Instance (Isolated)
Security & Privacy High theoretical risk of data leak- Maximum security; zero data
age. leakage.
Flexibility Highly inflexible; schema exten- Maximum flexibility; customized
sion is complex. schemas.
Update Management Highly efficient; patch one in- Complex; must push updates to
stance for all. many instances.
System Complexity High; code manages logical iso- Low; isolation handled by infras-
lation routing. tructure.
Cost & Scalability Cost-effective; maximizes re- Traditionally expensive, but con-
source utilization. tainers reduce this.
Table 5: Multi-Tenant vs. Multi-Instance Deployments
6 Cloud Software Architecture Decisions
When you choose the cloud as your delivery platform, you must answer four critical architec-
tural questions.
Figure 6: The core architectural decisions for cloud software engineering.
9
6.1 Pillar 1: Database Organization
Decision Factor Architectural Choice & Reasoning
Target Customers Small business/consumers → Multi-tenant. Large corporations → Multi-
instance.
Transaction Req. Strict ACID transactions → Multi-tenant or VM-based Multi-instance.
Database Size Massive relational/connected → Multi-tenant. Independent tables →
Container-based.
Interoperability Frequent import/export needs → Multi-instance for custom schemas.
Table 6: Choosing a Database Architecture
6.2 Pillar 2: Scalability and Resilience
• Scalability: Adapting to load changes (usually scaling out by adding parallel servers).
• Resilience: Maintaining services during failure. Achieved via an Active/Standby archi-
tecture in different physical locations.
– Hot Standby: Synced in real-time. Instant, transparent switch.
– Cool Standby: Restored from backup. System is down until catch-up completes.
6.3 Pillar 3: Software Structure
Structure Description Best Use Case
Monolithic All logic, UI, and data access bun- Prototypes or first releases for rapid
dled into a single system. development.
Microservices System broken into fine-grained, in- Modern cloud deployments using
dependent, stateless services. containers.
Table 7: Monolithic vs. Microservice Architectures
6.4 Pillar 4: Cloud Platform Choice
Choosing AWS, Google Cloud, Azure, etc. requires balancing:
• Technical Issues: Load spike handling, data center locations for compliance, available
PaaS tools.
• Business Issues: Developer experience, Service-Level Agreements (SLAs) for uptime.
The Danger of Vendor Lock-In
If you build your application using standard Docker containers, you can easily migrate
from AWS to Google Cloud. However, if you rely heavily on a provider’s proprietary
PaaS tools, your code is locked to their platform. Migrating later requires significant
rewrites.
10