What is Serverless?

Summary of technological concepts & key points (serverless + IBM Cloud framing)

What “serverless” means (not literally no servers)

• The cloud provider abstracts away server management and provisioning.
• Developers focus on writing code/business logic rather than operating infrastructure.

Evolution of deployment models (logic ↑, stack control ↓)

1. Bare metal: You manage OS installation, patching, environment setup—time-consuming.
2. Virtual machines: Improved resource use vs bare metal, but you still handle OS/environment and patching.
3. Containers (Docker): Package application code + dependencies into a container that can run across infrastructure.
   • Easier deployment, but scaling/container management can become challenging.
   • Still involves compute being “on” (some idle time).
4. Serverless (current focus): Greater abstraction from underlying infrastructure; primarily write business logic.

How serverless works (Functions as a Service)

• Most major cloud providers offer Functions as a Service (FaaS).
• A function is a single unit of deployment (e.g., file processing).
• Functions run in response to events (e.g., a user action like clicking submit triggers an event that invokes the function).

Serverless commonly uses an event-driven architecture:

• Other cloud services (e.g., databases, IoT, etc.) emit events.
• Your application logic reacts to those events.

Example scenario (image processing)

• A user uploads an image and submits → creates an event.
• The event invokes a function to resize the image and store it in storage.
• This illustrates event-to-function invocation and a typical serverless workflow.

Drawbacks / limitations

• Timeouts: Functions are stateless, spin up briefly, and are deleted after execution; if work doesn’t finish in time, the app fails.
• Latency: Can be an issue depending on how time-sensitive the application is.

Benefits (claimed advantages)

• Pay for execution only: No cost for idle capacity; functions are often described as running on the order of ~100 ms.
• Auto-scaling by the provider: Less need to provision resources yourself.
• Faster time to market: Reduced infrastructure management speeds development.
• Polyglot support: Ability to use multiple languages/frameworks supported by the platform.
• High availability: Provider handles fault tolerance and multi–zone regions (MZRs); event-driven services are also fault tolerant, aiming for overall high availability.

Main speaker / source

• Ashher Syed (IBM Cloud team)