Deploying to the cloud
Concept · Chapter 13
Deploying to the cloud
Section titled “Deploying to the cloud”DevOps and the cloud are commonly aligned: core values like quick delivery and automation are enhanced by cloud deployment. Architects should understand both the cloud deployment types and the cloud service models.
Cloud types
Section titled “Cloud types”Public cloud
Section titled “Public cloud”- Resources owned/operated by a third-party provider, delivered over the Internet, shared across organizations (often multi-tenant).
- High reliability, near-unlimited scalability, pay-only-for-use, no maintenance burden, best economies of scale.
- Downsides: less control over data; regulatory/compliance concerns for sensitive data (e.g. HIPAA for patient information). Know the regulations affecting your software and ensure you or the provider can meet them.
Private cloud
Section titled “Private cloud”- Resources used exclusively by one organization (single-tenant); hosted in the org’s own data center or by a third party — all infrastructure dedicated to one org.
- Costlier, more modest economies of scale, but greater customization, control, and potential security.
- On-premises gives complete control over processes, data policies, and physical resources.
- Caveat: a private cloud is not automatically more secure — a poorly implemented one becomes a public vulnerability. Providers make security a core competency; SMBs often can’t match a major provider’s reliability/efficiency/scalability. The choice depends on org needs and long-term strategy.
Hybrid cloud
Section titled “Hybrid cloud”- Combination of public and private — “best of both worlds.”
- Host high-volume/low-security functionality in public cloud; mission-critical/sensitive workloads in private cloud.
- Enables gradual migration (legacy apps on-premises, others in public cloud).
- Supports cloud bursting (burst compute pattern): an app runs in the private cloud until a demand spike bursts it into the public cloud — cost-effective vs. keeping idle over-provisioned hardware; pay only for extra capacity when needed.
- Useful for predictable outages (maintenance, brown/blackouts, natural disasters) by shifting traffic to the public cloud.
Cloud models
Section titled “Cloud models”Ordered by increasing abstraction (and decreasing control/responsibility over infrastructure): IaaS → CaaS → PaaS → FaaS → SaaS. Higher abstraction frees the team to focus on application logic and business value.
Infrastructure as a Service (IaaS)
Section titled “Infrastructure as a Service (IaaS)”- Rent the hardware; provider maintains storage, network, cooling.
- You handle nearly everything else: OS, patches/security, anti-virus, middleware, server and logical network config.
- Uses: website/web-app hosting, test/dev environments, storage/backup/recovery, big data.
- Eliminates hardware capex and maintenance; increases agility. Common first step into the cloud (similar to how orgs already run IT).
Containers as a Service (CaaS)
Section titled “Containers as a Service (CaaS)”- Builds on IaaS by adding a container orchestration platform (Kubernetes, Docker Swarm, Apache Mesos) for cloud-native apps.
- Containerized, dynamically orchestrated apps → teams control packaging of app + dependencies + versions, giving portability, consistency, predictability, reusability; run anywhere (VM, laptop, private or public cloud) without reconfiguration.
- You still own OS, patches/security, logging/monitoring, capacity, and scaling.
- Containers vs. VMs: VMs virtualize hardware via a hypervisor, each carrying a full OS copy → heavier, slower start/stop. Containers use a container engine for OS-level virtualization, sharing one OS kernel → lightweight, fast startup, less disk/memory, higher density per server, and (with an orchestrator) dynamic placement and rapid failure recovery.
Platform as a Service (PaaS)
Section titled “Platform as a Service (PaaS)”- Complete platform to build and deploy apps; higher abstraction than IaaS/CaaS.
- Provider maintains hardware and the OS (including patches), plus supporting software, tools, DBMS, and middleware — team doesn’t manage the OS.
- Speeds development, lets teams focus on domain code, no extra staff/time.
- Downsides: loss of OS control and potential provider lock-in when relying on provider-specific tools. Language support, once limited, is now broad.
Serverless / Function as a Service (FaaS)
Section titled “Serverless / Function as a Service (FaaS)”- Similar to PaaS but not PaaS.
- PaaS still requires forecasting and paying for provisioned capacity; serverless charges per execution, not for hosting time.
- Serverless can bring an entire application up/down per request — no under- or over-provisioning, no idle-server charges at off-peak.
- See Serverless architecture.
Software as a Service (SaaS)
Section titled “Software as a Service (SaaS)”- Far-right, highest abstraction (“on-demand software”); everything including the software is provided — you only handle configuration.
- Typically a subscription by timeframe and user count (no license purchase).
- Examples: Salesforce (CRM), Gmail, Office 365, Dropbox. No local install → simpler maintenance/support, no technical staff to install or upgrade.
Related
Section titled “Related”Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.13 “Deploying to the cloud”, pp. 1020-1033.