Git, Linux & DevOps
Cloud Computing Fundamentals
Cloud computing means using computing resources - servers, storage, databases, networking - that live in a provider's data center and are rented over the internet, typically billed for what you actually use rather than bought outright. It's organized in layers: infrastructure (IaaS) gives you raw virtual machines and networking, platform (PaaS) gives you a managed place to run code without managing servers, and software (SaaS) gives you a finished application. The same underlying ideas - elasticity, regions, managed services - apply across every major provider, even though the product names differ.
Why it matters
- It changes fixed costs into variable ones
- Instead of buying servers sized for peak load that sit idle most of the time, cloud billing scales with actual usage, though that only saves money if usage is actually monitored and controlled.
- It provides elasticity that's hard to match with owned hardware
- Extra capacity for a launch or a traffic spike can be provisioned in minutes and released afterward, rather than requiring hardware bought and racked ahead of time.
- Geographic regions affect both latency and law
- Which region data and compute run in determines how far a request has to travel to reach a user, and which country's data protection rules apply to that data.
- Managed services remove entire categories of operational work
- A managed database or message queue handles patching, backups and failover that would otherwise be a team's own responsibility to build and maintain.
IaaS, PaaS and SaaS
These three layers describe how much of the stack you manage versus how much the provider does. With infrastructure as a service, you get virtual machines and networking, and you manage the operating system and everything above it yourself. With platform as a service, the provider also manages the operating system and runtime, and you deploy just your application code. With software as a service, you use a finished application and manage none of the underlying stack at all. Moving up the stack trades control for less operational work.
Regions and availability zones
A region is a distinct geographic area a provider operates in; an availability zone is typically an isolated facility within a region, with its own power and networking, so that a failure in one zone doesn't necessarily take down the others. Spreading resources across zones, or across regions, improves resilience against a localized failure, but it adds real complexity - data consistency between locations, and sometimes added latency or cost - so it's a deliberate trade-off rather than a default.
Describing infrastructure as code
Rather than clicking through a console to create each server or database, infrastructure can be described declaratively in version-controlled text: what should exist, not the steps to create it. A tool then reconciles the actual state with what's described, which makes environments reproducible and changes reviewable the same way application code changes are.
resource "compute_instance" "web" {
region = "eu-west"
instance_type = "small"
count = 3
}
resource "object_storage" "uploads" {
region = "eu-west"
}Mistakes people make here
- Assuming 'in the cloud' means security is someone else's problem
- the shared responsibility model means the provider secures the underlying infrastructure, but configuring access, encryption and network rules correctly is still the customer's job; a large share of cloud security incidents trace back to misconfiguration, not a provider failure.
- Leaving resources running after they're no longer needed
- pay-as-you-go billing means an idle test database or an oversized instance left running silently accrues cost with no one noticing until the bill arrives.
- Picking a region without thinking about where users actually are
- a region on the other side of the world from most users adds real, physical latency to every request that no amount of code optimization fixes.
- Treating autoscaling as a substitute for capacity planning
- autoscaling reacts to load that's already happening; it doesn't remove the need to think about what happens if a spike arrives faster than new capacity can start.
- Not planning for a single region or provider going down
- even large providers have outages; whether that risk is acceptable, or worth spreading across zones or regions, is a decision worth making deliberately rather than discovering during an outage.
Strengths and trade-offs
Where it is strong
- Removes the lead time and capital cost of buying physical hardware before you can run anything.
- Elastic capacity handles variable or unpredictable load far better than fixed, owned hardware.
- Managed services offload real operational work - patching, backups, failover - that a small team would otherwise have to build itself.
- Global regions make it practical to place compute physically close to users anywhere in the world.
The trade-offs
- Costs are easy to lose track of: usage-based billing across many services, without discipline, can end up more expensive than owned hardware would have been.
- Depending heavily on one provider's specific managed services makes it harder to move to another provider later, often called vendor lock-in.
- Not every workload benefits: steady, predictable, large-scale workloads sometimes cost less on owned or long-term-committed hardware than on-demand cloud pricing.
- Outages happen at the provider level too; moving to the cloud changes who is responsible for uptime, it doesn't guarantee it.
Who needs this
Anyone deploying an application beyond their own laptop encounters these concepts, whether or not 'cloud' is in their job title. How deep to go depends on the role: a backend developer needs to understand the service tiers they use, while a dedicated infrastructure or platform engineer needs the full picture.
Questions about cloud computing fundamentals
- What's the actual difference between IaaS, PaaS and SaaS?
- It's about how much you manage versus how much the provider manages. IaaS gives you virtual machines and networking - you install and manage the OS and everything above it. PaaS gives you a place to deploy your code and manages the OS and runtime for you. SaaS is a finished application you just use - you manage none of the underlying stack.
- What is a region, and why does it matter which one I pick?
- A region is a distinct geographic location a provider operates data centers in. It matters for latency (a region far from your users adds real delay to every request), for cost (prices can differ by region), and for legal compliance (some data protection laws require certain data to stay within a specific country or geography).
- Is the cloud always cheaper than owning hardware?
- No, and it's a genuine trade-off rather than a settled answer. Cloud pricing avoids upfront hardware cost and scales with usage, which is valuable for variable or unpredictable workloads. For a steady, well-understood, large workload running continuously for years, owned or long-term-committed hardware can end up cheaper, which is why some large companies run part of their infrastructure that way.
- What does 'multi-cloud' mean and is it necessary?
- It means using more than one cloud provider, either for different workloads or as redundancy against one provider's outage or pricing changes. It adds real operational complexity - different tools and APIs per provider - so most teams start with a single provider and only adopt multi-cloud deliberately, for a specific reason, rather than by default.