Managed services, serverless computing, and object storage

Renting a virtual machine removes the need to purchase and maintain the physical computer, but it still gives the customer a computer to operate.

If the coffee company rents a VM and installs PostgreSQL on it, its engineers may still need to install the database, configure it, apply operating-system and database updates, and monitor memory and storage. They may also need to configure backups, replace unhealthy machines, respond to failures, and plan for additional capacity.

The cloud provider operates the physical data center and hardware, but the customer still operates much of the software environment running inside the VM.

Cloud providers eventually recognized that customers might want to rent the operational work as well as the machine. This led to managed services.

Self-managed versus managed

Infrastructure can be placed on a spectrum from self-managed to fully managed.

With a self-managed serviceConcept · lights on your mapself-managed serviceA system where the customer installs, patches, monitors, backs up, and recovers it themselves. More control than a managed service, and every bit of that control is also a responsibility., the customer controls and operates more of the technology stack.

With a managed serviceConcept · lights on your mapmanaged serviceA system where the provider takes over more of the setup, maintenance, scaling, and recovery, for a premium and with less control than self-managing it. Build-versus-buy, applied to operations., the provider takes responsibility for more of the setup, maintenance, scaling, and failure recovery.

The tradeoff is: more control usually creates more operational responsibility. More management usually reduces operational work but also reduces some control.

This is the build-versus-buy decision applied to infrastructure operations.

A self-managed database

Suppose the coffee company wants to use PostgreSQL. One option is to rent a virtual machine and install PostgreSQL itself.

The stack might look like:

The provider manages the physical infrastructure and virtualization layer.

The coffee company manages the operating system, the PostgreSQL installation, database updates, and storage capacity. It also manages backups, monitoring, replication, failover, security configuration, and recovery procedures.

This provides substantial control. The company can choose specific versions, extensions, configurations, and operating-system settings, but that control creates work because someone must be responsible when the database becomes unhealthy at 3:00 AM.

A managed database

Instead of installing PostgreSQL on a VM, the company can use a managed database service, asking the provider for something resembling: create a PostgreSQL database with this amount of processing power and storage.

The provider may handle much of the underlying work, including provisioning the machines, installing the database software, replacing failed hardware, and applying certain patches. It may also monitor foundational infrastructure, create configured backups, support replication or failover, and increase storage capacity.

The customer connects to the database and uses it without directly operating every underlying machine.

A managed-database stack might look like:

The machine has not disappeared. Instead, the provider has hidden more of its operation behind a service interface.

Managed does not mean responsibility-free

A managed database reduces operational work, but the customer still has important responsibilities.

The coffee company may still need to manage:

• Tables and schemas
• Primary and foreign keys
• Indexes
• Query performance
• Database users
• Access permissions
• Data validation
• Migrations
• Retention rules
• Privacy obligations
• Backup configuration
• Restore testing
• Cost
• Application behavior

The provider might create automated backups, but the customer must decide whether the backup schedule and retention period satisfy its recovery objectives.

A database can be technically healthy while the customer runs a dangerous migration or writes an inefficient query.

A useful principle is: a managed service transfers some operational responsibility. It does not transfer ownership of the product’s data and decisions.

Database as a Service

A managed database may be described as Database as a Service, or DBaaS.

The customer receives a database through an interface, without manually constructing the complete environment.

Examples include services offering managed versions of PostgreSQL, MySQL, and SQL Server, as well as document databases, key-value databases, and data warehouses.

On AWS, one widely recognized managed relational-database service is Amazon RDS, which stands for Relational Database Service.

A company might run PostgreSQL through RDS, or it might install PostgreSQL directly on an EC2 instance.

EC2 with PostgreSQL installed by the customer is more self-managed; managed PostgreSQL through RDS is more provider-managed.

The database technology may be similar, but the division of operational responsibility changes.

The managed-services spectrum

Managed services are not an on-or-off switch.

Different services hide different amounts of infrastructure.

A simplified spectrum might look like:

At the start of the chain, the customer manages most of the stack. By the last step, it interacts mainly with a finished capability.

Each step toward the managed end usually trades away some direct control over the underlying environment.

What is serverless computing?

At the highly managed end of the spectrum is serverless computingConcept · lights on your mapserverlessComputing where the customer provides code and configuration and the provider runs it. No servers to provision or maintain (they exist; you never meet them). Billed per execution, scaled per event; AWS’s version is Lambda. Also called Function as a Service (FaaS)..

The name is misleading. Servers still exist, and code must still run on physical processors inside data centers.

“Serverless” means that the customer does not provision, maintain, or directly manage the servers running the workload. The customer provides code and configuration, and the provider decides where and how to run it.

A useful mental model is: with a VM, you rent a computer. With serverless, you ask the provider to run a piece of work.

What is a serverless function?

A common serverless model allows developers to upload a function.

A function might perform one focused task:

The provider runs the function when a configured event occurs.

For example: new order created → run receipt function → send confirmation

The customer does not select a permanent machine and manually keep it running.

The provider handles much of the compute provisioning, execution environment, scaling, machine replacement, foundational monitoring, and capacity allocation.

This model is often called Function as a Service, or FaaS.

AWS Lambda

AWS Lambda is Amazon’s widely recognized serverless function service. A team can upload function code and configure Lambda to run it when something happens. Possible triggers include:

• An HTTP request
• A file upload
• A scheduled time
• A message arriving in a queue
• A database event
• Another cloud service event

When engineers say “we could make this a Lambda,” they usually mean that the job may fit a small, event-triggered function, with no need for a permanently managed server. Examples might include resizing a photo after upload, processing a webhook, generating a report every night, sending an order notification, cleaning up temporary files, or transforming an incoming data record.

Paying per execution

Traditional virtual machines are often billed while they are allocated or running, even if they are waiting for work.

Serverless functions are commonly billed according to factors such as the number of executions, execution duration, memory allocated, and processing capacity used.

If a function runs only a few times per day, the company may pay for only those executions without keeping a VM active all day.

This can be attractive for infrequent jobs, unpredictable traffic, small event-driven tasks, and short-lived processing.

However, pricing depends on the workload.

A continuously busy serverless function may not always be less expensive than a long-running service.

Serverless scaling

Suppose one customer uploads a photo. The provider may run one copy of the processing function, but if thousands of customers upload photos at once, it may run many copies in parallel.

The simplified model is:

• Few events → few function executions
• Many events → many function executions

The provider handles much of this scaling automatically.

But automatic scaling does not eliminate every limit. The system may still face account concurrency limits, database connection limits, third-party API rate limits, high costs, or downstream services that cannot scale as quickly.

One serverless component can scale rapidly enough to overwhelm the database or service behind it.

Serverless functions are often stateless

A serverless function should generally not assume that the same execution environment will remain available for the next request because the provider may reuse an environment temporarily but may also replace it at any time.

That means important state should be stored in an external persistent system such as a database, object storage, a cache, or a queue.

This follows the pets-versus-cattle principle from the previous lesson.

The execution environment is replaceable, so important data needs a persistent home.

Cold starts

If no ready execution environment exists, the provider may need to prepare one before running the function, a startup delay commonly called a cold start.

A later execution may reuse an already prepared environment and start more quickly. This is sometimes called a warm execution.

Cold-start delays may be unnoticeable for background jobs but more important for latency-sensitive customer requests, and the exact behavior depends on the provider, language, configuration, and traffic pattern.

You only need to recognize the tradeoff: serverless reduces machine management, but the platform’s execution model can affect performance.

Serverless limitations

Serverless functions are useful, but they are not the best model for every workload. They may have limits involving maximum execution time, available memory, temporary storage, supported runtimes, and startup latency. Network connections, deployment package size, long-running background processes, and specialized operating-system access may be limited as well.

A continuously running application, low-latency service, or highly customized system may fit better on containers or virtual machines.

“Just make it a Lambda” is an architectural suggestion, not a universal solution.

What is object storage?

One managed cloud service is important enough to introduce immediately: object storageConcept · lights on your mapobject storageA managed service storing data as named objects inside buckets (photos, videos, PDFs, backups, logs), retrieved by key through an API. Highly scalable and durable; AWS’s S3 is so standard the name is nearly generic. Files on the shelf; structured records in the database..

In Module 7, you learned that structured records such as customers and orders commonly live in databases. But products also need to store photos, videos, PDFs, audio files, backups, data exports, logs, and large datasets.

These items are often stored in object storage.

Objects, buckets, and keys

Object storage organizes information as objects.

An object usually contains the data itself, a name or identifier, and metadata describing it.

For example, a profile photo might be stored as an object containing:

Objects are commonly grouped inside containers called buckets.

A simplified structure might look like:

The key is the object’s name within the bucket.

Applications use the bucket and key to store or retrieve the object.

Object storage versus a file system

Object storage is not exactly the same as the folders on a laptop. A file system presents files inside directories and allows applications to modify parts of files through ordinary file operations.

Object storage usually treats each object as one unit retrieved or replaced through an API, and a key such as profiles/customer-88/photo.jpg looks like a folder path, but the “folders” may be part of the object’s name, not traditional physical directories.

This design helps object storage scale across large distributed systems.

Amazon S3

Amazon Simple Storage Service, commonly called Amazon S3, is AWS’s widely used object-storage service, and applications use S3 to store objects inside buckets and retrieve them using APIs.

S3 stands for: Simple Storage Service

When engineers say “put the file in S3,” they generally mean: store this file as an object in an S3 bucket.

Because S3 is so widely recognized, people sometimes use the phrase informally when discussing object storage more generally. However, S3 is a specific AWS service.

Other cloud providers and storage companies offer their own object-storage systems.

Why object storage is useful

Object storage is designed to support very large collections of files without requiring the customer to manage individual storage disks. It can provide:

• High scalability
• Strong durability
• Simple API access
• Metadata
• Access-control features
• Encryption options
• Versioning
• Lifecycle and retention rules
• Integration with other cloud services

The customer does not need to decide which physical disk stores each photo. The provider distributes and protects the objects across its underlying infrastructure.

This is another abstraction: the customer asks for an object by name. The provider manages where the bytes physically live.

Durability versus availability

Cloud storage descriptions often emphasize durability.

Durability asks: how unlikely is it that the stored data will be permanently lost?

Providers may preserve several copies or use other redundancy techniques to reduce the chance that one hardware failure destroys an object.

Availability asks a different question: can the application access the object right now?

An object can be highly durable but temporarily unavailable because of a service or network problem. The distinction is:

• Durability: Will the data continue to exist?
• Availability: Can the system retrieve it at this moment?

Both matter, but they are not the same guarantee.

Object storage access control

Objects should not automatically be public.

A customer’s private profile photo, tax document, or backup must be protected with access rules. The company may configure:

• Which users or services can upload objects
• Which users or services can retrieve them
• Whether an object is publicly accessible
• Whether access expires
• Whether encryption is required
• Whether actions are logged

A common security mistake is accidentally making a storage bucket or object public. The provider supplies access-control tools, but the customer must configure and use them correctly.

This is another example of shared responsibility.

Temporary access

Sometimes a private object needs to be shared for a limited period. The coffee app may need to let Erik view a private receipt PDF.

The backend can create a temporary signed link granting access to that specific object for a limited time.

The object remains private generally, but the link authorizes one controlled retrieval, allowing the application to deliver files without making the entire storage location public.

Object-storage pricing

Object storage may charge for the amount of data stored, the number of read requests and the number of write requests, data transferred out, storage tier, retrieval speed, and geographic replication.

A large archive that is rarely accessed may use a cheaper storage tier with slower retrieval.

Frequently viewed images may use a faster tier and be combined with a content delivery network.

As with compute, the customer is paying for a service measured across several resource dimensions.

Database or object storage?

A useful beginner rule is: relational records often belong in a database. Large files often belong in object storage.

For example, the coffee application might store this in the database:

The actual image bytes live in object storage.

The database stores the structured metadata and relationship. Photo 501 belongs to customer 88, and its object-storage key is profiles/customer-88/photo.jpg.

This allows the system to use both tools for what they do well.

The boundary is not absolute

Databases can technically store binary files, and object storage can hold structured JSON, CSV, and analytical table files, so the correct choice depends on how the data is used. Teams may ask:

• Does the application need relational queries?
• Does the data need transactions?
• Is it usually retrieved as one complete file?
• How large is each item?
• How often is it updated?
• How should access be controlled?
• How much does storage cost?
• How long must the data remain?

“Structured data goes in databases and files go in object storage” is a useful first model, but real systems may combine the technologies in more nuanced ways.

IaaS, PaaS, and SaaS

The technology industry commonly describes cloud services using three broad labels, a responsibility ladder where each step trades control for reduced operational work. The labels are Infrastructure as a Service, Platform as a Service, and Software as a Service.

These categories describe how much of the technology stack the provider operates.

Infrastructure as a Service

Infrastructure as a ServiceConcept · lights on your mapIaaSInfrastructure as a Service, renting foundational resources such as virtual machines, storage, and networking. An EC2 instance is the classic example. The lowest rung: most control, most operational work., or IaaS, provides foundational resources such as virtual machines, storage, and networking.

The provider manages the physical infrastructure and virtualization.

The customer manages more of the operating system and application environment.

An EC2 virtual machine is a common IaaS example. In this model the provider is responsible for the building, the hardware, and the virtualization, while the customer is responsible for the operating system, software, application, and data.

IaaS provides flexibility and control but leaves the customer with more operational responsibility.

Platform as a Service

Platform as a ServiceConcept · lights on your mapPaaSPlatform as a Service. The provider runs your application on a managed platform, so you supply code rather than servers. The middle rung between IaaS and SaaS; serverless functions sit near it., or PaaS, provides a managed environment in which customers deploy applications without operating as much of the underlying infrastructure.

The customer provides code and configuration.

The provider manages the operating systems, application runtimes, scaling, deployments, foundational monitoring, and machine replacement, though the exact coverage varies from one platform to another.

A traditional PaaS lets the customer say: run this web application.

The customer does not directly choose and maintain every server, and PaaS reduces infrastructure management but may limit supported languages, configurations, and system access.

Function as a Service

Serverless functions such as AWS Lambda are commonly described as Function as a Service, or FaaS.

FaaS is closely related to PaaS but focuses on individual event-triggered functions, not complete long-running applications.

A simplified comparison is:

• IaaS: Give me a machine.
• PaaS: Run my application.
• FaaS: Run this function when an event occurs.

These boundaries are not perfectly sharp. Modern cloud services frequently combine characteristics from several categories.

Software as a Service

Software as a ServiceConcept · lights on your mapSaaSSoftware as a Service, a finished product you simply log into, like Gmail or Slack. The top rung: least operational work, least control, and you write no code at all., or SaaS, provides a finished software product that users access through a browser, mobile app, API, or other client.

Examples include Gmail, Slack, Salesforce, Notion, and Zoom.

The user does not operate the underlying servers, runtime, or application code.

Instead, they primarily configure and use the finished product. The model is:

• Provider: infrastructure → platform → application
• Customer: accounts → settings → usage → data entered into the product

The customer still has responsibilities involving permissions, data governance, and correct configuration, but it is not building the software platform itself.

The responsibility ladder

The categories can be viewed as a responsibility ladder:

With on-premises infrastructure, the organization manages nearly the entire stack.

With IaaS, the provider manages the facilities and physical infrastructure.

With PaaS, the provider also manages more of the runtime environment.

With FaaS, the customer provides focused functions while the provider manages execution.

With SaaS, the customer uses a finished application.

Each step toward SaaS reduces some operational burden but may increase vendor dependency, product constraints, switching difficulty, provider-specific behavior, and ongoing service fees.

There is no universally correct location on the spectrum.

Build versus buy, applied to operations

The managed-services decision asks: which layers should our engineers operate themselves? A company may self-manage when it needs specialized configurations, maximum control, unique performance characteristics, particular security requirements, lower costs at sufficient scale, or technology unavailable as a managed service.

It may choose a managed service when it values faster setup, reduced operational work, automated maintenance, built-in scaling, provider expertise, faster recovery, and more engineering focus on the product.

The premium paid for a managed service is partly payment for the provider’s operational labor, automation, and expertise.

The company is renting responsibility, not merely the software.

Managed queues and messaging

Cloud providers also offer managed versions of infrastructure concepts you will study in the next module.

Two AWS names worth recognizing are Amazon SQS and Amazon SNS.

SQS, or Simple Queue Service, is a managed message queue. A queue allows one system to leave work for another system to process later.

SNS, or Simple Notification Service, supports publish-and-subscribe communication. One system publishes a message, and several interested systems may receive it.

You do not need to understand their architecture yet.

For now, recognize them as examples of the same pattern: the cloud provider operates the infrastructure, while the customer uses the capability through an API.

Queues and publish-subscribe systems become central in Module 9.

Seeing the coffee application across the spectrum

The coffee company might combine several service models.

Its architecture could include:

• EC2 virtual machines — IaaS compute for the main backend
• Managed PostgreSQL — Database as a Service
• AWS Lambda — serverless functions for photo processing
• S3 — object storage for images and receipts
• SQS — managed queue for background jobs
• Gmail or another business application — SaaS used by employees

One company can use self-managed and managed services together, and the correct choice may differ for each component.

The payment system may require tightly controlled infrastructure, photo resizing may fit a serverless function, customer images may fit object storage, and employee email may be purchased as SaaS.

Cloud architecture is not one decision but a series of decisions about which responsibilities the company should retain and which it should rent.

The mental model to remember

A self-managed service leaves more installation, maintenance, scaling, and recovery work to the customer.

A managed service transfers more of that operational work to the provider.

A managed database reduces infrastructure management, but the customer still owns its schema, queries, permissions, data, and product behavior.

Serverless computing allows customers to run code without directly provisioning or maintaining servers.

Function as a Service, or FaaS, runs event-triggered functions such as those deployed through AWS Lambda.

Object storage stores files and other data as named objects inside buckets.

Amazon S3 is AWS’s widely used object-storage service.

Durability describes whether stored data survives. Availability describes whether it can currently be accessed.

IaaS provides foundational infrastructure.

PaaS provides a managed application platform.

FaaS provides managed function execution.

SaaS provides a finished software product.

The farther the customer moves toward managed services, the more operational responsibility the provider assumes — and the more the customer depends on the provider’s interface, limitations, pricing, and reliability.

You should now understand that cloud computing is not only the rental of machines. It is also the rental of operational capabilities, from managed databases and storage systems to functions and finished software.

The cloud’s first abstraction turned physical machines into virtual machines.

Its second abstraction made the machines increasingly disappear.