Wednesday, October 7, 2026

STOP MANAGING EVERYTHING YOURSELF IN THE CLOUD | How IaaS, PaaS, Managed Services, Serverless, and Shared Responsibility Change What You Actually Operate



Imagine you want to put an application on the Internet.

In the traditional approach, you might think about buying or renting a server, installing an operating system, configuring storage, setting up networking, applying updates, installing a database, configuring security, monitoring the machine, and keeping everything running.

Then someone tells you:

"Put it in the cloud."

That sounds like the cloud removes all of those problems.

It doesn't.

It changes which problems you have to solve yourself.

That distinction is the foundation of cloud computing.

Cloud computing is not simply "someone else's computer." It is a model for obtaining computing resources and capabilities as services, typically through a network, with resources that can be provisioned and released on demand. NIST's widely used definition identifies characteristics including on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service.

The important question is therefore not:

"Is this in the cloud?"

The better question is:

"Which layer of the computing system am I asking someone else to operate for me?"

That question explains the difference between infrastructure, platforms, managed services, serverless systems and software-as-a-service.

1. Start With a Computer You Control

Forget the word cloud for a moment.

Imagine you own a physical server.

You are responsible for the whole stack:

APPLICATION
      ↓
RUNTIME / LIBRARIES
      ↓
OPERATING SYSTEM
      ↓
DRIVERS
      ↓
SERVER HARDWARE
      ↓
STORAGE
      ↓
NETWORK
      ↓
DATACENTER
      ↓
POWER / COOLING / PHYSICAL SECURITY

If the server fails, you deal with it.

If a disk fails, you deal with it.

If the operating system needs patching, you deal with it.

If the application crashes, you deal with it.

If the network configuration is wrong, you deal with it.

This is the extreme case of maximum control and maximum responsibility.

Cloud computing begins by moving some of these responsibilities to a provider.

2. The First Great Cloud Idea: Separate the Layers

Suppose a cloud provider operates the physical datacenter.

You no longer need to personally maintain:

Physical building
Power
Cooling
Physical servers
Physical networking

But perhaps you still want control over:

Operating system
Storage
Network configuration
Application

The provider can give you a virtual machine.

Now the relationship looks like:

YOU
 ├── Application
 ├── Runtime
 ├── Operating system
 ├── Configuration
 └── Data

CLOUD PROVIDER
 ├── Physical server
 ├── Datacenter
 ├── Physical network
 └── Underlying infrastructure

This is the basic idea behind Infrastructure as a Service, or IaaS.

NIST defines IaaS as a model in which the consumer provisions fundamental computing resources such as processing, storage and networking and can deploy operating systems and applications on them.

You have moved the physical infrastructure burden to someone else.

You have not eliminated infrastructure management.

You have moved it upward.

3. A Virtual Machine Is Still a Computer

This is an important mental correction.

When you create a cloud virtual machine, it can feel as though you have created "a server in the cloud."

Conceptually, that is reasonable.

But physically, your virtual machine is implemented using real infrastructure.

Think:

PHYSICAL SERVER
└── Virtualization layer
    ├── Virtual Machine A
    ├── Virtual Machine B
    └── Virtual Machine C

Each virtual machine can behave like an independent computer.

It can have:

  • virtual CPU resources;
  • virtual memory;
  • virtual storage;
  • virtual network interfaces;
  • an operating system;
  • applications.

This abstraction allows cloud providers to divide physical infrastructure among many customers while maintaining logical isolation.

The result is powerful:

You can obtain a computer-like environment without buying the physical computer.

4. But IaaS Still Makes You an Administrator

Suppose you create a Linux virtual machine.

You may still need to:

  • update the operating system;
  • configure users;
  • configure SSH access;
  • manage firewall rules;
  • install application software;
  • configure databases;
  • manage logs;
  • monitor CPU and memory;
  • secure credentials;
  • apply security patches;
  • back up important data;
  • troubleshoot failures.

The provider may keep the physical server operational.

But your virtual machine is still your responsibility.

This is why moving to IaaS does not mean:

"I don't need to know anything about servers."

It means:

"I no longer need to personally operate the physical server."

That is a very different statement.

5. Now Move One Layer Higher

Suppose your real goal is not to manage an operating system.

Your goal is to run an application.

Why should you spend your time maintaining:

  • operating-system packages;
  • virtual machines;
  • patching;
  • machine images;
  • server configuration?

A cloud provider can offer a higher-level environment.

You provide your application.

The provider manages more of the underlying stack.

This is the basic idea behind Platform as a Service, or PaaS.

NIST describes PaaS as a model in which the consumer deploys applications using supported programming languages, libraries, services and tools while the provider manages the underlying infrastructure, including servers, operating systems and storage.

The relationship becomes:

YOU
 ├── Application
 ├── Application configuration
 └── Data

CLOUD PROVIDER
 ├── Runtime/platform
 ├── Operating system
 ├── Virtual infrastructure
 ├── Physical infrastructure
 └── Datacenter

You have surrendered more control.

But you have also surrendered more maintenance work.

6. This Is the Cloud Tradeoff

The cloud is easier to understand when you stop treating service models as competing technologies.

Think of them as different positions on a control-responsibility spectrum.

MORE CONTROL
     ↑
     │
    IaaS
     │
    PaaS
     │
 Managed Services
     │
 Serverless
     │
    SaaS
     │
     ↓
LESS INFRASTRUCTURE TO MANAGE

This is simplified because real services overlap.

But the mental model is powerful.

As you move upward:

Provider manages more
        ↓
You configure less infrastructure
        ↓
You usually gain convenience
        ↓
You usually surrender some control

There is no universal "best" level.

The right level depends on what you are trying to accomplish.

7. Consider a Database

Suppose your application needs PostgreSQL.

With IaaS, you might create a virtual machine and install PostgreSQL yourself.

Then you become responsible for much of its operation.

You may need to think about:

  • installation;
  • updates;
  • storage;
  • backups;
  • replication;
  • monitoring;
  • failover;
  • security;
  • capacity.

But a cloud provider may offer a managed database service.

Now you can request:

"Give my application a PostgreSQL database."

The provider manages much more of the database infrastructure.

You still have responsibilities.

You still need to understand:

  • schemas;
  • queries;
  • users;
  • permissions;
  • data;
  • application connections;
  • backups and recovery requirements;
  • performance;
  • cost.

But you no longer have to operate the database server in exactly the same way as if you installed PostgreSQL yourself.

This is the essence of a managed service.

8. Managed Does Not Mean Responsibility-Free

This is one of the most dangerous misunderstandings in cloud computing.

People hear:

"Managed database."

and think:

"The provider takes care of the database."

That is too broad.

Managed means the provider operates certain parts of the service for you.

It does not mean the provider automatically understands your application or protects you from every mistake.

For example, the provider may operate:

Database infrastructure
Hardware
Underlying operating system
Service availability mechanisms

while you remain responsible for:

Your data
Database schema
Queries
Credentials
Permissions
Application configuration
Data governance

The exact division depends on the service.

The important principle is:

Managed infrastructure does not eliminate application responsibility.

9. The Shared Responsibility Model

Cloud security becomes much clearer once you understand this.

Security responsibility is divided between provider and customer.

Microsoft's current Azure guidance, for example, explicitly shows that the division changes between IaaS, PaaS and SaaS. In IaaS, customers manage virtual machines, operating systems and applications; in PaaS, they deploy applications without managing VMs or operating systems; in SaaS, they use provider-managed applications.

A simplified model looks like this:

                    YOU          PROVIDER
                    ───          ────────
Application          ✓
Data                 ✓
Identity             ✓
Configuration        ✓
Operating system     depends
Runtime              depends
Virtual machines     depends
Physical servers                  ✓
Datacenter                       ✓
Physical network                 ✓

The exact boundary changes with the service.

This is why cloud security cannot be reduced to:

"The provider secures the cloud."

You must also understand:

What part of the cloud are you actually controlling?

10. SaaS Moves Even Further Up

Now imagine you use an online email service.

You do not:

  • install its operating system;
  • maintain its servers;
  • patch its database;
  • configure its physical network;
  • deploy its application code.

You simply use the application.

This is Software as a Service, or SaaS.

NIST describes SaaS as using a provider's applications running on cloud infrastructure, commonly accessed through a browser or program interface, while the consumer does not manage the underlying infrastructure.

The conceptual stack becomes:

YOU
 └── Use application

PROVIDER
 ├── Application
 ├── Runtime
 ├── Operating system
 ├── Infrastructure
 └── Datacenter

This is why using a cloud email service and renting a virtual machine are both "cloud computing" but feel completely different.

You are consuming different layers.

11. What About Serverless?

Now we can approach one of the most misunderstood terms in modern cloud computing.

Serverless does not mean there are no servers.

There are servers.

They are simply not your servers to manage in the traditional sense.

Suppose you have a function that needs to run when someone uploads an image.

Instead of maintaining a server continuously, you can deploy a function and configure an event that triggers it.

Conceptually:

IMAGE UPLOAD
     ↓
EVENT
     ↓
FUNCTION
     ↓
PROCESS IMAGE
     ↓
STORE RESULT

The cloud platform handles much of the infrastructure required to execute the function.

You concentrate on the code and configuration.

This can be extremely useful for event-driven workloads.

12. Serverless Changes the Question

With a traditional server, you might ask:

"How many servers do I need?"

With a serverless function, you may ask:

"What should happen when this event occurs?"

That is a profound shift.

Traditional model:

SERVER
 ↓
APPLICATION
 ↓
WAIT FOR REQUEST

Event-driven serverless model:

EVENT
 ↓
FUNCTION EXECUTION
 ↓
RESULT

The infrastructure is still there.

But the abstraction hides much of it.

13. Serverless Is Not Automatically Better

Serverless introduces tradeoffs.

You may gain:

  • less infrastructure administration;
  • automatic scaling characteristics;
  • event-driven execution;
  • easier deployment for certain workloads.

But you may also encounter:

  • execution limits;
  • startup latency in some situations;
  • platform-specific constraints;
  • more complex distributed architectures;
  • monitoring challenges;
  • provider-specific APIs;
  • cost behavior that differs from always-on servers.

So the correct question is not:

"Should everything be serverless?"

It is:

"Does this workload benefit from the abstraction?"

14. Think in Terms of the Job

Suppose you are building a simple application.

You need:

Web interface
API
Database
File storage
Authentication

You could build it using virtual machines.

Or:

Managed web platform
Managed database
Object storage
Managed authentication
Serverless functions

The second architecture might allow you to spend more time on the application itself.

But you have also created dependencies on several cloud services.

Now your architecture looks like:

USER
 ↓
WEB APP
 ↓
API / FUNCTIONS
 ↓
MANAGED DATABASE
 ↓
OBJECT STORAGE
 ↓
AUTHENTICATION SERVICE

The application may be easier to operate.

But the architecture itself becomes a system that you must understand.

Cloud does not remove complexity.

It changes where the complexity lives.

15. The Cloud Is a Collection of Abstractions

This is perhaps the most useful way to think about cloud computing.

At the physical level:

Servers
Storage
Networks
Datacenters

The cloud provider abstracts them into:

Virtual machines
Storage services
Virtual networks
Managed databases

Then higher-level services abstract those further:

Application platforms
Serverless functions
Managed APIs
Managed authentication
Managed analytics
AI services

At the highest level:

Ready-to-use software

So:

PHYSICAL RESOURCES
       ↓
INFRASTRUCTURE
       ↓
PLATFORM
       ↓
MANAGED SERVICES
       ↓
APPLICATION SERVICES
       ↓
SOFTWARE

Every step upward hides more implementation detail.

16. Abstraction Is Powerful Because It Changes Your Work

Imagine you want to build a website that processes uploaded documents.

At the infrastructure level, you might need to think about:

Servers
Operating systems
Storage
Networking
Scaling
Processes

At a higher level, your problem becomes:

Upload document
       ↓
Trigger processing
       ↓
Extract information
       ↓
Store result
       ↓
Return result

That is closer to the actual business problem.

This is one reason cloud platforms became so important.

They allow developers to work at higher levels of abstraction.

Instead of managing every machine, you can increasingly describe what capability you need.

17. But Higher Abstraction Requires Better Understanding

There is a paradox here.

The more infrastructure you outsource, the easier it can be to deploy something.

But when something goes wrong, understanding the underlying layers becomes even more valuable.

Suppose your serverless function is slow.

You may need to investigate:

Function code
 ↓
Dependencies
 ↓
Runtime
 ↓
Network
 ↓
Database
 ↓
Storage
 ↓
External API

Suppose your managed database is slow.

You may need to investigate:

Queries
 ↓
Indexes
 ↓
Connections
 ↓
Database configuration
 ↓
Network latency
 ↓
Application behavior

The cloud hides infrastructure.

It does not hide the need for systems thinking.

18. Elasticity Is One of Cloud's Important Ideas

Imagine your application normally has:

100 users

but suddenly receives:

100,000 users

A fixed server may struggle.

Cloud systems can provide mechanisms for adding or releasing resources.

This is related to elasticity.

NIST identifies rapid elasticity as one of the essential characteristics of cloud computing.

Conceptually:

LOW DEMAND
   ↓
FEWER RESOURCES

HIGH DEMAND
   ↓
MORE RESOURCES

But do not confuse:

scaling capability

with:

automatic perfect scaling.

You still have to design the application and configure the platform appropriately.

19. Scaling Can Be Vertical or Horizontal

Suppose your application needs more computing capacity.

You could make one machine larger:

SMALL SERVER
     ↓
LARGER SERVER

This is vertical scaling.

Or you can add more instances:

SERVER
SERVER
SERVER
SERVER

This is horizontal scaling.

Cloud platforms can support both approaches depending on the service.

Horizontal scaling introduces another problem:

How do multiple application instances share state?

Now you encounter concepts such as:

  • load balancing;
  • stateless application design;
  • shared storage;
  • distributed databases;
  • caching;
  • queues;
  • sessions.

This is where cloud architecture begins connecting directly to distributed systems.

20. Statelessness Becomes Valuable

Imagine a web application running on three instances:

Instance A
Instance B
Instance C

A user makes one request.

It reaches A.

The next request reaches C.

If the user's important state exists only in A's local memory, C may not know what happened.

A more scalable architecture moves shared state into appropriate external systems.

For example:

INSTANCE A ─┐
INSTANCE B ─┼──→ SHARED DATA SERVICE
INSTANCE C ─┘

This is one reason cloud-native applications often emphasize stateless application components.

The NIST cloud definition itself notes characteristics of cloud software such as service orientation, statelessness and low coupling in its explanatory material.

21. Low Coupling Makes Systems Easier to Change

Suppose your application has one enormous component responsible for:

Users
Payments
Email
Images
Orders
Reports

Changing one part can affect everything.

Instead, you might separate responsibilities:

USER SERVICE
PAYMENT SERVICE
IMAGE SERVICE
ORDER SERVICE
REPORTING SERVICE

These components communicate through defined interfaces.

This can improve flexibility.

But distributed systems also introduce new problems:

  • network failures;
  • latency;
  • service discovery;
  • authentication;
  • observability;
  • consistency;
  • retries.

Again, the cloud has not eliminated complexity.

It has enabled a different way of organizing it.

22. Cloud Storage Is Another Useful Example

When people say:

"Store this file in the cloud."

they may be referring to an object-storage service.

Instead of thinking about a traditional disk attached to a server, you work with objects such as:

bucket
 ├── image.jpg
 ├── document.pdf
 └── video.mp4

The application interacts with a service through an API.

This changes how software is designed.

The application can treat storage as a service rather than needing to know which physical disk contains the file.

Again:

APPLICATION
      ↓
STORAGE API
      ↓
CLOUD STORAGE SYSTEM
      ↓
PHYSICAL STORAGE

The physical complexity is hidden behind an interface.

23. APIs Are the Language of Cloud Services

Cloud services become particularly powerful when they can be controlled programmatically.

Instead of manually clicking through a dashboard, software can make API requests.

For example, conceptually:

APPLICATION
    ↓
API REQUEST
    ↓
CLOUD SERVICE
    ↓
RESOURCE CREATED / UPDATED

This means infrastructure can become programmable.

A script can create resources.

A deployment system can update an application.

An automation system can respond to events.

An AI-assisted development workflow can call services.

Cloud therefore connects naturally with:

  • APIs;
  • automation;
  • infrastructure as code;
  • DevOps;
  • CI/CD;
  • monitoring;
  • platform engineering.

24. The Dashboard Is Not the Cloud

This is another important distinction.

A cloud dashboard is an interface for controlling cloud resources.

The dashboard is not the underlying system.

The same resource may often be controlled through:

Web console
CLI
API
Infrastructure-as-code tool
Automation system

Conceptually:

                 ┌── WEB CONSOLE
                 │
                 ├── CLI
APPLICATION ─────┼── API
                 │
                 └── AUTOMATION
                        ↓
                  CLOUD RESOURCE

This is why learning cloud computing should not stop at:

"Click this button in the console."

The deeper skill is understanding what resource the button creates and how that resource can be controlled programmatically.

25. Infrastructure Can Become Code

Suppose you need:

Network
Database
Storage
Application
Permissions

You could configure them manually.

Or you can describe them using an infrastructure-as-code system.

Conceptually:

CONFIGURATION
      ↓
INFRASTRUCTURE TOOL
      ↓
CLOUD API
      ↓
RESOURCES

Now your infrastructure can be:

  • versioned;
  • reviewed;
  • reproduced;
  • tested;
  • automated.

This is one of the major steps from manually managed computing toward modern cloud engineering.

26. What Are You Actually Paying For?

Cloud pricing can also be understood through the abstraction model.

You are generally not paying for an abstract "cloud."

You are paying for resources or service usage.

Depending on the service, billing may relate to things such as:

  • compute;
  • storage;
  • data transfer;
  • requests;
  • database capacity;
  • active users;
  • execution;
  • provisioned resources.

This is connected to NIST's measured service characteristic: cloud systems can meter resource use at an appropriate level of abstraction.

This creates a new engineering responsibility:

Your architecture can influence your bill.

A poorly designed system can therefore be both technically inefficient and economically inefficient.

27. Cloud Architecture Is Also Economic Architecture

Imagine two designs.

Design A

One always-running server handles everything.

Design B

Several managed services scale according to demand.

Neither is automatically cheaper.

Design B may reduce operational work but introduce per-request charges and multiple service costs.

Design A may be simple and predictable but require more administration and may waste capacity during quiet periods.

So architecture involves multiple dimensions:

PERFORMANCE
SECURITY
RELIABILITY
MAINTENANCE
SCALABILITY
CONTROL
COST

A good cloud engineer does not optimize only one.

28. The Question of Lock-In

There is another tradeoff.

Suppose you build your entire application around proprietary cloud services.

You may gain powerful capabilities.

But moving to another provider can become difficult.

This is commonly called vendor lock-in.

For example:

Application
   ↓
Provider-specific APIs
   ↓
Provider-specific database
   ↓
Provider-specific functions
   ↓
Provider-specific identity

Moving everything elsewhere may require substantial changes.

That does not mean proprietary services are bad.

Sometimes the productivity and capabilities they provide are worth the dependency.

But the dependency should be a conscious architectural decision.

29. Portability Is a Design Choice

You can deliberately use more portable technologies:

Standard database
Containerized application
Open protocols
Portable infrastructure

Or you can deliberately use provider-specific services:

Managed database
Serverless platform
Provider identity
Provider AI service
Provider event system

The choice depends on the project.

A small application may benefit enormously from managed services.

A large organization may have strong reasons to prioritize portability.

There is no universal answer.

The important skill is understanding the tradeoff before committing.

30. Reliability Changes Too

When you operate your own server, you may have one machine.

If it fails:

SERVER DOWN

Cloud architecture can introduce redundancy:

INSTANCE A
INSTANCE B
INSTANCE C

If one fails, traffic can potentially continue through others.

But redundancy must be designed.

A cloud provider cannot automatically make a poorly designed application highly available.

For example:

Three web servers
       ↓
One database
       ↓
Database fails
       ↓
Whole application affected

You have increased redundancy at one layer while leaving a single point of failure at another.

Cloud architecture therefore requires systems thinking across the whole stack.

31. Cloud Does Not Remove the Need for Backups

A cloud service may provide replication, snapshots or backup features.

But:

REPLICATION ≠ BACKUP

A replicated database can faithfully replicate an accidental deletion.

A highly available system can remain highly available while serving incorrect data.

Backups serve a different purpose.

You need to understand:

  • what is being backed up;
  • how frequently;
  • where backups are stored;
  • how long they are retained;
  • who can access them;
  • how restoration works;
  • whether restoration has actually been tested.

Cloud makes these capabilities easier to obtain.

It does not make them unnecessary.

32. Security Follows the Same Logic

Moving an application to the cloud does not magically make it secure.

You still need to think about:

IDENTITY
ACCESS CONTROL
SECRETS
NETWORKING
APPLICATION SECURITY
DATA PROTECTION
LOGGING
MONITORING
BACKUPS
CONFIGURATION

The provider protects infrastructure it operates.

You remain responsible for the components you control.

The exact boundary depends on the service model.

So before deploying anything, ask:

What does the provider secure?

Then:

What do I have to secure?

Then:

Which settings could accidentally expose my resources?

That is the beginning of cloud security thinking.

33. A Practical Experiment: Compare Three Ways to Host an Application

Suppose you have a simple web application.

Imagine three approaches.

Approach 1 — Virtual Machine

Cloud VM
 ├── Operating system
 ├── Runtime
 ├── Application
 └── Configuration

You manage much of the software stack.

Approach 2 — Platform Service

Cloud platform
 └── Your application

The provider manages more of the operating environment.

Approach 3 — Serverless

Event / Request
      ↓
Function
      ↓
Result

You focus primarily on application logic and configuration.

Now ask:

Question VM Platform Serverless
OS management More Less Provider
Infrastructure control High Medium Lower
Operational burden Higher Lower Often lower
Portability Often higher Varies Often lower
Scaling model You configure more Platform-assisted Service-managed
Control High Medium Lower
Best fit Custom environments Application deployment Event-driven workloads

These are broad patterns, not universal rules.

The important lesson is that the service model determines what you operate.

34. Learn to Ask "Who Owns This Layer?"

Whenever you encounter a cloud service, ask:

Who owns the physical server?
Who manages the operating system?
Who patches the runtime?
Who controls the network?
Who manages the database engine?
Who protects the application?
Who controls the data?
Who manages the identities?
Who configures access?
Who pays for usage?

The answers reveal the actual architecture.

This is a far better way to understand cloud products than memorizing product names.

35. The Cloud Is Really About Delegation

At the deepest level, cloud computing is about delegating infrastructure work through standardized services.

You can delegate:

Physical infrastructure
      ↓
Virtual infrastructure
      ↓
Operating systems
      ↓
Runtime environments
      ↓
Databases
      ↓
Application infrastructure
      ↓
Entire applications

But every delegation has consequences.

You gain:

  • speed;
  • convenience;
  • operational leverage;
  • scalability;
  • access to specialized infrastructure.

You may surrender:

  • control;
  • portability;
  • visibility into lower layers;
  • some architectural freedom.

And you acquire new responsibilities:

  • service selection;
  • configuration;
  • identity;
  • cost management;
  • integration;
  • monitoring;
  • vendor management.

The cloud therefore changes the nature of the engineering job.

36. From Server Administrator to System Architect

In a traditional environment, a large part of the work might involve maintaining machines.

In a modern cloud environment, more of the work can move toward:

Choose the right service
        ↓
Design the architecture
        ↓
Connect services
        ↓
Configure security
        ↓
Automate deployment
        ↓
Monitor behavior
        ↓
Control cost
        ↓
Improve reliability

This is not necessarily "less technical."

It is technical at a different level.

You still need to understand the lower layers because higher-level decisions depend on them.

37. Your Cloud Mental Model

When someone says:

"It's in the cloud."

translate that into a more useful question:

"Which computing layer has been turned into a service, and which layers am I still responsible for?"

Then draw the stack.

YOUR APPLICATION
       ↓
YOUR DATA
       ↓
RUNTIME
       ↓
OPERATING SYSTEM
       ↓
VIRTUAL MACHINE
       ↓
PHYSICAL SERVER
       ↓
DATACENTER

Now mark the boundary.

With IaaS:

YOU
────────────
Application
OS
VM configuration

PROVIDER
────────────
Physical infrastructure

With PaaS:

YOU
────────────
Application
Configuration
Data

PROVIDER
────────────
Platform
OS
Infrastructure

With SaaS:

YOU
────────────
Use the software
Configure your account/data

PROVIDER
────────────
Application
Platform
OS
Infrastructure

With serverless:

YOU
────────────
Function code
Configuration
Data

PROVIDER
────────────
Execution environment
Scaling infrastructure
OS
Physical infrastructure

The exact boundary varies by product, but the model is what matters.

38. The Real Skill Is Choosing the Right Abstraction

The goal of cloud computing is not to eliminate servers from your thinking.

It is to stop making every project solve the same infrastructure problems from scratch.

If you need complete control over the operating system, IaaS may make sense.

If you mainly need to deploy an application, PaaS may be more appropriate.

If you need a database but do not want to operate database infrastructure, a managed database may be appropriate.

If you need code to run in response to events, serverless may be useful.

If you simply need a finished business application, SaaS may be the correct level.

The best architecture is therefore often the one that gives you enough control to solve the problem without forcing you to operate infrastructure that does not create value for your particular application.

That is the central cloud lesson.

The Mental Model to Keep

Do not remember cloud computing as a collection of fashionable terms.

Remember the stack:

PHYSICAL HARDWARE
       ↓
VIRTUAL INFRASTRUCTURE
       ↓
OPERATING SYSTEM
       ↓
RUNTIME / PLATFORM
       ↓
MANAGED SERVICES
       ↓
APPLICATION
       ↓
USER

Then remember what cloud changes:

MORE PROVIDER RESPONSIBILITY
             ↑
            SaaS
             ↑
      Serverless / Managed
             ↑
            PaaS
             ↑
            IaaS
             ↑
MORE CUSTOMER CONTROL

And remember the question that matters most:

What am I actually responsible for?

Once you can answer that, the cloud stops being a mysterious place where "servers live."

You can see it for what it really is:

a way of consuming computing capabilities through layers of abstraction, while deliberately deciding how much infrastructure you want to control and how much you want someone else to operate. 


Image: eG Innovations

at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)