Skip to main content
What is Serverless Computing?
  1. Glossary/

What is Serverless Computing?

6 mins·
Ben Schmidt
Author
I am going to help you build the impossible.

You have likely heard the term thrown around in technical meetings or pitch decks. Serverless computing. It sounds impossible at first glance. How can computing happen without a server? The reality is that there are still servers involved. The term does not mean the absence of hardware. It refers to the removal of that hardware from your list of responsibilities.

In a traditional setup, you provision a server or a virtual machine. You install an operating system. You manage updates. You worry about security patches. You pay for that server whether your application is serving one customer or one million. It is a fixed piece of inventory that requires maintenance.

Serverless computing flips this model. It is a cloud computing execution model where the cloud provider runs the server and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application rather than on pre-purchased units of capacity. It is the ultimate utility model for code execution.

For a founder, this distinction is not just technical. It is financial and operational.

The Mechanics of Serverless

#

To understand if this is right for your business, you need to understand how it functions under the hood. In a serverless architecture, you write code in the form of functions. These are small, single-purpose pieces of code.

This is often referred to as Function as a Service or FaaS. You upload these functions to a cloud provider like AWS, Google Cloud, or Azure. The code sits dormant until an event triggers it.

An event could be:

  • A user visiting a specific URL on your website
  • An image being uploaded to a database
  • A scheduled time of day
  • A payment transaction being processed

When the event occurs, the cloud provider spins up a container, executes your code, returns the result, and then destroys the container. You are billed only for the milliseconds that your code was running.

If no one uses your product between 2:00 AM and 6:00 AM, your cost for compute during that time is zero. This is a radical departure from paying for a server to sit idle in a data center just in case a user shows up.

Comparing Serverless to Traditional Infrastructure

#

It helps to compare this against the other common options available to early-stage companies. The two main alternatives are Virtual Machines (VMs) and Container Orchestration (like Kubernetes).

Think of a Virtual Machine like renting a house. It is yours. You have to clean it. You have to secure the windows. If the heater breaks, you have to call someone to fix it. You have full control, but you also have full liability. If you need more space, you have to rent a second house.

Container Orchestration is like managing a large apartment complex. You have systems in place to manage many units (containers), but you are still the building manager. You decide how many units are available and you are responsible for the overall structure.

Serverless is like a hotel. You show up, you stay for a night, and you leave. You do not care who changes the sheets or fixes the plumbing. You only pay for the nights you are in the room. If you need ten rooms for one night, the hotel provides them. If you need zero rooms the next night, you pay nothing.

For a startup with limited engineering resources, moving from home ownership to a hotel stay can free up massive amounts of time. Your team stops being system administrators and starts focusing entirely on product logic.

Focus on code not infrastructure.
Focus on code not infrastructure.

Strategic Advantages for Startups

#

The primary advantage is speed to market. When you remove the need to configure load balancers, install operating systems, and manage clusters, you can ship features faster. In the early days of a company, velocity is the only advantage you have over incumbents.

Scalability is the second major factor. In a traditional setup, a sudden viral moment can crash your servers. You have to manually add more capacity, often too late. With serverless, the cloud provider automatically allocates more resources as traffic spikes. It handles the load of ten users and ten thousand users with the same architectural logic.

Cost efficiency is the third factor, though this comes with a caveat. For sporadic traffic, which is common in new products, serverless is almost always cheaper. You avoid paying for idle capacity. However, at a certain scale with predictable heavy loads, serverless can actually become more expensive than owning reserved instances. This is a calculation you must monitor as you grow.

The Trade-offs and Unknowns

#

Every architectural decision has a cost. It is important to look at this scientifically rather than viewing serverless as a magic bullet. There are constraints you must be aware of.

The most cited issue is the cold start. Because your code sits dormant until an event triggers it, there is a slight delay the first time a function is called after a period of inactivity. The cloud provider has to spin up the environment. This might add a few hundred milliseconds of latency. For real-time high-frequency trading, this is a dealbreaker. For a standard web app, it is usually negligible.

Vendor lock-in is another consideration. Writing code for AWS Lambda is slightly different than writing for Google Cloud Functions. The logic is the same, but the triggers and integrations are proprietary. Moving a serverless application from one cloud to another is significantly harder than moving a standard Docker container.

Debugging can also be more complex. You cannot SSH into a server to look at logs because there is no server to SSH into. You are reliant on the logging and monitoring tools provided by the vendor. This requires a shift in how your developers approach troubleshooting.

When to Use Serverless

#

Based on these factors, when should a founder push for a serverless approach?

It is ideal for:

  • Building a Minimum Viable Product (MVP) where speed and low cost are paramount
  • Applications with spiky or unpredictable traffic patterns
  • Data processing tasks like resizing images or processing files
  • Scheduled tasks and cron jobs
  • APIs that serve mobile or web applications

You might want to pause and reconsider if:

  • You have long-running processes that take minutes or hours to complete
  • You require ultra-low latency with zero variance
  • Your workload is constant and predictable at a high volume

As you build your company, you have to ask yourself where your value lies. Does your value come from managing infrastructure better than Amazon or Google? Or does your value come from the unique business logic you provide to your customers?

Serverless allows you to outsource the former to focus on the latter. It is not perfect for every scenario, but for a startup trying to find product-market fit without burning cash on idle servers, it is a powerful tool in the arsenal.