Anna: This section sets up Cloud vs On-Premise Decisions. Treat it as the frame for the decisions, handoffs, and evidence that appear in the next slides.
Greg: The practical question is simple: by the end, what should a junior IT professional be able to explain, check, or document in a real workplace?
Anna: When founders say "we need to pick cloud or on-prem," they're really deciding where compute, storage, networking and identity will live.
Greg: Exactly—and the answer can differ per layer. SaaS keeps you hands-off, PaaS gives you guardrails, and IaaS is the build-it-yourself toolbox.
Anna: Add in acronyms like SRE and questions about colocation versus true on-prem, and it's easy to lose clarity. Start by mapping what customers expect, what regulators demand and what your team can realistically operate.
Anna: Glossary: terms you'll hear focuses attention on a concrete part of the work. SaaS / PaaS / IaaS: Software, Platform and Infrastructure as a Service—progressively more control, but also more responsibility, SRE (Site Reliability Engineering): The discipline focused on keeping services available and reliable through automation and operations rigor, and Colocation vs on-premise: Colocation rents space and power in a professional data centre; on-premise means hardware lives in your own facility.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: SRE (Site Reliability Engineering): The discipline focused on keeping services available and reliable through automation and operations rigor; Colocation vs on-premise: Colocation rents space and power in a professional data centre; on-premise means hardware lives in your own facility; Reserved instances vs pay-as-you-go: Commit to long-term usage for discounts, or pay on-demand for flexibility.
Anna: Startup runway vs operational overhead focuses attention on a concrete part of the work. Months 0–12: Prioritise velocity, keep the team shipping features and leverage managed services with generous free tiers, Year 2: As usage grows, weigh predictable reserved cloud spend against the fixed costs of leased hardware and support staff, and Year 3+: Hybrid patterns emerge—latency-sensitive workloads or data residency demands may justify colocated gear, while the rest stays cloud-native.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Year 2: As usage grows, weigh predictable reserved cloud spend against the fixed costs of leased hardware and support staff; Year 3+: Hybrid patterns emerge—latency-sensitive workloads or data residency demands may justify colocated gear, while the rest stays cloud-native.
Anna: Serverless first: when it shines focuses attention on a concrete part of the work. No infrastructure patching, and scaling is automatic—perfect for small teams without SRE coverage, Pay-per-use keeps experimentation cheap while you iterate on product-market fit; a food delivery beta with ~100 users might run $50/month, and Lock-in risk is mitigated by designing around open APIs, exporting data regularly and scripting data replays into alternative services.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Pay-per-use keeps experimentation cheap while you iterate on product-market fit; a food delivery beta with ~100 users might run $50/month; Lock-in risk is mitigated by designing around open APIs, exporting data regularly and scripting data replays into alternative services.
Anna: In the first twelve months, speed beats everything—use the managed services that let you ship without hiring SREs.
Greg: Right, because you literally can't afford to hire SREs yet. A senior SRE costs $180k+ in salary alone, before tooling or on-call bonuses.
Anna: By year two, finance wants predictability. That's when you compare reserved cloud instances to colocated gear and understand your utilisation curves.
Greg: And as you approach Series B, you revisit the architecture—maybe customer data has to stay in-region, or latency targets push you toward an edge footprint.
Anna: Decision helper focuses attention on a concrete part of the work. Start here → Need usable prototype in <5 minutes?, │ ├─ Yes → Stay serverless / SaaS, and │ └─ No.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: │ ├─ Yes → Stay serverless / SaaS; │ └─ No; ↓.
Anna: Containers: deceptively complex focuses attention on a concrete part of the work. Containers demand observability, image pipelines, security scanning and registry hygiene—skills many pre-Series A teams lack, Treat the platform as a product: budget time for cluster upgrades, policy automation and chaos testing, and It's like deciding to brew your own coffee when you haven't figured out how to work the office coffee machine yet.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Treat the platform as a product: budget time for cluster upgrades, policy automation and chaos testing; It's like deciding to brew your own coffee when you haven't figured out how to work the office coffee machine yet.
Anna: Self-managed infrastructure: read the fine print focuses attention on a concrete part of the work. Self-hosting can cut per-unit costs once workloads stabilise, but only if utilisation stays high and change frequency slows, Budget for redundant hardware, spares, remote hands at the data centre and compliance audits before declaring savings, and Document shared responsibility: your team now owns patching, access reviews, backups and capacity upgrades end-to-end.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Budget for redundant hardware, spares, remote hands at the data centre and compliance audits before declaring savings; Document shared responsibility: your team now owns patching, access reviews, backups and capacity upgrades end-to-end.
Anna: Free tiers and startup credits focuses attention on a concrete part of the work. AWS Activate, Azure for Startups and Google Cloud credits can cover six figures of spend—plan workloads to maximise the runway, Track expiry dates and graduation thresholds; AWS Activate credits, for example, expire after two years or when you raise a Series A—whichever comes first, and Mix in SaaS with generous free tiers (Cloudflare's free CDN, Auth0's 7,000-user tier, Notion's unlimited personal plan) to avoid burning credits on commodity services.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Track expiry dates and graduation thresholds; AWS Activate credits, for example, expire after two years or when you raise a Series A—whichever comes first; Mix in SaaS with generous free tiers (Cloudflare's free CDN, Auth0's 7,000-user tier, Notion's unlimited personal plan) to avoid burning credits on commodity services; Sudden bills post-credit are a common failure mode—also known as the "Oh no, we forgot we're not still in free tier" moment that ruins a founder's Tuesday.
Anna: Questions before jumping to containers focuses attention on a concrete part of the work. Do we have repeatable CI/CD with automated tests and security scanning in place?, Can we monitor, patch and respond to incidents 24/7 without burning out a three-person engineering team?, and Are there regulatory or customer requirements that truly block managed services?.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Can we monitor, patch and respond to incidents 24/7 without burning out a three-person engineering team?; Are there regulatory or customer requirements that truly block managed services?; Spoiler alert: if your "on-call rotation" is just Sarah checking her phone during dinner, the answer is no.
Anna: Serverless is a gift when you're still searching for product-market fit. No patching, no capacity planning—just deploy functions.
Greg: And the bill stays tiny while usage is modest. That food delivery beta with a hundred testers might cost $50 a month instead of thousands in idle servers.
Anna: The trade-off is vendor coupling, so script periodic API reviews, export datasets and rehearse migrations so an exit option stays alive.
Anna: Decision checkpoints focuses attention on a concrete part of the work. Reassess architecture at each funding milestone—seed, Series A, Series B—to confirm the stack matches burn rate and talent, Run total cost of ownership models that include people, tooling, vendor support and opportunity cost of slower delivery, and Prototype exit ramps: document how to move a workload between serverless, managed and self-hosted so switching is a deliberate move, not a panic.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Run total cost of ownership models that include people, tooling, vendor support and opportunity cost of slower delivery; Prototype exit ramps: document how to move a workload between serverless, managed and self-hosted so switching is a deliberate move, not a panic.
Anna: Common mistakes to avoid focuses attention on a concrete part of the work. Over-engineering early architecture with bespoke Kubernetes before validating demand, Ignoring data transfer and egress costs between regions or providers when forecasting spend, and Assuming "cloud = infinite scale" without designing guardrails, budgets and auto-scaling limits.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Ignoring data transfer and egress costs between regions or providers when forecasting spend; Assuming "cloud = infinite scale" without designing guardrails, budgets and auto-scaling limits.
Anna: Managed services sit in the middle—they remove toil but still let you shape the environment.
Greg: That serverless approach we just mentioned? Managed platforms are the next step when you need more knobs without rebuilding plumbing.
Anna: Think managed Kubernetes, relational databases or desktop-as-a-service, all defined through infrastructure as code so the setup is reproducible.
Greg: Just remember: even if the provider handles hardware, your team still carries the pager for misconfigurations and app bugs.
Anna: Containers promise cost control, but they demand engineering maturity.
Greg: Without observability, vulnerability scanning, hardened base images and a registry strategy, you're just moving risk from AWS into your unfinished build pipeline.
Anna: Treat the platform like a product—budget time for upgrades, policy automation and yes, the coffee-machine moment when you realise you built something no one can maintain.